¿Qué es un reloj de ondas?

Estoy leyendo el Capítulo 12. Prácticas de diseño recomendadas del Manual de Quartus II Versión 13.1 Volumen 1: Diseño y síntesis que establece (p. 8):

Los contadores de ondulación utilizan registros en cascada, en los que el pin de salida de un registro alimenta el pin de reloj del registro en la siguiente etapa. Esta cascada puede causar problemas porque el contador crea un reloj ondulado en cada etapa. Estos relojes de ondulación deben manejarse adecuadamente durante el análisis de tiempo, lo que puede ser difícil y puede requerir que realice asignaciones de tiempo complicadas en sus herramientas de síntesis y ubicación y enrutamiento.

¿Qué es un reloj de ondas? ¿Por qué es difícil el análisis de tiempo en un reloj de ondulación?

Respuestas (4)

En Quartus II, el reloj Ripple es cualquier reloj impulsado por la salida de otro registro. Un par de problemas con los relojes de ondulación:

  1. El último reloj tendrá un retraso con respecto al reloj de entrada, porque pasa por varios fracasos. Entonces, ¿cuál es el problema con este retraso? Tendrá problemas cuando su diseño tenga rutas de dominio cruzado entre estos dos relojes. Si alguna ruta tiene un reloj de lanzamiento desde el dominio de reloj de entrada y un reloj de captura proveniente de ese dominio de reloj derivado, esa ruta tendrá una gran desviación. Por lo tanto, tendrá dificultades para cumplir con el tiempo.

  2. Otro problema es escribir restricciones SDC. Tienes que escribir las definiciones de reloj en cada etapa incluso si no se usan. Vea un ejemplo aquí en la página 18.

Este es un contador de ondas:

esquemático

simular este circuito : esquema creado con CircuitLab

Es un contador asíncrono que dividirá el reloj de entrada por 2 en cada etapa. Es un contador asíncrono porque cada etapa cambiará en momentos diferentes y cada flip-flop tiene una entrada de reloj diferente. La diferencia de tiempo entre cada etapa está determinada por el retardo CLOCK->Q del flip-flop utilizado. El resultado simulado se muestra a continuación, mostrando que cada etapa retrasa la transición de salida por el retraso de reloj a salida.

ingrese la descripción de la imagen aquí

Ahora, para poner la importancia de esto en la perspectiva de un FPGA, la herramienta de análisis de tiempo quiere asegurarse de que todo se registre en el momento correcto. Parte de eso es hacer que cada señal que ingresa al pin CLK de un flip-flop sea un reloj del sistema que debe sincronizarse con todos los demás relojes. Como tal, si ingresé el esquema anterior en una herramienta de síntesis de FPGA, consideraría las redes CLK_IN, DIV_2, DIV_4y DIV_8como redes de "reloj", independientemente de si se usan para controlar otros relojes. Esto probablemente funcionará bien como contador (existe la posibilidad de una violación del tiempo de espera en cada flip-flop), pero no está hecho en el método de lógica síncrona.

Si está usando esto para tomar un reloj de entrada rápido y derivar un reloj único más lento (por ejemplo, hacer DIV_8un reloj maestro para el sistema), entonces probablemente esté bien.

El problema surge cuando desea que los circuitos rápidos CLK_INinteractúen con circuitos lentos sincronizados con DIV_8. En este caso, desea sincronizar los flancos ascendentes del reloj, pero tendrá una gran desviación de reloj entre estas redes de reloj. La cantidad de sesgo de reloj generado por una etapa podría ser suficiente para causar errores de sincronización, y más etapas casi lo garantizarán.

Si desea crear dos relojes sincronizados dentro de una FPGA, lo mejor que puede hacer es utilizar un generador de reloj síncrono o un módulo de reloj que sea interno de la FPGA, como un bloque PLL/DCM.

