Jump to content
    

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

значит в документ ввел поправки:

1. Большая конкретика в определениях:

Conventions

 

RTL: Register Transfer Level. This document mean, that RTL is coding style which is using for synthesis purposes. This code can contain processes with sensitivity list or processes without sensitivity list with single level of ”wait until” expression. This code can be synthesizable via synthesizer.

 

BEH : Behavioral code. This document mean, that BEH is coding style which is using for functional testing purposes only. This code can contain multi level hierarchy of ”wait until” expression and use any techniques for process’s synchronization. This code may not be synthesizable via synthesizer.

 

SIM : Test benches, test code and resources for simulation and verification.

2. поправка к таблице

1.1. Source Files Naming Convention

NOTE : there is no reason to use exactly this file’s name convention , but suffix’s name convention must be keep.

3. Убрал обязательный суффикс для entity

 

2 CaPpuCcino

 

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

а почему?

да что бы избежать путаницы. Конечно можно решить эту проблему с помошью поля Polarity

в имени сигнала, порта но ИМХО это все же хуже чем придерживаться все время одного и того же стиля.

Искать очипятку в коде например на 5К строк не самое приятное занятие :)

 

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

 

I think you are right, but i have no much time to do it immediately. :(

This document will be devepoled to include as much as posible useful advices & rules. I think this document will be useful not only for novice.

I just need only in time. :)

 

 

Господа остается под вопросом пункт

4.32. RTL: It is not allowed to initialize signals at their declaration. It is not allowed to initialize variables at their declaration in processes. It is acceptable to initialize variables at their declaration inside functions.

 

Это взято из Ben Cohena, но я считаю что это в неверно. Да это полезно для того, чтобы не расходились результаты симуляции модели до и после синтеза. Но я полагаю что это решаеться грамнотной политикой организации сигнала сброса. Что вы про это думаете ?

 

Кстати вот новое правило для coding style:

 

4.55. Use reset only for signals which need to be reset. As you are creating each section of your next design, simply ask yourself: "Does this bit need to be reset"?

 

© Ken Chapman - Get Smart About Reset (Think Local, Not Global)

Share this post


Link to post
Share on other sites

2 CaPpuCcino

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

а почему?

да что бы избежать путаницы. Конечно можно решить эту проблему с помошью поля Polarity

в имени сигнала, порта но ИМХО это все же хуже чем придерживаться все время одного и того же стиля.

Искать очипятку в коде например на 5К строк не самое приятное занятие :)

да ну ерунда куча стандартов использует фреймы отрицательной полярности - поле для описание полярности использовать гораздо коpректней IMHO- я всегда обо3начаю актив лоу с суффиксом _n (_b -общепринято)- если взять за правило никаких проблем в отладке не вижу - всегда в глаза бросается

Share this post


Link to post
Share on other sites

4.32. RTL: It is not allowed to initialize signals at their declaration. It is not allowed to initialize variables at their declaration in processes. It is acceptable to initialize variables at their declaration inside functions.

Это взято из Ben Cohena, но я считаю что это в неверно. Да это полезно для того, чтобы не расходились результаты симуляции модели до и после синтеза. Но я полагаю что это решаеться грамнотной политикой организации сигнала сброса. Что вы про это думаете ?

меня вот это сразу немного смутило It is not allowed to initialize variables at their declaration in processes.

а с остальным согласен - сигналы инициализировать не стоит, но ток сбрасывать; для функции инициализация не страшна - переменные динамические (если ток в новом стандарте не появятся статические переменные функции как это сделали в СВ)

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."

а почему?

 

 

да что бы избежать путаницы. Конечно можно решить эту проблему с помошью поля Polarity

в имени сигнала, порта но ИМХО это все же хуже чем придерживаться все время одного и того же стиля.

Искать очипятку в коде например на 5К строк не самое приятное занятие (IMG:style_emoticons/default/smile.gif)

 

Есть одно но - триггеры-то сбрасываются нулем(altera). А в некоторых плисах '1'(actel). К примеру, если проект дебажится на altera-cyclone и реализуется в actel-apa, то правильнее полярность сигнала сброса задавать в конфигурирующем пакете и не трогать entity и декларации портов.

 

It is not allowed to initialize variables at their declaration in processes

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

 

Пример:

