Chanclas con varios relojes

Supongamos que tengo 2 flip-flops FF1 y FF2 que funcionan con varios relojes. ¿Cuáles podrían ser las posibles violaciones con las que nos encontraríamos? Me preguntaron esto en una entrevista a la que respondí diciendo que la diferencia en el sesgo o los relojes causaría violaciones de tiempo y metaestabilidad y expliqué más cómo resolver violaciones de configuración/tiempo de espera. Pero al final, el entrevistador dijo que estos problemas aparecen solo cuando usamos un solo reloj con sesgo/retraso entre las entradas de reloj de los 2 flip-flops. Así que me preguntaba si alguien puede decirme qué sucede cuando uso varios relojes.

esquemático

simular este circuito : esquema creado con CircuitLab

¡Vaya, no sé nada sobre el editor de esquemas! ¡Interesante!
Si los relojes son significativamente diferentes, puede ocurrir una especie de aliasing; esto se aplica cuando el reloj 2 es más bajo que el reloj 1.
¿Los dibujó el entrevistador como FF disparados por el borde o por el nivel? Estaba tratando de que usted discutiera cómo los esquemas de reloj multifásico reducen/eliminan el problema del sesgo y permiten una solución más robusta frente a un esquema de activación de borde de una sola fase.
No, esta fue una entrevista telefónica y sus FF se activaron al límite. ¿Conoce algún enlace que describa el uso de múltiples relojes y sus problemas o ventajas?
@Rancho CLK1 registrará datos a través de la lógica a un ritmo decentemente rápido y si CLK2 va más lento que CLK1, puede "perder" cambios vitales en la salida de la lógica, casi como si estuviera muestreando una señal demasiado lentamente, puede obtener efectos de aliasing que hacen un lío de las cosas. Buscar alias
¿Eso no implica metaestabilidad? ¿La salida sería un valor imprevisto ya que los datos de FF1 podrían no capturarse en FF2 y podrían tener un valor incorrecto? Ok, profundizaré en el alias

Respuestas (2)

El entrevistador simplemente se equivocó. Siempre debe pensar en las violaciones del tiempo de configuración/retención y la posibilidad resultante de metaestabilidad al considerar las señales que pasan de un "dominio" de reloj a otro, independientemente de si los relojes son "casi sincrónicos" o completamente asincrónicos.

Para las señales que realizan transiciones a una velocidad significativamente más lenta que cualquiera de los relojes, generalmente puede usar sincronizadores de doble FF. En otros casos, deberá usar FIFO asincrónicos verdaderos, posiblemente con algún tipo de control de flujo o mecanismo de negociación.

