Práctica de diseño cruzando dominios de reloj y señales asíncronas

Question

He estado diseñando algunos proyectos en diferentes FPGA en VHDL, y parece que mi fuente más común de "errores difíciles de encontrar" es cuando olvido sincronizar una señal asíncrona, o olvido volver a sincronizar una señal que cruza dominios de reloj.

Hasta ahora, mi mejor arma ha sido dibujar el esquemático de bloques de los componentes.

Entonces mi pregunta es, ¿cuál es la mejor práctica de diseño para prevenir estos errores?

Answer 1

Hoy en día, incluso los diseños FPGA pueden tener arquitecturas de reloj extremadamente complejas y muchas entradas asíncronas, lo que resulta en muchos posibles problemas de CDC.

Diría que los siguientes puntos constituyen un conjunto mínimo de "reglas generales" para evitar errores de CDC:

1. Llevar un registro de todas las señales que cruzan dominios de reloj (diagramas, listas, hojas de cálculo, lo que sea más conveniente para ti). Las señales de entrada asíncronas también deben incluirse.
2. Todas las señales de la lista anterior deben sincronizarse, a menos que exista una razón clara para no hacerlo.
3. ¡Nunca sincronices señales de varios bits bit a bit! En su lugar, utiliza esquemas de sincronización especiales para buses (FIFO sincronizado, handshake bidireccional, etc.).
4. Si hay un reset asíncrono en el sistema, y este reset no se aplica a todos los flip-flops, todas las señales originadas en este dominio de reset y pasadas a la lógica no reseteada deben tratarse como asíncronas (y ser incluidas en la lista del punto #1).

Estoy seguro de que la lista anterior de prácticas está incompleta y puede ampliarse fácilmente.

También sugiero considerar herramientas de verificación de CDC (como Questa CDC de Mentor) - estas herramientas utilizan técnicas formales para detectar automáticamente problemas de CDC en tu diseño.

Answer 2

Algunas prácticas de nombrado pueden ser útiles:

• Cualquier señal que cruce un dominio de reloj debe tener el dominio al que está sincronizado añadido. Entonces, si tienes count en el dominio de reloj impulsado por la señal clk (y necesita ir a otro dominio de reloj impulsado por other_clk), llámalo count_clk y count_other_clk.

• Mantén todo el código de sincronización de un dominio de reloj a otro en un solo lugar. Tal vez encapsúlalo, dependiendo de cuánto haya. Pon comentarios claros alrededor de él (por ejemplo, arriba está clk, este es el cruce de dominio de clk a other_clk, abajo está other_clk)

• Se pueden añadir _async al final de las señales verdaderamente asíncronas.

Esto al menos facilita un poco la revisión de código, pero si tienes muchos dominios y muchos cruces, te beneficiará invertir en algunas herramientas que ayuden (como Spyglass por ejemplo, que hace mucho más que simplemente verificar dominios de reloj)

Answer 3

Además de las respuestas anteriores:

Tiempo de Reporte

Utiliza tu herramienta de análisis de tiempo en tu cadena de herramientas de FPGA para encontrar cualquier señal que hayas olvidado manejar correctamente.

Puedes generar fácilmente una lista de transferencias de reloj no restringidas, todas las cuales deben estar sincronizadas y añadir una ruta falsa adecuada. Lo ideal es incrustar esto en tu sistema de compilación para que falle con un error si hay alguna transferencia de reloj no restringida, ¡así no puedes olvidarte de ellas!

Reutiliza código

Ten una única entidad/módulo para hacer tu sincronización de un solo bit, utiliza un genérico/parámetro para controlar el número de registros en la cadena de resincronización. Es posible que quieras un sincronizador separado para los resets.

Incrusta restricciones

La ventaja de reutilizar código - incrusta las restricciones de ruta falsa en el RTL. De esta manera, no tienes que recordar añadir restricciones de tiempo para cada señal.

Una nota sobre ubicación

Los registros en cadenas de sincronización deben estar ubicados cerca uno del otro para garantizar que se proporcione la ventana de tiempo máxima. Altera afirma detectar automáticamente cadenas de sincronización, por lo que no deberían necesitar restricciones de ubicación. Si eres paranoico en Xilinx, puedes utilizar restricciones RLOC para asegurar que los registros del sincronizador estén ubicados cerca uno del otro (desafortunadamente, Altera no soporta restricciones de ubicación relativa).