¿Por qué los pestillos inferidos son malos?

Mi compilador se queja de pestillos inferidos en mis bucles combinatorios ( always @(*), en Verilog). También me dijeron que los pestillos inferidos deberían evitarse preferiblemente.

¿Qué es exactamente lo que está mal con los pestillos inferidos? Ciertamente hacen que los lazos combinatorios sean más fáciles de escribir.

Un "pestillo" es diferente de un "Flip-Flop" en que un FF solo cambia su salida en respuesta a un borde de reloj. Un pestillo puede cambiar su salida en respuesta a algo que no sea un reloj. Por ejemplo, un SR-Latch tiene un conjunto y una entrada de reinicio y, si alguno de ellos está activo, la salida puede cambiar. Donde como un SR-FF solo responde a un conjunto o reinicio cuando también hay un borde de reloj.

En un FPGA, desea que su lógica sea totalmente sincrónica. Lo que significa que todos los elementos de almacenamiento (como los FF) se sincronizan desde una sola fuente de reloj. Cualquier cosa que sea asíncrona a ese reloj debe tratarse con mucho cuidado; de lo contrario, se producirán errores de sincronización.

Un pestillo es básicamente un elemento de almacenamiento asíncrono. No tiene entrada de reloj y, por lo tanto, no se puede sincronizar con ningún reloj. Debo señalar que hay FF ​​con reinicio asincrónico y entradas de reinicio, y estos deben tratarse con el mismo cuidado que los pestillos normales.

Entrar en todos los problemas de tiempo que pueden causar los pestillos va mucho más allá de lo que se puede cubrir aquí, pero déjenme darles un ejemplo:

Supongamos que tiene un SR-Latch y desea que se configure cada vez que un contador de 8 bits alcanza un cierto valor. No estoy seguro de cuál sería el código Verilog, pero en VHDL el código es: set <= '1' when count = "11010010" else '0'; Esa señal establecida va a la entrada establecida en nuestro SR-Latch.

La lógica que se genera es puramente combinatoria; Una combinación de compuertas y compuertas, o compuertas e inversores (o LUT). Pero las rutas de señal a través de esa lógica combinatoria no siempre son perfectas y la señal "establecida" podría tener problemas técnicos. La ruta de la señal a través de un grupo particular de puertas podría tomar más tiempo que otro grupo, haciendo que la salida establecida se active por un breve momento antes de que la salida se establezca en el estado final.

Esta falla de salida podría causar que se establezca nuestro SR-Latch, aunque no se suponía que lo hiciera. Si cambiamos de un SR-Latch a un SR-FF, con el mismo reloj que el contador, el SR-FF esperará un ciclo completo antes de cambiar de estado. En esencia, esperará a que se establezca la señal establecida antes de mirarla.

Si las rutas a través de la lógica combinatoria para la señal establecida se enrutan de manera diferente (causando diferentes retrasos), entonces el comportamiento de falla también cambiará. La lógica podría funcionar bien, pero debido a que usted cambió algo completamente no relacionado, esta lógica se enruta de manera diferente, por lo que aparece el error. La temperatura y el voltaje también cambiarán el tiempo de la señal y, por lo tanto, pueden cambiar el comportamiento de falla.

Esta incertidumbre en el tiempo es la razón por la que debe evitar bloqueos en su lógica. Los FF son mucho más seguros de usar. Esta es la razón por la cual su compilador le está advirtiendo acerca de los pestillos, ya que es fácil hacer un pestillo por error y probablemente no lo quiera allí de todos modos.

Por supuesto, a veces se requieren pestillos. Solo tiene que usarlos muy raramente, solo cuando sea absolutamente necesario, y luego debe diseñar la lógica correctamente para que no haya fallas posibles.

¿Qué hace que un pestillo inferido?
Para la lógica combinatoria, la salida del circuito es una función de entrada solamente y no debe contener ninguna memoria o estado interno (pestillo).

En Verilog, una variable mantendrá su valor anterior si no se le asigna un valor en un bloque siempre . Se debe crear un pestillo para almacenar este valor presente.

