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

[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]

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

[Timmy]

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

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

[gin]

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

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

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

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

[Shivers]

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

[gin]

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

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

[Shivers]

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

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

[gin]

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

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

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

[Bad0512]

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

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

[Shivers]

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

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

[gin]

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

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

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

[Shivers]

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

[TRILLER]

-выключить автоудаление дублей.

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

[Shivers]

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

[gin]

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

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

Код

set_multicycle_path -from [get_registers {arst_logic:arst_logic_inst|d2_a}] -to [get_clocks {clk_a}] -setup -end 2
set_multicycle_path -from [get_registers {arst_logic:arst_logic_inst|d2_a}] -to [get_clocks {clk_a}] -hold -end 2

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

[Bad0512]

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

Код

set_multicycle_path -from [get_registers {arst_logic:arst_logic_inst|d2_a}] -to [get_clocks {clk_a}] -setup -end 2
set_multicycle_path -from [get_registers {arst_logic:arst_logic_inst|d2_a}] -to [get_clocks {clk_a}] -hold -end 2

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

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

[gin]

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

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

[Shivers]

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

[ViKo]

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

[alexadmin]

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

[Bad0512]

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

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

[Shivers]

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

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

[Bad0512]

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

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

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

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

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

[gin]

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

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

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

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

[krux]

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

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

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

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

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

[Shivers]

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

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