¿Qué opciones tengo a la hora de sintetizar registros de control?

Question

Cuando el diseño incluye registros de control que se activan/leen en un dominio de reloj dedicado (SPI o I2C, etc.), ¿cómo se gestionan normalmente?

Por ejemplo:

• ¿Los mantiene en su propio dominio del reloj y false_path a donde quiera que vayan, sin preocuparse demasiado por la metaestabilidad?

• ¿O tal vez tener mucho cuidado para asegurarse de que hay flops metaestables en cada cruce de dominio, aumentando el área en el caso de grandes reg-maps? Y si se extienden a varios dominios de reloj, ¿podrías colgar varios sincronizadores de la línea de control?

¿Alguna otra sugerencia que se me escape?

Answer 1

Hay que prestar atención CADA cada vez que se cruzan dominios de reloj. Hay que analizar cada señal para ver si requiere una lógica especial o no. Si no lo haces, acabarás quemándote, y probablemente mucho. Es posible que gran parte de tu lógica no necesite una sincronización especial, pero no puedes dar por sentado que no hace falta nada.

Una cosa que es muy importante, pero a menudo se pasa por alto, incluso por los expertos, es que no se puede simplemente doble registro (o doble reloj) buses (std_logic_vector en VHDL). Hacerlo eliminaría los problemas de metaestabilidad, pero no los errores de datos debidos a la desviación entre bits en el bus. Para estos casos se requiere una lógica especial.

Answer 2

El único caso en el que "no preocuparse demasiado por la metaestabilidad" es una opción es con las señales cuasiestáticas: señales que no cambian cuando se utilizan activamente. Los ajustes de configuración que se aplican una vez antes de empezar a utilizar la función lógica primaria y luego se dejan solos suelen cumplir esta descripción. Se trata de una práctica de diseño arriesgada. Si lo haces el tiempo suficiente, acabarás quemándote, pero quizá sea un riesgo que estés dispuesto a correr. Ten en cuenta también que cualquier ruta entre dominios intencionada que añadas dificultará la identificación de rutas no intencionadas si ejecutas un comprobador automático de rutas entre dominios.

Si eso te asusta a la hora de utilizar de forma no sincronizada los datos del registro, quizá quieras planteártelo:

• Si la mayoría de los usos de los bits de registro están en un único reloj de mayor velocidad, puedes implementar la interfaz I2C/SPI en el dominio de reloj rápido. Sincroniza inmediatamente las entradas de baja velocidad al reloj rápido.

• Añade la lógica de sincronización a la interfaz de lectura/escritura del registro en lugar de hacerlo en los bits individuales del registro. Para múltiples relojes de destino, puedes implementar un repetidor de uno a muchos. No estoy seguro de lo bien que este enfoque encaja con los protocolos I2C/SPI.

Answer 3

Consigue que tus señales I2C y SPI entren en tu dominio de reloj principal de una forma muy controlada, preocupándote todo el tiempo por la metaestabilidad. Restrinja las herramientas para que sus flipflops de resolución de metaestabilidad no se coloquen en lados opuestos del chip, y no se repliquen (normalmente es este que se obtiene al cruzar dominios de reloj, en lugar de la metaestabilidad como tal).

Una vez hecho esto, tus registros de control y estado pueden existir en tu dominio de reloj principal y no tienes que preocuparte más.