Una instrucción if-else incompleta generará pestillos. Una instrucción if-else se considera "incompleta" si el estado de salida no está definido para todas las condiciones de entrada posibles. Lo mismo ocurre con una declaración de caso incompleta , o una declaración de caso que no tiene un valor predeterminado: elemento.

¿Por qué los pestillos inferidos son malos?
Los pestillos inferidos pueden servir como una 'señal de advertencia' de que el diseño lógico podría no implementarse según lo previsto. Esposible que falte una declaracióncrucial de caso o caso en el diseño.

Los pestillos pueden provocar problemas de tiempo y condiciones de carrera. Pueden conducir a una retroalimentación combinatoria (enrutamiento de la salida de regreso a la entrada) que puede ser impredecible.

Para evitar crear pestillos inferidos:

• Incluya todas las ramas de una declaración if o case
• Asigne un valor a cada señal de salida en cada rama
• Utilice las asignaciones predeterminadas al comienzo del procedimiento, por lo que se asignará cada señal.

Algunas partes parafraseadas de "FPGA Prototyping by Verilog Ejemplos" por P. Chu

Los cierres son muy difíciles de usar en FPGA o CPLD, por lo que muchas personas simplemente los evitan por completo. Una de las razones es que muchos FPGA no tienen un pestillo incorporado, por lo que están hechos de puertas lógicas, esto puede causar problemas de sincronización desagradables.
Además, no tiene ningún control sobre los retrasos de tiempo y las condiciones de carrera cuando usa un pestillo (a menos que haya un elemento nativo)

Aconsejaría no usar pestillos a menos que no pueda prescindir de ellos (por ejemplo, tomar prestado tiempo para cumplir con la frecuencia de reloj máxima necesaria) y usar técnicas de codificación para hacer que sea menos probable inferir accidentalmente pestillos.

Los diseños de lógica secuencial construidos usando lógica combinatoria y retroalimentación generalmente hacen una suposición que parecería razonable cuando se usan puertas físicas: que la salida de una puerta no cambiará en respuesta a un cambio en la entrada, hasta algún momento después de que la entrada haya cambiado realmente. Hay algunas ocasiones en las que esa suposición puede no ser válida cuando se usan puertas reales (por ejemplo, si una puerta NOR rápida y un inversor rápido son impulsados ​​por una señal que sube lentamente de VSS a VDD, y si el inversor cambia a 1.2 voltios mientras que la NOR la compuerta no cambia hasta 1.7 voltios, la compuerta NOR puede ver que la salida del inversor baja antes de ver que la señal de aumento lento se ha elevado), pero estos problemas generalmente se pueden resolver agregando un búfer cada vez que cambia lentamente la señal se enruta a más de un destino. Desafortunadamente,

El problema es que, a menos que se indique explícitamente lo contrario, un compilador FPGA puede reemplazar arbitrariamente un circuito combinatorio con un circuito totalmente diferente que tenga el mismo comportamiento en estado estacionario, pero puede tener una temporización completamente diferente. Por ejemplo, suponga que una función combinatoria compleja F toma seis entradas U a Z. F se alimenta directamente al circuito P y (F NAND Z) se alimenta al circuito Q. El compilador podría darse cuenta de que el valor alimentado a Q solo dependerá de F cuando Z es alto, y puede calcular una función F 'que es como F, excepto que Z se supone alto; Q puede ser alimentado con (F 'NAND Z) en lugar de (F NAND Z). Sería completamente posible que la realización más eficiente de P tuviera cinco retrasos de puerta, pero la realización más eficiente de Q solo tendría dos. Así,

Si un circuito tiene un bucle de retroalimentación combinatoria, un compilador FPGA tendrá que agregar nodos de señal física que, físicamente, tendrán un retraso positivo (no puede existir un bucle de retroalimentación de retardo cero en el mundo real), pero no hay garantía de que dichos nodos se agregarían en los lugares necesarios para que el circuito se comporte como se desea. Ni siquiera hay una garantía de que un ligero cambio en el diseño no haga que el compilador cambie de una ubicación arbitraria que funciona en el mundo real, a una ubicación arbitraria diferente que falla.

Los detalles sobre cómo atrapar un pestillo en el diseño se explica brevemente en este enlace.

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