Асинхронный сброс Опции

[gin]

Всем привет! Возникли вопрсы по реализации асинхронного сброса в проекте. Посмотрел рекомендации Альтеры по этому поводу (http://quartushelp.altera.com/13.0/mergedProjects/verify/da/comp_file_rules_reset_external.htm) и реализовал вторую схему (два триггера на сброс которых приходит внешний асинхронный ресет, на входе D первого - лог. "1", выход первого идет на D вход второго, с выхода второго и берется сигнал для дальнейшего сброса схемы).
Запустил Таймквест - получил отрицательные слаки по recovery time. Насколько это опасно при для корректной работы ПЛИС, и как избавиться от этих слаков? Спасибо.

Сообщение отредактировал gin - Oct 22 2013, 08:07

[Shivers]

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

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

[Bad0512]

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

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

Всё то, что вы говорите видимо актуально для Альтеры, у Хилых всё немного по-другому:
1. Для сброса есть отдельный dedicated вход на триггере, атрибутами он может конфигуриться как синхронный либо асинхронный.
2. Никаких специальных роутинговых ресурсов под ресеты не заложено, они распространяются по обычному интерконнекту, как и любые другие сигналы (в отличии например от клоков).
Поэтому имеет смысл уменьшать fanout для того чтобы облегчить роутеру задачу.

Для меня вообще остается загадкой, как технологически гарантируется корректный старт пользовательской логики ФПГА по завершении этапа конфигурации. Понятно, что есть глобальный enable для всех триггеров, но ведь каждый из триггеров может работать от разной частоты, и значит надо енабл к этой частоте подсинхронизировать - этож гигантские накладные расходы.
Нет ли где описания на эту тему для почитать?

У Хилых процесс отпускания всех триггеров синхронен либо с JTAG clock либо с USER clock - это рулится опциями bitgen.