Cruce de dominios de reloj: ¿Es posible diseñar una arquitectura de un dominio más rápido a uno más lento y de un dominio más lento a uno más rápido simultáneamente?

Si tengo un diseño que tiene reloj de lectura y reloj de escritura, y quiero que funcione para los siguientes escenarios:

  1. reloj de lectura más rápido y reloj de escritura más lento
  2. reloj de lectura más lento y reloj de escritura más rápido

¿Es esto posible sin cambiar la arquitectura de un escenario a otro?

Por ejemplo: tengo un solo pulso que pasa de un dominio de reloj a otro. Quiero que sea detectado en cualquiera de los escenarios.

PD: Nunca antes había trabajado en CDC. Acabo de empezar a investigarlo.

No especifica si está utilizando un FPGA o cualquier otro objetivo. Dado que el cruce de dominios de reloj puede crear errores sutiles, muchos fabricantes suelen proporcionar IP enlatada que hace bien el trabajo. Por ejemplo, puede usar un pequeño núcleo FIFO asíncrono.
¿Qué debe suceder en los diversos tipos de bordes de reloj, qué tipos de retrasos en el protocolo de enlace son aceptables y se sabrá algo "por adelantado" sobre los cambios en los relojes?

Respuestas (2)

Para empezar, depende de la arquitectura de su diseño. Por ejemplo, considere transmitir 'datos' y 'datos válidos' de un dominio a otro.

Si el reloj del circuito de origen es más lento que el reloj del circuito de destino, el circuito de destino puede, y lo hará, ver 'dataValid' como afirmado para más relojes de los que la fuente pretendía que fueran. Si el reloj de origen es más rápido que el reloj de destino, el circuito de destino puede pasar por alto que 'dataValid' es alto por completo o verlo como afirmado para menos relojes de los que la fuente pretendía que fueran.

La lista de áreas de preocupación continúa, pero el punto es que el circuito debe diseñarse teniendo en cuenta el flujo de datos, los tiempos de viaje y el protocolo de enlace entre los dos circuitos. A menudo es esencial planificarlo desde el principio, pero a veces se puede agregar más tarde con menos problemas. Luego están todos los problemas de diseñar la metaestabilidad.

Todo se puede hacer, todo se puede hacer perfectamente bien, pero necesita comprensión y planificación. No es una tarea baladí.

Sí, un método es insertar "burbujas" (ciclo inactivo) en el lado que sea más rápido para mantener igual el número total de ciclos entre ambos lados. Esta es una especie de técnica de pseudo-sincronización para FIFO.

Por lo general, esto solo se haría en el lado más rápido. Si los relojes pueden cambiar cuál es más rápido, puede colocar uno en cada lado y desactivar el que esté en el lado más lento.

O puede optar por una solución FIFO asíncrona que no requiera nada especial para el lado más lento/más rápido. Para lidiar con la metaestabilidad, generalmente se usan dos FF para almacenar el puntero de escritura (reduce en gran medida la posibilidad de metaestabilidad a un nivel estadísticamente insignificante), lo que brinda un ciclo adicional de retraso entre lectura/escritura. Esto aumenta la latencia pero no tiene efecto en el rendimiento.

No tengo claro el primer método. ¿Puedes explicarlo más? Nunca encontré este método. Gracias.
@ssgr: Suponga que tiene una relación de reloj de 3:4. Durante un período de tiempo, el lado más lento tendrá 3 ciclos, mientras que el lado más rápido tendrá cuatro ciclos. Entonces, si cada cuarto ciclo en el lado rápido deshabilita todo (bloqueo) durante un ciclo, entonces tendrá la misma cantidad de ciclos en ambos lados. El controlador lógico que logra esto se llama "generador de burbujas". google.com/patents/US8205111
Un término más genérico para lo que hace el "generador de burbujas" es "control de flujo". El control de flujo puede adoptar muchas formas, pero la idea básica es que existe una especie de apretón de manos bidireccional entre un productor y un consumidor de información que evita que el lado más lento se vea abrumado por el lado más rápido. Incluso si la "información" es solo un flujo de pulsos, habrá una retroalimentación de que se ha generado un pulso en el lado de salida, de modo que se pueda aceptar otro en el lado de entrada.
@DaveTweed: Pero, si lee el documento, el generador de burbujas no es parte del circuito de negociación (que se realiza con lógica de solicitud/reconocimiento), sino que se establece según las proporciones de los relojes y utiliza la navegación a estima para omitir ciertos ciclos. Como dije, este es solo un método.
Pero estás suponiendo que un reloj se deriva directamente del otro, por lo que tienen una relación de frecuencia fija y simple. La pregunta del OP es más general que eso y, en general, debe asumir que son efectivamente asincrónicos y descontrolados, que es lo que impulsa la necesidad de retroalimentación.
@DaveTweed: ¿Leíste mi respuesta o solo estás parloteando? Usted resumió mal el documento de ejemplo al que hice referencia, luego, cuando lo corrigió, eligió algún otro problema que no era para criticar. Como dije en el segundo párrafo "O podría optar por una solución FIFO asíncrona". Honestamente, comentas muchas de mis respuestas y, en general, nunca agrega nada, excepto para inyectarte a ti mismo.
Cruce de dominios de reloj: ¿Es posible diseñar una arquitectura de un dominio más rápido a uno más lento y de un dominio más lento a uno más rápido simultáneamente?
RespuestasAquíPolítica de privacidad1y, 0v