¿Es bueno codificar lógica combinacional y secuencial separada en dos bloques siempre?

2

El modelado de lógica secuencial y combinacional dentro del mismo siempre bloquea una buena práctica o se recomienda codificarlos en bloques separados.

always @(a or b) 
  y = a ^ b;

always @(posedge clk or negedge rst_n) 
  if (!rst_n) q <= 1'b0; 
  else
  q <= y;

O haciendo esto:

always @(posedge clk or negedge rst_n) 
  if (!rst_n) q <= 1'b0; 
  else
  q <= a ^ b;

Sé que ambos darían como resultado la misma funcionalidad.

Pero también se dice que mezclar asignaciones de bloqueo y no bloqueo en el mismo bloque siempre es un estilo de codificación deficiente. ¿No utilizamos el bloqueo para la lógica combinacional y el no bloqueo para la lógica secuencial?

  1. El modelado de lógica secuencial y combinacional dentro de la misma siempre bloquea una buena práctica.

  2. La mezcla de asignaciones de bloqueo y no bloqueo en el mismo bloque siempre es un estilo de codificación deficiente.

Entonces, en ese caso, las afirmaciones anteriores son contradictorias, ¿no?

    
pregunta Sai Gautham

2 respuestas

1

Principalmente basado en opiniones, y debajo está el mío.

Cada bloque siempre debe implementar la lógica combinatoria o el diseño secuencial, pero el diseño secuencial puede contener expresiones que resulten en lógica combinatoria, siempre que el resultado que se asigne sea lógica combinatoria o diseño secuencial para todos los resultados del bloque siempre . Ustedes dos ejemplos ya se adhieren a esta regla.

Utilice la asignación de bloqueo para la lógica combinatoria y la asignación de no bloqueo para el diseño secuencial para evitar condiciones de carrera entre diferentes bloques siempre controlados por el mismo reloj.

Finalmente, aproveche el uso de una herramienta avanzada de síntesis / simulación, y escriba el código de la manera más obvia y legible, para reducir el riesgo de errores y facilitar el mantenimiento futuro. El propósito de tener una herramienta avanzada de síntesis / simulación es que la herramienta maneja la tediosa tarea de usar los recursos de la mejor manera, para que pueda escribir el código de la manera más fácil. Por lo tanto, no escriba código de hardware personalizado con el fin de utilizar los recursos de la mejor manera, excepto si tiene conocimiento de un problema específico, lo que probablemente no sea el caso con su código de ejemplo.

Con tu ejemplo, creo que el bloque siempre simple es el más obvio y legible, por lo que debería preferirse.

    
respondido por el Morten Zilmer
0

Mi punto de vista es que cuando reviso el código para su reutilización, optimización, depuración o solo comprensión, tiendo a centrarme en la interacción entre entradas y salidas y las señales / estados intermedios.

Lo encuentro más fácil cuando el código se escribe de tal manera que cada combinación posible de entradas / señales / estado que afecte a una salida / señal / estado esté cerca para que pueda entender cuál es la señal / estado / salida afectado por. Aunque, esto no siempre es posible, trato de hacer esto donde sea para facilitar la revisión.

Entonces, para resumir, mi preferencia es la opción 2.

    
respondido por el dst

Lea otras preguntas en las etiquetas