Synchronized reset и разные тактовые, Каскад для внешнего сброса + разные тактовые Опции

[vea]

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

[des00]

Для каждого clkX делать отдельный каскад?

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

[vea]

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

Спасибо. Вот так?

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

на частотах повыше от 3 регистров.

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

[des00]

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

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

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

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


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

Прикрепленные файлы

 CummingsSNUG2002SJ_Resets.pdf ( 271.44 килобайт ) Кол-во скачиваний: 212

 

[SM]

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

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

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

[des00]

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

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

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

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

[SM]

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

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

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

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

[vea]

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

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

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

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


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

[SM]

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

[alxkon]

Не совсем.

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

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