[BSACPLD 15]

Коллеги, существует ли литература / сайты где подробно описаны основные правила хорошего тона при проектировании под FPGA?

- что рекомендуется делать.

- что не рекомендуется.

- за что бить по рукам.

Самому как-то лень писать, да и я тоже могу чего-нибудь не знать...

Лично для себя я выработал следующий набор правил:

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

- чем меньше разных тактовых доменов, тем лучше.

- для понижения частоты работы блоков использовать clock enable, а не generated clock.

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

- все переменные объявляются в начале файла, а не по мере их использования.

- все переменные объявляются явно.

- для знаковых чисел указывается их знаковость (signed).

- аппаратно зависимые блоки оборачиваются во врапперы.

- никаких LPM в проекте (Altera/Intel).

- никакой схематики и устаревших языков (исключение Block Design в Xilinx и QSYS в Altera).

- по возможности использовать стандартные шины (APB, AXI, Avalon, Wishbone).

- код пишется максимально кроссплатформенным и параметризованным.

- в начале файла обязательно налиличе timescale.

- все переменные инициализируются X при моделировании.

- код проверяется на соответствие стандарту в ModelSim/NCSim.

 

Это так сказать набор правил выработанный за долгие годы работы, но не факт что он полный / достаточный.

Хотелось бы почитать подходящую литературу и узнать мнение знающих людей.

[des00 25]

на форуме раза 4 это обсуждалось, со ссылками и документами. Ищите)

[iosifk 3]

25 минут назад, BSACPLD сказал:

Это так сказать набор правил выработанный за долгие годы работы, но не факт что он полный / достаточный.

Хотелось бы почитать подходящую литературу и узнать мнение знающих людей.

Согласен с des00. Если смотреть с точки зрения инженера, то многократно все описано. Кроме одного момента. С точки зрения "юриста" надо добавить, что каждый файл проекта должен содержать "шапку", где указано "что, кто и когда"... Если файл не текстовый, то к нему должен быть дополнительный файл с этими данными.... А иначе вполне возможна ситуация, когда на сервере кто-то файл проекта слегка поправит, а у остальных все перестанет работать...

 

[BSACPLD 15]

20 minutes ago, iosifk said:

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

Так ведь нехороший человек может и не вписать себя в шапку ;)

Для таких случаев как раз и есть svn / git и другие системы контроля версий.

[iosifk 3]

14 минут назад, BSACPLD сказал:

Так ведь нехороший человек может и не вписать себя в шапку ;)

Для таких случаев как раз и есть svn / git и другие системы контроля версий.

Так ведь дата создания файла хотя бы в файловом менеджере видна. И она должна совпадать с записью о изменении версии файла. 

Или представьте, что идет сопровождение проекта и файлы сделаны полгода назад. К тому бежать за вопросами и разъяснениями?

[Mad_kvmg 0]

У Mentor Graphics есть такой тул HDL Designer, в целом ничем не примечателен, но у него есть Lint Checker с десятком либов с coding rules/styles/safe synthesis. Причем можно добавлять свои правила и менять severity level.

Естественно соответствие правилам проверяется автоматически и code review c RTL дизайнером вы начинаете с логов чекера, а не с просмотра кода глазками. 

[Nick_K 0]

Если Вы работаете над специализированным проектом - то берёте и читаете Юзер гайды конкретного производителя ПЛИС. Обычно там описаны все стандарты переменных, типы присвоений и используемые конструкции.

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

У меня вон был случай, когда оказалось, что у Xilinx создаваемое IP прекрасно понимает объявление портов, к примеру, клока заканчивающееся на _clk или ресета на _nrst, а я привык писать в конце тип порта: выход-вход _o/_i. Пришлось переучиваться, ибо дополнительно писать/переписывать тонны скриптов не логично и трудозатратно.

[one_eight_seven 6]

1 minute ago, Nick_K said:

У меня вон был случай, когда оказалось, что у Xilinx создаваемое IP прекрасно понимает объявление портов, к примеру, клока заканчивающееся на _clk или ресета на _nrst, а я привык писать в конце тип порта: выход-вход _o/_i. Пришлось переучиваться, ибо дополнительно писать/переписывать тонны скриптов не логично и трудозатратно.

А можно было обернуть в модуль, отвечающий принятому обозначению. Потому что сегодня Хилые, завтра Avery/Cast, послезавтра - Synopsys, и все по разному генерируют. Поэтому, wrapper - это хорошо, когда он существует для приведения к единому виду, принятому на предприятии, которая производит изделие, и где есть свои скрипты/кодогенераторы/правила проверки.

[Nick_K 0]

13 hours ago, one_eight_seven said:

А можно было обернуть в модуль, отвечающий принятому обозначению. Потому что сегодня Хилые, завтра Avery/Cast, послезавтра - Synopsys, и все по разному генерируют. Поэтому, wrapper - это хорошо, когда он существует для приведения к единому виду, принятому на предприятии, которая производит изделие, и где есть свои скрипты/кодогенераторы/правила проверки.

С одной стороны вы правы. Но это был уже третий враппер для модуля, при том что когда генерируется IP из библиотеки, оно всегда дополнительно оборачивается в автоматический враппер. Посиму делать "цибульку" для простого модуля несколько геморно.

[lexx 0]

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

И этот весёлый 'hx во внутренней SRAM кэша процессора, при отсутствии  инициализации в начале симуляции.

[BSACPLD 15]

3 hours ago, lexx said:

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

Дело в том, что в некоторых моделях для симуляции той же DDR, timescale может стоять отличным от того что хотите Вы и он переопределит шаг временного моделирования во всех нижестоящих файлах.

3 hours ago, lexx said:

И этот весёлый 'hx во внутренней SRAM кэша процессора, при отсутствии  инициализации в начале симуляции.

Если это память программ, то да. Ее нужно инициализировать. А во всех остальных случаях это лишь потенциальное место для некорректного состояния системы из которого она может никогда не выйти. Вот X как раз и нужны для проверки того как система выходит из некорректных состояний.

[lexx 0]

21 hours ago, BSACPLD said:

некоторых моделях для симуляции той же DDR, timescale может стоять отличным от того что хотите Вы и он переопределит шаг временного моделирования во всех нижестоящих файлах

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

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