Параллельное ПЗУ разнообразной емкости и разрядности данных, аналогичный регистр-защелка по данным,
обратная связь выхода регистра на адресные входы ПЗУ.
Входные сигналы - также на адресные входы ПЗУ.
Автомат однако.
Декодер манчестерского кода был сделан по такой схеме.

Да, наверное такой случай можно придумать и вообще в порыве энтузиазма притянуть еще пару случаев. Но в общем довольно НЕЧИТАЕМО на самом деле. Причина в том, что под читаемость попадает и привычность стиля. Для меня еще огромный недостаток, что при работе/отладке в реальных условиях, а не на столе под отладчиком, нет ЕСТЕСТВЕННОГО наглядного вывода развития событий автомата и истории вылета автомата.


МОНОЛИТНЫЕ Автоматы с большим количеством состояний просто незачем делать. У меня есть не один проект, где при лобовом использовании автоматов состояний были-бы тысячи.
Вместо этого есть порядка десятка связанных автоматов с десятком, ну двумя десятками состояний. При этом они находятся тоже не в одном switch/case. Например, часть из них уходит в ОТДЕЛЬНЫНУЮ функцию переключения состояний автомата. В этой же функции вся отладка консольная.

Если Вы откажетесь от любимой консоли, то будете в отладчике смотреть состояние по осмысленному наименованию одной строкой из enum


Кстати, расскажите подробнее про отладку - как то происходит? Вот как быстро понять текущее состояние автомата?

Использование отладчика, например, в заполярье на сопке не есть хорошая идея. Точнее очень плохая, поскольку там нет ни специалиста, ни компьютера и исходниками и проектом, ни отладчика. Ну а то, что выводится у консоль, то удаленно доступно и лог сбрасывается. При этом отладка может быть и не включена - состояния автомата с сопутствующими данными пишутся в некий буфер и при ошибке распечатывается предистория, как дошли до состояния такого.
И вообще - отладчик универсальный инструмент, но специализированный инструмент можно сделать лучше.

Да, у меня тоже такое есть, имя состояния выводится после времени установки. Но тут то просто - процесс медленный, все выводится в реальном масштабе времени. С быстрыми автоматами буферизация данных становится сама по себе непростой задачей.

По этой причине незачем печатать развернутые сообщения (выбор детализации, как по объему распечатки, так и по набору состояний ) и, как уже писал, запуск распечаток от одного заданного состояния до другого. Причем есть буфер для запоминания трассы автомата, который вообще постфактум может быть распечатан - дошли до интересующего состояния и распечатали. Ну и проблемы отладки автоматов это, обычно медленные автоматы, которые от разнообразных внешних воздействий зависят. Быстрые обычно внутренние, их можно и на столе отладчиком посмотреть.

Тут уже мое "заполярье" - иногда приходится реализовывать протокол обмена по описанию, все вроде симуляторами проверил, а с реальным дивайсом в поле не работает, а он за тысячи километров.

Тогда и меня должны понять, поскольку у меня "протокол по описанию" нередко бывал на многие ТЫСЯЧИ страниц. Тут уж никакой симулятор "на столе" не изобразишь для отладки, тем более без ошибок. Ну и встречное оборудование на реальных сетях все время меняется. И служит все десятки лет. Вот перед Новым Годом по подключению очередного комплекта оборудования разработанного и вылизанного более 10 лет назад "компетентные органы" https://ru.wikipedia.org/wiki/СОРМ мозг выносили - типа у них "все правильно".

Я Вас ни в чём не собираюсь убеждать. Каждый пишет в меру своего умения и знаний. Насильно обучить чему-то невозможно.
Кто хочет, тот поймёт и все преимущества моего метода, плюсы и минусы и случаи когда его удобно применять. Ибо они очевидны.
Описал этот метод не для того чтобы с кем-то спорить тут. Использовать его только понимающим. Остальные - пройдите мимо, не вам это.


Включить мозг и догадаться, что PC сохраняется по фиксированному адресу ОЗУ - посмотреть там.

А потом ? - искать по окну дизассемблера?
Не выглядит особенно удобным по сравнению со значением из enum.