Есть каскад из двух регистров для внешнего сброса (обычная схема, как в справке квартуса здесь). Этот каскад тактируется clk1 и (соответственно со схемой) сбрасывать им можно регистры, которые тактируеются также clk1. Как правильно сбрасывать регистры, которые используют clk2, clk3 и т.д.?
Для каждого clkX делать отдельный каскад?

да, при этом, если логика на разных тактовых связанная, желателен быть перенос сигнала сброса с каскада на каскад. В порядке возрастания частоты

Еще есть зависимость от частоты. для пущей стабильности лично я такое только на частотах меньше 100 ставлю. на частотах повыше леплю от 3 регистров.

Спасибо. Вот так?
Нажмите для просмотра прикрепленного файла
Получается, снятие сброса не будет "одновременным" для разных тактовых? Будет нарастающая задержка, которую надо компенсировать?

Это обязательно? Хотелось бы единообразия.

В сбросе опасен не момент сброса, а момент его снятия. Сброс всех доменов должен идти одновременно, а вот снятие по цепочке. И не надо там ничего компенсировать. Цепочка на рисунке у вас сделана правильно.


я обычно ставлю 4 ре регистра.


в приложении неплохая статья. изучайте.

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


я обычно ставлю при f<100=2, 100..150=3, 150..200=4, 200..250=5.
но всё это как-то на глазок, что в корне неправильно. Интересно было бы знать, а сколько в действительности-то требуется? т.к. лишняя задержка -- она не всегда приятна.
Где бы посмотреть кривые вероятности метастабильного состояния на выходе в зависимости от частоты и количества регистров при условии, скажем, подачи "самого неудачно сдвинутого" относительно тактов сигнала на входе?

формула MTBF есть в доках о метастабильности от вендоров плис.

При том там считается вполне достаточным использование 2 триггеров, независимо от частоты.

значит мы разные доки читаем, либо делаем разные выводы.

Вот ещё полезная статья от Кена Чапмана до кучи.

Причем не все вендоры хотят их афишировать
http://forums.xilinx.com/t5/Virtex-Family-...ery/td-p/476482

Интересно. И здесь как раз 4 регистра - с указанием, что их число определяет минимальную длину сброса (и только?).
Но основная идея - нет особой необходимости в глобальном сбросе. Насколько это правильно?
В pdf есть ссылка на "Get your Priorities Right – Make your Design Up to 50% Smaller" - там в том числе и про сброс, но с привязкой к конкретной реализацией в кристаллах Xilinx. Насколько это соответсnвует Альтеровским кристаллам?

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

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

Только цепочка должна быть не тупо с повышением тактовой, а такой, как распространяется сигнал сброса, не привязываясь к частотам, то есть, оттуда, где он генерируется (например в домене "А"), он идет в домены "Б", и "В", а потом, обратно из доменов "Б" и "В", сигнал, говорящий домену "А", что все сбросилось, и можно начинать работать, то есть, снимать сигнал сброса с себя. Вот как-то примерно так. Направление, по большому счету, зависит от того, кто инициирует операцию, и кто на нее откликается - инициатор должен разрешаться только после того, как все остальные домены сбросились, независимо от того, у кого какая тактовая.

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

Вы правы, но это только в случае реализации "тупого" инициатора и приемника, например, когда сигнал готовности приема данных при сбросе устанавливается в состояние разрешения.


Я стараюсь делать модули во время сброса пассивными во всех смыслах, порой это приводит к наличию дополнительной логики, но зато никаких проблем со сбросами. И как сказал проброс сигнала делаю с низкочастотного домена в высокочастотный. Хотя это не обязательно, но люблю порядок

Вот именно. И получаем простую схему:

1) совершенно АСИНХРОННЫЙ сброс, без всякого проброса чего либо и куда либо. Просто, глобальный резет.
2) Этот сброс, в том числе, запрещает работу всех приемников, таймеров, и прочего, что может словить метастабильность.
3) Инициатор (а он всегда есть, и один, который самый первый из всех), через какое-то время после снятия сброса разрешает работу всего, чего надо, и разрешает уже по каналам управления, которые проброшены через домены, как им следует быть проброшенными. И единственное синхронизированное от сброса место - эта первичная разрешалка. Один бит данных.

