[Мур 1]

Поясните свой тезис пожалуйста.

С каким из утверждений вы не согласны?

 

Да дело не в ошибочности утверждений, а в подходе к достижению цели.

Принцип параллельного выполнения процессов трудно осознается последовательными программистами. Гораздо проще сразу видеть в синтаксисе электрические схемы.(это удел железячников).

И потом,- в голове HDL дизайнера постоянно сидит архитектура базовой макроячейки и тогда сам становишься синтезатором, распределяя этот ресурс наиболее приемлемым образом. Результат виден во вьювере... Как способ угадать действия синтезатора...

 

HDL-дизайнер пишет пожелания, которые со временем меняются, чтобы достичь приемлемого быстродействия. Итерации этого процесса более изнурительны, чем у программистов контроллеров, где есть взаимно однозначное соответствие между написанным и реальным выполнением. Да и степень абстракций HDL-дизайнера явно недостаточно. Очень напоминает ассемблер... ИМХО

[Golikov 0]

А как ваше пренебрежение программистами отвечает на изначально поставленный вопрос и его развитие. Что надо писать в списке чувствительности и почему?

 

Кстати мир меняется быстрее чем кажется. Уже сейчас появляются предложения описания задачи максимально абстрактно чтобы у синтезатора было больше маневра для оптимизации. И пишут это авторы синтезатора, и я проверил реально стервец хорошо задачу решает. Некоторые решения даже ставят в тупик реальным качеством результата...

[Flip-fl0p 4]

Посмотрел я, что пишут наши зарубежные коллеги.

http://www.alteraforum.com/forum/showthread.php?t=5002

Цитирую :

Quartus ignores sensitivity lists for synthesis. The logic produced is defined by the code signals used within the process.

From memory I cannot remember whether Quartus even produces a warning.

Modelsim on the other hand does make use of sensitivity lists so missing signals in the list can produce different behaviour between simulation and synthesis.

 

Sensitivity lists are there purely for simulation - they let the simulator know when a process needs to be executed. This saves alot of processor time because it doesnt need to re-evaluate every process whenever a signal changs.

 

Поскольку изначально VHDL был придуман в 1983 как язык моделирования схем. А в то время, вычислительные мощности были очень и очень скромные, то необходимо было средство, которое будет экономить вычислительные ресурсы. Списки чувствительности и были сделаны для этого. Не просто так, в VHDL 2008 разрешили список чувствительности писать так:

PROCESS (ALL)

Ведь вычислительные мощности возросли на несколько порядков, и отпала острая необходимость в экономии вычислительных мощностей. Хотя это все моё предположение. Но если обратиться к книгам, то во многих книгах пишут примерно то-же. Списки чувствительности - нужны для ускорения процесса моделирования.

[Мур 1]

А как ваше пренебрежение программистами отвечает на изначально поставленный вопрос и его развитие. Что надо писать в списке чувствительности и почему?

 

Кстати мир меняется быстрее чем кажется. Уже сейчас появляются предложения описания задачи максимально абстрактно чтобы у синтезатора было больше маневра для оптимизации. И пишут это авторы синтезатора, и я проверил реально стервец хорошо задачу решает. Некоторые решения даже ставят в тупик реальным качеством результата...

Да с чего вы взяли, что у меня пренебрежение?..

Это совершенно разные вселенные!.. Ничего общего! Тут проще всего железячникам.

 

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

 

Вот и получается, что общее для и для HDL-дизайнера и программиста контроллеров,- понимание задачи.

[Golikov 0]

получаешь структуру предельно сложную

Сложную структуру где и чего?

 

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

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

 

[Мур 1]

Сложную структуру где и чего?

...того, что вами описывается кодом(как вам кажется)..

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

 

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

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

 

Вы пробуйте для начала и тогда делайте выводы. Вьювер RTL вам в помощь.

[Golikov 0]

Забавный человек, буквы вроде одни и те же а слов не понимает:)...

 

Перегружать список чувствительности не стоит.

А то что будет?

 

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

то есть схемы вида out = in1 & in2 | in3 надо избегать и делать их синхронными? И кроме задержки в такт в добавок как раз получить потенциальную возможность мета-стабильности?

 

 

Так потому симуляция и разная, что создаются разные схемы.

А вот схема похоже как раз создается одна и та же, просто она либо полно либо не полно отражается в симуляции, о чем и разговор.

[Flip-fl0p 4]

...того, что вами описывается кодом(как вам кажется)..

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

 

 

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

 

