Метод HDL-описания в модулях XILINX и других. Опции

[Олег Гаврильченк...]

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

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

Сообщение отредактировал Олег Гаврильченко - Dec 1 2017, 09:51

[el.d]

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

[iosifk]

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

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

[Олег Гаврильченк...]

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

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

[iosifk]

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

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

[Tpeck]

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

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