Mi compilador se queja de bloqueos inferidos en mis bucles combinatorios ( always @(*) , en Verilog). También me dijeron que los cierres inferidos deberían evitarse preferiblemente.
¿Qué es exactamente lo que está mal con los cierres inferidos? Ciertamente hacen que los bucles 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 del 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 restablecimiento y si alguno de ellos está activo, la salida puede cambiar. Donde, como SR-FF, solo responde a un conjunto o se reinicia cuando también hay un margen de reloj.
En un FPGA, desea que su lógica sea completamente sincrónica. Lo que significa que todos los elementos de almacenamiento (como los FF) están sincronizados desde una única fuente de reloj. Cualquier cosa que sea asíncrona a ese reloj debe ser tratada 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 tener en cuenta que hay FF con entradas de reinicio y reinicio asíncronas, y estas deben tratarse con el mismo cuidado que los cierres normales.
Ir a todos los problemas de tiempo que pueden provocar los cierres es mucho más allá de lo que se puede cubrir aquí, pero permítame darle un ejemplo:
Supongamos que tiene un SR-Latch y desea que se configure cada vez que un contador de 8 bits alcance un determinado valor. No estoy seguro de cuál sería el código de Verilog, pero en VHDL el código es: establecer < = '1' cuando 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 mezcla de y-gates, o-gates, y los inversores (O LUTs). Pero las rutas de señal a través de esa lógica combinatoria no siempre son perfectas y la señal de "conjunto" podría tener fallas en ella. La ruta de la señal a través de un grupo particular de puertas puede tomar más tiempo que otro grupo, lo que hace que la salida establecida se active por un breve momento antes de que la salida se establezca en el estado final.
Este fallo de salida puede hacer que se establezca nuestro SR-Latch, aunque no se suponía. Si cambiamos de un SR-Latch a un SR-FF, desactivamos el mismo reloj que el contador, entonces el SR-FF esperará un ciclo de reloj completo antes de cambiar de estado. En esencia, esperará a que la señal establecida se estabilice 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), el comportamiento de falla también cambiará. La lógica podría funcionar bien, pero luego, debido a que cambió algo totalmente no relacionado, esta lógica se enruta de manera diferente y así aparece el error. La temperatura y el voltaje también cambiarán la temporización de la señal y, por lo tanto, pueden cambiar el comportamiento de la falla.
Esta incertidumbre en el tiempo es la razón por la que debes evitar trabas en tu lógica. Los FF son mucho más seguros de usar. Esta es la razón por la que su compilador le advierte acerca de los cierres, ya que es fácil hacer un cierre por error y probablemente no lo quiere allí de todas formas.
Por supuesto, a veces se requieren cierres. Solo tiene que usarlos muy raramente, solo cuando sea absolutamente necesario, y luego debe diseñar la lógica correcta para que no haya problemas técnicos posibles.
¿Qué hace un cierre 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 (latch).
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 declaración if-else incompleta generará latches. Una declaración if-else se considera "incompleta" si el estado de salida no está definido para todas las posibles condiciones de entrada. Lo mismo ocurre con una declaración caso incompleta o una declaración caso que no tiene un elemento predeterminado: .
¿Por qué son malos los cierres inferidos?
Los pestillos inferidos pueden servir como una 'señal de advertencia' de que el diseño lógico podría no implementarse como se esperaba. Es posible que falte una declaración if-else o case en el diseño.
Los cierres pueden llevar a problemas de tiempo y condiciones de carrera. Pueden conducir a retroalimentación combinatoria (enrutamiento de la salida a la entrada) que puede ser impredecible.
Para evitar la creación de cierres inferidos:
Algunas partes parafraseadas de "FPGA Prototyping by Verilog Example" 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, lo que puede causar problemas de sincronización desagradables. Además, no tienes ningún control sobre los retrasos de tiempo y las condiciones de carrera cuando usas un pestillo (a menos que haya un elemento nativo)
No recomendaría el uso de pestillos a menos que no pueda prescindir de ellos (por ejemplo, pedir prestado para cumplir con la frecuencia máxima de reloj necesaria) y usar técnicas de codificación para hacer que la deducción accidental de pestillos sea menos probable.
Los diseños de lógica secuencial construidos mediante el uso de lógica combinatoria y retroalimentación generalmente suponen que serí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 que la entrada realmente haya cambiado. Hay algunas ocasiones en las que esa suposición puede no ser válida cuando se utilizan puertas reales (por ejemplo, si una puerta NOR rápida y un inversor rápido están impulsados por una señal que aumenta lentamente de VSS a VDD, y si el inversor cambia a 1,2 voltios mientras que el NOR la compuerta no cambia hasta 1.7 voltios, la compuerta NOR puede ver que la salida del inversor se va 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 se produzca un cambio lento. La señal se enruta a más de un destino. Desafortunadamente, tal suposición podría no ser válida en absoluto con un FPGA.
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 tiene el mismo comportamiento de estado estable, pero puede tener una temporización completamente diferente. Por ejemplo, supongamos 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 en la puerta, pero la realización más eficiente de Q solo tendría dos. Por lo tanto, aunque parezca que Q debería cambiar un retardo de puerta más tarde que P, podría haber cambiado dos retrasos de puerta más temprano.
Si un circuito tiene bucles de retroalimentación combinatorios, 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 hay no se garantiza que dichos nodos se agregarán a los lugares necesarios para que el circuito se comporte como se desea. Tampoco hay una garantía de que un ligero cambio en el diseño no hará que el compilador cambie de una ubicación arbitraria que funciona en el mundo real, a una ubicación arbitraria diferente que fracasa.
Los detalles sobre cómo atrapar un pestillo en el diseño se explican brevemente en este enlace.