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

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

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<

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


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