W mikrokontrolerach serii SAM-D21 Atmel wiele urządzeń peryferyjnych używa zegara, który jest asynchroniczny z zegarem głównego procesora, a dostęp do tych urządzeń peryferyjnych musi odbywać się za pomocą logiki synchronizacji; na urządzeniach peryferyjnych, których zegar jest wolny w stosunku do czasu procesora, może to spowodować naprawdę duże opóźnienia. Na przykład, jeśli RTC jest skonfigurowany do korzystania z zegara 1024Hz (jak wydaje się być celem projektu), a procesor pracuje z częstotliwością 48 MHz, odczyt rejestru „aktualny czas” spowoduje wstawienie przez logikę magistrali ponad 200 000 stanów oczekiwania (minimum pięciu cykli zegara 1024Hz). Chociaż możliwe jest, że CPU wyda żądanie odczytu, wykona jakiś inny niepowiązany kod i zwróci ponad 200 000 cykli później, aby pobrać czas, wydaje się, że nie ma sposobu, aby faktycznie odczytać czas szybciej.
W moim rozumieniu synchronizacji, jednobitowy obwód synchronizujący opóźni sygnał o 2-3 cykle docelowego zegara; synchronizacja wielobitowej ilości jest nieco trudniejsza, ale istnieje wiele podejść, które mogą zagwarantować niezawodne zachowanie w ciągu pięciu cykli zegara docelowego, jeśli jest on szybszy niż zegar źródłowy, i tylko kilka cykli więcej, jeśli nie jest. To, co robiłby Atmel SAM-D21, wymagałoby sześciu cykli w źródłowej domenie zegarowej do synchronizacji i jakie czynniki sprzyjałyby projektowi, którego opóźnienia synchronizacji są na tyle długie, że wymagają przerwania „synchronizacji wykonanej”, w porównaniu z takim, który zapewnia opóźnienia synchronizacji są wystarczająco krótkie, aby uczynić takie przerwania niepotrzebnymi?