Перейти к содержанию
    

Метод 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. Они применяют какую-то другую методологию описания последовательных схем. Часто там даже нет машины состояний. Зато, очень много коротких описаний процессов. Но логику, по которой все это описано я не понимаю. Если, кто-то ее знает, объясните, пожалуйста.

Изменено пользователем Олег Гаврильченко

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Так всё же зависит от алгоритма вычислений.

Одну и ту-же задачу часто можно решить разными алгоритмами.

Можно даже автомат описать не классическим FSM, а регистрами и логикой переключения.

То что у них так описано - это не значит, что это сделано правильно и корректно.

Ведь помимо HDL описания важно его ещё и правильно задокументировать, чтобы потом была возможность поддержки этого проекта, если он не одноразовый.

А документировать кучу маленьких процессов очень, и очень сложно. Если вообще это возможно сделать...

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

3. Если это не тривиальная схема с последовательной логикой. То я составляю алгоритм ее работы, выделяю какие нужны состояния и регистры(Control path и Data path).

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

в том числе и код Xilinx модулей

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

 

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

отличные примеры в исходниках, то, что надо для обучения.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Представьте в голове (или на бумаге) схему модуля, который Вы пишите.

А после перенесите её в HDL.

И можно использовать хоть 2 процесса, хоть 200.

Лучше использовать такое количество процессов, которое соответствует наиболее наглядному представлению функциональности.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Модули управления, принимающие команды по AXI пишу без FSM, там она не нужна. Согласую их с модулями обработки через CDC.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Я сейчас представляю проект как иерархическую структуру автоматов с таймерами и "исполнительных узлов".

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

Таким образом резко сокращается число строк кода в одном файле. А значит, сокращается и вероятность появления ошибок. Такие проекты гораздо проще симулировать, поскольку каждый файл должен быть параметризирован.

Сам же автомат однозначно пишется из блок-схемы процесса управления объектом.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

1. Если это тривиальный модуль, такой как счетчик, мультиплексор и др....

3. Если это не тривиальная схема с последовательной логикой...

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Я сейчас представляю проект как иерархическую структуру автоматов с таймерами и "исполнительных узлов".

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

Таким образом резко сокращается число строк кода в одном файле. А значит, сокращается и вероятность появления ошибок. Такие проекты гораздо проще симулировать, поскольку каждый файл должен быть параметризирован.

Сам же автомат однозначно пишется из блок-схемы процесса управления объектом.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Есть замечательная книга под названием "Advanced FPGA Design Architecture, Implementation, and Optimization" Steve Kilts. ISBN 978-0-470-05437-6

В книге показано на примерах, как структура дизайна влияет на скорость/пропускную способность/задержки в проекте.

Мне показалось, что там подробно расписано, в каких случаях удобно использовать FSM, где лучше использовать тонну комбинаторной логики, а где кучу маленьких процессов.

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Гость
Эта тема закрыта для публикации ответов.
×
×
  • Создать...