Estoy explorando una gama de técnicas para implementar árboles de reloj TMR como parte de un diseño global de TMR (todos los recursos, incluidos los pines de E / S, árboles de reloj, árboles de restablecimiento, lógica y registros se implementan con redundancia triple). Como no estoy interesado en estar sujeto a las herramientas GTMR automáticas de ningún proveedor, estoy buscando hacerlo a mano. Entiendo que se requiere GTMR en FPGA porque una SEU con un solo evento en los bits CRAM de un FPGA basado en SRAM podría desconectar el árbol del reloj de una gran parte de la lógica que estaba impulsando ...
Observo las dificultades con los siguientes 3 enfoques en un Altera Cyclone V SE:
1) Altera's Cyclone ALTPLL puede generar hasta 6 salidas de reloj desde una fuente de reloj. Es técnicamente posible solicitar 3 relojes de salida, cada uno de los relojes de salida funciona con la misma frecuencia objetivo, ciclo de trabajo y desplazamiento de fase. Desafortunadamente, la redundancia se "optimiza" mediante la herramienta de ajuste, lo que da como resultado que solo se active un único árbol de reloj global. ¿Alguien puede proponer cómo evitar esta optimización? - > Sí, es probable que sea mejor tener tres ALTPLL. Consulte el enfoque 2. Sin embargo, el enfoque 1 sería interesante para explorar el jitter entre los registros de conducción de 3 redes de reloj diferentes que utilizan este enfoque.
2) En la verdadera moda de GTMR, asumamos que usamos tres pines del reloj de entrada, cada uno de los pines del reloj de entrada controla su propio par de módulos {ALTPLL, ALTCLKCTRL}. Con una aplicación bastante generosa de orientación a las herramientas (por ejemplo, syn_keep / syn_noprune / dont_touch como controles), es posible impulsar tres redes de árbol de reloj globales con 3 PLL diferentes operando a las mismas velocidades. He configurado un arnés de temporización muy simple (1 pin de entrada de datos controla un registro de desplazamiento de 10 bits. Esas 10 bandejas de entrada se colocan en el estado de activación de registro de desplazamiento de 2x 10 bits, cada registro de desplazamiento controla un pin de salida de datos. todos los registros están controlados por su propio pin de reloj (pin_m? _clock)). Con este sencillo esquema de prueba en su lugar, el "resumen de configuración" del analizador de tiempo de TimeQuest se queja de que: pin_m0_clock slack: 0.650 Punto final TNS: 0.000 pin_m1_clock slack: -0.877 Punto final TNS: -7.575 (marcado como un error) pin_m2_clock slack: -0.855 Punto final TNS: -7.9641 (marcado como un error) No estoy seguro de lo que se requiere para abordar estos errores de manera segura.
3) Si usamos tres pines de reloj (controlados por una única fuente de reloj, o tres fuentes de reloj sincronizadas en fase y frecuencia), y tres árboles de reloj, en los que cada pin de reloj acciona directamente su propio módulo ALTCLKCTRL, es posible para impulsar tres redes globales de árboles reloj a través del FPGA. Usando el mismo arnés de prueba descrito en (2) más arriba, TimeQuest Timing Analyzer no presenta ninguna queja. Hay alrededor de -0.339 (m0_clock- > m1_clock) a -0.583 (m0_clock- > m2_clock) sesgo de reloj. Observo que el control de reloj para M0 y M1 están ubicados físicamente muy juntos en el borde central izquierdo del chip, donde el tercer control de reloj para M2 está ubicado en el borde inferior central del chip y puede explicar algunas de las diferencias. en sesgo (339 vs 583). [9 de noviembre de 2014: pude reducir el sesgo de 583 a ~ 300 agrupando los módulos altclktrl físicamente juntos, e impulsando cada uno de los 3 pines del reloj desde un pines de entrada de reloj de borde positivo dedicado] .
Como un elemento relacionado, implementé una versión de un solo reloj del mismo arnés de prueba para verificar la inclinación del reloj entre registros en el mismo reloj ... y se redujo a -0.071. Espero que haya alguna forma de reducir significativamente ese > 300 sesgo a algo mucho más bajo. (Según mi opinión, al menos uno de los objetivos principales de reducir el jitter entre los árboles de reloj de TMR es evitar problemas de metastabilidad en el circuito de retroalimentación de las máquinas de estados finitos TMR [loopback - > voter - > FSM logic - > D -FF - > loopback].)
Me interesaría escuchar consejos sobre cómo mejorar este (3) tercer enfoque. No estoy seguro de qué son exactamente las ventajas y desventajas de conducir las redes de reloj globales directamente desde los pines, pero parece que el enfoque (2) anterior sería mejor si los errores reportados en (2) pudieran superar.
Aprecio todos los comentarios, guías y consejos sobre cómo hacer / optimizar correctamente cualquiera de los tres enfoques manuales anteriores. No dude en proponer un enfoque manual aún mejor para TMR global en el chip.
Gracias
The Happy Techy