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

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

recovery time куда? Если на сброс самих триггеров-синхронизаторов сброса, то это в большинстве случаев нормально, и надо поставить false path на этот путь.

Клоков несколько, на каждый из них естественно своя схема сброса. Проблема только с одним клоком



Не выполняется recovery time для всех триггеров в данном клоковом домене

Посмотрите внимательно, возможно вы сброс из одного клокового домена использовали в триггере из другого домена. Если вы что то еще хитрое творите со схемой сброса, проблема может и вообще в другом быть, в междоменных триггерах пересинхронизации, к примеру.
Если клоки между собой асинхронные, не забывайте между ними делать false_path, либо create_clock_groups -asynchronous.

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

Очень может быть, ведь асинхронный ресет не резиновый - количество глобальных сбросов можно вычитать из даташита.

p.s. наврал с констрейном. set_clock_groups - так правильно

Квартус и клоки, и сбросы заводит на глобальные линии, так что их видимо пока хватает. Я попробовал уменьшить частоту со 155 до 145 МГц - при 145 recovery time удовлетворяет требованиям. Получается, что не хватает нескольких сотен пикосекунд. Мне кажется, что возможно задать ограничение на время между снятием сигнала сброса и фронтом клока для триггеров, только вопрос как?

Скорее всего у вас слишком большой fanout у цепи сброса, можно попытаться его уменьшить.В синплифае это делается директивой "syn_maxfan".

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

p.s. Во! И как я забыл, ай яй: если вы не формируте сброс длительностью в один такт, то напишите на цепь сброса малтисайкл 2 или больше. Должно помочь.

Fan-out действительно большой - 1548, с другой стороны, Квартус завел сброс на глобальную линию, там не должно так сильно влиять. Дублировать не очень хочется - тогда ведь дубли займут другие глобальные линии, тем более в проекте еще будут другие клоки и сбросы.
Сброс у меня будет формироваться при отсутствии (пропадание) сигнала locked от PLL, не знаю сколько по времени, наверное гораздо дольше чем один такт)) Может мультицикл поможет, не приведете пример, как его описать?

По идее, это пишется как то так (проверить не на чем): set_multicycle_path 2 -from (путь иерархии до выхода триггера, формирующего сброс) -to (клок)
Раньше эту команду можно было прямо в квартусе выбирать из выпадающего списка. Путь иерархии можно было искать по именам регистров после синтеза. Значение малтисайкла и клок тоже из выпадающего меню можно было выбрать. Я с квартусом года два уже не работал, забывать стал

А где эта галочка?

Раньше за это специальная галочка отвечала, где то в настройках квартуса. Сейчас - не знаю. Гуглите. Вот, например >link<

Прописал в констрейтах мультицикл, как вы и рекомендовали - помогло, спасибо!
Собственно вот что написал:


Только теперь вопрос возник, насколько квартус всё это понял. Гарантирует ли он, что асинхронный сброс снимется со всех регистров одновременно? Не будет ли такой ситуации, что ресет с одной части регистров снимется перед фронтом клока, а с другой части - после фронта?

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

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

Да, это проблема. Разброс скорее всего будет, и большой. В 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 контуром или приходит напрямую с разъема, то такой подход вообще не живет.
Книжки во многом правы, но если стандарт того не требует, я бы все же применил обычную схему синхронизации.