Uno puede, en cierto sentido, tener que "pensar" en ellos, pero hay muchas situaciones del mundo real en las que la naturaleza de al menos una fuente de reloj garantizará que las dos entradas nunca se registren cerca una de la otra, por lo que el "pensamiento " es posible que no tenga que extenderse a nada más allá de "Estas entradas siempre van a cambiar al menos 10us de distancia; los tiempos de s/h en el segundo pestillo son 2ns y 5ns. Dado que 10us es mayor que 5ns, no hay problema".
@supercat: si puede decir eso, entonces está tratando con relojes que están en el mismo dominio y mis comentarios no se aplican.
¿Quizás no entiendo exactamente qué significa "dominio"? Suponga que dos relojes independientes a 3,00 MHz y 3,14159 Mhz pasan a latches T cuyas entradas están doblemente sincronizadas con señales de "habilitación", y el dispositivo que controla las señales de habilitación deshabilitará una latch durante al menos 1us antes de habilitar la otra. Si las salidas de esos pestillos T se usaran como relojes, ¿se consideraría que están en el mismo dominio o en diferentes dominios?
@supercat: OK, con los relojes intermitentes, no estás hablando de técnicas de diseño sincrónico en absoluto, y tienes que aplicar reglas de diseño asincrónico completas. Obviamente, en esta situación particular, puede proponer algunas reglas básicas que eviten la metaestabilidad, pero al menos tuvo que "pensar" para llegar allí.
Por diferentes dominios CLK solo se refería a relojes que son independientes. Estamos acostumbrados a ver el mismo clk en todos los FF (diseños sincrónicos) en nuestros cursos. Entonces, por lo que he aprendido, solo puedo pensar en metaestabilidad y violaciones de tiempo. Por múltiples dominios, dudo si se refería a que los relojes estaban un poco separados. Supongo que algo así como 2 y 4 MHz o 5 y 10 MHz (puede que no sean ejemplos del mundo real). No pregunto mucho ya que no quiero demostrar que no sabía nada sobre relojes múltiples. ¡Así que solo respondí lo que sabía! Gracias por las respuestas. Lo haré; investigar más sobre esto.
@Rancho: Es curioso que un entrevistador sugiera que la metaestabilidad es solo un problema cuando hay una sola fuente de reloj; si un reloj es mucho más rápido que el otro y los tiempos alto y bajo del reloj lento son al menos dos períodos del reloj rápido, se puede evitar la metaestabilidad con bastante facilidad sincronizando el reloj lento con el rápido. Las cosas son mucho más difíciles si se sabe que ninguno de los relojes es mucho más lento que el otro.
@DaveTweed: ¿Qué tan difícil es combinar lógica síncrona y asíncrona en un diseño? He notado que muchos controladores basados ​​en ARM realmente minimizan la cantidad de lógica asíncrona o agregan una molesta lógica de sincronización entre ellos y cualquier cosa que tenga que ver con el núcleo; desde una perspectiva práctica, puede ser más fácil en el software lidiar con el hecho de que configurar una alarma de "despertar" en un contador asíncrono de 32,768 Hz en el momento en que aumenta podría generar un evento falso, que tener que esperar dos 30 us después de solicitar una alarma antes de que se pueda cambiar. Si el software desactiva la interrupción antes...
...escribiendo la hora de la alarma, borra la bandera de interrupción, y luego verifica que el reloj no haya avanzado antes de habilitar la bandera de interrupción (si es así, repita todo el procedimiento), es posible que la bandera de interrupción se vaya metaestable, pero el software nunca lo habilitaría en ninguna situación en la que pudiera ser metaestable. ¿Las herramientas de diseño se resistirían a cualquier intento de crear un diseño de este tipo (dado que las herramientas verían que el pestillo podría volverse metaestable, pero no sabrían que el software anticiparía tal condición y se aseguraría de que en realidad no causara un problema)?
@supercat: ¿De qué manera la lógica de sincronización es más "molesta" que implementar el elaborado protocolo de software que ha descrito? En general, las herramientas de diseño harán lo que les digas; como máximo, recibirá advertencias sobre posibles violaciones del tiempo de configuración/espera. Además, la mayoría de las herramientas tienen formas de suprimir esas advertencias en rutas específicas para las que ha realizado otros arreglos.
@DaveTweed: Cada vez que uno configura una alarma para lo que debería ser un tiempo futuro, es una buena idea verificar, después de configurar la alarma, para asegurarse de que todavía sea un tiempo futuro. Si el único pestillo relacionado con la sincronización es un indicador de "coincidencia" que comparte un reloj con el contador y toma un resultado de comparación generado de forma asincrónica, entonces si el contador no se ha movido mientras se configuraba la alarma, uno sabrá que está configurado. adecuadamente. Si el valor de alarma programado coincide con el valor de conteo, la activación ocurrirá en el siguiente ciclo de conteo. Si el registro de alarma está doblemente sincronizado...
...la alarma más temprana que se puede establecer será de dos ciclos de 32Khz en el futuro. Peor aún, en una serie de procesadores con tales funciones de activación, si uno configura una alarma para un futuro lejano, se acuesta y algún estímulo externo lo despierta casi de inmediato, no podrá comenzar a configurar la alarma para un futuro lejano. tiempo más cercano hasta que la solicitud anterior se haya propagado completamente a través del sincronizador. Por lo tanto, se hace necesario manejar los eventos de activación que se supone que ocurrirán dentro de los próximos cuatro relojes de manera diferente a los de tiempos más distantes.
@DaveTweed: Una cosa que mucha gente de hardware no reconoce es que a menudo no es realmente más difícil en el software hacer algo y volver a intentarlo si falla, que esperar hasta que se pueda hacer algo y hacerlo; si la operación lleva, por ejemplo, 50 ciclos y casi siempre tiene éxito en el segundo intento, si no en el primero, gastar hasta 100 ciclos es mucho mejor que gastar hasta 2000-3000.
@supercat: Estoy de acuerdo, parece que los diseñadores de hardware no consideraron adecuadamente los problemas a nivel del sistema en ese caso. Realmente no hay necesidad de sincronizar dos veces el registro de alarmas, cuando lo único que realmente le importa es la salida del comparador de alarmas. Una implementación de hardware diferente sería mucho más amigable con el software.
@DaveTweed: No sé por qué hay tantos diseños diferentes de "reloj en tiempo real con alarma" hostiles al programador. Parecería que debería ser simple diseñar un contador de 47 bits con un comparador de 32 bits que podría permitir configurar una alarma para cualquier medio ciclo futuro del reloj de 32 KHz y tener un efecto inmediato; el código que quiere configurar una alarma o leer el valor completo de 48 bits tendría que hacer un intento/prueba/reintento, pero esa lógica sería una buena idea en sistemas robustos incluso sin problemas de metaestabilidad. Por cierto, el RTC de un procesador tiene una característica curiosa: ...
...un registro que puede indicar al comparador de alarmas que ignore los 0-7 bits inferiores del contador. Supuestamente, esto reducirá el consumo de energía, pero no estoy seguro de por qué debería hacerlo; si cada bit del contador que comienza con el MSB genera una "coincidencia = (upper_bits_match & Cnt0 & Comp0) o (upper_bits_match & !Cnt0 & !Comp0)", los bits inferiores del contador no harían que ningún transistor en el comparador cambie hasta que los bits superiores coincidan, por lo que el consumo de corriente dinámico debería ser básicamente cero. Es posible que no desee que la comparación se extienda a través de los 32 bits, pero...
... generar una señal de "coincidencia" para los 24 bits superiores y luego introducirla en una cadena para los 8 inferiores aún debería funcionar para minimizar el consumo dinámico de corriente.

