跨时钟域问题(ClockDomainCrossing)

《跨时钟域问题(ClockDomainCrossing)》由会员分享，可在线阅读，更多相关《跨时钟域问题(ClockDomainCrossing)（5页珍藏版）》请在装配图网上搜索。

1、引言：设计者有时候需要将处于两个不同时钟域的系统对接，由于接口处是异步(会产生setuptime和holdtimeviolation，亚稳态以及不可靠的数据传输)的，因此处理起来较同步逻辑更棘手，需要寻求特殊处理来进行接口界面的设计。任意的两个系统如果满足以下条件之一，就可称其为异步的：(1)工作在不同的时钟频率上；(2)工作频率相同，但是相位不相同；处理跨时钟域的数据传输，有两种实现方案(1) 采用握手信号来交互(2) 以异步FIFO来实现、以握手信号交互：假设系统A以这种方式向系统B传递数据，握手信号分别为req和ack。握手协议：Transmitterassertsthereq(requ

2、est)signal,askingthereceivertoacceptthedataonthedatabus.Receiverassertstheack(acknowledge)signal,assertingthatithasacceptedthedata.这种处理跨时钟域的方式很直接，但是也最容易产生亚稳态，由于系统A发送的req信号需要系统B中的时钟去sample，而系统B发出的ack信号又需要系统A中的时钟去sample，这样两边都存在着setuptime和holdtimeviolation的问题。为了避免由于setuptime和holdtimevilation所造成的亚稳态，通常我

3、们可以将异步时钟域交互的信号用localsystem的时钟打两级甚至三级寄存器，以此来消除亚稳态的影响。下图以系统A发送到系统B的req信号示例消除亚稳态的方法：当然，这种处理方式是以损失传输速率为代价的，加入两到三级寄存器同步异步时钟域的信号，会有许多时钟周期浪费在了系统的“握手”。有时候，我们也会对数据多打两拍reg来同步，但通常情况下，我们并不会采取这种方式，它不仅需要较多逻辑，而且收效甚微。通常对数据的同步是以异步FIFO来实现的。下图给出了1bit数据传输打两拍reg所做的同步，从中可以发现，与前面的握手信号处理完全一致。方向考虑可以单独流片，因此对整个逻辑结构进行了划分，在做FPG

4、A原型验证的时候，将这两块逻辑分别映射到不同的器件单元中，这里暂且称它们为wrapper。和wrapperl。实践结果表明，wrapper。和wrapperl的相位需要存在180度的反相，弥补板级走线的延迟影响。这样一来，在wrapper。和wrapperl主交互界面的信号就横跨时钟域，存在着亚稳态问题的困扰了。由于个人对此处亚稳态问题的认识程度不充分，当时没有对界面上的信号做处理，而是将精力放在了对pin脚延迟的处理上，结果收效甚微。设计的功能是视频编码相关的，测试的结果就会发现：一开始，经过前处理的数据写入到SDRAM内部也是正常的，编码出来的图像经过AP（ApplicationProgr

5、am）实时播放显示也是正常的，而且有早期测试的基础放在那里，显然不可能是编码内核本身出了差错；在间隔一段时间后，可以明显看到AP实时播放的图像出现了绿色的竖状条，而且随着时间的累积，这些竖条会逐步扩展，移动。这种现象很明显地告诉设计人员：前处理后的数据与SDRAM通信时存在着bug！SDRAMcontroller模块，或者说总线仲裁模块（我们的设计并不是采用SOC方案，而是以纯ASIC的方案进行，总线仲裁和流水线调度都放在了SDRAMcontroller中）的问题排查是比较好解决的。一来，该模块中集成了SDRAM自测试逻辑，可以很方便地检测对SDRAM的读写是否存在着误差；二来，编码内核本身从

6、SDRAM取数据也进行了旁路设计,就是说编码的数据可以是以测试模式来处理，而并非实际外接的数据源，这样就可以在长时间编码时查看AP是否同样会出现上述症况。在本人和项目组其他同仁以上述方案进行了探索性测试后，确定了前面所述的结论：问题的根源肯定不是发现在编码内核，而是前处理后的数据与SDRAM通信时存在着bug!但，令人沮丧的是，我们走了一条错误的道路，认为问题的根源在于板级延迟造成的，而不是跨时钟域的问题，直到走到死胡同里才发现：哟，原来刚才那条小道才是出路!实践也确实检验了处理亚稳态的理论：wrapper。和wrapper1的交互信号在做了两级寄存器同步后，整个系统安全稳定的运行!所以说，看