А сброс при этом, совершенно асинхронный... И думать о нем не надо.

согласен. я раб привычек доведенных до автоматизма, наверное поэтому и ставлю

Я правильно понимаю, что асинхронный сброс используется только для этого первого блока, а остальные включаются синхронным ENABLE (т.е. в них синхронизированный асинхронный сброс просто не заходит)?
Нажмите для просмотра прикрепленного файла

Не совсем.

Во первых, асинхронный сброс (который ни с чем не надо синхронизировать), заходит во все блоки сразу во всех доменах, и их всех асинхронно сбрасывает. Для этого в FPGA придумана единая глобальная линия сброса, и поэтому она там одна (а не пачка, как линий тактовых). И никакого "синхронизированного асинхронного сброса" нет. Он заходит на все сбросы не синхронизированным - прямо Ваш "RESET_n" как он есть. (но! внимание! именно на АСИНХРОННЫЕ входы сбросов всех блоков, которые требуют сброса)

Во вторых, этот самый Enable нужен далеко не всем блокам, и не целиком целиком - Enable нужен конкретным отдельно взятым триггерам, которые на момент снятия RESET-а по каким-то причинам могут иметь на входе состояние, отличное от того, во что они были установлены по RESET, и то, не всем. Например:
- Если это регистр, который записывается по команде из блока-инициатора, то ему отдельный Enable не нужен. Его и так инициатор разрешает только тогда, когда ему надо, и гарантировано, что не сразу после сброса..
- Eсли это таймер, считающий сам по себе с момента снятия резета, с приращением в 1 - то тоже не нужен. Почему? Потому что, при смене его состояния из 0 в 1 худшее, что может произойти, это что он задержится в состоянии 0 на 1 такт из-за метастабильности. Ну и что? От этого никому не холодно и не горячо.
- А вот если это некий сумматор, который прибавляет к значению регистра некий код, не равный 1 (а точнее, не коду с одним разрядом, установленным 1), и этот код может быть таким в момент снятия резета, то вот тут уже нужно разрешение работы, чтобы не было сбоя.

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

UPD:
А вот Enable этот генерируется синхронизирвоанным, как-то так:

reg [2:0] en_ff
always @(posedge clk or negedge RESET_n)
if (~RESET_n) en_ff <= 3'd0;
else en_ff <= {en_ff[1:0], 1'b1};

выход синхронизированного Enable берется с en_ff[2], и подается в необходимые точки, при необходимости, пересинхронизированным на другие клоки и в остальные клок-домены. А цепь асинхронного сброса надо исключить из временнОго анализа через set_false_path, так как Вы сами, схемотехнически устранили все возможности для сбоев.

Идея хорошая. Но есть сомнения. Вот тут (страница 13, второй снизу абзац):
говорится, что:
Это значит, что таймер может и не с нуля начать считать...

Неа, не может, если изучить схему CMOS триггера. Если он сам в нуле, и на входе данных тоже ноль, то, что с ним не делай (кроме асинхронной установки в 1, которая тут не используется), в единицу его никак не загнать. Метастабильное состояние может возникнуть лишь тогда, и только тогда, когда в результате некоего действия ожидается смена состояния. И тогда оно может, как бы, неполностью смениться, что и есть суть метастабильности. А если внешних причин к смене состояния нет, то и метастабильность невозможна.

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

Хотелось бы Вам верить. Ведь так гораздо проще реализовывать. Но вот в статье "уважаемые дяденьки" пишут... и подкинул нам её как эталон "уважаемый товарищ" )))

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

Во всё вникать и проверять доказательства самому - не хватит времени на всё, это надо было делать ещё в вузе ))) Сейчас проще прислушаться к опыту "старших товарищей".

Когда дело доходит до оптимизации, когда надо "впихнуть невпихуемое", еще не тем заниматься приходится...

Спасибо за развернутые объяснения.
Пока все-таки буду перестраховываться и пропускать сброс через каскад - меньше шансов наделать ошибок.

В статье Asynchronous & Synchronous ResetDesign Techniques - Part Deux, пункт 7.2 так и говорится: "[...] examine the transistor-level version of the model [...] the circuit was indeed not susceptible to metastability problems if the d-input was low when a reset recovery violation occurred [...]" (речь о втором регистре в каскаде, о третьем-четвёртом даже не говорится).
Правда, схемы в этой статье не такие уж и простые.

