论LEC在IC设计周期中的重要性

VLSI的设计周期分为两个阶段：前端和后端。前端涵盖架构规范、编码和验证，而后端涉及目标制程技术节点上设计的物理实现。

本文主要介绍LEC（逻辑等效检查）在ASIC设计周期中的重要性，如何检查它以及当LEC失败时该怎么做。我们将探索一个测试用例，看看如果LEC失败会发生什么，如何查明问题以及采取哪些措施来解决问题。

LEC的重要性

• ASIC在流片之前，要经历一系列设计步骤，如综合、布局布线、签核（sign-offs）、ECO（工程变更单）以及众多优化过程。在每个阶段，我们都需要确保逻辑功能完好无损，并且不会因为任何自动或手动更改而中断。如果功能在整个过程中的任何时刻发生变化，整个芯片就变得毫无用处。这就是为什么LEC是整个芯片设计过程中最重要的原因之一。

• 随着制程技术节点的缩小和复杂性的增加，逻辑等效检查在确保功能的正确性方面起着重要作用。

  
  

LEC包括三个步骤，如下图所示：设置模式，映射模式和比较模式。

图1：逻辑等效检查流程图

有各种用于执行LEC的EDA工具，例如Synopsys Formality和Cadence Conformal。这里，我们将Conformal工具作为参考，以解释LEC的重要性。

逻辑等效检查的步骤

让我们仔细看看逻辑等价检查的各个步骤：

1.

2.

3.

在从设置模式到LEC模式的过渡中，Conformal工具展平并模拟Golden和修改后的设计并自动映射关键点。关键点定义为：

• 主要输入

• 主要产出

• D Flip-Flops

• D锁存

• TIE-E门（错误门，在修订设计中存在x赋值时创建）

• TIE-Z门（高阻抗或浮动信号）

• 黑匣子

  
  

相反，当Conformal工具必须使用完全不同的名称映射设计时，无名映射方法很有用。默认情况下，它会在退出设置模式时使用名称优先映射方法自动映射关键点。Conformal工具未映射的关键点被归类为未映射的点。

未映射的点分为三类：

• 额外未映射的点是仅在其中一个设计（Golden或Revised）中出现的关键点。

• 无法到达的未映射点是没有可观察点的关键点，例如主输出。

• 未映射的未映射点是可到达的关键点，但在相应设计的逻辑扇入锥中没有对应点。

  
  

• 等效

• 非等效

• 逆等效（Inverted-equivalent）

• 中止

在中止比较点的情况下，我们可以将比较工作更改为更高的设置。因此，Conformal工具可以仅在中止的比较点上继续比较。Conformal工具显示用于比较的完整运行时间和总内存。

LEC完成后会生成多个报告：

• 非等效报告

• 未映射的报告

• Blockbox报告

• Abort.rpt

• Unreachable.rpt

• Floating.rpt

• Mapped.rpt

在签核或流片处理阶段，时间表太紧，无法处理具有一些严重逻辑故障的块。有时，在进行手动修复或定时ECO时会破坏逻辑连接。在流片阶段，逻辑故障的可能性很高，物理设计工程师没有太多时间来关闭块。此外，当您获得功能ECO并进行手动连接时，破坏逻辑连接的可能性很高。让我们看一个块中LEC失败的实际例子，看看它是如何被解决的。

首先，如果LEC在所有级别失败，请不要惊慌，如前所述。当LEC失败时，第一步是检查“non-equivalent.rpt”文件。由于连接断开，可能会在“non-equivalent.rpt”文件中报告更多的单元名称。

这背后的原因是许多路径会经历一个失败/断开的连接 - 因此它的所有端点（比较点） - 被报告为“非等效”。

第1步：非等效报告

第一步是检查非等效文件。下面的示例非等效文件显示了LEC中失败的152个比较点。

这152个非等效触发器是多位触发器。在多位触发器中，我们合并两个触发器以形成具有多个输入和输出引脚的单个触发器。例如，如果我们将两个单比特触发器合并为一个多比特触发器，它将以D0，D1作为输入引脚，Q0，Q1作为输出引脚。

由于是多位触发器，报告显示152个触发器计数为非等效，但实际上只有72个是非等效的。由于这些是两位触发器，因此总计数为72x2 = 144个触发器。剩下的是单比特触发器。

第2步：未映射的报告

下一步是检查未映射的文件。此文件显示逻辑连接断开的未映射网络。我们需要跟踪网络并找出这些网络缺失的连接。

在上图中，我们可以看到在设计中没有映射一个网络（BUFT_net_362908）。从图2中可以看出，一旦我们检查LEC故障数据库中的这个网络（BUFT_net_362908）连接，我们看到它只连接到其他单元的输入引脚（* _364714 / A），但是另一个连接（由于无意的单元缺失，使得该网络缺失了。

下图中突出显示的网络为unmapped.rpt文件中报告的网络。

图2：未映射报告中的网络

这里，我们可以看到LEC失败设计中报告网络的连接。

当我们在未映射的文件中报告网络扇出（BUFT_net_362908）时，它在LEC传递数据库中连接到152个触发器。

而LEC失败数据库中非等效文件中报告的152个触发器与LEC通过数据库中报告的网络扇出（BUFT_net_362908）相同。

现在，我们需要在之前的LEC传递数据库中找到该网络的实际网络连接。在检查时，我们可以很容易地注意到报告的网络连接到LEC故障数据库中缺少的一个逆变器。

为了找到丢失的单元格，我们必须在之前的LEC传递数据库中回溯跟踪此网络并检查实际连接。

不要在未映射和非等效报告之间混淆。在未映射的报告中，我们只看到未驱动输入引脚的浮动网络，而在非等效报告中，我们看到所有单元格都是这个丢失单元格的扇出。

第3步：修复LEC问题

在找到LEC故障的原因后，我们必须插入一个丢失了的逆变器，并在LEC故障数据库中重做该逆变器的输入/输出逻辑连接。图3显示了新增的逆变器及其输入输出连接。现在，如果我们重新运行LEC，它将通过，非等效报告将显示零非等效点。

图3：修复丢失的连接

LEC失败的常见区域

• 如果在设计中使用多位触发器，则将出现映射golden网表与修订网表的问题，因为触发器名称将在修订后的网表中更改。

• 在修订的网表中克隆后，时钟门控单元未被映射。

• 在定时修复期间或在执行手动ECO时，逻辑连接会中断。

• 功能ECO实施。

• 缺少DFT约束。

LEC的益处

• 减少对门级仿真的依赖。

• 提高了对合成和布局布线的新工具修订的信心。

• 在不编写测试模式的情况下等效性几近完美。

• 降低后端进程丢失的漏洞风险。

结论

本文介绍了逻辑等效检查，及其流程设置、调试步骤和修复LEC的解决方案。使用真实场景，还展示了LEC完成后生成的报告，并提出了一种简单的方法来找出LEC失败的根本原因。

IC设计团队遇到LEC失败问题并不罕见，采取本文所述的步骤将帮助您解决与LEC相关的问题。