Por lo que sé, es una mala práctica en los procesos combinados usar pestillos, y debo asignar un valor a cada señal en cualquier caso. ¿Por qué la misma regla no se refiere a procesos secuenciales (me refiero a procesos de reloj) y por qué no se me advierte que para ciertas señales no asigno valores?
Cuando decimos que es una mala práctica inferir los latches, estamos hablando de pestillos transparentes , que son sensibles al nivel y generalmente tienen un rendimiento de sincronización pobre en un FPGA.
Un diseño secuencial infiere flip-flops, que son edge sensibles en su entrada de reloj (y posiblemente sensibles al nivel en entradas de configuración / reinicio). A diferencia de los latches, el FPGA está diseñado específicamente para tener un buen rendimiento al implementar diseños secuenciales utilizando flip-flops.
La razón por la que no asignar una salida en ciertas ramas en un proceso secuencial no es perjudicial, es que al hacer esto, en general se infiere la lógica de 'habilitación' para el flip-flop. Como resultado, su rendimiento no se degrada, ya que aún funciona en un modo sensible al borde, basado en el reloj.
Los pestillos no son "malos" per se , simplemente no son el método de diseño previsto en un FPGA. Hay escenarios en los que una interfaz externa exige el uso de cierres. No son siempre un error, solo necesitas entender cuándo y dónde pueden ser apropiados.
Usaré verilog para los ejemplos en esta publicación porque no he escrito ningún VHDL en años, los principios son los mismos para ambos idiomas.
Primero, consideremos el caso no sincronizado
always @(en,d) begin
if (en) begin
q = d;
end
end
Este es un bloque siempre sin reloj (el equivalente a un proceso VHDL). Crea un cierre transparente.
El problema con los pestillos transparentes es que son sensibles a los fallos y razas.
Considere lo que sucede si en cambia a cero al mismo tiempo d cambia de valor. Tienes una condición de carrera. Si el cambio a en llega primero, q obtiene el valor antiguo de d. Si el cambio a d llega primero, q obtiene el nuevo valor de d.
Ahora, considere lo que sucede si la lógica que se crea es defectuosa. Un fallo en en puede hacer que el nuevo valor de d se propague involuntariamente a q.
Ahora veamos el caso cronometrado.
always @(posedge clk) begin
if (en) begin
q <= d;
end
end
Ahora ya no tenemos un pestillo transparente. Obtenemos un registro cronometrado. No importa en qué orden y en qué lleguen, siempre y cuando lleguen a tiempo para el próximo borde del reloj. No importa si hay fallas después de un borde del reloj siempre que se hayan establecido antes del siguiente borde del reloj.