Jump to content

    
BSACPLD

Правила корректного написания кода

Recommended Posts

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

Share this post


Link to post
Share on other sites
25 минут назад, BSACPLD сказал:

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

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

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

 

Share this post


Link to post
Share on other sites
20 minutes ago, iosifk said:

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

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

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

Share this post


Link to post
Share on other sites
14 минут назад, BSACPLD сказал:

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

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

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

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

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

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

Share this post


Link to post
Share on other sites
1 minute ago, Nick_K said:

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

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

Share this post


Link to post
Share on other sites
13 hours ago, one_eight_seven said:

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

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites
3 hours ago, lexx said:

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

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

3 hours ago, lexx said:

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

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

Share this post


Link to post
Share on other sites
21 hours ago, BSACPLD said:

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

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

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

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.