今天为什么仍必须进行门级仿真（GLS）

今天为什么仍必须进行门级仿真（GLS）

使用门级仿真（GLS），在最终流片前2天，我发现了芯片中的功能和时序错误，包括细微但致命的时序错误。
继续阅读前，我必须发出“注意”警告：GLS可能是一项极其昂贵的任务，如果做错了，在芯片投入生产之前就无法发现关键的设计缺陷。但是，如果做对了，我今天发现Gatesims的成本/收益会越来越好。无论如何，GLS都发现了formal，STA，ABV，lint和仿真都不会发现到的芯片bug。如果您不进行GLS，则可能会冒很大的风险。

零延迟问题…

任何芯片开发团队的目标都是拥有坚实的流程（lint，LEC，STA，验证），以使GLS永远不会发现任何bug，从而不需要GLS。但是，GLS确实发现了错误。在设计过程的最后期，几乎快流片了，GLS错误通常非常严重，并且会导致无法解决的问题。即使有可能解决方法，查找和调试GLS故障也比在实验室中调试芯片要容易得多。

在实验室中调试可能在GLS中几个小时内就能找到并调试的错误的情况并不罕见。尽管GLS比RTL更难调试，但它比硅上调试更容易调试。

之所以存在GLS错误，是因为几乎所有的芯片Verilog / SystemVerilog / VHDL仿真都是通过“理想世界”零延迟测试完成的，这些测试在预先综合的Veilog / VHDL / SystemVerilog RTL代码上运行。这些仿真量身定制以提高仿真运行时的性能-但牺牲了它们捕获某些类型的bug的能力。

此外，在RTL被验证后，产生用于制造硅的门级网表时，会对设计执行许多步骤。这些RTL后步骤中的一些步骤包括对门的综合；以及布局和布线；电源插入；为内置自检（BIST）和内置自修（BISR）添加逻辑；并插入可测试性（DFT）逻辑。 RTL测试不会从任何这些步骤中发现bug，因为在这些步骤中添加的逻辑并不是最初的RTL所具备的！

此外，GLS还发现由于不良的时序约束，Primetime / Tempus STA错过了芯片时序问题。门级模型更接近于实际的硅设计-在门进行测试经常会发现RTL中找不到的异步逻辑中的时序错误。

特别警告：随着当今的芯片设计越来越大，GLS变得越来越难。但与此同时，对GLS的需求比以往任何时候都大。 芯片中RTL设计中不存在的逻辑量增加了。再加上100个无关时钟的复杂性，增加了最终芯片无法时序收敛的风险。最终，随着从流片到硅所需的工时和日历时间的增加-使门级错误的成本大大提高-并使其比以往任何时候都更加重要，这使得一次流片就能工作变得更加重要。

DAN JOYCE的仅通过门级仿真发现的16个错误类型

以下是只能使用GLS找到的芯片设计bug的列表。请记住，以我的的GLS经验来看，在项目的最后阶段，设计团队告诉我“该芯片已经准备好了！我们准备好了！”；在那之后，我至少捕获了这些芯片致命bug中的1个。

1. 时序错误。使用不正确的时序约束实际上会导致您的DC或Genus综合工具创建时序错误-然后使用那些相同的错误约束来运行Primetime或Tempus STA。因此，相同的约束错误将同时导致错误和错误检查，从而错过检测该错误的机会。

2. Linting错误。诸如Real Intent或Spyglass之类的Lint工具会查看Verilog / SystemVerilog / VHDL RTL源代码产生错误的门。坏消息是，某些linting工具（我不会说哪个）会产生过多的警告，需要手工检查和放弃。放弃错误的linting警告的人为错误会在RTL和门级功能之间造成差异。更糟糕的是，LEC不会发现这些被放弃的错误。

3. BFM掩盖的错误。 RTL验证通常使用BFM（总线功能模型）来简化测试生成和结果检查。错误地对DUT的一部分建模的BFM可能会导致bugs被遗漏。您的GLS必须执行一些由门级内核驱动的测试，而不仅仅是内部BFM。

