¿Cuál es la importancia de usar un reinicio asíncrono en lugar de un reinicio síncrono?

2

Tengo un módulo Verilog simple con solo un DFF de reinicio sincrónico:

module scratch (input clk, reset_n, serial,
                output reg serial_ff);

   always @ (posedge clk) begin
      if (!reset_n) begin
         serial_ff <= 1'b0;
      end
      else begin
         serial_ff <= serial;
      end
   end

endmodule // scratch

Al ejecutar un control de pelusa (hal 06.20-s004) en mi diseño para ASIC, recibo la siguiente advertencia en la categoría DFT:

*W,FFWASR (./scratch.v,9|0): Flip-flop 'serial_ff' does not have any asynchronous 
set or reset.
------
Flip-flops must have asynchronous set or reset. If a flip-flop
does not have any asynchronous set or reset then it is not 
controllable from primary inputs.

The following example illustrates this problem:

if(rst)
port_a <= '0';
elsif rising_edge(clk) then
port_a <= var_a;
port_b <= var_b;
end if;

In the above HDL code, the value of 'port_a' can be
brought to '0' using asynchronous reset 'rst', while 
this is not the case with 'port_b'. This may cause
issues during simulation.

Ya estoy usando un reinicio síncrono para el FF, por lo que se está inicializando. Pero la advertencia me dice que use un reinicio asíncrono en su lugar. Pero ¿por qué es esto importante para la prueba? ¿Qué tipo de fallas puede identificar esta metodología DFT (R asíncrona en lugar de R síncrona)?

En resumen, ¿cuándo debería importarme y cuándo puedo ignorar la advertencia?

Actualización: encontré un parámetro mencionado al pasar en la documentación: "setreset_type". Me puse a leer todo el conjunto de documentos y parece que está sin documentar. Así que supongo que Cadence REALMENTE quiere que todos usen reinicios asíncronos religiosamente. Pero la verdad es que los reinicios no deben implementarse religiosamente, sino que el diseñador debe considerar los compromisos y los requisitos de diseño para cualquier tipo de reinicio. Esta es la conclusión contundente de las respuestas hasta el momento, ¡así que todos obtendrán puntos por ser útiles! Actualizaré si puedo encontrar cómo usar ese parámetro no documentado. Esa fue la única configuración posible que pude encontrar después de revisar todos los documentos relacionados. Por ahora, ignoro la advertencia ya que ya hemos considerado el diseño del restablecimiento desde el nivel de arquitectura del sistema.

    
pregunta travisbartley

3 respuestas

5

Esta respuesta es válida para ASICs.

Después de leer algunas referencias en la red, descubrí que la pregunta "sincronizar o asíncrono" es un tipo de pregunta "iOS o Android". Todo lo que sigue es mi opinión sobre el tema que está sesgado.

Los reinicios asíncronos son dolor en el cuello porque:

  1. Son sensibles a la falla
  2. Deben desactivarse de forma síncrona
  3. Deben desactivarse de forma síncrona, en todos los flops, en el mismo ciclo de reloj
  4. Pueden causar problemas de metastabilidad si hay fallas que no se restablecen.

Aunque las secciones 1 y 2 son fáciles de manejar, el resto son problemas importantes que requieren una comprensión profunda y un montón de herramientas para la validación.

Y ahora, la dolorosa verdad: los reinicios asíncronos son aún preferibles para los sistemas grandes. Las ventajas de los reinicios asíncronos son:

  1. Los restablecimientos asíncronos tienen prioridad sobre cualquier otra señal
  2. Los restablecimientos asíncronos no comparten rutas combinacionales con otras señales
  3. Los restablecimientos asíncronos no requieren relojes

El hecho de que se reinicien todos los flops, y de que todos los flops no estén restablecidos en el mismo ciclo de reloj es una ventaja importante (y si no sucede en el mismo ciclo, esto se indica mediante herramientas y está a la espera por decisión del diseñador). En diseños complejos (que contienen muchos dominios de reloj en los que cada reloj está cerrado decenas o cientos de veces) es muy difícil asegurarse de que no haya casos de esquina cuando se utilizan reinicios de sincronización. Los restablecimientos asíncronos son independientes de estos problemas (todavía hay un lugar donde los restablecimientos asíncronos cumplen con los relojes, en la lógica de desactivación, que debe ser diferente para cada dominio de reloj).

La advertencia que ve sugiere que todos sus flops deben restablecerse de forma asíncrona. Sin embargo, es una cuestión de decisión micro-arquitectónica qué tipo de reinicio usar, y esto debería ser consistente a través de algún límite definido. Aún así, si está seguro de que un restablecimiento no estándar es más apropiado en algún lugar, utilícelo y renuncie a la advertencia.

EDIT:

Durante la inserción del escaneo, todos los flops en una cadena de escaneo deben funcionar correctamente. Si está utilizando un reinicio asíncrono alimentado externamente, entonces la condición anterior es muy simple de satisfacer: solo ate la red externa a un valor sin reinicio.