Вы пробуйте для начала и тогда делайте выводы. Вьювер RTL вам в помощь.

Не совсем понял Вас.

А как-же стандарт VHDL 2008, разрешающий такое вот описание списка чувствительности: PROCESS (ALL) ?

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

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

Гораздо более интересное поведение, если список сделать неполным. Тогда изменение неуказанного сигнала, не запустит процесс на моделирование - и как следствие расхождение в поведении реальной схемы и проведение на моделирование.

Вот кстати уже были похожие вопросы :

https://electronix.ru/forum/index.php?showtopic=92126

Позволю себе процитировать одно сообщение :

Список чувствительности используется тогда, когда идет моделирование процесса.

Список чувствительности это команда, что когда изменилось состояние одного сигналов списка (event=1) пришло время заглянуть в этот процесс и посмотреть что там происходит.

 

Т.е. если в процессе описываем триггер конструкцией вида if (clk='1' and clk'event), то процесс clk надо вписать в список чувствительности, что бы "ускорить" моделирование. Хотя у меня в ActiveHDL все моделируется и когда я забываю про список.

 

Синтезатору на этот список начихать, но Synplify PRO в варнингах предупредит, что список чуствительности не полон, на синтезированную схему это не повлияет.

 

Идем далее

Посмотрите на следующий код

Код

library IEEE;

use IEEE.STD_LOGIC_1164.all;

use IEEE.STD_Logic_arith.all;

 

entity TEMP is

port (clk: in std_logic;

a: out integer);

end entity TEMP;

 

architecture archi of TEMP is

signal b: integer:=0;

begin

process (clk)

begin

b<=b+1;

end process;

a<=b;

end architecture;

 

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

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

Изменено 11 апреля, 2017 пользователем Flip-fl0p

[Мур 1]

Забавный человек, буквы вроде одни и те же а слов не понимает:)...

 

Ваше поведение говорит мне о вашей молодости. Вам ВАЖНО получить СВОЙ опыт. Для этого нужен эксперимент. Импровизируйте,- и тогда вы поймете смысл слов.

А то что будет?

создаются избыточные конструкции, которые вам на самом деле не нужны в 50% случаев

то есть схемы вида out = in1 & in2 | in3 надо избегать и делать их синхронными? И кроме задержки в такт в добавок как раз получить потенциальную возможность мета-стабильности?

Именно так. Весь дизайн обязательно надо делать синхронным. С точностью до наоборот,- асинхронность есть почва для метастабильности

А вот схема похоже как раз создается одна и та же, просто она либо полно либо не полно отражается в симуляции, о чем и разговор.

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

 

Не совсем понял Вас.

 

Вы не путайте бенч с самим дизайном. В бенче у вас нет никаких ограничений. Вы можете фантазировать как угодно.

 

В железе - другое дело. Тут вы в базисе макроячеек и за ВСЕ придется платить. И потому избыточные конструкции тут как паразиты. Толку от них нет, а дорогой ресурс теряется...

[Flip-fl0p 4]

Такая конструкция out = in1 & in2 | in3 - это-же обычная комбинационная схема. Она даст некую задержку, которая в итоге повлияет на максимальную частоту. Если частота проекта такова, что выполняются временные ограничения по времени предустановки и удержания сигнала (Tsu, Th) то никаких проблем я здесь не вижу (поправьте меня если я ошибаюсь). Как комбинационная логика приведёт к метастабильности ? Как относиться комбинационная логика к синхронному дизайну ?

И как список чувствительности влияет на синтез, если специалист от Altera на форуме (тоже Альтеровском) ответил

Quartus ignores sensitivity lists for synthesis

[Мур 1]

Такая конструкция out = in1 & in2 | in3 - это-же обычная комбинационная схема. Она даст некую задержку, которая в итоге повлияет на максимальную частоту. Если частота проекта такова, что выполняются временные ограничения по времени предустановки и удержания сигнала (Tsu, Th) то никаких проблем я здесь не вижу (поправьте меня если я ошибаюсь). Как комбинационная логика приведёт к метастабильности ? Как относиться комбинационная логика к синхронному дизайну ?

И как список чувствительности влияет на синтез, если специалист от Altera на форуме (тоже Альтеровском) ответил

Как по мне, то говорить о некой частоте, когда все участники вашей комбинационной схемы полностью асинхронны относительно друг друга бессмысленно. ТimeQuest будет орать благим матом...

Конвейерные системы подразумевают ловить результат комбинационных схем между фронтами тактирования.

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

[Flip-fl0p 4]

