En los microcontroladores de la serie Atmel SAM-D21, muchos periféricos usan un reloj que es asíncrono al reloj de la CPU principal, y los accesos a estos periféricos deben pasar por la lógica de sincronización; en periféricos cuyo reloj es lento en relación con el tiempo de CPU, esto puede agregar algunos retrasos realmente grandes. 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 está funcionando 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 forma de leer el tiempo más rápido.
Según tengo entendido de la sincronización, un circuito de sincronización de un solo bit retrasará una señal en 2-3 ciclos del reloj de destino; sincronizar una cantidad de varios 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é estaría haciendo el Atmel SAM-D21 que requeriría seis ciclos en el dominio del reloj de origen para la sincronización, y qué factores favorecerían un diseño cuyos retrasos de sincronización son tan largos como para necesitar una interrupción de "sincronización realizada", frente a uno que garantice los retrasos de sincronización son lo suficientemente cortos como para que tales interrupciones sean innecesarias?