SoC的CDC验证技术

1.简介

随着SoC复杂性的增加，设计中必须使用多个独立时钟。因此，CDC验证成为任何SoC设计周期不可或缺的一部分。一个典型的SoC由几个IP（每个IP具有自己的时钟集）组成。这会导致SoC出现一些新的路径，而这些路径在IP级别是无法预料的。由于庞大的设计规模，多个异步域，第三方和旧式IP重用等，因此，为SoC设计一种在违规次数和运行时间方面最优化的方法至关重要。本文讨论了几种用于SoC的CDC验证的方法。

2. CDC验证的不同方法

2.1平面SoC验证

这是在任何设计上运行CDC的常规方法。在此方案中，我们给出约束并作为一个实体在整个设计上运行。它与在任何小型设计或IP上运行CDC相同。我们在中央时钟和复位发生器模块的输出端定义时钟和复位。该工具能够跨IP传播它们。我们只需要检查任何不受限制的时钟或在之后重置即可。因此，这种情况下的设置非常容易，因为可以轻松获得约束。在这种情况下，我们可以节省设置时间。

但是，只有在整个设计可用且集成良好时，才能执行此类CDC验证。在这种情况下，由于我们在等待集成良好的SoC开始设置和分析，因此我们可能会在设计周期的后期发现任何严重的错误。在这里，我们同时收到内部和内部IP违规情况。我们需要分析这两种违规行为。由于存在大量违规和大量运行时间，因此很难针对大型SoC使用此类方案。

2.2 IP黑盒流程

在此流程中，某些IP可能用黑框表示，以便在SoC上进行CDC分析。通过黑匣子，我们可以节省大量的运行时间，因为整个IP不需要进行CDC合成和分析。对于庞大的IP，可以有选择地完成此操作。在此，对于黑框所示的IP，我们不会收到任何内部IP违规的情况。但是，必须确保在所有此类IP上运行模块级CDC。此外，SoC集成商有责任在与SoC集成此类IP的同时查看与每个端口相关的时钟域。

2.3 IP灰盒流程

对于大型SoC，假设交付给SoC的IP是纯净的，便会开发这种流程。就CDC而言，这里我们实现了IP的灰盒。我们仅检查内部IP冲突，而不检查完全属于IP的冲突。考虑下面所示的情况（图1），其中两个IP之间存在交互。我们有两个CDC路径，路径1（内部IP1）和路径2（在IP1和IP2之间）。在SoC进行分析时，我们指示该工具不要对内部IP路径执行任何CDC分析，而仅报告内部IP路径。因此，在以下情况下，仅报告路径2，而未报告路径1。这种情况下的设置与平面SoC验证的设置相同。在这里，时钟和复位也定义在顶层。因此，我们获得了减少设置时间的内在优势。由于没有在IP内部执行任何分析，因此在运行时间方面，我们也从中受益匪浅。

此处存在一个限制，即如果一个IP生成了任何限定符（在下面说明），并且在该IP之外使用，则该工具可能无法将该特定限定符识别为有效的限定符。因此，使用该限定符的任何有效CDC交叉都不会被该工具视为CDC通过。限定词是控制/限定交叉的信号,例如，在基于多路复用器的同步器中，通过选择多路复用器来控制交叉。我们可以通过两种方式克服这一缺点：

通过在平面设计上进行初始运行（不使用IP灰箱）来生成此类限定符列表（从工具），并使用IP灰箱方案将所有后续运行的信息提供给工具。

使用平面SoC验证进行两次并行运行，另一次使用IP灰盒流程方法进行并行运行。然后应用豁免以删除所有内部IP违规，作为平面验证运行的后处理。现在，这两个运行变得可比较，因为它们都只包含违反IP的行为。他们现在唯一的区别是由于某些未识别的限定符而在IP灰盒流程中额外违反了规定。我们应该过滤掉这些额外的违规行为，并将其添加为所有后续IP灰色装箱方法运行的豁免（后处理）。

图1 IP灰盒流程示意图

该方案存在一个固有的缺点。假设我们获得了一个CDC干净的IP，并且期望在其输入端有两个同步时钟。现在考虑一种情况，我们错误地在SoC级别的IP上连接了异步时钟。由于期望同步时钟，因此IP中将不存在同步器。如果我们在平面设计下运行（没有IP灰色框），则该工具将标记IP中的违规行为，因为我们已经连接了异步时钟，并且没有同步器。这些违规行为将向我们表明IP或SoC中存在问题。但是，如果我们使用IP 灰盒流程，则不会收到这些违规（因为它们是Intra IP），因此会错过与SoC连接相关的问题。

为了解决上述问题，可以使用IP灰盒流程的一种变体，在这种情况下，我们要求工具对内部和内部IP路径进行分析。由于用于CDC的IP是纯净的，因此我们要求各IP所有者放弃IP CDC。我们将这些IP豁免应用于后处理运行的SoC CDC。对内部IP路径的豁免申请确保了我们仅拥有内部IP路径。在这里，由于SoC连接错误而导致的任何意外IP违规都将被标记，因为它们不会被放弃IP。与进行IP内部分析相比，与IP灰盒流程相比，运行时间将增加。但是在正常情况下，我们将仅分析内部 IP违规情况。

2.4分层的自下而上的流程

在这种方法中，首先分别对每个块/ IP进行验证，然后将验证扩展到整个系统。在为SoC设计几个新IP的情况下，这种方案很有用。综合，静态时序分析等许多其他功能都使用分层方法进行签名。在此流程中，我们针对每个IP分别在块级别开发时钟和重置约束，并在独立环境中进行验证。这确保了我们不会像平板SoC验证方案那样等待良好的集成设计。因此，我们可以降低在设计周期后期发现任何严重错误的风险。

此方法的重要步骤之一是验证IP级别和SoC级别约束的兼容性。这样可以确保我们能够捕捉到任何SoC连接性问题，例如前面所述的IP 灰盒流程固有的缺点。在此流程中，我们对IP执行CDC分析，并生成其抽象模型。这些抽象模型包含IP端口的时钟域信息。然后，我们将所有这些抽象模型与任何SoC粘合逻辑集成在一起，并检查是否存在违反内部 IP的情况。在这里，由于我们不是在阅读和综合模块/ IP，而是仅使用它们的抽象模型，因此可以节省大量的运行时间。这种方法对于门数众多的设计很有用。该方案还有助于将IP抽象模型重用于多个SoC。

2.5分层自上而下的流程

在此自上而下的流程中，SoC所有者推动CDC验证。我们在顶层开发约束并将其传播到块/ IP。这样可以确保在模块级满足从顶部给出的所有要求。该方案省去了验证IP级和SoC级约束条件兼容性的额外步骤，因为前者仅由后者生成。在可以利用SoC约束的早期可用性进行有效的自上而下CDC验证的情况下，可以使用它。

首先，我们从顶层环境转移的约束中清除IP。在此方案中，在独立环境中处理IP时，我们可以捕获内部 IP CDC问题，如所述。考虑下面所示的情况（图2），如果给定域（此处为clk1）中的顶部信号（此处为“ out”）将馈入IP，则确保它被用于目标IP，否则他们必须将其同步到将使用该域的域（此处为clk2）。

清除IP后，我们便将所有这些抽象模型与任何SoC胶合逻辑集成在一起，并检查是否存在违规情况。

图2分层自上而下的流程

3结论

随着设计规模和复杂性的增加，由于运行时间长且需要良好集成的设计，常规的CDC流程（即Flat SoC验证）可能不是最佳选择。本文讨论了可用于执行SoC的CDC分析的各种技术/流程，还讨论了每种方案的优缺点。