Как по мне, то говорить о некой частоте, когда все участники вашей комбинационной схемы полностью асинхронны относительно друг друга бессмысленно. ТimeQuest будет орать благим матом...

Конвейерные системы подразумевают ловить результат комбинационных схем между фронтами тактирования.

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

Тогда возникает закономерный вопрос.

Что является критерием синхронной\асинхронной схемы ?

Допустим у меня есть некая схема, работающая на частоте SYS_CLK. Все элементы с памятью, триггеры, регистры, и пр тактируются от частоты SYS_CLK. В схеме присутствуют блоки комбинационной логики. Схема удволетворяет временным ограничениям. В какой момент времени схема станет асинхронной ?

Для себя я сделал вывод такой - если все элементы памяти управляются одной и той-же частотой (я не беру в расчет пересечение клоковых доменов) - то схема считается синхронной. Опять-же, поправьте, если я пришёл к неправильному выводу.

 

[Golikov 0]

Ваше поведение говорит мне о вашей молодости.

Интересный вывод. То есть попытка полностью понять что происходит, понять инструмент и в деталях управлять процессом - это молодость:)?

Вы как я понимаю точно знаете что будет да?

 

создаются избыточные конструкции, которые вам на самом деле не нужны в 50% случаев

А на основании чего вы это заявляете? Вы как я понял сторонник "деды так делали и мы так будем" :))) так вот может иногда стоит по молодецки поэкспериментировать? А заодно нам дуракам расскажете что получилось.

 

Именно так. Весь дизайн обязательно надо делать синхронным.

Вот это мне демонстрирует полное непонимание или не владение темой. С чего вдруг то надо обязательно так делать?

Более того засунут под клок приведенную схему вы создаете огромное количество проблем, чисто комбинаторная схема лишена мета-стабильности просто по определению :) Если не понимаете, спросите я объясню.

 

 

Вижу ,что вы далеки от железа.

Плохо видите) Вы не хотите слушать что вам говорят, и вешаете ярлыки не разобравшись.

 

 

 

 

 

И как список чувствительности влияет на синтез, если специалист от Altera на форуме (тоже Альтеровском) ответил

Весь интернет и форумы основных производителей ПЛИС вместе с их суппортом считают что никак, но Мур другого мнения. Правда в силу нашей молодости он не хочет нам объяснить деталей:(

 

 

Такая конструкция out = in1 & in2 | in3 - это-же обычная комбинационная схема. Она даст некую задержку, которая в итоге повлияет на максимальную частоту. Если частота проекта такова, что выполняются временные ограничения по времени предустановки и удержания сигнала (Tsu, Th) то никаких проблем я здесь не вижу (поправьте меня если я ошибаюсь). Как комбинационная логика приведёт к метастабильности ? Как относиться комбинационная логика к синхронному дизайну ?

Именно, в этом и был смысл примера, но видать он был слишком молодецким%) Более того попытки защелкнуть комбинаторику в триггера без синхронизации, вот тут то как раз все встанет в полный рост с мета-стабильностью, гонками сигналов и прочими проблемами. Это к тезису что синхронный дизайн всегда благо.

 

 

И есть один очень хороший пример

sample_and: process(d)
begin
   a <= b & c; //тут ошибка надо было a <= b and c;
end process;

Уважаемый Мур прокомментируете что будет при синтезе и симуляции данной схемы

[Мур 1]

Тогда возникает закономерный вопрос.

Что является критерием синхронной\асинхронной схемы ?

Допустим у меня есть некая схема, работающая на частоте SYS_CLK. Все элементы с памятью, триггеры, регистры, и пр тактируются от частоты SYS_CLK. В схеме присутствуют блоки комбинационной логики. Схема удволетворяет временным ограничениям. В какой момент времени схема станет асинхронной ?

Для себя я сделал вывод такой - если все элементы памяти управляются одной и той-же частотой (я не беру в расчет пересечение клоковых доменов) - то схема считается синхронной. Опять-же, поправьте, если я пришёл к неправильному выводу.

Ответ на поверхности...

ВАше описание внутренностей дизайна имеют естественную синхронность. А вот внешний мир по определению асинхронен. Корректно эти события привязать к тактированию внутренностей вашего синхронного дизайна.

У вас верные убеждения. Поправлять нечего..

[Golikov 0]

Что является критерием синхронной\асинхронной схемы

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

 

 

 

А вот внешний мир по определению асинхронен

А что делать с SPI slave при взаимодействии с мастером из внешнего мира?