[SM 0]

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

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

 

PS

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

[troiden 0]

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

[SM 0]

Для отдельного модуля GSR не поможет.

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

 

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

 

 

--------------

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

[alxkon 0]

Не совсем.

 

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

Какой подход все же лучше?

 

[Golikov 0]

1. Чем вам не нравится сброс от главного автомата?

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

 

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

[alxkon 0]

1. Чем вам не нравится сброс от главного автомата?

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

 

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

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

 

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

 

1. Всегда старался строить КА так что бы им не нужен был сброс, кроме начального.

2. Не нравится описание - в каждом стейте нужно проверять, не изящно.

 

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

 

[Golikov 0]

Не нравится описание - в каждом стейте нужно проверять, не изящно.

 

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

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

 

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

 

 

 

Всегда старался строить КА так что бы им не нужен был сброс, кроме начального.

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