Асинхронный резет для нескольких таковых доменов, Как правильно делать? Опции

[MIX@]

Здравствуйте, уважаемые!

Делаю проект на альтере (Stratix IV), где имеются несколько (4-5) тактовых доменов. Клоки на все домены вырабатываются внутренним PLL от единственного внешнего синхросигнала. Сигнал внешнего сброса заведён на вход сброса PLL. Сигнал захвата PLL тактовой частоты (lock) использую как асинхронный сброс на генератор внутреннего резета (8-ми битный счётчик с триггером на выходе). Генератор внутреннего сброса синхронизируется от одного из сигналов, вырабатываемого PLL. И уже дальше этот внутренний резет идёт на входы асинхронного сброса всех остальных модулей.

Проблема - TimeQuest выдаёт дофигище нарушений ограничения типа Recovery/Removal практически во всех блоков всех тактовых доменов.

Основной вопрос - корректно ли делать такую схему сброса в принципе?

Допустим, можно синхронизировать резет на все тактовые домены, но:

1) Как это корректнее делать (имею в виду - превращение в чистый синхронный резет или же в синхронизированный асинхронный)?
2) В FPGA вроде бы есть глобальные роуты по которым идёт клок? Почему по этим же линиям нельзя пускать асинхронный сброс?
3) Есть блок (фреймбуфер), работающий сразу в 3-х тактовых тактовых доменах, с кучей Dual-Clocked FIFO для пересинхронизации - как правильно сбросить его?

Заранее спасибо за советы.

Сообщение отредактировал MIX@ - Jan 10 2013, 13:33

[Mad_max]

Посмотрите тут
http://www.eetimes.com/design/programmable...-reset-my-FPGA-
может быть что-нибудь полезное извлечете

[dvladim]

Синхронизируйте сброс для каждого домена. Если Recovery/Removal не уйдут, то придется переделывать сброс на синхронный.

[SM]

Проблема - TimeQuest выдаёт дофигище нарушений ограничения типа Recovery/Removal практически во всех блоков всех тактовых доменов.

Основной вопрос - корректно ли делать такую схему сброса в принципе?

Чтобы решить проблему в лоб - запретите анализ recovery/removal путей по этим сигналам сброса. Нарушения сразу прекратятся.

Насчет корректности, в большинстве случаев такая схема сброса корректна, если сигнал, инициирующий работу всей системы, не конфликтует по времени со снятием сигнала сброса, то есть не приходит слишком быстро после его снятия. Поэтому для таких систем стоит применять схему асинхронного сброса, как экономящую ресурсы ПЛИС. Однако, могут быть и исключения - например имеются триггеры, на которых на входе данных в момент снятия сигнала сброса присутствует сигнал, который должен на ближайшем такте сменить состояние этого триггера на противоположное от состояния в сбросе - в таком случае нарушение времени recovery/removal может привести к метастабильности. Но и тут не все так плохо - если, например, этот триггер находится в составе обыкновенного делителя, то его работа не будет нарушена, а просто сдвинута на один такт после снятия сброса, что для делителя совершенно все равно. Реальные проблемы могут возникнуть, если в момент снятия сигнала сброса приходит несколько различных синхронных сигналов, используемых совместно - например шина данных совместно с каким либо разрешенным в данный момент сигналом управления. В таком случае есть риск получить ошибку в получении данного с такой шины в первом такте после снятия сброса.

В общем - в большинстве случаев, причем в подавляющем большинстве, можно запретить анализ времянок асинхронных set/reset-цепей и спать спокойно. Но может найтись какой-то тяжелый случай, в котором соблюдение времянок типа Recovery/Removal важно. Однако, эти случаи редки, и, как правило, затрагивают схемы, управляемые не общим сбросом, а использующие асинхронный сброс в процессе их работы "локально".

[bogaev_roman]

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

Код

set_false_path -from

Если делать пересинхроннизацию сброса на каждый домен с большим fan-out, то на высокой частоте временной анализатор его не вытянет. И именно из-за этого появится полный набор различных косяков типа метастабильности. То счетчик после сброса принимает значение 0, то 1... из-за того, что в stratixiv по умолчанию синхронный сброс на ячейке поступает не на отдельный вход сброса, а на элемент and с входом данных и только после этого на вход d триггера.

[blackfin]

Генератор внутреннего сброса синхронизируется от одного из сигналов, вырабатываемого PLL. И уже дальше этот внутренний резет идёт на входы асинхронного сброса всех остальных модулей.
Основной вопрос - корректно ли делать такую схему сброса в принципе?

Q-II Handbook (v12.1,p.501):

Synchronized Asynchronous Reset

To avoid potential problems associated with purely synchronous resets and purely
asynchronous resets, you can use synchronized asynchronous resets. Synchronized
asynchronous resets combine the advantages of synchronous and asynchronous
resets. These resets are asynchronously asserted and synchronously deasserted. This
takes effect almost instantaneously, and ensures that no data path for speed is
involved, and that the circuit is synchronous for timing analysis and is resistant to
noise.
Figure 12–20 shows a method for implementing the synchronized asynchronous reset.
You should use synchronizer registers in a similar manner as synchronous resets.
However, the asynchronous reset input is gated directly to the CLRN pin of the
synchronizer registers and immediately asserts the resulting reset. When the reset is
deasserted, logic “1” is clocked through the synchronizers to synchronously deassert
the resulting reset.

[attachment=73941:Reset.jpg]

Проблема - TimeQuest выдаёт дофигище нарушений ограничения типа Recovery/Removal практически во всех блоков всех тактовых доменов.

Нужно добавить в SDC:

# Cut the asynchronous reset input
set_false_path -from [get_ports {reset_n}] -to [all_registers]