El enfoque en el ejemplo es una forma perfectamente razonable de diseñar máquinas de estado. También es el enfoque que tiendo a seguir en todos mis diseños, incluidas algunas máquinas de estado bastante grandes en grandes sistemas.
Lo que hay que recordar acerca de este enfoque es que todo sucede con una latencia de un ciclo desde el estado. Para explicar lo que quiero decir, veamos el ejemplo que dio:
...
S0: begin
L <= 0;
D <= 0;
state <= S1;
end
...
Cuando estamos en el estado S0 , los registros L , D y state se actualizan. Sin embargo, debido a que es un proceso cronometrado, los valores no cambian inmediatamente cuando ingresamos S0 . En su lugar, cambian el ciclo del reloj a continuación . Esto significa que tomando este ejemplo, L y D irán a 0 cuando ingresemos el estado S1 . Cualquier lógica que utilice el registro state debe tener esto en cuenta al realizar cualquier cálculo. También es algo a tener en cuenta al analizar la salida de simulación.
Más allá de eso, hay mejoras prácticas en este diseño.
Todas las salidas están registradas, lo que significa que cualquier cosa que las use en la línea no tiene que lidiar con una nube de lógica combinatoria. Esto es a diferencia de las máquinas de estado en las que las salidas dependen asincrónicamente de los registros de la máquina de estado, lo que resultará en una gran nube combinatoria que puede causar problemas de tiempo en los diseños de alta velocidad. De ahí proviene la latencia de 1 ciclo en este enfoque.
Me parece mucho más claro de seguir porque tienes toda la lógica en un solo lugar, siguiendo en un nivel alto estado por diseño de estado. Esto es diferente a los que dividen el diseño en dos bloques siempre: uno asíncrono para la lógica y uno síncrono para el siguiente estado.
TL; DR Básicamente, puede utilizar este enfoque de diseño con gran éxito, siempre que lo recuerde y pueda hacer frente a la latencia de 1 ciclo.
También estoy intentando implementar un FSM de alto nivel en Verilog que tenga una cantidad de sentencias condicionales (si) anidadas y muchas entradas. En general, el diseño que estoy intentando implementar es un diseño síncrono en el que las entradas y salidas también están disponibles en los bordes del reloj. Entonces, mi pregunta es: ¿hay algún escollo en el diseño de un FSM como este? Cualquier ayuda es apreciada.