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

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

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

 

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

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

 

1. ALSE's VHDL Design Rules & Coding Style

2. Ben Cohen - VHDL Coding Guide and Methodologies.

 

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

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

 

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

 

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

elecard_vhdl_coding_styles_rules.doc

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


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

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

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


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

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

 

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

 

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

elecard_vhdl_coding_styles_rules.htm

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


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

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

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


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

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

 

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

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


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

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

 

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

 

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

 

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

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


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

2 des

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

 

2 Gate

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

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


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

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

 

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

 

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

 

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

 

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

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

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

 

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

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

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


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

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

 

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

 

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

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


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

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

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

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

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

 

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

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


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

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

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


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

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

 

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

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


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

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

а почему?

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


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

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

а почему?

 

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

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


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

Присоединяйтесь к обсуждению

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

Гость
К сожалению, ваш контент содержит запрещённые слова. Пожалуйста, отредактируйте контент, чтобы удалить выделенные ниже слова.
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...