SOC验证之CDC验证

newyork major

于 2025-07-14 16:37:21 发布

阅读量737

点赞数 21

CC 4.0 BY-SA版权

分类专栏： soc基础文章标签： SOC CDC 跨异步

本文链接：https://blog.csdn.net/zhangshangjie1/article/details/149326999

soc基础专栏收录该内容

4 篇文章

订阅专栏

Design Complexity and CDC

现今的soc, 几乎没有任何设计是在单个时钟上运行的。一个典型的SoC将有三个或更多的时钟，并且这些时钟是异步的。我们用lint工具和其他的一些手段，进行CDC check，但是问题在于，在RTL静态或者基于仿真的分析，与真正的物理芯片中的行为，这两者之间，并不是完全等价的。在RTL级或门级上，由于跨时钟域导致的亚稳态问题不是很容易预测。因此，模拟无法准确预测真实芯片的行为，有一些critical的bug, 可能会从验证流程中遗漏到后续环节；这导致近25%的问题是由时钟问题引起的，CDC是其中的主要原因。

如下是一些典型的SOC系统中，clock domain的个数，以及与之相对应的signal的数量；

下面这张图，显示了在一个系统中的，典型的跨异步的场景，图中，不管是单比特，还是多比特，都需要进行同步；

如下图所示，在rx接收端，会产生亚稳态问题；

Metastability(亚稳态)

CDC中，最主要的问题是，当data从一个时钟域，传输到另外一个时钟域时，会出现亚稳态；可能存在的原因有多种：

从慢时钟域传递到快时钟域；
从快时钟域传递到慢时钟域；
或者即使是同频，但是存在相位差；

这些原因，会导致信号传递到另外一个时钟域时，产生setup/hold violation;

以上图为例，当TxData同步到RxClk时，存在setup violation, 这会导致RxData存在亚稳态，这意味着我们不知道它将稳定到什么状态，或者在一个时钟内完全稳定下来。如果这个TxData是一个将会保持多拍的信号，那么RxData经过多拍采样，最终会稳定在一个正确的状态；图中只是为了简单说明这个问题，让Rxdata的亚稳态，在一个cycle内稳定下来，但是有很多真实的场景并不是这样的；

如果这个亚稳态信号Rxdata, forward到了前面的逻辑中，我们就不知道到底是一个什么状态/数据，传递到了前面的逻辑中；由于跨时钟域的信号会在一段时间内都是波动的，接收时钟域的输入逻辑可能识别出波动信号的逻辑电平是不同的，从而将错误信号传播到接收时钟域。在RTL仿真中，这种亚稳态会被认为是“X”（未知）状态（正确），超出RxDFF的逻辑可能会变得无用（即“X”传播会导致逻辑中的各种问题）。

简而言之，同步失败是由于输出趋于亚稳态，并且在必须再次对输出进行采样时没有收敛到legal的稳定状态。

Synchronizer

Two-Flop Synchronizer

所谓的同步器，是一种可以将异步信号，转换成与目的域同步信号的device；

打两拍，是一种最简单的同步器：

TxDFF这个flop, 称之为发送端触发器，将对应的数据送出来；
接收端，第一个flop, 可能会非常接近发送端触发器，其接收的数据可能会有setup/hold violation, 此时如果直接用这个寄存器的输出，是0，是1，难以预料；
此时，我们再插入第二个flop, 此时第一个flop的输出，就有足够的时间来稳定，也就是亚稳态在一个cycle内，能够稳定下来，此时第二个flop采到的数据，就是一个稳定信号；
此时第二个寄存器的输出，也就是个稳定信号，可以传递到其他地方，不会产生不可预期错误；

这个同步器，需要注意如下几点：

发送端的寄存器，和接收端的第一个寄存器之间，不能有任何的glue logic, 这样能够保证更大的亚稳态恢复时间；
在后端布局布线时，RxDFF1/RxDFF2之间，应该尽可能的放的近一点；

Three-Flop Synchronizer(High-Speed Designs)

对于某些高速的design, 平均故障间隔时间（MTBF）太短了，数据可能在第二个flop完成之间，就已经发生了变化，从而导致TxData未完成同步；这种情况下，我们就需要第三个flop来保证高速情况下的同步完成；

Synchronizing Fast-Clock (Transmit) into Slow-Clock (Receive) Domains

