Почему учебники verilog обычно делают сброс асинхронным?

Question

Этот вопрос находится в контексте синтеза ПЛИС, если это имеет какое-либо значение. В техническом описании (iCE40UP) указывается, что каждая логическая ячейка имеет флоп D-типа с асинхронным сбросом и входами разрешения синхронизации.

Многие учебники Verilog вводят последовательную логику с чем-то вроде:

always @(posedge clk)
  begin
    some_reg <= [...]
  end

Я знаком с тактовой логикой, и это имеет для меня интуитивный смысл.

Тогда обычно вводятся следующие следующие понятия:

• Будьте осторожны, чтобы случайно не создать защелку, потому что вам действительно нужен правильный регистр.
• always @(posedge clk or [pos|neg]edge reset)
• always @(*)

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

На риск, что мой вопрос закроют за то, что он плохо сформирован... что мне не хватает?

• Является ли асинхронный сброс рекомендуемой практикой проектирования? Что получается, если не рассматривать сброс как любой другой вход и не вступать в силу в следующем цикле? Документация для реальных чипов обычно требует, чтобы вывод RST* удерживался на низком уровне в течение многих тактов.

• Делает ли наличие защелки в дизайне асинхронным? Как мы гарантируем, что при наличии защелки, управляемой чем-то, находящимся за пределами домена часов, наблюдается правильное время?

• Когда кто-нибудь на самом деле захочет защелку в тактовом исполнении? Почему verilog позволяет так легко создать его случайно?

Спасибо!

По-видимому, связанные с этим вопросы: - Verilog D-Flip-Flop не повторно блокируется после асинхронного сброса - Что если я использовал асинхронный сброс, должен ли я сделать так, чтобы синхронный поворот включился?

Answer 1

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

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

Altera и Xilinx добавляют путаницы, рекомендуя своим клиентам использовать только синхронный сброс. Использование только синхронного сброса может хорошо работать на Altera и Xilinx, так как обе являются основанными на SRAM архитектурами FPGA, поэтому сбои при включении питания никогда не являются проблемой.

Но если вы хотите сделать свой проект переносимым на другие архитектуры, такие как ASIC или флэш-FPGA, то асинхронный сброс может быть лучшим выбором по умолчанию.

По поводу вашего вопроса о метастабильности, вызванной асинхронным отдыхом. Это правильно. Полностью асинхронный сигнал сброса может вызвать метастабильность. Вот почему вы всегда должны синхронизировать передний фронт активного низкого асинхронного сигнала сброса. Только задний фронт сброса может быть полностью асинхронным.

Синхронизация только переднего фронта выполняется двумя триггерами.

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