ring_cnt - не инициализируется и не сбрасывается(просто бегает по кругу);
как в симуляторе будет работать строчка ring_cnt<=ring_cnt+1?

Share this post


Link to post
Share on other sites

2 CaPpuCcino

 

да ну ерунда куча стандартов использует фреймы отрицательной полярности - поле для описание полярности использовать гораздо коpректней IMHO- я всегда обо3начаю актив лоу с суффиксом _n (_b -общепринято)- если взять за правило никаких проблем в отладке не вижу - всегда в глаза бросается

 

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

 

2 CaPpuCcino и vetal

 

с остальным согласен - сигналы инициализировать не стоит, но ток сбрасывать; для функции инициализация не страшна - переменные динамические (если ток в новом стандарте не появятся статические переменные функции как это сделали в СВ)

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

 

Больше вопросов чем ответов. Почему сигналы сбрасывать не стоит ? Берем простой пример: 10 ти ступенчатый конвейер, параллельно с которым идет сигнал валидности данных. В этом случае начальное состояние регистров не важно, но для симуляции, почему бы не проинитить их нулями без сигнала сброса. В реальном же железе введние сигнала сброса на эти цепи не имеет смысла, кроме раздувания логики.

 

То же самое ИМХО касается использования переменных, отладчиком проще по коду лазить. Хотя думаю что в случае использования переменных только для упрощения описания, а не имплементации регистров и т.д. разницы между проинициализированной переменной и просто переменной нет.

 

Насчет динамических и статических переменных а разве impure функции в ВХДЛ не для этого придуманы ?

 

Так все таки убирать это правило или нет ? :)

 

2 vetal

 

Есть одно но - триггеры-то сбрасываются нулем(altera). А в некоторых плисах '1'(actel). К примеру, если проект дебажится на altera-cyclone и реализуется в actel-apa, то правильнее полярность сигнала сброса задавать в конфигурирующем пакете и не трогать entity и декларации портов.

 

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

constant RESET_POLARITY_XILINX : std_logic := '1';

constant RESET_POLARITY_ALTERA : std_logic := '0';

 

constant RESET_POLARITY : std_logic := RESET_POLARITY_XILINX; (или альтера)

