Jump to content

    

Обсуждение для гуру и не только(+)

Добрый день господа!

 

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

В качестве опоры взял следующие документы

 

1. ALSE's VHDL Design Rules & Coding Style

2. Ben Cohen - VHDL Coding Guide and Methodologies.

 

Кое что убрал, кое что добавил. Часть документа еще не проработанна.

Документ еще не окончен, всем кому документ понравился могут использовать его в своей работе, всем кому не понравился и может покритиковать по делу буду премного благодарен за помощь в доводке документа до ума (томичам можно и в пивном эквиваленте на эмбедеровке)!!!

 

Документ разрабатывается для стандартизации и повторного использования кода, разработанного девелоперами компании в нескольких проектах.

 

Заранее большое спасибо.

elecard_vhdl_coding_styles_rules.doc

Share this post


Link to post
Share on other sites

а вывеси его в "статьи" аштээмэлем - там и обсудим и до финального варианта доведем

Share this post


Link to post
Share on other sites
а вывеси его в "статьи" аштээмэлем - там и обсудим и до финального варианта доведем

 

Да без проблем, только скажите как это сделать ? (каюсь грешен, в этом полный ламер :) )

 

наверное так :)

elecard_vhdl_coding_styles_rules.htm

Share this post


Link to post
Share on other sites

Я вот здесь http://electronix.ru/forum/index.php?showtopic=17494 выкладывал аналогичный документ по верилогу, но никакого интереса он не вызвал. М.б. он будет полезен в этой ветке?

Share this post


Link to post
Share on other sites
Я вот здесь http://electronix.ru/forum/index.php?showtopic=17494 выкладывал аналогичный документ по верилогу, но никакого интереса он не вызвал. М.б. он будет полезен в этой ветке?

 

спасибо, изучу на досуге

Share this post


Link to post
Share on other sites

По идентификаторам: я предпочитаю префиксы суффиксам.

 

Зачем суффикс для entity name?

 

Не понял пункт 4.38. Пропущен "not"?

 

У меня название файла --- это имя entity или package. Да еще в низком регистре. Очень актуально для скриптов. Винде все равно, а Линуксу приятно...

Share this post


Link to post
Share on other sites

2 des

да нее.. я не о том - есть раздел "Статьи" в шапке глянь - он спецом для этого и был создан

 

2 Gate

книжка большая больно - не каждый осилит -да и потом что обсуждать если это законченное твoрение (или нет?)

Share this post


Link to post
Share on other sites
По идентификаторам: я предпочитаю префиксы суффиксам.

 

Используется как суффиксная так и префиксная запись, суффиксная определяет типы идентификатора и его функциональность, префиксаная его функциональное предназначение.

 

Зачем суффикс для entity name?

 

Я тоже его не использую, но в книге Ben Cohena это было, думаю что это необходимо в случае разбиения entity и architecture на 2 файла, для идентификации при вставках компонента (хотя это очевидно, пункт можно убрать).

 

Не понял пункт 4.38. Пропущен "not"?

4.38. BEH & SIM: Do not use processes with sensitivity list.

думаю что это верно(по опыту работы стараюсь не пользовать процессы со списком чувствительности при симуляции в тестбенче)

 

У меня название файла --- это имя entity или package. Да еще в низком регистре. Очень актуально для скриптов. Винде все равно, а Линуксу приятно...

хмм понятно, нужно продумать.

Share this post


Link to post
Share on other sites

не согласен с разделением на RTL, BEH и SIM - группировка странная - RTL и BEH группировка по стилям описания, SIM - классификация по цели применения . Симуляция может проходить как на РТЛ так и на поведенческом уровне. при этом если говорить о синтезабельном подмножестве - то это только РТЛ, если говорить о тестбенчах - то предпочтительный стиль описания - поведенческий (к тому же чистое поведение не синтезируется на настоящий момент)

 

Не понял пункт 4.38. Пропущен "not"?

 

да нет действительно при поведенческом описание чувствительности целого процесса лучше избегать - замедляет модель - иначе это уже ближе к РТЛ (т.е. даже если вы используете CASE при описание КА - то это еще не признак поведеньческого описания)

Share this post


Link to post
Share on other sites

Не понял пункт 4.38. Пропущен "not"?

данет действительно при поведенческом описание чувствительности целогопроцесса лучше избегать - замедляет модель - иначе это уже ближе к РТЛ(т.е. даже если вы используете CASE при описание КА - то это еще непризнак поведеньческого описания)

Про "пропущен not" --- это я погорячился.

Все равно не понимаю. Вы же делаете синхронный дизайн, так? Значит, вам надо формировать входные сигналы по клоку, тому же самомоу клоку, который заходит в ПЛИС. Как без списка чувствительности? Иcпользовать wait until rising_edge(Clk)? И что, таки намного быстрее, чем process(Clk)?

 

Вообще, давайте конкретный пример.

Share this post


Link to post
Share on other sites
Про "пропущен not" --- это я погорячился.

Все равно не понимаю. Вы же делаете синхронный дизайн, так? Значит, вам надо формировать входные сигналы по клоку, тому же самомоу клоку, который заходит в ПЛИС. Как без списка чувствительности? Иcпользовать wait until rising_edge(Clk)? И что, таки намного быстрее, чем process(Clk)?

 

Вообще, давайте конкретный пример.

самодеятельностью заниматься не буду - тем более вы свой - посмотрите "Writing testbenches. Functional verification of HDL models" Janik Bergeron 2001 глава 4 раздел "Behavioral versus RTL thinking" (она есть, сами знаете где ;) хоть и немножко устарела по уровню технологии ). суть в том чтобы сократить количество запусков (которые могут быть и холостыми) процессов до только значимых при симуляции. иначе этот переход можно охарактеризовать как тереход от CycleBaseAccurate(CBA) модели к TransactionLevelModel (TLM) - в больших проектах экономия времени значима.

в случае верификации синтезабельной модели - само железо остаётся на РТЛ уровне (от этого никуда не деться - и чувствительность по клокам и прочим привычным аппаратурщикам конструкциям остаются неприкасаемыми - а вот тестбенч предпочтительнее писать на поведеньческом уровне (т.к. экономит время симуляции и соответствует намерению разработчика а не описанию еще одной цифровой сxемы цепляемой к верифицируему проекту - в общем лучше посмотрите книжку - а то мы в оффтоп от основной темы уйдём) хотя это не всегда единственно приемлемый/верный вариант

Share this post


Link to post
Share on other sites
не согласен с разделением на RTL, BEH и SIM - группировка странная - RTL и BEH группировка по стилям описания, SIM - классификация по цели применения . Симуляция может проходить как на РТЛ так и на поведенческом уровне. при этом если говорить о синтезабельном подмножестве - то это только РТЛ, если говорить о тестбенчах - то предпочтительный стиль описания - поведенческий (к тому же чистое поведение не синтезируется на настоящий момент)

 

Хмм согласен, завтра введу конкретику в определение.

Share this post


Link to post
Share on other sites

"4.46. RTL, BEH, SIM: Avoid active-low signals inside the design. The internal logic should be active-high."

а почему?

Share this post


Link to post
Share on other sites
"4.46. RTL, BEH, SIM: Avoid active-low signals inside the design. The internal logic should be active-high."

а почему?

 

Повидимому чтобы избежать путаницы и лишних ошибок, связанных с опечатками (0 вместо 1 и т.п). :)

Share this post


Link to post
Share on other sites

to: Des00

 

Few examples also would be good idea, otherwise people will have different interpretations of what you said.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this