des00 25 3 июля, 2006 Опубликовано 3 июля, 2006 · Жалоба Добрый день господа! Для ведения большого проекта, решил собрать в кучку те правила и стиль, которому придерживаюсь при разработке. В качестве опоры взял следующие документы 1. ALSE's VHDL Design Rules & Coding Style 2. Ben Cohen - VHDL Coding Guide and Methodologies. Кое что убрал, кое что добавил. Часть документа еще не проработанна. Документ еще не окончен, всем кому документ понравился могут использовать его в своей работе, всем кому не понравился и может покритиковать по делу буду премного благодарен за помощь в доводке документа до ума (томичам можно и в пивном эквиваленте на эмбедеровке)!!! Документ разрабатывается для стандартизации и повторного использования кода, разработанного девелоперами компании в нескольких проектах. Заранее большое спасибо. elecard_vhdl_coding_styles_rules.doc Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
CaPpuCcino 0 3 июля, 2006 Опубликовано 3 июля, 2006 · Жалоба а вывеси его в "статьи" аштээмэлем - там и обсудим и до финального варианта доведем Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
des00 25 3 июля, 2006 Опубликовано 3 июля, 2006 · Жалоба а вывеси его в "статьи" аштээмэлем - там и обсудим и до финального варианта доведем Да без проблем, только скажите как это сделать ? (каюсь грешен, в этом полный ламер :) ) наверное так :) elecard_vhdl_coding_styles_rules.htm Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Gate 0 3 июля, 2006 Опубликовано 3 июля, 2006 · Жалоба Я вот здесь http://electronix.ru/forum/index.php?showtopic=17494 выкладывал аналогичный документ по верилогу, но никакого интереса он не вызвал. М.б. он будет полезен в этой ветке? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
des00 25 3 июля, 2006 Опубликовано 3 июля, 2006 · Жалоба Я вот здесь http://electronix.ru/forum/index.php?showtopic=17494 выкладывал аналогичный документ по верилогу, но никакого интереса он не вызвал. М.б. он будет полезен в этой ветке? спасибо, изучу на досуге Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
andrew_b 17 3 июля, 2006 Опубликовано 3 июля, 2006 · Жалоба По идентификаторам: я предпочитаю префиксы суффиксам. Зачем суффикс для entity name? Не понял пункт 4.38. Пропущен "not"? У меня название файла --- это имя entity или package. Да еще в низком регистре. Очень актуально для скриптов. Винде все равно, а Линуксу приятно... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
CaPpuCcino 0 3 июля, 2006 Опубликовано 3 июля, 2006 · Жалоба 2 des да нее.. я не о том - есть раздел "Статьи" в шапке глянь - он спецом для этого и был создан 2 Gate книжка большая больно - не каждый осилит -да и потом что обсуждать если это законченное твoрение (или нет?) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
des00 25 3 июля, 2006 Опубликовано 3 июля, 2006 · Жалоба По идентификаторам: я предпочитаю префиксы суффиксам. Используется как суффиксная так и префиксная запись, суффиксная определяет типы идентификатора и его функциональность, префиксаная его функциональное предназначение. Зачем суффикс для 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 3 июля, 2006 Опубликовано 3 июля, 2006 · Жалоба не согласен с разделением на RTL, BEH и SIM - группировка странная - RTL и BEH группировка по стилям описания, SIM - классификация по цели применения . Симуляция может проходить как на РТЛ так и на поведенческом уровне. при этом если говорить о синтезабельном подмножестве - то это только РТЛ, если говорить о тестбенчах - то предпочтительный стиль описания - поведенческий (к тому же чистое поведение не синтезируется на настоящий момент) Не понял пункт 4.38. Пропущен "not"? да нет действительно при поведенческом описание чувствительности целого процесса лучше избегать - замедляет модель - иначе это уже ближе к РТЛ (т.е. даже если вы используете CASE при описание КА - то это еще не признак поведеньческого описания) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
andrew_b 17 3 июля, 2006 Опубликовано 3 июля, 2006 · Жалоба Не понял пункт 4.38. Пропущен "not"? данет действительно при поведенческом описание чувствительности целогопроцесса лучше избегать - замедляет модель - иначе это уже ближе к РТЛ(т.е. даже если вы используете CASE при описание КА - то это еще непризнак поведеньческого описания) Про "пропущен not" --- это я погорячился. Все равно не понимаю. Вы же делаете синхронный дизайн, так? Значит, вам надо формировать входные сигналы по клоку, тому же самомоу клоку, который заходит в ПЛИС. Как без списка чувствительности? Иcпользовать wait until rising_edge(Clk)? И что, таки намного быстрее, чем process(Clk)? Вообще, давайте конкретный пример. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
CaPpuCcino 0 3 июля, 2006 Опубликовано 3 июля, 2006 · Жалоба Про "пропущен 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 3 июля, 2006 Опубликовано 3 июля, 2006 · Жалоба не согласен с разделением на RTL, BEH и SIM - группировка странная - RTL и BEH группировка по стилям описания, SIM - классификация по цели применения . Симуляция может проходить как на РТЛ так и на поведенческом уровне. при этом если говорить о синтезабельном подмножестве - то это только РТЛ, если говорить о тестбенчах - то предпочтительный стиль описания - поведенческий (к тому же чистое поведение не синтезируется на настоящий момент) Хмм согласен, завтра введу конкретику в определение. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
CaPpuCcino 0 3 июля, 2006 Опубликовано 3 июля, 2006 · Жалоба "4.46. RTL, BEH, SIM: Avoid active-low signals inside the design. The internal logic should be active-high." а почему? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
makc 233 3 июля, 2006 Опубликовано 3 июля, 2006 · Жалоба "4.46. RTL, BEH, SIM: Avoid active-low signals inside the design. The internal logic should be active-high." а почему? Повидимому чтобы избежать путаницы и лишних ошибок, связанных с опечатками (0 вместо 1 и т.п). :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Iouri 0 4 июля, 2006 Опубликовано 4 июля, 2006 · Жалоба to: Des00 Few examples also would be good idea, otherwise people will have different interpretations of what you said. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