(отсутствите инструмента define в VHDL все же минус :(, генерейт не столь удобен )

 

Предлагаю это тоже внести как правило ?

 

PS. Интересно а все сигналы ЛЯ альтеры имеют активный '0' или нет ?

Share this post


Link to post
Share on other sites

2 CaPpuCcino и vetal

 

 

с остальным согласен - сигналы инициализировать не стоит, но ток сбрасывать; для функции инициализация не страшна - переменные динамические (если ток в новом стандарте не появятся статические переменные функции как это сделали в СВ)

 

 

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

 

 

Больше вопросов чем ответов. Почему сигналы сбрасывать не стоит ? Берем простой пример: 10 ти ступенчатый конвейер, параллельно с которым идет сигнал валидности данных. В этом случае начальное состояние регистров не важно, но для симуляции, почему бы не проинитить их нулями без сигнала сброса. В реальном же железе введние сигнала сброса на эти цепи не имеет смысла, кроме раздувания логики.

 

То же самое ИМХО касается использования переменных, отладчиком проще по коду лазить. Хотя думаю что в случае использования переменных только для упрощения описания, а не имплементации регистров и т.д. разницы между проинициализированной переменной и просто переменной нет.

 

Насчет динамических и статических переменных а разве impure функции в ВХДЛ не для этого придуманы ?

 

Так все таки убирать это правило или нет ? (IMG:style_emoticons/default/smile.gif)

Сигнал reset - особенный сигнал, и требует особого отношения. Для этого сигнала, как правило, отводится глобальная цепочка внутри ПЛИС, но когда все глобальные линии заняты клоками и/или прочими более важными сигналами, то может встать вопрос о целесообразности заводить данный сигнал на все триггеры, и особенно на те, которые инициализируются снаружи. Это может и не актуально на новых чипах, зато на тех, что постарше можно напороться на сложности с разводкой и пр. гадости. При выбрасывании этого сигнала за пределы глобальных трассировочных ресурсов - необходимо добиться, с помощью ограничений и/или прочих доступных инструментов того, что бы данный сигнал корректно отрабатывался и при этом влиял на быстродействие схемы с минимальными потерями, что достигается применением специальных приемов (ссылку на форуме выкладывали).

 

Убирать правило не стоит, но можно смягчить формуировку для случаев когда без этого не обойтись.

 

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

constant RESET_POLARITY_XILINX : std_logic := '1';

constant RESET_POLARITY_ALTERA : std_logic := '0';

 

constant RESET_POLARITY : std_logic := RESET_POLARITY_XILINX; (или альтера)

(отсутствите инструмента define в VHDL все же минус (IMG:style_emoticons/default/sad.gif), генерейт не столь удобен

Примерно так и сделано.

 

интересно а все сигналы ЛЯ альтеры имеют активный '0' или нет ?

Нет, только сигналы асинхронного сброса и установки триггеров.

 

Предлагаю это тоже внести как правило ?

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

Что может быть не актуально для большинства разработок.

Share this post


Link to post
Share on other sites

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

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

А как насчет переложения содержимого на родную речь?

Share this post


Link to post
Share on other sites

2 vetal

 

Сигнал reset - особенный сигнал, и требует особого отношения. Для этого сигнала, как правило, отводится глобальная цепочка внутри ПЛИС, но когда все глобальные линии заняты клоками и/или прочими более важными сигналами, то может встать вопрос о целесообразности заводить данный сигнал на все триггеры, и особенно на те, которые инициализируются снаружи. Это может и не актуально на новых чипах, зато на тех, что постарше можно напороться на сложности с разводкой и пр. гадости. При выбрасывании этого сигнала за пределы глобальных трассировочных ресурсов - необходимо добиться, с помощью ограничений и/или прочих доступных инструментов того, что бы данный сигнал корректно отрабатывался и при этом влиял на быстродействие схемы с минимальными потерями, что достигается применением специальных приемов (ссылку на форуме выкладывали).

 

хмм господа, либо я торможу либо что то тут не так. Объясните мне темному чем вот это

signal pipa : std_logic_vector;

pipa_proc : process (

clk

) is

begin

if (rising_edge(clk)) then

pipa <= popa;

end if;

end process;

лучше чем вот это

signal pipa : std_logic_vector := (others => '0');

pipa_proc : process (

clk

) is

begin

if (rising_edge(clk)) then

pipa <= popa;

end if;

end process;

 

если регистр pipa не требует сброса ?

 

ведь именно об этом идет реч. обе схемы синтезируются и собираються одинаково.

 

зачем городить сброс если он не нужен ? я считаю это излишним т.к:

1. Если нас интересует момент включения фпга, то там и так будет предопределенное состояние (ставиться в атрибутах загрузки битстрима)

2. Если при работе не нужно сбрасывать регистр и валидность данных в регистре определяеться либо другим сигналом либо корректным поведением сигнала разрешения записи в этот регистр.

 

 

2 maksya

 

No I will never do it. Because i think each engineer must know English language. ;)

Share this post


Link to post
Share on other sites

2 maksya

 

No I will never do it. Because i think each engineer must know English language. ;)

All right then, have it your own way. Whatever the case, this is your activity and I'm not entitled to blame your choice.

Share this post


Link to post
Share on other sites

2 vetal

 

 

 

Сигнал reset - особенный сигнал, и требует особого отношения. Для этого сигнала, как правило, отводится глобальная цепочка внутри ПЛИС, но когда все глобальные линии заняты клоками и/или прочими более важными сигналами, то может встать вопрос о целесообразности заводить данный сигнал на все триггеры, и особенно на те, которые инициализируются снаружи. Это может и не актуально на новых чипах, зато на тех, что постарше можно напороться на сложности с разводкой и пр. гадости. При выбрасывании этого сигнала за пределы глобальных трассировочных ресурсов - необходимо добиться, с помощью ограничений и/или прочих доступных инструментов того, что бы данный сигнал корректно отрабатывался и при этом влиял на быстродействие схемы с минимальными потерями, что достигается применением специальных приемов (ссылку на форуме выкладывали).

 

 

 

хмм господа, либо я торможу либо что то тут не так. Объясните мне темному чем вот это

 

 

signal pipa : std_logic_vector;

pipa_proc : process (

clk

) is

begin

if (rising_edge(clk)) then

pipa <= popa;

