[des00 25]

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

 

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

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

 

1. ALSE's VHDL Design Rules & Coding Style

2. Ben Cohen - VHDL Coding Guide and Methodologies.

 

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

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

 

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

 

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

elecard_vhdl_coding_styles_rules.doc

[CaPpuCcino 0]

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

[des00 25]

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

 

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

 

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

elecard_vhdl_coding_styles_rules.htm

[Gate 0]

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

[des00 25]

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

 

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

[andrew_b 14]

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

 

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

 

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

 

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

[CaPpuCcino 0]

2 des

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

 

2 Gate

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

[des00 25]

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

 

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

 

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

 

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

 

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

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

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

 

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

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

[CaPpuCcino 0]

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

 

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

 

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

[andrew_b 14]

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

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

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

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

 

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

[CaPpuCcino 0]

Про "пропущен 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емы цепляемой к верифицируему проекту - в общем лучше посмотрите книжку - а то мы в оффтоп от основной темы уйдём) хотя это не всегда единственно приемлемый/верный вариант

[des00 25]

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

 

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

[CaPpuCcino 0]

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

а почему?

[makc 190]

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

а почему?

 

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

[Iouri 0]

to: Des00

 

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