Вопрос возможно, покажется непонятным. Он касается методики описания HDL-проекта на HDL-языке, неважно каком, Verilog или VHDL
Мне известны только такие методы описания модуля на HDL:
1. Если это тривиальный модуль, такой как счетчик, мультиплексор и др., то он описывается по шаблону, который легко найти в руководстве по HDL от производителя ПЛИС или в Google.
2. Если это схема соединяющая другие модули, то здесь тоже не сложно. Определить сигналы, определить компоненты, соединить их.
3. Если это не тривиальная схема с последовательной логикой. То я составляю алгоритм ее работы, выделяю какие нужны состояния и регистры(Control path и Data path). Составляю диаграмму состояний и определяю какое следующее значение будет у регистров в Data path. Определяю, какие значения должны будут иметь выходы. Таким образом, если я пишу на VHDL у меня обычно 4 процесса: 2 последовательных, определяют что на каждом такте Clk регистры и состояние должны принимать следующее значение, и 2 процесса, описывающие следующее состояние и следующее значение регистров. И еще описание выходных сигналов.

Однако, когда я просматриваю чужой код, в том числе и код Xilinx модулей как для симуляции, так и для синтеза, я вижу что там все сделано не так, как в п.3. Они применяют какую-то другую методологию описания последовательных схем. Часто там даже нет машины состояний. Зато, очень много коротких описаний процессов. Но логику, по которой все это описано я не понимаю. Если, кто-то ее знает, объясните, пожалуйста.

А разве всегда надо пихать конечный автомат?

Очевидно, нет, раз разработчики из XILINX его не используют. Но я без конечного автомата и Data Path не умею делать ничего сложнее счетчика. И поэтому и задал этот вопрос.

Я лично для себя не могу понять, с чем у вас проблема. По сути, то, что описали - это просто обобщение пункта 2. То есть, вы говорите, что грубо говоря в одной VHDL архитектуре встречали множество маленьких процессов. По сути, каждый такой процесс можно рассматривать как отдельный блок, и тогда получаем структуру из пункта 2, разве нет?

Так всё же зависит от алгоритма вычислений.
Одну и ту-же задачу часто можно решить разными алгоритмами.
Можно даже автомат описать не классическим FSM, а регистрами и логикой переключения.
То что у них так описано - это не значит, что это сделано правильно и корректно.
Ведь помимо HDL описания важно его ещё и правильно задокументировать, чтобы потом была возможность поддержки этого проекта, если он не одноразовый.
А документировать кучу маленьких процессов очень, и очень сложно. Если вообще это возможно сделать...

А можете пример кода выложить?

Не стоит воспринимать это как референс, там индусы так колхозят на скоряк, что мама не горюй.

Лучше по книгам учиться, например, SystemVerilog For Design Second Edition от Stuart Sutherland и ко.
отличные примеры в исходниках, то, что надо для обучения.

Представьте в голове (или на бумаге) схему модуля, который Вы пишите.
А после перенесите её в HDL.
И можно использовать хоть 2 процесса, хоть 200.
Лучше использовать такое количество процессов, которое соответствует наиболее наглядному представлению функциональности.

Олег Гаврильченко, в целом модули, обрабатывающие поток данных (DSP), пишу так же как Вы описали (разделяю поток обработки и управляющую логику). Зачастую обработка сложная - я разделяю входную часть - ставлю FIFO и автомат состояний для управления входом. По окончании приема данных FSM переключает входное FIFO и генерирует строб автомату, который выполняет обработку сигнала и одновременно выдает на выход данные. Во многом это связано с использованием AXIS и AXI. Так получается удобно модули последовательно составлять - не заботишься, что данные где-то пропадут...
Модули управления, принимающие команды по AXI пишу без FSM, там она не нужна. Согласую их с модулями обработки через CDC.

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

Скорее всего вы видите код, который прошел обфускацию. Он синтезируем, но совершенно не понятен и не модифицируем.

Любую "не тривиальную схему" можно составить из "тривиальных модулей" в альтернативу использования FSM. Не понятна, все таки, логика по которой это написано, или логика по которой это работает? Если первое, то это вопрос стиля кодирования. А если второе, то надо смотреть конкретный код.

Буду благодарен, если Вы покажете какой-нибудь пример. Или дадите ссылку на информацию, где это объяснено.

Ответ отправил в личку.

Есть замечательная книга под названием "Advanced FPGA Design Architecture, Implementation, and Optimization" Steve Kilts. ISBN 978-0-470-05437-6
В книге показано на примерах, как структура дизайна влияет на скорость/пропускную способность/задержки в проекте.
Мне показалось, что там подробно расписано, в каких случаях удобно использовать FSM, где лучше использовать тонну комбинаторной логики, а где кучу маленьких процессов.

Если для описания используется VHDL, то Вам, возможно, было бы интересно обратить внимание еще на Two Process Method (Jiri Gaisler).

А можете продублировать?
Спасибо.

Могу конечно, просто задолбали козлы, которые считают, что я тут только и делаю, что рекламирую свои статьи и свой сайт... Надоело им объяснять... Но раз уж Вы просите, то...
Смотрите мой "Краткий Курс", глава "дополнительный раздел об автоматах". Там как раз и написано об автомате Мастере-ведущем и автомате ведомом.
Вообще об автоматах ищите по словам: "Шалыто А.А., автоматное проектирование, ИТМО"...
Будут вопросы, могу ответить по скайпу подробнее...