4. IP错误。您可以拥有能够在RTL中完美运行的第三方IP，但是已经悄无声息的包含只能在GLS中捕获的时序/功能/ ifdef /编译指示bug。这些隐藏的IP错误可以杀死芯片。

5. 时钟错误。您的RTL具有实际毛刺，超过最大频率的频率或占空比bug，通常仅在具有完整SDF时序的GLS测试中才能看到。

6. 复位时序错误。这些通常是时钟区域，其中复位在其D-FF的不同时钟沿释放。这些也称为初始化bug。它们只能在门控仿真中被延迟检测到。

7. `ifdef错误。在代码的`ifdefs中，RTL仿真使用的一组`ifdefs与综合所使用的`ifdefs不同。 LEC不会发现这一点，除非您运行GLS，否则您不会怀疑任何东西。

8. 动态频率变化时钟错误。通常，高性能低功耗的芯片必须能够在不使逻辑停顿的情况下切换频率。该逻辑只能在具有完整时序的GLS上进行验证，以检测这些时钟问题。

9. 多时钟路径（MCP）错误。例如，您有一个带有12周期MCP的芯片。

   a）您的源信号必须在整个12个周期内保持稳定，

   和

   b）您的目标触发器只能在第12个周期捕获结果-不能更早或更晚。

   如果您没有执行上面的“ a”或“ b”操作，它将创建一个MCP 建立/保持时间问题，导致最终输出触发器出现亚稳态（“ X”）。

10. force/release错误。通常在测试平台中克服一些瓶颈，将使用如下代码：

                   force load_fifo_name_here = 1'b1;
                   force ecc_error = 1'b0;
                   force aix_bus = 32'bFFFFFFFF;

发生的情况是，验证人员忘记删除或“release”了全部或部分“force”命令-导致测试通过且错误未被发现。当通过综合，重命名信号时，GLS会为大多数内部“force”抛出编译错误。剩下的一些“force”有待检查和消除（如果可能）。

11. BIST / BISR错误。如果您设计的原始Veilog / VHDL源RTL不包含BISR或BIST逻辑，则涉及BIST / BISR逻辑的错误只能在GLS中找到。

12. DFT错误。通常，RTL不包含DFT逻辑，因此DFT逻辑中的那些错误只能在GLS中找到。

13. 电源插入错误。通常，您的RTL没有插入电源。 UPF测试是为了在RTL中找到它们而进行的尝试，但是由于RTL中不包含大多数电源逻辑，因此只有通过“power aware”门级仿真才能完成电源逻辑的唯一真实测试。这是仅当您的钳位单元，电压转换器和电源岛正确连接并驱动了启用电源的网表时，门级库单元的仿真模型才起作用的地方。

14. Delta延迟竞争冒险条件。有时，RTL使用＃0或＃1或阻塞和非阻塞赋值导致RTL delta延迟竞争冒险。这些是仿真工件。如果您的源RTL仿真错误，人们将修改RTL使其错误pass。他们假设一切正常。但是它们的最终Gates的工作方式与RTL不同-这是一种罕见的情况，只有GLS才能检测到真正的硅行为异常。

15. LEC漏洞。所有LEC工具都通过在两个门级模型之间进行逻辑等效来工作。如果要在具有相同设计的RTL和Gates之间进行LEC，则LEC工具首先将RTL综合为简单的Gate实现。如果您的“ RTL”不能100％地综合与RTL功能100％匹配的门，则您的LEC运行将比较您的门级网表和已损坏的“ RTL”门模型。您可能会因此获得不正确的LEC结果。

16. LEC Waivers。大型设计被分成几部分，以使LEC在合理的时间内处理它。在此切割过程中任何工具错误或任何不正确的waivers都会导致RTL和Gates之间的功能差异。只有GLS可以检测到这一点。

带着所有这些警告，我一直期望我的下一个芯片是GLS找不到formal，STA，ABV，lint和仿真都没有捕获的致命bug。但是不幸的是，在我以往流片的22个芯片中，这还没有实现。