在接下来的讨论中，我们将需要同步的信号称为CDC信号。这将使描述概念更容易。

上面的两个例子中，当：

发送端的频率和接收端的一致；
或者发送端的频率比接收端的频率慢时；

        打两拍，或者三拍同步器，都能很好的工作；考虑到将较慢的信号采样到较慢的时钟域比将较快的信号采样到较慢的时钟域会导致更少的潜在问题，设计人员可能希望利用这一事实，使用简单的两个触发器同步器在时钟域之间传递单个CDC信号。

但是当发送端的频率比接收端的频率更高时，可能会存在如下问题：

一个信号在同步的过程中，可能在还没有同步完成时，该信号又发生了变化；
或者是过于接近采样时钟边缘；

        如上图所示，如果发送端的信号，只维持一个cycle, 那么CDC信号的上升/下降沿，可能会在两个接收端时钟的中间，此时较慢的时钟，是不能采到该信号的；这样会导致整个电路功能错误；

因此，在慢采快的电路中，打两拍的同步器，是不能正常work的；

一种可能的解决方式是，发送端控制该同步信号维持多个cycle, 保证超过接收端一个cycle的时间；

一般的经验法则是发送信号的最小脉冲宽度是接收时钟频率周期的1.5倍。
这个解决方式的提出是假设CDC信号至少被接收时钟采样一次。如果工程师将此解决方案错误地视为通用解决方案并错过传输（CDC）信号周期要求，则会出现此解决方案的问题。
这就是SystemVerilog断言发挥作用的地方。在CDC信号从高频域穿越到低频域时，对其进行周期检查。

还有其他的方式可以解决这个问题，这里不做讲解；

Multi-bit Synchronization

        当在时钟域之间传递多个信号时，简单的同步器不能保证数据的安全传输。在进行多时钟设计时，工程师经常犯的一个错误是将同一个transaction中需要的多个CDC bits从一个时钟域传递到另一个时钟域，并忽略了CDC位同步采样的重要性。

所谓的同步采样，指的是当多比特信号进行同步后，不同的bit之间，可能会存在skew, 导致该信号采样错误；即使我们可以完美地控制和匹配多个信号的轨迹长度，上升和下降时间的差异以及die上的工艺变化可能会引入足够的skew，导致采样失败。

这里简单介绍几种方式;

The Gray Code Solution

        在多时钟设计中使用的最安全的计数器是格雷码计数器。Gray码只允许每个时钟转换更改一个比特，从而消除了试图同步跨时钟域的多个变化的CDC比特所带来的问题。标准格雷码具有非常好的转换特性，可以将格雷码转换为二进制码。使用这些转换，可以很容易地设计高效的格雷码计数器。

二进制和格雷码之间的转换关系如下：



Asynchronous FIFO

如果是同步多个bits，无论是数据位还是控制位，都可以通过异步FIFO完成。异步FIFO是一个shared memory或register buffer，数据从写时钟域插入，数据从读时钟域移除。由于发送端和接收端都在各自的时钟域内工作，使用双端口缓冲区，如FIFO，是在时钟域之间传递多比特值的安全方法。标准的异步FIFO设备允许在FIFO未满时插入多个数据字或控制字。如果FIFO不为空，接收器可以提取多个数据或控制字。

CDC Checks Using SystemVerilog Assertions

        SystemVerilog断言（SVA）是检查时钟（或采样边缘）边界上sequential domain conditions的好方法。从一个时钟域穿越到另一个时钟域的CDC信号是使用SVA进行检查的完美候选。

        SVA完全支持多时钟域断言以及多线程局部变量，以进行完整的证明检查，以确保您的CDC同步器（无论设计风格如何）按承诺工作。注意，这里给出的断言既可以用于simulation-based的检查，也可以用于formal-based的检查（静态函数式）。但我将专注于simulation-based的检查，因为formal/static functional仍然没有被许多工程小组完全采用，它本身需要一个完整的章节。

        让我们从最简单的设计开始。稍后我们将看到使用上述基于格雷码计数器的异步FIFO对CDC多位数据传输的全面断言。

对于任何同步器设计，都会有关于TxData稳定性的assumptions。它应该在两个时钟内保持稳定吗？三个时钟?这是为了确保CDC信号Rx1Data有足够的时间过滤亚稳态区域并将正确的值传递给RxData（输出）。

        让我们假设TxData在每次假定一个新值（即它改变了）时，应该在两个时钟内保持稳定。这个假设是必需的，因为我们假设TxClk比RxClk快。这种设计的时序图参见图8.7。