La pregunta se hace de manera confusa, lo que podría haber sido el objetivo principal, ya que mezcla algunos conceptos de diferentes aspectos de lo que se conoce como "temporización síncrona de bucle abierto". Es posible que haya estado buscándote para aclarar algunos conceptos clave. Lazo abierto en este contexto significa que los retrasos/fase no están controlados. Aquí hay una breve descripción general para señalar la dirección en una gran simplificación.

1) Reloj global, activado por flanco. Lo que la mayoría de la gente piensa de wrt a la lógica sincrónica. El más popular para el diseño de lógica de gama baja porque el FF activado por bordes brinda un modelo simple de diseño secuencial, en segundo lugar, los FF activados por bordes son comunes y se derivan de TTL, CMOS y en las bibliotecas de celdas estándar que los reemplazaron y, en tercer lugar, la mayoría de los cursos de diseño lógico solo cubren diseños activados por borde. - el inconveniente es que existen dos restricciones: El retardo máximo de la lógica debe ser inferior a un límite para que el circuito funcione con un tiempo de ciclo determinado. El retraso mínimo debe ser mayor que un límite relacionado con el sesgo de reloj para que el circuito funcione a cualquier frecuencia de reloj.

El retraso mínimo en la lógica:

t d , yo o gramo i C t s k mi w + t h o yo d t pag r o pag , C > q

La restricción mínima del ciclo es:

t C y t d , yo o gramo i C + t s k mi w + t s mi t tu pag + t pag r o pag , C > q

2) sincronización bifásica sensible al nivel. Es quizás el régimen de diseño de mayor volumen. porque esto es lo que se usa en upprocessors y dispositivos más complejos. Por supuesto, hay muchas variantes de esto, aquí solo vemos la versión de reloj sin superposición. La lógica se divide entre las FF's maestra y esclava y el tiempo de ciclo mínimo está limitado únicamente por el tiempo prop de cada bloque lógico y el reloj->Q de las FF's. La rotación del reloj (con límites) no figura en estos diseños y, como resultado, son más robustos, más rápidos y más pequeños. No me queda claro por qué esto no se enseña con tanta frecuencia.

t C y t d , yo o gramo i C 1 + t d , yo o gramo i C 1 + 2 t pag r o pag , C > q

Este segundo caso, cuando no hay relojes OL, y no hay un segundo bloque lógico, vuelve al primer caso.

3)Tiempo de ejecución: que no discutiremos aquí.