Перевожу:

"схема была действительно не восприимчива к проблемам метастабильности, если вход "D" был низким, когда произошло нарушение времени восстановления сброса"

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

А вот Xilinx не сответует использовать везде глобальный асинхронный сброс. Мол не дает использовать дополнительный вывод у тех триггеров ячейки, в которые этот ресет не заводится, и увеличивает количество занимаемых ресурсов.
Ну и у некоторых элементов вообще нет входа асинхронного сброса.

Я не буду спорить, что в каких-то, отдельно взятых, ПЛИС это может оказаться неэффективным из-за их неудачной в этом плане архитектуры. Однако, у всех альтер имеется одна (и только одна) линия глобального сброса (global clear), к которой имеется возможность подключить сброс или предустановку любого триггера матрицы, и, точно также, у lattice (линия называется GSR, и она тоже единственная на весь чип). То есть, такие ПЛИС, где этот подход увеличивает занятость ресурсов - это исключения из правила.

PS
У Xilinx, кстати, тоже есть такой сброс, как и у Lattice, GSR называется... Так что...

Ситуация, когда надо погасить весь кристалл, значительно реже ситуации, когда надо погасить отдельный модуль. Для отдельного модуля GSR не поможет.

У каждого отдельно взятого триггера есть бит конфигурации, подключен он к GSR, или не подключен. И роль GSR - set или reset. Так что, еще как поможет, если это использовать грамотно. Синтезатор подключает к GSR только те триггеры, которые требуют резета по RTL, если используется авто-инферринг сигнала GSR, а не его задание как "жестко гасить все".

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


--------------
UPD: Вот, на картинке - GSR подключен, он асинхронный. И это не мешает использовать еще и LSR для чего-то другого, по желанию синтезатора. То есть, двойная экономия - и на разводке глобального ресета, и еще и на какой-то логике, которую синтезатор может реализовать через LSR в режиме синхронной предустановки в 1 (ну или сброса).
Нажмите для просмотра прикрепленного файла

Решил поднять старую тему.
Как идеологически верно поступить в таком случае:
Модуль состоит из нескольких Конечных Автоматов (КА), один из них главный управляющий, следит за результатами остальных.
Подчиненные КА следят за внешними (относительно ПЛИС) сигналами, каждый за своим определенным набором.
Главный КА дает разрешение на работу global_en и подчиненные КА начинают работу, есть сигнализация типа busy, done, error,....
В штатном режиме все просто, все КА будут в состоянии idle.
При обнаружении ошибки в работе нужно сбросить все остальные КА в состояние idle (busy = '0' ).
По моему идейно верно было бы установить global_en в '0'. Но такой подход потребует проверку global_en = '0' в каждом стейте, если внешние процессы медленные относительно процессов в ПЛИС и автомат не скоро перейдет в idle. Eсли состояний много то описание КА получается не очень... Другой вариант это главный КА делает локальный внутримодульный синхронный сброс всем подчиненным КА. И это не очень нравится.
Какой подход все же лучше?

1. Чем вам не нравится сброс от главного автомата?
2. Почему вы не можете global_en проверять каждый такт и перебросить автомат в IDLE как только, так сразу, а не при очередном переходе?

Сигнал сброса может быть из 2 источников объединенных по ИЛИ, тут просится именно такое решение один общий сброс от схемы, и дополнительный сброс от ведущего автомата.

Спасибо за ответ!

Честно говоря похоже некая фрустрация, все проблемы от стереотипов в голове. Темные места в подсознании помноженные на ненужный перфекционизм

1. Всегда старался строить КА так что бы им не нужен был сброс, кроме начального.
2. Не нравится описание - в каждом стейте нужно проверять, не изящно.

Сделаю с ресетом от главного КА + общий сброс.

проверяйте после автомата в том же алвайсе, последние условие перекроет все верхние.
можно в начале как дополнительная ветвь else if после сброса

изящно описать то можно многими путями




сброс хорошая вещь, явное приведение блока в определенное состояние, меньше сценариев - выше качество проверки и итоговая надежность