首先，断言检查TxClk的posedge的TxData是否发生了变化。
如果有，我们首先将TxData存储到multi-threaded local variable Data中，之所以需要添加1‘b1，because local data store must be attached to an expression。
因为我们没有任何条件，我们简单地说“always true”是表达式。“Always true”意味着无论何时TxData发生变化，总是将TxData存储到数据中。
然后，我们在CDC边界时钟RxClk上检查，通过比较Rx1Data与存储的TxData（在数据中），数据是否确实已传输到Rx1Data。一个时钟之后，RxData必须与TxClk上传输的TxData匹配。这保证了CDC 1位双触发器同步按预期工作。再次注意，必须坚持TxClk比RxClk快的假设。

现在，让我们针对多比特的格雷码同步器，设计一个全面的断言；

在这个断言中，data_check property检查FIFO是否未满。如果是这样，则将wr_ptr保存到局部变量“ptr”中，将FIFO中的数据保存到局部变量“data”中并显示，以便我们可以轻松地看到模拟过程中断言的进展情况。

如果条件为真，则结果表明：

rd_ptr的第一个匹配项与wr_ptr相同（注意wr_ptr存储在局部变量ptr中）；
读数据与写数据相同（注意写数据存储在前件的局部变量data中）。

sequence rd_detect（ptr）用作表达式，用于first_match。它说从现在开始直到永远，直到你检测到一个读取，它的rd_ptr等于wr_ptr（存储在前件中的局部变量“ptr”中）。

可以编写许多这样的断言，以查看同步器设计是否正常工作。作为练习，尝试为您的同步器设计编写简单的断言。

CDC Verification Methodology

        由多个时钟信号混频引起的亚稳态并不能通过仿真得到准确的模型。除非你利用彻底的、自动化的跨时钟域（CDC）分析来识别和纠正问题区域，否则当芯片样品从工厂返回时，你将不可避免地遭受不可预测的行为。底线：自动CDC验证解决方案对于多时钟设计是强制性的。

        传统的CDC验证方法包括

人工检查RTL代码中是否存在同步器
running full timing simulations
sweeping clocks against each other
using special simulation models to randomly vary the delays through synchronizers

        这些方法只能找到给定设计中的一小部分错误。一个有效的CDC验证方法应该包括structural, protocol, and re-convergence fanout verification.

Structural Verification

        每个同步器都必须具有正确的结构，以适应跨时钟域发送的信号类型。例如，

2-DFF同步器通常是单比特信号的最佳解决方案，但不应该用于多比特信号，除非对它们进行gray编码以确保一次只有一个比特变化。
多比特信号可以使用单独的控制信号、异步FIFO或其他方法跨域同步。
此外，在同步器内部或之前不应该有组合逻辑。

Protocol Verification

每个同步器必须遵循a set of rules, called a transfer protocol，以确保CDC信号正确地跨时钟域传输。例如，

即使是最简单的2-DFF同步器也需要发射信号保持足够长的稳定时间，以保证它在接收域被捕获。如果发送时钟比接收时钟快，这种情况可能不会发生。
多比特信号的同步结构需要更复杂的协议检查。当违反CDC传输协议时，错误可能不会在模拟中发生，但最终会在实际硬件中发生。
协议分析应该使用静态的形式化方法。应该部署SVA来检查协议是否正确遵循;

Re-convergence Fanout Verification

        当多个信号从一个时钟域同步到另一个时钟域，然后在接收域被相同的逻辑使用时，就会发生重新收敛。如果这种逻辑假设信号之间存在时序关系，那么这种设计就不能容忍亚稳态，最终会失败。这是因为同步器的目的是“过滤”亚稳态，以确保接收逻辑不会看到不可预测的值。



        Multi-bit signals 分别经过2-dff同步，然后通过组合逻辑成为一个有效信号，驱动后级组合逻辑。经过逻辑组合后的信号可能会出现一个cycle的非预期值被误采样，影响功能逻辑。原因可总结为两点:

F1到F2的path delay和F6到F7的path delay不同, skew的存在导致clk_B采样存在先后顺序。
就算布线保证skew几乎不存在， Multi-bit signals 在同一时刻发生变化。但是因为2-dff同步存在cycle uncertainty的问题,也会出现一个cycle的不确定值。

  Automated CDC Verification

      让我们看看如何将结构分析和协议分析结合起来，以提出一种自动化的综合方法。下面是一个通用的图表，代表了许多EDA供应商现在提供的自动化过程。

Step 1: Structural Verification

        识别有CDC信号的RTL块（not the entire SoC RTL）。将这样的RTL块提供给static formal structural analysis tool。此工具将在您的逻辑中识别CDC同步“structures”，并分析它们是否满足要求。例如，单bit CDC同步将与双触发器同步器一起工作。但对于多比特同步器，双触发器解决方案将不起作用。你可能需要一个基于异步fifo的解决方案或一个格雷码计数器（每次只有1位变化）。

        该工具将分析这种情况，并提供结构性分析报告。结果还存储在一个UCDB风格的数据库中，以供进一步的调试分析。这一步应该找到丢失和错误实现同步器的问题，以及潜在的重新收敛问题。

        在这一步中更重要的是自动化系统Verilog断言的派生。例如，对于双触发器同步器，输入数据应保持稳定至少1.5倍的接收时钟。结构分析工具将（应该）自动为协议验证的下一阶段编写这样的断言。有很多这样的约束/检查需要提供给协议分析器。结构分析工具“知道”已经设计了什么类型的结构，因此应该能够为结构需要遵守的协议创建断言。

        您需要评估EDA供应商工具提供的结构分析结果，并接受建议或拒绝它们并实现您预想的最佳结构。别担心;如果你的结构不符合同步协议的要求，协议分析器会报告给你。

Step 2: Protocol Verification

        一旦结构分析完成，断言（自动创建或手动创建）将被输入到the protocol analyzer。the protocol analyzer采用的static formal method会对RTL块尝试所有可能的输入组合（both in temporal and combinational domain），看看是否有断言失败。这些断言确保CDC信号从TX到RX域是稳定的；对多比特CDC数据进行格雷编码或采样后保持稳定。分析结果将显示同步器需要分析的故障。此步骤的多次迭代将确保逻辑在所有输入条件下都能生存，并且亚稳态已得到解决。

        除了静态形式，您还可能希望使用创建的断言进行模拟。例如，你可以轻松地检查时钟是否有重新收敛的逻辑。或者您希望部署所谓的静态+模拟混合方法，以根据所需的协议规范检查结构完整性。

Step 3: Debug

        当然，debug是这个策略的重要组成部分。结构和协议分析的结果存储在一个UCDB风格的数据库中。调试工具会将结构与协议关联起来，并显示这种关系。它还将帮助您调试失败的断言。EDA工具确实支持这种调试功能。根据调试结果，您可以更改RTL或更改输入测试向量和亚稳态注入策略。这个循环会一直持续下去，直到没有任何断言可以触发，亚稳态问题也完全解决。这就是我所说的proposed methodology。您可以与EDA vendor讨论，看看他们提出的解决方案离目标有多近。

CDC Verification at Gate Level

The next problem is CDC at gate level.

当在多时钟设计上进行门级仿真时，用setup time和hold time表达式对触发器的ASIC库模型进行建模，以匹配实际触发器的时间规范。ASIC库通常对触发器进行建模，以在发生时序违规时在触发器输出上驱动X（未知数）。在模拟门级同步器时，设置时间和保持时间违反可能导致ASIC库发出设置时间和保持时间错误消息，并且违规信号经常被驱动到X值。当试图验证整个门级设计的功能时，这些X值会传播到设计的其他部分，从而导致问题（图8 - 10）。

当在门级进行CDC验证时，有许多技术可以关闭这种“X”传播。如果您熟悉SystemVerilog和EDA模拟器，那么您可能会熟悉这些技术。但是为了完整起见，这里列出了它们。

更改触发器设置并将保持时间设置为0。这显然不会造成任何时间违规，从而防止因为时间违规而生成“X”。但这基本上会使供应商提供的库中的“所有”flops的设置/保存无效。所以这可能不是一个好的策略。
关闭触发器单元格的“指定”块中的计时检查。许多供应商提供了一个命令行选项“+no_notifier”来自动关闭“X”代，因为时间违规。我相信这是一种首选的方法，因为您确实会得到一个时间违规，告诉您存在同步问题，但不会生成“x”。