Pourquoi certains microcontrôleurs ont-ils des retards de synchronisation aussi importants?

Sur les microcontrôleurs de la série Atmel SAM-D21, de nombreux périphériques utilisent une horloge qui est asynchrone à l'horloge du processeur principal, et les accès à ces périphériques doivent passer par une logique de synchronisation; sur les périphériques dont l'horloge est lente par rapport au temps CPU, cela peut ajouter des retards vraiment énormes. Par exemple, si le RTC est configuré pour utiliser une horloge de 1024 Hz (comme cela semble être l'intention de conception) et que le CPU fonctionne à 48 MHz, la lecture du registre "heure actuelle" entraînera l'insertion par la logique du bus de plus de 200 000 états d'attente (un minimum de cinq cycles de l’horloge 1024 Hz). Bien qu'il soit possible que le CPU émette une demande de lecture, exécute un autre code non lié et renvoie plus de 200 000 cycles plus tard pour récupérer l'heure, il ne semble pas y avoir de moyen de lire l'heure plus rapidement.

D'après ma compréhension de la synchronisation, un circuit de synchronisation à un bit retardera un signal de 2-3 cycles de l'horloge de destination; la synchronisation d'une quantité multi-bits est un peu plus difficile, mais il existe une variété d'approches qui peuvent garantir un comportement fiable dans les cinq cycles de l'horloge de destination si elle est plus rapide que l'horloge source, et seulement quelques cycles de plus si ce n'est pas le cas. Que ferait l'Atmel SAM-D21 qui nécessiterait six cycles dans le domaine de l'horloge source pour la synchronisation, et quels facteurs favoriseraient une conception dont les délais de synchronisation sont suffisamment longs pour nécessiter une interruption "synchronisation effectuée", par rapport à une interruption qui assure les délais de synchronisation sont suffisamment courts pour rendre ces interruptions inutiles?

C'est une façon différente de faire les choses pour moi, je suis habitué à mes architectures où mes registres sont soit sur mon horloge CPU, soit au moins la moitié de cette horloge. Vous écrivez donc vos registres et ils sont prêts tout de suite. Peut-être le font-ils de cette façon pour économiser de l'énergie? S'ils placent des registres périphériques dans leur propre domaine d'horloge très lent, ils n'ont peut-être pas à se réveiller et à exécuter l'oscillateur principal ou l'horloge du processeur, mais peuvent continuer à mettre à jour les valeurs sur le périphérique.

Si c'est le cas, vous pouvez écrire un registre dans votre bloc périphérique super lent, puis désactiver l'îlot d'alimentation pour l'ensemble du processeur ou de l'horloge, et laisser le synchroniseur lent le lire jusqu'à ce qu'il soit satisfait, puis interrompre le processeur pour le faire ressortir de sommeil.

Alternativement, il pourrait vous permettre de charger le maximum d'instructions dans votre temps de veille, au lieu de faire tourner six cycles et d'attendre chaque écriture.

Quant à savoir pourquoi ils utilisent autant de cycles de synchronisation, cela pourrait être de la paranoïa, ou ils pourraient répondre à une norme de fiabilité élevée pour l'un de leurs clients. Je ne peux pas le dire avec certitude, mais je sais que j'ai vu des clients ayant des demandes, comme chaque vérin doit avoir ecc et être préchargé à une valeur définie, etc.

Je suppose que ce n'est pas une réponse définitive, mais ce sont mes pensées après avoir parcouru un peu la fiche technique.