Почему предполагаемые защелки плохие?

Мой компилятор жалуется на предполагаемые защелки в моих комбинаторных циклах ( always @(*)в Verilog). Мне также сказали, что следует избегать предполагаемых защелок.

Что именно не так с предполагаемыми защелками? Они, безусловно, облегчают написание комбинаторных циклов.

«Защелка» отличается от «триггера» тем, что FF изменяет свой выход только в ответ на фронт тактового сигнала. Защелка может изменить свой выход в ответ на что-то, кроме часов. Например, SR-Latch имеет набор и вход сброса, и если любой из них активен, выход может измениться. Где, как SR-FF, реагирует на установку или сброс только тогда, когда имеется также край тактового сигнала.

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

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

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

Допустим, у вас есть SR-Latch, и вы хотите, чтобы он устанавливался каждый раз, когда 8-битный счетчик достигает определенного значения. Я не уверен, каким будет код Verilog, но в VHDL этот код: set <= '1' когда count = "11010010" else '0'; Этот установленный сигнал поступает на установленный вход нашей SR-Latch.

Логика, которая генерирует, является чисто комбинаторной; смесь и-ворота, или-ворота, и инверторы (или LUT). Но пути прохождения сигнала по этой комбинаторной логике не всегда идеальны, и сигнал «set» может иметь глюки. Путь прохождения сигнала через определенную группу затворов может занять больше времени, чем у другой группы, в результате чего заданный выходной сигнал активируется на короткое время, прежде чем выходной сигнал устанавливается в конечное состояние.

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

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

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

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

Что делает предполагаемую защелку?
Для комбинаторной логики выход схемы является функцией только входа и не должен содержать никакой памяти или внутреннего состояния (защелки).

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

Неполный оператор if-else будет генерировать защелки. Если-иначе заявление считается «неполным» , если состояние выхода не определен для всех возможных входных условий. То же самое касается неполного оператора case или оператора case , который не имеет default: item.

Почему предполагаемые защелки плохие?
Предполагаемые защелки могут служить «предупреждением» о том, что логическая схема может быть реализована не так, как задумано. Важноеутверждение if-else или case может отсутствовать в дизайне.

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

Чтобы избежать создания предполагаемых защелок:

• Включите все ветви заявления if или case
• Назначьте значение каждому выходному сигналу в каждой ветви
• Используйте назначения по умолчанию в начале процедуры, поэтому каждый сигнал будет назначен.

Некоторые части, перефразированные из «Прототипирования ПЛИС на примерах Verilog» П. Чу

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

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

Схемы последовательной логики, построенные с использованием комбинаторной логики и обратной связи, обычно делают предположение, которое кажется разумным при использовании физических шлюзов: что выход гейта не будет изменяться в ответ на изменение входа, пока некоторое время спустя вход фактически не изменится. В некоторых случаях это предположение может не соблюдаться при использовании реальных затворов (например, если быстрый затвор NOR и быстрый инвертор оба приводятся в действие сигналом, который медленно повышается от VSS к VDD, и если инвертор переключается при 1,2 В, в то время как NOR вентиль не переключается до 1,7 вольт, вентиль NOR может видеть низкий уровень выходного сигнала инвертора, прежде чем он увидит, что медленно нарастающий сигнал поднялся), но такие проблемы обычно можно решить, добавляя буфер всякий раз, когда медленно меняющийся Сигнал направляется более чем в один пункт назначения. К несчастью,

Проблема состоит в том, что, если явно не указано иное, компилятор FPGA может произвольно заменить комбинаторную схему совершенно другой схемой, которая имеет такое же стационарное поведение, но может иметь совершенно другую синхронизацию. Например, предположим, что комплексная комбинаторная функция F принимает шесть входов от U до Z. F подается непосредственно в схему P, а (F NAND Z) подается в схему Q. Компилятор может понять, что значение, подаваемое в Q, будет зависеть только от F, когда Z высокий, и может вычислять функцию F ', которая похожа на F, за исключением того, что Z предполагается высоким; Затем Q можно кормить с (F 'NAND Z), а не (F NAND Z). Вполне возможно, что наиболее эффективная реализация P будет иметь пять задержек затвора, но наиболее эффективная реализация Q будет иметь только две. Таким образом,

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

Подробности о том, как поймать защелку в дизайне, кратко объяснены в этой ссылке.

https://www.doulos.com/knowhow/fpga/latches/