[des00 25]

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

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

 

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

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

 

[SM 0]

Я стараюсь делать модули во время сброса пассивными во всех смыслах,

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

 

1) совершенно АСИНХРОННЫЙ сброс, без всякого проброса чего либо и куда либо. Просто, глобальный резет.

2) Этот сброс, в том числе, запрещает работу всех приемников, таймеров, и прочего, что может словить метастабильность.

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

 

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

[des00 25]

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

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

 

[vea 0]

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

 

1) совершенно АСИНХРОННЫЙ сброс, без всякого проброса чего либо и куда либо. Просто, глобальный резет.

2) Этот сброс, в том числе, запрещает работу всех приемников, таймеров, и прочего, что может словить метастабильность.

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

 

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

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

Изменено 13 января, 2015 пользователем vea

[SM 0]

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

[Krys 2]

- Eсли это таймер, считающий сам по себе с момента снятия резета, с приращением в 1 - то тоже не нужен. Почему? Потому что, при смене его состояния из 0 в 1 худшее, что может произойти, это что он задержится в состоянии 0 на 1 такт из-за метастабильности. Ну и что? От этого никому не холодно и не горячо.

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

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

говорится, что:

If the asynchronous reset is released

at or near the active clock edge of a flip-flop, the output of the flip-flop could go metastable and thus the reset state

of the ASIC could be lost.

Это значит, что таймер может и не с нуля начать считать...

 

 

[SM 0]

Это значит, что таймер может и не с нуля начать считать...

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

 

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

[Krys 2]

Иначе бы весь смысл его статьи потерялся бы :) :)

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

 

[SM 0]

Хотелось бы Вам верить.

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

[Krys 2]

А не надо мне верить. Возьмите, и поанализируйте схемы триггеров на транзисторном уровне.

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

 

[SM 0]

Во всё вникать и проверять доказательства самому

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

[vea 0]

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

Спасибо за развернутые объяснения.

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

[vea 0]

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

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

Правда, схемы в этой статье не такие уж и простые.

Изменено 20 января, 2015 пользователем vea

[SM 0]

the circuit was indeed not susceptible to metastability problems if the d-input was low when a reset recovery violation occurred [...]

 

Перевожу:

 

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

 

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

[troiden 0]

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

Ну и у некоторых элементов вообще нет входа асинхронного сброса.