Nos microcontroladores da série Atmel SAM-D21, muitos periféricos usam um relógio que é assíncrono ao relógio principal da CPU, e os acessos a esses periféricos devem passar pela lógica de sincronização; em periféricos cujo relógio é lento em relação ao tempo da CPU, isso pode adicionar alguns atrasos realmente enormes. Por exemplo, se o RTC estiver configurado para usar um relógio de 1024Hz (como parece ser a intenção do projeto) e a CPU estiver funcionando a 48Mhz, a leitura do registro "horário atual" fará com que a lógica do barramento insira mais de 200.000 estados de espera (no mínimo de cinco ciclos do relógio de 1024Hz). Embora seja possível que a CPU emita uma solicitação de leitura, execute algum outro código não relacionado e retorne mais de 200.000 ciclos mais tarde para buscar o tempo, não parece haver nenhuma maneira de realmente ler o tempo mais rapidamente.
Pelo meu entendimento da sincronização, um circuito de sincronização de bit único atrasará um sinal em 2-3 ciclos do relógio de destino; sincronizar uma quantidade de vários bits é um pouco mais difícil, mas há uma variedade de abordagens que podem garantir um comportamento confiável em cinco ciclos do relógio de destino, se for mais rápido que o relógio de origem, e apenas alguns ciclos a mais, se não for. O que o Atmel SAM-D21 estaria fazendo que exigiria seis ciclos no domínio do relógio de origem para sincronização e quais fatores favoreceriam um design cujos atrasos na sincronização sejam longos o suficiente para exigir uma interrupção "sincronização concluída", versus um que garanta os atrasos de sincronização são curtos o suficiente para tornar desnecessárias essas interrupções?