7、本文的各位同仁，千万要记得在处理跨时钟域问题时多留神，不要被这个看似不大不小的问题折腾得食不甘味、夜不能寐啊，哈哈，有些小夸张2.1以异步FIFO应对跨时钟域设计对性能要求较高而不太计较资源，或者不期望浪费时间在握手信号的处理上时，通常会采用异步FIFO来处理跨时钟域可能引入的亚稳态问题。异步FIFO的两个界面分别完成数据的写入和读取，两个界面的时钟是不一致的（当然，如果一致的话也就无从谈异步FIFO了）。这里假设系统A向异步FIFO写入数据，系统B从异步FIFO中读取数据。为了对可能引入的错误操作进行处理（例如，没有空间了，却还有数据要写入，或者是相反，完全腾空了，却有读取数据的操作），我们

8、引入了FIFO空、满（empty,full）信号，这两个信号都是产生于相对应的时钟域，也就是说，这两个信号是处在不同的时钟域当中的!例如：FIFOfull信号由系统A产生（当FIFO写满时，我们不期望系统A有数据要写入，否则，会发生数据丢失），或者说该信号是有写入时钟驱动的；类似地,FIFOempty信号受读取时钟驱动（当FIFO读空时，我们也不期望系统B有读数据的请求，否则，会读取错误的数据）。如何设计异步FIFO不是本文所要探讨的问题，不过我希望提醒大家的是：对FIFO空、满信号的处理一定要多加注意，上面以及提到，这两者是处于不同时钟域中的，会造成亚稳态问题。2.2结合实际工作谈谈以异步F

9、IFO处理的跨时钟域问题无论是做数据通信、音视频处理、图形图像，还是做网络安全、数据存储，都无法避开的问题就是和各种各样的数据总线协议打交道。通常来讲，我们的设计不可能碰巧刚刚好和总线协议的时钟同时钟域，或者总线协议支持多种时钟域驱动，因此一来，对数据的传输通道而言，始终都无法避开的一个问题就是：跨时钟域数据交互！以异步FIFO来处理跨时钟域的数据传输是通用的解决手段，需要特别注意的则是对FIFO空、满信号的处理。拿所设计的项目中一条传输通路为例，其数据写入是从SDRAM中吐出的，其数据读取符合某一种总线协议，其时钟频率与内核不一致。这样对于写入端而言，需要对FIFO空信号进行如下处理：首先，

10、在SDRAM中没有数据时，不要发送要数据的请求；其次，保证FIFO的深度适当，使得发出FIFO空信号时，SDRAM中不会发生数据覆盖现象；对于取数据端而言，类似地，需要对FIFO满信号进行如下处理：首先，保证FIFO满信号能够尽量有规律地发出，保证传输通道以及上层处理程序能够有效响应；其次，对FIFO满信号（实际处理时的中断信号正是由此信号再作处理得来）以及每次传输得包大小能够调节，保证数据传输得稳定性；简单来讲，FIFO空了，就有要数据的权利；FIFO满了，就有吐数据的权利；但是，在处理这种空、满信号时又需要考虑周全，什么样的情形下，即使时饿了也不能立刻给吃的；什么样的情形下，即使是饱了也不能立刻离席！而且这个筵席是两方当事人所摆设的，要顾全双方的感受！打了上述这个小小的比方，不知道是否得当，大家看时权且一笑而过，心领神会就可P.S.:其实，在逻辑设计中，跨时钟域、亚稳态影响正越来越凸现，我们的设计日益复杂，需要交互的接口繁多，如何提高设计的可靠性，保证数据传输以及信号交互的稳定，将是一个重要的设计议题。本文抛砖引玉，希望有更多高手予以探讨！此外，本人不才，准备将收集到的一些有关跨时钟域的问题整理好、翻译好后与大家一同分享。