Uno de los bugs más frustrantes después del tape-out de semiconductores es este:La simulación de funciones es perfecta, Silicon Bring-up funciona la mayor parte del tiempo, pero "a veces" se comporta erráticamente. Cuando intento reproducirlo delante de un profesor, funciona bien.... Los registros de depuración también son débiles debido a la falta de reproducibilidad. Si escarbas lo suficiente, sueles llegar a la misma conclusión:
- "La temporización está rota en algún sitio"
- Ese "algún sitio" suele ser un control global como Clock/Reset.
- Específicamente, un impulso muy fino (glitch) en el punto Clock to MUX.
Los glitches en la ruta de reloj son una clase diferente de glitch que los glitches de datos. Los glitches en la ruta de datos suelen consumirse en la lógica combinacional.
Los glitches de reloj, en cambio, pueden ser percibidos por el flip-flop como un "flanco de reloj extra", y a partir de ese momento, un flanco anómalo puede distorsionar todo el estado del sistema. Por eso la solución clásica es el Glitch-Free Clock MUX (GFCM).
1) Por qué se produce el Glitch en un Multiplexor (MUX)
El 2 más sencillo:1 La lógica de un MUX es limpia.
out = (~S & A) | (S & B)En RTL, parece que cambia de A a B en cuanto sel pasa de 0→1.
A nivel de puerta, es otra historia.
- (~S & A) y (S & B) caminos tienen diferente retardo de celda / retardo de cable.
- La propagación de la señal de S no llega a ambos caminos simultáneamente.
- En ese corto espacio, la combinación de entrada OR cambia brevemente, causando cambio de señal durante un corto tiempo. (peligro estático / peligro dinámico)
En un MUX de reloj, A y B suelen ser relojes asíncronos. Dado que la relación de fase entre A y B no es fija, la probabilidad de que la transición sel sea capturada en un "mal momento" es mayor de lo esperado, dando lugar a un bug de silicio que falla "a veces".
2) Por qué es necesario el Clock Glitch
- El ancho de pulso puede ser reconocido como reloj por FF aunque sea corto
Slew/threshold en el árbol de reloj, Dependiendo del filtrado interno de pulsos de la librería FF, pueden ser válidos "bordes no deseados". - Fácil romper setup/hold al mismo tiempo
Si un glitch se adjunta justo antes de un flanco normal, rompe el hold; si se adjunta inmediatamente después, rompe el setup. De cualquier forma, el resultado es aleatorio. - En la era de DVFS/Fail-over/Dominio de potencia, la conmutación de reloj es algo habitual.
3) Glitch-Free의 핵심 정의: "Sellado de las condiciones de transición", no "Glitch 0"
La clave para un Glitch-Free Clock MUX es sencilla.
No se pasan flancos de reloj mientras se cambia el reloj de salida
La señal de selección (Enable) sólo se cambia durante la parte estable del reloj.
Una idea importante aquí:
Los GFCMs son a menudo circuitos habilitados para pausa en lugar de circuitos sin costuras.
Esto significa que el precio de estar libre de glitch puede ser perder un ciclo o dos. Esto debería especificarse en la especificación del diseño." Si el objetivo es la conmutación "sin glitch", no debería ser sólo cuestión de cambiar la MUX, sino que debería abordarse a nivel de arquitectura PLL/clocking.
4) 가장 널리 쓰이는 구조(정석): "Mutual-Exclusion + Safe-Window Update"
Si el glitch está demasiado cerca del reloj antiguo, causará una violación de temporización.
Para evitar esto, necesitamos algo de lógica para pausar el cambio de reloj durante un tiempo.
Si nos fijamos en las partes delantera y trasera, se trata de la misma estructura que un MUX,
- Hay un sincronizador de dos etapas en el interior,
- Hay un bucle de realimentación que se sincroniza con el reloj opuesto cuando cambia la señal SELECT.
Al final, hace lo siguiente.
- habilitar1 y habilitar2 nunca pasan a 1 al mismo tiempo (exclusión mutua)
- apagar un lado antes de encender el otro (romper-antes-de-hacer)
Paramos el reloj brevemente durante la transición, y abrimos el otro lado sólo en el lado seguro.
Esta "pausa" es el coste y la fiabilidad del Glitch-Free.
El canal de Electronicspedia tiene un ejemplo muy bueno de Glitch, así que lo adjunto:
5) "Glitch vs Glitch-Free" en forma de onda (sólo núcleo)
(1) naive MUX (Glitch can occur)
Como se muestra en la figura,
Cuando Sel es 0, CLK1 es la salida, y cuando Sel es 1, CLK2 es la salida.
La alternancia de reloj que sobresale como la parte punteada de CLK Out, que el diseñador no quería, se denomina glitch:
6) En el análisis SDC y CDC:
La salida del Clock MUX es "tanto CLK1 como CLK2". Por lo tanto, es común definir dos relojes generados para el pin de salida, y es exclusivo que ambos relojes generados no puedan estar activos al mismo tiempo.
- El sync FF dentro de la CGPM es CDC, así que compruebe la seguridad funcional por separado con una herramienta CDC (SpyGlass-CDC, etc.).
7) CTS/PnR 인사이트: Los GFCMs no son "bloques lógicos", son "dispositivos Clock Root"
Los GFCMs son de calidad variable dependiendo de su colocación. Esto es especialmente cierto en nodos avanzados:
- Tan cerca de la fuente de reloj (PLL/OSC) como sea posible: Las redes de reloj más largas antes y después del MUX aumentan el impacto SI/EM/IR-drop y la dificultad de gestión del skew:
- Select/control es control, no datos: A medida que crece el fanout, las estructuras sin glitch aumentan el "retardo de transición". Si le das a esta ruta un análisis set_case_analysis, podrías encontrar una enorme violación en la simulación a nivel de puerta. Esto debe gestionarse para poder imponer restricciones:
- Separación de funciones de CTS: El verdadero árbol de reloj se encuentra después de la salida de la CGPM:
- Ciclo de trabajo / integridad de impulsos: Una simple puerta AND/OR puede crear distorsión de trabajo. Prefiera células calificadas por la fundición en lugar de simplemente crear GFCMs en RTL.
En pocas palabras:
Los GFCMs deben ser tratados como parte de la arquitectura de reloj y están "protegidos" en PnR.
8) DFx(Scan/ATPG/Bring-up) 관점: La CGPM es la "puerta a las pruebas"
El escaneo suele tener diferentes exigencias de reloj de desfase y reloj de captura, y las pruebas a velocidad son más exigentes. He aquí cómo un GFCM mal diseñado rompe DFx:
- el escaneo se detiene porque la conmutación de reloj no está permitida en el modo de prueba
- se detiene en la sección de captura, rompiendo el patrón
- se producen fallos en la transición reset/test_en, haciendo que funcione mal
Así que el patrón de trabajo suele ser así.
- Desviar directamente test_clk con test_en (como RTL arriba)
- O tener un mux de reloj separado para escanear, separado del mux de reloj de función
¡Hay algunos expertos que sólo hacen muxes de reloj sin glitch como este!
Describir el Glitch-Free Clock MUX como un "glitch-free mux" es demasiado escueto.
En un SoC moderno, la GFCM es la infraestructura de reloj que se ejecuta a través de DVFS/Fail-over/Dominio de potencia/DFx.
Este pequeño bloque revela la madurez del diseño:
- Los diseños de estudiantes miran "¿tiene sentido la RTL?"
- Los diseños junior miran "¿pasa la STA?"
- Los diseños senior miran "¿puede producirse en masa?"
.