[Kopart 0]

 Вы всё про FPGA, в которой есть ресет при включении.

А вот в ASIC - такого нет.

 

Обычно в библиотеках есть компоненты FF (flip-flop) без ресета (синхронный сброс на логике) и со специальным асинхронным сбросом.

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

Иногда требуется сбросить триггеры, когда выключен клок.

 

Обычно для надежности (что всё учли) ставят асинхронный ресет во все тригерры asic. 

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

Все  остальные (в цепочке обработки) можно использовать без ресета.

Но это требует дополнительных трудозатрат.

Хотя это можно проверить при симуляции. Там где забыли использовать сигнал общего ресета - выход тригерра будет в не определённом состоянии.

 

Так что можно резюмировать для ASIC: вход асинхронного ресета необходим для определенных триггеров.

А также при симуляции можно явно не прописывать модельную инициализацию, а делать как и будет в "железе" с ресетом. 

[sazh 3]

 Вы всё про FPGA, в которой есть ресет при включении.

А вот в ASIC - такого нет.

Так что можно резюмировать для ASIC: вход асинхронного ресета необходим для определенных триггеров.

А также при симуляции можно явно не прописывать модельную инициализацию, а делать как и будет в "железе" с ресетом. 

 

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

Хотя по включению питания эти элементы вставали в состояние как им заблагорассудится.

Было забавно наблюдать как некоторые горе разработчики тумблером по питанию щелчками туда сюда добивались работоспособности разработанного устройства.

Так что неопределенность при моделировании - это благо. А ресет - необязательно.

[yes 5]

я тоже хочу высказаться за асинхронный сброс - иногда без него не обойтись и времянка нормальным STA анализируется так же как и для синхронного (называется RECOVERY REMOVAL - аналоги SETUP HOLD)

 

примеры обязательного асинхронного сброса - места где определенное состояние должно быть до того как пойдет тактовый сигнал

это всяческие шины, переходы между тактовыми доменами и т.п.

 

а для FPGA использование синхронного сброса жрет FABRIC, то есть трассировочные ресурсы, что может быть весьма критичным для плотного дизайна

 

----------------

 

специфически по поводу ASIC, хочу заметить, что я тоже разделял такие заблуждения, но не поленился и посмотрел библиотеки TSMC 90-40nm

 

А вот в ASIC - такого нет.

 

Обычно в библиотеках есть компоненты FF (flip-flop) без ресета (синхронный сброс на логике) и со специальным асинхронным сбросом.

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

Иногда требуется сбросить триггеры, когда выключен клок.

 

Обычно для надежности (что всё учли) ставят асинхронный ресет во все тригерры asic. 

 

Так что можно резюмировать для ASIC: вход асинхронного ресета необходим для определенных триггеров.

А также при симуляции можно явно не прописывать модельную инициализацию, а делать как и будет в "железе" с ресетом. 

 

в библиотеках полно триггеров с синхронным сбросом/установкой, их обычно столько же сколько и с асинхронными

площади равны (даже в более мелких библиотеках синхронный сброс может быть меньшей площади, чем асинхронный)

 

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

 

асинхронный сброс в АЗИКах может требоваться для работы логики сканирования (SCAN) и т.п. - но это зависит от требований бэкенда

 

=======================

 

выскажу такую мысль - если есть возможность построить логику без сброса для АЗИКа и особенно для FPGA, то этим можно воспользоваться,

 

для ASIC триггера без сброса значительно меньше триггеров со сбросом (в полтора раза)

 

для FPGA не тратится трассировка

 

 

 

 

 

 

 

[LV26 0]

я тоже хочу высказаться за асинхронный сброс - иногда без него не обойтись и времянка нормальным STA анализируется так же как и для синхронного (называется RECOVERY REMOVAL - аналоги SETUP HOLD)

 

примеры обязательного асинхронного сброса - места где определенное состояние должно быть до того как пойдет тактовый сигнал

это всяческие шины, переходы между тактовыми доменами и т.п.

 

а для FPGA использование синхронного сброса жрет FABRIC, то есть трассировочные ресурсы, что может быть весьма критичным для плотного дизайна

 

----------------

 

специфически по поводу ASIC, хочу заметить, что я тоже разделял такие заблуждения, но не поленился и посмотрел библиотеки TSMC 90-40nm

 

 

 

в библиотеках полно триггеров с синхронным сбросом/установкой, их обычно столько же сколько и с асинхронными

площади равны (даже в более мелких библиотеках синхронный сброс может быть меньшей площади, чем асинхронный)

 

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

 

асинхронный сброс в АЗИКах может требоваться для работы логики сканирования (SCAN) и т.п. - но это зависит от требований бэкенда

 

=======================

 

выскажу такую мысль - если есть возможность построить логику без сброса для АЗИКа и особенно для FPGA, то этим можно воспользоваться,

 

для ASIC триггера без сброса значительно меньше триггеров со сбросом (в полтора раза)

 

для FPGA не тратится трассировка

 

Да я тоже за асинхронный сброс триггеров.

Синхронный сброс в общем случае внедряется в "datapath", что чревато деградацией быстродействия.

