Всем привет! Возникли вопрсы по реализации асинхронного сброса в проекте. Посмотрел рекомендации Альтеры по этому поводу (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

Не гарантирует, на то и мультицикл. Другое дело что в большинстве случаев это (когда снимется клок) неважно.

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

Да, это проблема. Разброс скорее всего будет, и большой. В asic это правится построением дерева сбросов, а вот в ПЛИС так выравнять не получится -какое дерево есть, такое есть. Остается только вариант с дублированием сбросов из моего предыдущего поста, возможно что квартус сам поймет, где нужно ввести дублированный сброс.
Можете в порядке эксперимента несколько раз ужать этот клоковый домен, следя за слаками. Если значение изменится скачкообразно, значит ваш домен сейчас просто превышает область одного регионального сброса, и вылезает в соседнюю область.

Да выкинуть ненужные сбросы, и всех делов!

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

Синхронный сброс в ПЛИС как раз предпочтительнее чем асинхронный именно из-за того, что он предсказуем. На эту тему есть хорошая статья у Ken Chapman - гуру из Xilinx, автор пикоблейза кроме всего прочего. Накладные расходы на синхронный сброс минимальны - пара триггеров на каждый сигнал, не более того. Может чуть больше если хочется уменьшить fanout, но всё равно это очень мало. Поведение схемы при разбросе разных ресетов можно легко посмотреть в симуляторе. В большинстве случаев ничего страшного не произойдёт. А вообще нужно стараться избегать использования сбросов там где они излишни (линии задержки, например, и т д).

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

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

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



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

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



В плане временного анализа - синхронный конечно же лучше, только не всегда есть тактовая частота, чтобы его использовать - приходится применять асинхронный. Ну и как написали, у Алтеры синхронный сброс использует ЛУТы, что может увеличить объем и задержки.

Это зависит от наличия галочки "power-up dont care" и наличия блока initial. Как ни странно он используется синтезатором квартуса. Да, это дурной тон написания кода.


Синхронный сброс триггера в альтере есть, но не во всех семействах.

И ещё один момент. Синхронный сброс может не сработать при воздействии, длящемся менее периода тактового, поэтому во многих книгах рекомендуют делать для цепей ресета async assert + sync deassert. Но это - по желанию и возможностям разработчика.

Очень спорный момент. Раньше так действительно часто делали (пример тому - схема 3 по ссылке из первого поста), это классическая схема бездребезговой кнопки. В частности, стандарт PCI требует, чтобы устройство могло быть сброшено даже в отсутствие клока. Оборотная сторона медали - помехоустойчивость ниже плинтуса. К примеру, если сброс на плате формируется RC контуром или приходит напрямую с разъема, то такой подход вообще не живет.
Книжки во многом правы, но если стандарт того не требует, я бы все же применил обычную схему синхронизации.