En los diseños de reinicio de sincronización, también se debe cumplir la condición anterior. Esto se logra de la misma manera, pero como los reinicios de sincronización pueden compartir rutas combinacionales con otra lógica, las herramientas pueden detectar erróneamente los fracasos que pueden restablecerse durante la exploración (o no erróneamente).

A la luz de la información adicional proporcionada en los comentarios (no se reinicia el async en absoluto y se informa de esta advertencia para todos los fracasos), creo que puede deshabilitar esta regla completamente. Por otro lado, es posible que desee asegurarse de que su Lint DFT admita los restablecimientos de sincronización (es decir, tiene reglas paralelas para los restablecimientos de sincronización, y estas reglas están habilitadas)

EDIT2:

Encontré este gran artículo en la Web . Nunca he estado en SNUG, pero parece que hay muchos diseñadores que prefieren los esquemas de reinicio de sincronización. Puede encontrar un análisis bastante profundo de los esquemas de sincronización y asíncrono en el artículo anterior, junto con muchos consejos prácticos.

    
respondido por el Vasiliy
2

Ignoraría la advertencia, pero hay que entender que tendrá un valor indeterminado hasta el primer borde del reloj (donde var_b es válido). ¡Hay muchos casos en que esto es realmente deseable!

Si está diseñando para un Xilinx FPGA, donde una LUT también puede funcionar como un registro de desplazamiento gigante, entonces no desea un caso de reinicio para su registro de desplazamiento. Sin el caso de reinicio, un registro de desplazamiento se puede combinar en una sola LUT. Una vez que lo reinicie, todo el registro de cambios se realizará utilizando FF normales en lugar de una LUT.

En algunos otros casos, es posible que no desee un caso de reinicio para cada flip flop. Si está realizando un ASIC, el uso de un caso de reinicio solo en los flip flops críticos puede reducir el enrutamiento de tener que ejecutar la señal de reinicio a cada flip flop.

También es mi deber señalar que los reinicios asíncronos no son recomendables para los diseños de Xilinx (y supongo que la mayoría de los FPGA). En su lugar, use la sincronización de restablecimientos. No dijiste si estás haciendo un FPGA, por lo que es posible que esto no se aplique a ti.

Actualización: Más información sobre DFT.

El problema de no tener un reinicio para tus FF es que cuando se inician están en un estado indeterminado. En hardware real, pueden ser un 0 o 1. En simulaciones VHDL tienen una 'U' o 'X' (olvidé cuál). Al realizar pruebas (ya sea en hardware real o en simulación) esto debe tenerse en cuenta. En algunos casos, esto solo significa que esas señales deben ignorarse durante varios ciclos de reloj a medida que se inicia el sistema. En otros casos, puede hacer que algunas lógicas aparezcan de maneras diferentes pero aún válidas. Dependiendo de cómo esté realizando la verificación, esto puede o no ser un problema.

Considere un simple contador de 4 bits. Si tiene un reinicio "correcto", entonces aparecerá y comenzará a contar de esta manera: 0, 1, 2, 3, 4, etc. Pero sin reiniciar, el sistema real podría aparecer y contar 15, 0, 1, 2, 3, etc. o incluso 6, 7, 8, 9, etc. Algunos sistemas de verificación de diseño esperan que el sistema se presente de la misma manera cada vez, ya que solo comparan los vectores de prueba y no tienen en cuenta la funcionalidad real de el diseño. Entonces, si el sistema de verificación busca 0, 1, 2, 3, pero obtiene 6, 7, 8, 9, lo marcará como un error, aunque puede considerar que 6, 7, 8, 9 es perfectamente válido.

La solución a esto es tener un reinicio válido para cada FF. Esto facilita la verificación, pero complica muchas otras cosas. Mi preferencia es diseñar la lógica para que sea óptima, a expensas de hacer que la verificación sea más complicada.

    
respondido por el user3624
1

Las otras respuestas cubren las posibles minas terrestres.

En la alineación, la verificación de equivalencia formal u otra verificación, la propagación de Desconocidos y no importa preocupa enormemente los resultados. Tener un restablecimiento forzado a un estado conocido reduce la complejidad del análisis. Y, francamente, en algunos casos, la herramienta no puede (probablemente así) resolver el estado correcto (debido a la propagación de incógnitas y no importa). Al menos hasta que esas condiciones hayan pasado por el sistema.

Esa advertencia es "use las celdas de reinicio asíncrono o nuestras comprobaciones no pueden ser tan completas como nos gustaría y es su culpa si falla".

El cambio que enfrentas es: "¿Debo llevar un área de puerta adicional (¿es eso mucho?)" frente a "¿qué tan seguro estoy de que no tengo un estado oculto?" Si es lógica compleja, ¿ha cubierto todos los estados de inicio posibles? Si es un registro que luego se carga, se trata de manera diferente.

La tendencia es dejar que la herramienta se ocupe de ello. Y si la herramienta requiere que use ciertos tipos de celdas, entonces acepta la pérdida de área. Realmente depende del tamaño del diseño y la complejidad de la base de datos de diseño.

    
respondido por el placeholder

Lea otras preguntas en las etiquetas