end if;

end process;

 

 

лучше чем вот это

 

 

signal pipa : std_logic_vector := (others => '0');

pipa_proc : process (

clk

) is

begin

if (rising_edge(clk)) then

pipa <= popa;

end if;

end process;

 

 

 

если регистр pipa не требует сброса ?

 

ведь именно об этом идет реч. обе схемы синтезируются и собираються одинаково.

 

зачем городить сброс если он не нужен ? я считаю это излишним т.к:

1. Если нас интересует момент включения фпга, то там и так будет предопределенное состояние (ставиться в атрибутах загрузки битстрима)

2. Если при работе не нужно сбрасывать регистр и валидность данных в регистре определяеться либо другим сигналом либо корректным поведением сигнала разрешения записи в этот регистр.

 

Ды в том-то идело - я на 100% знаю, что там '0'. Или мне чихать на значение, при условии что оно имеет какую либо величину '0'/'1'. Только симулятор не догадывается, что там произвольное значение приимает '0' или '1', а не 'X','U' или 'Z'.

 

Вы не дописали. Надо было писать:

pipa<=popa;

popa<=pipa+1;

Что будет в popa, если вы не проинициализируете popa и pipa? :)

 

Допустим, что popa - регистр адреса блока памяти, который по документации во время инициализации обнуляется, а мы, в симуляторе 'X' пихаем. Что мы насимулируем(без инициализации), когда этот регистр адреса затянут обратной связью, с ячейками памяти, которые не инициализированы, хотя по документации ситуация сходна с регистрами адреса?

 

ЗЫ: Найдите решение уравнения pipa=F(pipa) при pipa='U'. :)

Share this post


Link to post
Share on other sites

2 vetal

Ды в том-то идело - я на 100% знаю, что там '0'. Или мне чихать на значение, при условии что оно имеет какую либо величину '0'/'1'. Только симулятор не догадывается, что там произвольное значение приимает '0' или '1', а не 'X','U' или 'Z'.

 

а разве вот эта строчка

signal pipa : std_logic_vector := (others => '0');

не подскажет симулятору что именно там лежит ?

 

 

Вы не дописали. Надо было писать:

pipa<=popa;

popa<=pipa+1;

Что будет в popa, если вы не проинициализируете popa и pipa? :)

 

 

похоже что вы либо не совсем поняли вот эту фразу или просто ее не заметили ;)

 

Если при работе не нужно сбрасывать регистр и валидность данных в регистре определяеться либо другим сигналом либо корректным поведением сигнала разрешения записи в этот регистр.

 

 

Допустим, что popa - регистр адреса блока памяти, который по документации во время инициализации обнуляется, а мы, в симуляторе 'X' пихаем. Что мы насимулируем(без инициализации), когда этот регистр адреса затянут обратной связью, с ячейками памяти, которые не инициализированы, хотя по документации ситуация сходна с регистрами адреса?

 

Ситуация сходна с тем, что я описал выше.

если popa это регистр адресса, и вы спроектировали свой КА таким образом, что бы он например перебирал адреса то за предположение о начальном значении регистра адреса ИМХО сразу растреливать нужно. В таких моментах нужно четко иметь сигнал сброса/установки этого регистра.

Продолжая тему памяти если же я точно знаю (а как я могу не знать точно если я это проектирую) что сигналы RdEna, WrEn a не будут выставленны на память при некорректном значении адреса, то какая разница есть сброс в регистре адресса памяти или его нет.

Share this post


Link to post
Share on other sites

Я как раз и говорю, что сбрасывать не надо, а для корректности симуляции обязательно проинициализировать абсолютно все триггеры. Т.к. в железке за нас это сделает сама микросхема во время загрузки.

 

Продолжая тему памяти если же я точно знаю (а как я могу не знать точно если я это проектирую) что сигналы RdEna, WrEn a не будут выставленны на память при некорректном значении адреса, то какая разница есть сброс в регистре адресса памяти или его нет.

1. Сигнала RdEnа - нет.

2. WrEn - зависит от начального значения адреса.

3. Из (2) необходим ЛИБО сброс ЛИБО инициализация.

 

за предположение о начальном значении регистра адреса ИМХО сразу растреливать нужно

Это не предположение, а документированная характеристика блока памяти(M4K) - всегда, после включения на адресе 0.

 

