UVM源码计划系列因为1X同学被分配了很繁重的工作，所以暂时先学到这，啥时候有闲暇时光了再继续往下学。同时IC checklist的三篇也已经推送完成，本来交付系列还有一些备份但是内容还是没打磨好，也日后再输出吧。总结下来最近就先专心更从RTL到GDS、异步逻辑以及开源项目阅览三个系列好了，在过程中再插入其他一些零散的文章，等到其他几个备份中的专题大概完成了再增加推送的系列吧。
本篇跟前文的内容有一定的重合，在行文中很多地方已经体现过了。不过既然已经写到这里了就归纳一下吧。总的来说，异步逻辑处理中，注意事项大概有以下这些，总结并不全面欢迎大家补充。避免目的时钟域再收敛
即多比特信号进行同步时，如需要进行逻辑运算必须在源时钟域完成组合逻辑并寄存处理，不能分别同步到目的时钟域后再进行逻辑处理。
这个老生常谈了，每个比特在同步过程中收敛的时刻不同，有的在第2拍采到正确值，有的在3拍采样到正确值，在目的时钟域对多个同步信号进行组合逻辑的话，产生的结果可能与预期不一致导致整个逻辑的混乱与进一步传播。同步器之间不能有任何组合逻辑
同样是老生常谈的一个点，同步就干干净净的处理就对了，千万别有组合逻辑，一是触发器路径延迟不同，高低电平传播时间不一致，组合逻辑会有错误逻辑以及竞争冒险与毛刺，同时也增加了采样的不稳定区间。同源信号扇出多个触发器的情况，需要先同步再复制同步后的信号
典型的场景就是A -> B，A -> C，BC都在目的时钟域，此时不要讲同步器复制对A分别跨异步，而是要先将A同步到目的时钟域后再驱动多个逻辑路径。使用格雷码跨异步，格雷码必须是依次变化的
比较典型的场景是计数器非整2的幂次计数翻转，这过程中会有格雷码多比特跳变的场景，不能使用格雷码同步器。此外使用格雷码同步器时，格雷码必须打拍输出，格雷码多比特的走线延迟建议不要大于Tmin_cyc（min 源、目的时钟周期），多比特之间的走线延迟差值尽可能的小。当异步电路存在反馈机制时，应当通过握手机制进行同步
尤其是反馈时间不定，异步握手同步器是合理的处理方式。对连续数据的传输速度有要求，或者实在不知道怎么同步了，就用异步FIFO
emmm上学时老师跟我们说的，如果实在不会了就用异步fifo进行同步吧，然后转头就花了一周来讲异步fifo怎么设计。单比特信号跨异步时的维持时间要求
Tcapture + Tjitter + Tsetup + Thold + T损失含义分别是目的使用周期，目的时钟最大抖动，目的时钟建立时间，目的时钟保持时间，传输损失。但是我一直有点不太理解，对于Tcapture + Tjitter + TThold这三个时间我觉得很清晰，要保证目的始终不漏采确实需要满足，但是Tsetup为什么需要包含在其中呢，我自己感觉不加这个时间也不会导致漏采的吧，没太想清楚。还有就是损失的这个时间应该如何计算，我也不太明白。因此，通常的做法是源脉冲信号大于Tcapture + 2ns（目的时钟为高频时钟）或大于2Tcapture(目的时钟为低频）。同步器采样点禁止动态门控
异步传输中存在时序不确定性，因为不同信号的到达时间可能不同，或者在传输过程中可能发生抖动。因此，在异步传输的场景下，动态门控可能导致采样点的不确定性，使得同步器采样到的信号不准确，从而可能导致错误的数据处理。在芯片设计中，通常需要满足一系列的时序约束，以确保数据在特定的时间窗口内到达目的地。动态门控可能导致时序约束无法满足，因为它会引入不确定的延迟，从而影响同步器的采样时刻。为了保证时序约束的满足，同步器的采样点通常会禁止动态门控，以确保在固定的时刻进行采样。![]()
系列文章入口——
