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


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

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

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

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

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

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


Сообщение отредактировал vea - Jan 13 2015, 13:17

Не совсем.

Во первых, асинхронный сброс (который ни с чем не надо синхронизировать), заходит во все блоки сразу во всех доменах, и их всех асинхронно сбрасывает. Для этого в 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 [...]" (речь о втором регистре в каскаде, о третьем-четвёртом даже не говорится).
Правда, схемы в этой статье не такие уж и простые.

Сообщение отредактировал vea - Jan 20 2015, 12:57

Перевожу:

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

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

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