Только вот внешний сброс с пина надо синхронизировать, IMHO.

[Oldring 0]

Синхронный сброс в общем случае внедряется в "datapath", что чревато деградацией быстродействия.

 

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

[dmitry-tomsk 0]

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

Да это неважно, грамотный сброс и pll (dcm) сбрасывает, а пока первый фронт на выходе появится - сброс уже давно будет снят со всех триггеров даже самой большой плис.

[aser 0]

Лет 10 назад в ПЛИС Xilinx рекомендовалось ВСЕ триггеры делать с асинхронным сбросом, тогда он реализовался через правильную сеть GSR.

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

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

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

 

[dvladim 0]

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

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

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

[LV26 0]

...

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

...

 

Ссылку, пожалуста.

[des00 25]

Ссылку, пожалуста.

White paper от хилых 3-4 годичной давности

[LV26 0]

White paper от хилых 3-4 годичной давности

 

Нее... des00 - это не серьезно :laughing:

Покажите мне пожалуйста, анатолий источник, где "настаивается" на синхронном ресете.

 

Единственное, что есть например в Xilinx WP-272 так это

"Flip-flops being reset can employ a synchronous set (FDS) or synchronous

reset (FDR) leading to a fully synchronous design and easy timing specifications and

analysis." (page 6)

 

Кто-то сможет заявить, что can имеет "настоятельный смысл"?

 

P.S.

Немного не в тему - но часто путают смысл слов "shall, should, may, can..."

Когда-то для себя составил вот такой файл "ISO Key words/IETF Key words (RCF2119)"

Надеюсь кому-то пригодится... иногда из-за неправильного понимания одного слова делаются весьма категоричные

умозаключения.

conformance_keywords.txt

Изменено 17 ноября, 2010 пользователем Victor®

[des00 25]

Нее... des00 - это не серьезно :laughing:

Покажите мне пожалуйста, анатолий источник, где "настаивается" на синхронном ресете.

если вы ищете именно такое слово, то нет. Но сама идея, которую доносят например эти документы

 

wp231 HDL Coding Practices to Accelerate Design Performance

wp275 Get your Priorities Right – Make your Design Up to 50% Smaller

 

утверждает об увеличении производительности систем без асинхронного сброса :

Few system-wide choices have as profound an effect on performance, area, and power as the choice of the reset. Some system architects specify the use of a global asynchronous reset for the system for the sole purpose of circuit initialization at power-up. This is, however, not necessary for FPGA designs. With Xilinx FPGA architectures, the use of a reset and the type of reset can have serious implications on the design performance © wp231

но если вам нужны шашечки, то вы правы

[LV26 0]

если вы ищете именно такое слово, то нет. Но сама идея, которую доносят например эти документы

 

wp231 HDL Coding Practices to Accelerate Design Performance

wp275 Get your Priorities Right – Make your Design Up to 50% Smaller

 

утверждает об увеличении производительности систем без асинхронного сброса :

 

но если вам нужны шашечки, то вы правы

 

Нет, шашечки мне не нужны :-)

 

Я повторю лишь свою первую реплику. Для меня вопрос ясен и понятен.

 

1) Разборки с резетом - дело интимное для каждого проекта.

2) Надо стараться не использовать резет вообще. Или только там, где это однозначно необходимо.

3) Синхронизировать внешний резет (если уж припекло его использовать). Асинхронный assert, синхронный deassert.

[ViKo 1]

Немного не в тему - но часто путают смысл слов "shall, should, may, can..."

Когда-то для себя составил вот такой файл "ISO Key words/IETF Key words (RCF2119)"

Надеюсь кому-то пригодится...

В стандарте на SystemVerilog тоже специально обращается внимание на это.

The terminology conventions used throughout this standard are as follows:

— The word shall is used to indicate mandatory requirements strictly to be followed in order to

conform to the standard and from which no deviation is permitted (shall equals is required to).

— The word should is used to indicate that among several possibilities one is recommended as

particularly suitable, without mentioning or excluding others; or that a certain course of action is

preferred but not necessarily required; or that (in the negative form) a certain course of action is

deprecated but not prohibited (should equals is recommended that).

— The word may is used to indicate a course of action permissible within the limits of the standard

(may equals is permitted to).

— The word can is used for statements of possibility and capability, whether material, physical, or

causal (can equals is able to).

И переводил я их так

shall – должно (необходимо, обязательно)

should – может (рекомендуется)

may – может (разрешается, допускается)

can – можно (возможно)

 

 

[yes 5]

В стандарте на SystemVerilog тоже специально обращается внимание на это.

 

И переводил я их так

shall – должно (необходимо, обязательно)

should – может (рекомендуется)

may – может (разрешается, допускается)

can – можно (возможно)

 

[off, сорри не удержался]

 

ну в английском с модальностями вообще без 100 грам не разберешься

 

must, ought, would, might, потом всякие формы have to, be to и так далее

до чего империализм довел разговорный язык :)

 

то ли дело китайский даташит - must и mustn't - все понятно :)

 

какая-то ностальгия, учил ведь когда-то а нынче помню меньше половины :(

http://en.wikipedia.org/wiki/English_modal_auxiliary_verb