En los microcontroladores de la serie SAM-D21 de Atmel, muchos periféricos utilizan un reloj que es asíncrono al reloj principal de la CPU, y los accesos a estos periféricos deben pasar por la lógica de sincronización; en los periféricos cuyo reloj es lento en relación con el tiempo de CPU, esto puede agregar algunos retrasos realmente enormes. Por ejemplo, si el RTC está configurado para usar un reloj de 1024Hz (como parece ser la intención del diseño) y la CPU se está ejecutando a 48Mhz, leer el registro de "hora actual" hará que la lógica del bus inserte más de 200,000 estados de espera (un mínimo de cinco ciclos del reloj de 1024Hz). Aunque es posible que la CPU emita una solicitud de lectura, ejecute algún otro código no relacionado y devuelva más de 200,000 ciclos más tarde para recuperar el tiempo, no parece haber ninguna manera de leer el tiempo más rápido. ¿Qué está haciendo la lógica de sincronización que tomaría tanto tiempo (el tiempo se especifica como al menos 5 ⋅ PGCLK + 2 ⋅ PAPB y como máximo 6 ⋅ PGCLK + 3 ⋅ PAPB)?
Por lo que yo entiendo de la sincronización, un circuito de sincronización de un solo bit retrasará una señal 2-3 ciclos del reloj de destino; sincronizar una cantidad de múltiples bits es un poco más difícil, pero hay una variedad de enfoques que pueden garantizar un comportamiento confiable dentro de los cinco ciclos del reloj de destino si es más rápido que el reloj de origen, y solo unos pocos ciclos más si no lo es. ¿Qué haría el Atmel SAM-D21 que requeriría seis ciclos en el dominio de reloj source para la sincronización, y qué factores favorecerían un diseño cuyos retrasos de sincronización son lo suficientemente largos como para requerir una "sincronización realizada"? "interrumpir, en lugar de uno que asegure que los retrasos de sincronización sean lo suficientemente cortos como para hacer que tales interrupciones sean innecesarias?