Про "предположение" - нарисуйте круг, и вы поймете о чем я говорю. Совершенно не актуально с какой стороны круга начинать работу. Для восприятия достаточно найти начало круга.

 

Подитог.

Я не согласен с формулировкой:

4.32. RTL: It is not allowed to initialize signals at their declaration. It is not allowed to initialize variables at their declaration in processes. It is acceptable to initialize variables at their declaration inside functions.

Т.к. при строгом соблюдении данного правила, в некоторых случаях, моделирование данного кода не соответствует действительности. Необходимо смягчить формулировку: "За исключением случаев, когда без инициализации невозможно адекватно верифицировать систему".

Share this post


Link to post
Share on other sites

Я не согласен с формулировкой:

4.32. RTL: It is not allowed to initialize signals at their declaration. It is not allowed to initialize variables at their declaration in processes. It is acceptable to initialize variables at their declaration inside functions.

Т.к. при строгом соблюдении данного правила, в некоторых случаях, моделирование данного кода не соответствует действительности. Необходимо смягчить формулировку: "За исключением случаев, когда без инициализации невозможно адекватно верифицировать систему".

Так ведь речь о RTL, а не о SIM (см. раздел Conventions). Поэтому и добавлять в формулировку слова "моделирование" и "верификация" не совсем корректно.

Share this post


Link to post
Share on other sites

Я не согласен с формулировкой:

4.32. RTL: It is not allowed to initialize signals at their declaration. It is not allowed to initialize variables at their declaration in processes. It is acceptable to initialize variables at their declaration inside functions.

Т.к. при строгом соблюдении данного правила, в некоторых случаях, моделирование данного кода не соответствует действительности. Необходимо смягчить формулировку: "За исключением случаев, когда без инициализации невозможно адекватно верифицировать систему".

Так ведь речь о RTL, а не о SIM (см. раздел Conventions). Поэтому и добавлять в формулировку слова "моделирование" и "верификация" не совсем корректно.

 

RTL: Register Transfer Level (almost equivalent to « synthesizable »).

BEH : Behavioral code almost equivalent to « synthesizable »).

SIM : Test benches, test code and resources for simulation and verification in general.

 

Все строится для того, что бы отлаживать (моделировать, верифицировать) RTL модель(описание) с помощью формирователя тестовых воздействий(testbench) уровня абстракции - SIM и выше, вплоть до TLM(с мостом TCA).

Просто SIM(TLA,TCA) используется для проработки идеи.

PS:

TLA - transaction level accurate

TCA - true cycle accurate

Share this post


Link to post
Share on other sites

Все строится для того, что бы отлаживать (моделировать, верифицировать) RTL модель(описание) с помощью формирователя тестовых воздействий(testbench) уровня абстракции - SIM и выше, вплоть до TLM(с мостом TCA).

Просто SIM(TLA,TCA) используется для проработки идеи.

PS:

TLA - transaction level accurate

TCA - true cycle accurate

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

 

И вообще, специфика данной темы заключается в том, что все обсуждения должны строиться только на соглашениях, принятых в документе elecard_vhdl_coding_styles_rules.doc. Я ведь не сказал, что Вы не правы впринципе. Я лишь отметил, что в контексте данного документа Ваше замечание не имеет силы до тех пор, пока не произойдут изменения в разделе Conventions. А пока, насколько Я понял, здесь под RTL понимается именно синтезируемое описание устройства на уровне регистровых передач. Следовательно, никаких языковых средств для моделирования в коде (в этом случае) быть не должно. "4.32. RTL: It is not allowed to ..." - Раз в начале стоит слово RTL, то остальная фраза относится именно к RTL !

 

[отступление от документа]

Честно сказать, мне самому тоже не нравится выделение RTL, BEH и SIM. IMHO, все три термина относятся к своей группе:

- (уровни абстракции описания) транзистор-вентиль-RTL-функция-поведение-система [можно и TLM приплести при желании :)]

- (форма представления проекта) BEHaviour - Structure

- (средства отладки описания) SIMulation (кстати моделировать можно на ЛЮБОМ уровне описания - от бега электронов в транзисторе до работы на системном уровне), Formal Verification, визуальный анализ кода ...

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.

×
×
  • Create New...