Las declaraciones if-else y case son equivalentes. Quizás sea más fácil leerlo más tarde cuando tenemos muchas posibilidades de ser verificadas.
Se supone que un condicional infiere mux en hardware. Sin embargo, existe una diferencia entre tener una cadena de 2 a 1 mux y un gran n-a-1 que haga lo mismo en términos de retardo de propagación.
¿Se supone que la declaración if-else y la declaración de caso deducen el hardware mismo ? ¿O hay alguna diferencia en cómo se sintetizarían?
No: if-else es secuencial; caso es concurrente. Un simple si es seguido por un else será equivalente a un multiplexor de dos entradas. Una sentencia if seguida por if else es equivalente a una serie de dos multiplexores de entrada como este:
Esto se debe a que el orden en que se verifican las condiciones de if-else es importante, es decir, tiene prioridad.
Una declaración de caso, por otro lado es concurrente. Todo sucede al mismo tiempo.
Ninguna declaración se asigna necesariamente a un multiplexor.
El código HDL se compila en una forma intermedia, que se optimiza simplificando las declaraciones (por ejemplo, eliminando las tautologías) y encontrando una asignación óptima al hardware real que también toma en cuenta los retrasos de propagación.
Por ejemplo
if(input)
then
output <= '1';
end if;
el compilador probablemente optimizará a output <= '1'; , ya que el estado inicial no está definido, y un valor fijo utiliza los menos recursos. Place & Route toma esto más lejos y configura el controlador de salida para el valor fijo, por lo que ni siquiera se utiliza un solo registro.
los retrasos de propagación deben tenerse en cuenta en su diseño, donde las interfaces esperan que los datos lleguen a un borde del reloj en particular, por lo que ya deberían haber sido parte de la especificación de la interfaz.
Por ejemplo, cuando construyo un filtro FIR, también genero una señal valid que se establece cuando se alcanza el estado estable después de un restablecimiento, y una señal marker que es simplemente un retraso en los marcadores de entrada. La implementación obvia genera valid \ $ N_ {taps} \ $ después del restablecimiento, y el retraso del marcador es \ $ \ frac {N_ {taps}} {2} \ $, pero eso no está garantizado en la interfaz. Si puedo obtener un mejor comportamiento de canalización agregando más etapas de registro en el medio, puedo hacerlo sin romper ningún componente conectado, y la lógica casi siempre se optimiza simplemente cuando el compilador determina que el retraso total se fija en el momento de la compilación. / p>