Si la tasa de conteo en un contador de ondulación es más lenta que la tasa del reloj maestro, esperaría que uno pudiera obtener el valor de manera confiable tomando múltiples lecturas consecutivas (tres a menos que la propagación de la ondulación sea muy lenta). No he visto muchos chips exponer un contador de ondulación directamente al software, pero cuando se usa, por ejemplo, un reloj de CPU rápido para leer un contador que se ejecuta a 32,768 Hz, hacer que el código tome lecturas hasta que obtenga dos consecutivos que coincidan no debería ser menos confiable que tener que usar una secuencia de varios pasos para capturar el valor en un registro sincronizado y leerlo.
@supercat El problema no es que sea imposible , solo que existe un peligro. Ha descrito estrategias de mitigación válidas, pero la herramienta de análisis de tiempo estático no hará suposiciones sobre el manejo de su señal. Puede anular este comportamiento configurando el diseño, pero la intención es que el software falle de forma "segura".
Me parece bien. Al observar los diversos requisitos que imponen los chips al contar señales asíncronas, a menudo me pregunto hasta qué punto las herramientas de diseño son sirvientes de los diseñadores de chips y hasta qué punto los diseñadores y sus diseños son esclavos de las herramientas. Yo pensaría, por ejemplo, que sería común que un chip quisiera reducir la velocidad de la CPU cuando no está haciendo mucho, pero poder aumentarla cuando llegan datos en serie que necesitan ser procesados, pero relativamente pocos microcontroladores lo permiten. la velocidad de la CPU se cambiará sin interrumpir las operaciones de UART.
Reconozco que para evitar la metaestabilidad, la E/S de estado de espera cero solo se puede permitir cuando la CPU accede a cosas que están sincronizadas con el reloj de la CPU; Sin embargo, si uno puede aceptar estados de espera, ¿debería haber algún problema con tener un subsistema de E/S como si estuviera conectado a la CPU a través de un bus de memoria asíncrono de estilo antiguo? ¿O el problema es en gran parte que las herramientas de diseño y simulación no pueden manejar estas cosas muy bien?
Una buena alternativa que evita todos estos problemas es implementar una lógica lenta basada en el reloj rápido más señales de habilitación de reloj que pulsan durante un ciclo de reloj por intervalo lento.
@BenVoigt: Eso es bueno si el reloj rápido siempre existirá y será "rápido". Lo que me gustaría ver sería un subsistema periférico que derivara la temporización de un reloj que estaba separado del reloj del sistema, podría ser cronometrado por el reloj del sistema cuando estaba funcionando adecuadamente rápido (controlado por una señal de reloj una vez por periférico ), o el propio reloj periférico (cuando el reloj del sistema no se puede utilizar), y estaría en todo momento dentro de dos relojes de donde estaría si el reloj periférico marcara continuamente el reloj. Sin embargo, no tengo idea de cuán viable sería tal cosa.
@supercat: No creo que sea factible. Puede perder un ciclo de reloj cada vez que la fuente del reloj cambia (debido a que no puede violar el tiempo de ciclo mínimo, tendrá que esperar el siguiente borde), por lo que no creo que "dentro de dos relojes" sea alcanzable a largo plazo. Algunos bloques de distribución de reloj de FPGA tienen capacidad de reloj alternativo, pero sin la garantía de "dentro de dos ciclos".
@BenVoigt: supongamos que uno tiene un contador de código gris de 3 bits que cuenta la cantidad de pulsos del reloj de 1 MHz que se han producido desde el encendido, y un contador de código gris de 3 bits que cuenta la cantidad de relojes "activos" procesados ​​por la lógica desde puesta en marcha. Cuando del reloj de 1 MHz al reloj de la CPU de 4 MHz, es posible que ocurran dos relojes de 1 MHz sin que se registre la lógica del periférico, pero en los dos primeros relojes de 4 MHz que recibe, debería notar que los contadores no coinciden y, por lo tanto, activar el periférico. lógica en ambos. El efecto sería que el primer reloj después del cambio...
... sucedería "tarde", pero uno podría cambiar las fuentes de reloj cualquier cantidad de veces sin una ganancia o pérdida neta de eventos de reloj. Algunas aplicaciones requerirían que los bordes generados por periféricos fueran precisos a 1us, pero en muchas aplicaciones, 1us de fluctuación no representaría un problema si la fluctuación representara la única incertidumbre en el conteo.
Chicos... este no es el lugar para debatir técnicas de sincronización de relojes. Mi punto (en la respuesta) es que esto es una advertencia y existen peligros potenciales si hay interacciones entre múltiples dominios de reloj. Si ha implementado una de estas técnicas, entonces ha prestado atención a la advertencia "Ripple Clock".
@supercat: piénselo, cada vez que cambia el reloj entre dos fuentes no alineadas, el intervalo entre los bordes no puede ser exacto (los relojes no están alineados), por lo que tiene que ser demasiado largo o demasiado corto. Demasiado corto viola las restricciones de tiempo, por lo que debe perder tiempo en cada cambio.

Este problema afecta no solo a los contadores binarios simples, sino también a los más complicados, como los contadores de décadas (como el 74HCT4017 ), donde cada contador cuenta internamente de 0 a 9 y está conectado para restablecerse a 0 en el décimo pulso.

Supongamos que tiene varios contadores de décadas, uno para la posición de las unidades, la posición de las decenas, la posición de las centenas, etc.

Cada uno de los contadores de décadas tiene una entrada de reloj. El reloj del contador de unidades se alimenta de la fuente de reloj principal, que presumiblemente se puede encender y apagar. El reloj del contador de decenas está conectado para llevar la salida del contador de unidades. Cuando el contador de unidades cuenta de 9 a 10, suceden dos cosas: el contador se restablece a 0 (por lo que nunca hay una salida válida de 10), y se propaga un pulso de reloj a la entrada de reloj del siguiente contador, en este caso el lugar de las decenas.

La razón por la que se llama reloj de ondulación es que el reloj que entra en el contador de decenas se retrasará al menos un retraso de propagación desde el reloj original que entra en el lugar de las unidades. Esto tendrá entonces lo que se llama un "efecto dominó", por ejemplo, si tiene un contador de 6 posiciones, el reloj que entra en la sexta posición en una transición de 099999 a 100000 se retrasará cinco veces.

Esto puede crear problemas de temporización, por ejemplo, si se trata de comparar la salida de los contadores con un valor particular, los contadores no cambian todos a la vez, por lo que el circuito de comparación puede activarse en el momento equivocado; no hay señal de que dice: todas las salidas son estables.

Por lo que he visto, Ripple Conters, como a veces se les llama, son temporizadores digitales (contadores) que se usan cuando no se requiere precisión y el objetivo es la simplicidad. Además, se pueden utilizar como divisores de reloj para preescalar una señal de reloj de entrada en un orden de 2 por etapa.

Básicamente, tienes una serie de FlipFlops conectados donde la salida de la etapa anterior se convierte en el reloj de la siguiente etapa.

Figura 1

Ver: contador de ondas