Чому деякі мікроконтролери мають такі величезні затримки синхронізації?

На мікроконтролерах серії Atmel SAM-D21 багато периферійних пристроїв використовують тактовий годинник, який є асинхронним до основного тактового процесора, а доступ до цих периферійних пристроїв повинен проходити через логіку синхронізації; на периферійних пристроях, годинник яких повільний відносно часу процесора, це може призвести до величезних затримок. Наприклад, якщо RTC налаштований на використання тактової частоти 1024 ГГц (як здається, проектний намір), а процесор працює на 48 МГц, зчитування регістра "поточного часу" призведе до того, що логіка шини вставить понад 200 000 станів очікування (мінімум з п'яти циклів тактової частоти 1024 Гц). Хоча можливо, щоб процесор видав запит на читання, виконав якийсь інший незв’язаний код і повернув 200 000+ циклів пізніше, щоб отримати час, схоже, не існує жодного способу швидше прочитати час.

Як я розумію синхронізацію, однобітна схема синхронізації буде затримувати сигнал на 2-3 цикли тактового призначення; синхронізувати багатобітну кількість - трохи складніше, але існують різноманітні підходи, які можуть гарантувати надійну поведінку протягом п’яти циклів годинного призначення, якщо це швидше, ніж вихідний годинник, і лише на кілька циклів більше, якщо це не так. Що робити Atmel SAM-D21, що вимагатиме шести циклів у вихідному тактовому домені для синхронізації та які фактори сприятимуть конструкції, затримки синхронізації якої є настільки довгими, що вимагають переривання "синхронізації, виконаної", проти того, що забезпечує Затримки синхронізації досить короткі, щоб зробити такі переривання непотрібними?

Це інший спосіб робити для мене речі, я звик до моїх архітектур, де мої регістри знаходяться або на моєму процесорному годиннику, або принаймні 1/2 цього годинника. Отже, ви пишете свої регістри, і вони вже готові. Можливо, вони роблять це таким чином для економії електроенергії? Якщо вони ставлять периферійні регістри в свій окремий дійсно повільний домен годинника, можливо, їм не доведеться прокидатися і запускати головний генератор або тактовий процесор, але вони можуть тримати оновлення значень на периферійних пристроях.

Якщо це так, ви можете записати реєстр у свій супер повільний периферійний блок, а потім відключити острів живлення для всього процесора або годинникового воріт, і дозволити повільному синхронізатору прочитати його, поки він не буде задоволений, а потім перервати процесор, щоб вивести його сну.

Крім того, це може дозволити вам набити максимальну кількість інструкцій у свій неспаний час, замість того, щоб крутити шість циклів і чекати кожного запису.

Щодо того, чому вони використовують стільки циклів синхронізації, це може бути параноя, або вони можуть відповідати якомусь високому стандарту надійності для одного з своїх клієнтів. Я не можу сказати точно, але я знаю, що я бачив клієнтів із вимогами, як кожен баран повинен мати ecc і бути попередньо завантажений до встановленого значення тощо.

Я думаю, це не остаточна відповідь, але це мої думки, переглянувши аркуш трохи.