реклама на сайте
подробности

 
 
> Асинхронный резет для нескольких таковых доменов, Как правильно делать?
MIX@
сообщение Jan 10 2013, 13:31
Сообщение #1


Участник
*

Группа: Участник
Сообщений: 53
Регистрация: 21-01-09
Пользователь №: 43 756



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

Делаю проект на альтере (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
Go to the top of the page
 
+Quote Post
 
Start new topic
Ответов
SM
сообщение Jan 10 2013, 17:23
Сообщение #2


Гуру
******

Группа: Свой
Сообщений: 7 946
Регистрация: 25-02-05
Из: Moscow, Russia
Пользователь №: 2 881



Цитата(MIX@ @ Jan 10 2013, 17:31) *
Проблема - TimeQuest выдаёт дофигище нарушений ограничения типа Recovery/Removal практически во всех блоков всех тактовых доменов.

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


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

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

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



Reply to this topicStart new topic
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0

 


RSS Текстовая версия Сейчас: 21st August 2025 - 07:09
Рейтинг@Mail.ru


Страница сгенерированна за 0.01406 секунд с 7
ELECTRONIX ©2004-2016