为什么有些微控制器具有如此大的同步延迟？

在Atmel SAM-D21系列微控制器上，许多外围设备使用的时钟与主CPU时钟异步，并且对这些外围设备的访问必须通过同步逻辑进行；在时钟相对于CPU时间较慢的外设上，这会增加一些非常大的延迟。例如，如果将RTC配置为使用1024Hz时钟（这似乎是设计意图），并且CPU以48Mhz运行，则读取“当前时间”寄存器将导致总线逻辑插入超过200,000个等待状态（最小1024Hz时钟的五个周期）。尽管有可能让CPU发出读取请求，执行一些其他不相关的代码，然后在以后返回200,000个以上的周期来获取时间，但似乎没有任何方法可以更快地实际读取时间。

根据我对同步的理解，一个单位同步电路会将信号延迟目标时钟的2-3个周期。同步多位数量会比较困难，但是有多种方法可以保证目标时钟的五个周期（比源时钟快）在五个时钟周期内具有可靠的行为，如果不是，则只能保证几个周期。Atmel SAM-D21的工作将需要在源时钟域中进行六个周期来进行同步，并且哪些因素会有利于其同步延迟足够长以至于需要“同步完成”中断的设计，而确保同步的中断则需要一个周期。同步延迟足够短，以致于不需要此类中断？

这对我来说是另一种处理方式，我已经习惯了我的体系结构，在这些体系结构中，寄存器要么位于CPU时钟上，要么至少位于该时钟的1/2上。这样，您编写您的寄存器，它们就可以立即准备就绪。也许他们这样做是为了省电？如果他们将外设寄存器放在自己单独的真正慢时钟域中，则也许不必唤醒并运行主振荡器或CPU时钟，但可以不断更新外设上的值。

如果是这种情况，那么您可以在超慢速外围模块中写入一个寄存器，然后为整个CPU禁用电源岛或对其进行时钟门控，然后让慢速同步器对其进行读取，直到满意为止，然后中断CPU将其取出睡眠

另外，它可以让您将最多的指令塞入您的清醒时间，而不必旋转六个周期并等待每次写入。

至于为什么他们使用这么多同步周期，可能是偏执狂，或者他们可能满足其客户之一的某些高可靠性标准。我不能肯定地说，但我知道我已经看到客户的需求，例如每个公羊都应具有ecc并预加载到设定值等。

我想这不是一个明确的答案，但这是我稍稍浏览一下数据表后的想法。