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

下面我将详细描述捕获只有在GLS才能发现的16种类型芯片的致命bug的方式，这在我之前在文章中描述过。请确保阅读该文章以了解我在这里所说的内容。

GLS成本VS收益率：

工程永远是金钱。是的，从技术上讲，上一篇文章列出的16种错误类型中的某些可以被其他方法捕获，但是使用这些其他方法捕获它们将非常昂贵。为了使GLS具有成本效益，您的验证团队必须制定一个GLS计划，该计划应：

• 有效地在流片之前发现所有重要的错误，

但

• 就人力资源，工具和计算资源而言并不昂贵。

使用这29条提示，可以让您指派一名工程师在设计过程的后期进行GLS（当您的第一个门级网表来自RTL综合时），这样，他就可以在您的网表发布到流片之前，以经济高效的方式捕获芯片致命的设计错误。

这些步骤中有许多是常识，但其中一些是我多年来痛苦的经验教训。您会惊讶于有些验证团队会跳过某些步骤。

---

1.选择一些具有成本效益的GLS回归测试用例

选择正确的测试用例可能是最重要的提示。它们需要尽可能短，并覆盖所有高风险区域。这意味着针对GLS暴露的错误类型。这包括与复位，与子块的基本通信（活动）以及时钟问题有关的错误。这也意味着分析某些关键模块的成本与风险以及芯片的目标和时间限制。

• 在GLS中进行完全复位的初始化
  对于GLS而言，最重要的测试也许是芯片的复位初始化。 RTL测试通常与BFM一起对处理器进行测试，以简化测试。通常存在“force”来跳过每个测试不需要的耗时初始化序列。但是那些BFM和“force”可能掩盖了一个严重的错误，该错误使芯片无法通过boot启动。

  一旦启动，就可以使用软件解决方案，因此，能boot启动至关重要。大多数芯片实现了多个boot启动选项。

  每个都应在GLS中运行。这可能需要C代码或固件开发，很难创建和调试。但是芯片验证团队通常会在实验室中再次使用该代码。至少需要一个没有内部BFM或“force”的复位初始化测试。

• 您必须在GLS中测试所有模块的活动性
  确保您可以对整个芯片进行快速的系统检查。

  芯片的所有主要模块都应退出复位状态，然后进行初始化，然后再通过GLS中的基本功能测试。

  所有状态机都应通过基本操作遍历到，包括位于PHY和集成IP中的状态机。

  从芯片中的每个initiator 对DDR，SRAM和片上寄存器进行写/读访问也很重要。

  所有SRAM和FIFO应至少部分地使用。这里可能会有一些艰难的选择-尤其是对于IP。

  如果外部IP具有较高的工作可信度，则可以提出为这些模块跳过GLS的论点。但是，即使是高可信度的IP也被发现配置或综合错误，并导致了仅在GLS中发现的较晚的错误。

• 时钟，时钟模式，在GLS中以最大频率运行
  在所有关键时钟模式下，在芯片上运行基本的读写/数据移动测试。

• GLS中的低频测试模式
  创建一个测试模式，该测试模式将所有测试置于低速时钟模式下，以便在清除建立时间网表之前为Timing GLS创建SDF反向注释。

• 使用短而有效的GLS测试
  移植RTL的测试用例，但可以缩短测试时间-减少循环次数。覆盖范围应针对toggle-数据路径中的所有位都必须toggle-尤其是对于可能存在时序问题的组件（例如PHY和SRAM）。但是，GLS不适用于收敛的覆盖率。极端情况的错误不太可能仅在门级仿真中存在。不建议使用GLS查找它们。

---

2. 使用三种模型（RTL，Gate，SDF）进行仿真

具有成本效益的GLS需要一种调试方法，该方法可以快速，轻松地将故障快速隔离到实际的门或D-FF。

由于测试用例通常来自其他团队，因此GLS工程师通常会调试其他人编写的测试用例，这通常是GLS工程师不熟悉的逻辑。以这种方式调试RTL测试都很困难，那么在门上就是不可能的了。

您应该设置仿真环境，以允许每个测试用例在DUT（被测设备）的3种不同模型上运行。 您可以使用RTL模型开发验证基础结构，以创建和熟悉wave，监视器，检查器，断点和日志消息。

• RTL DUT：用于测试生成和初始通过波
  编译和运行速度最快-尤其是在存储波形时。

• 具有0延迟的GATE DUT：用于优化仿真器性能
  这个仿真模型。编译和运行速度较慢-尤其是在存储波形时。

• 带SDF反标的GATE DUT
  到目前为止，编译速度最慢。仿真速度比零延迟门差一些。许多团队正在跳过SDF GLS。很多团队在流片之前还是没有完成。遵循以下这4条技巧，以合理的精力并及时在流片前进行SDF GLS：

  A）在setup或hold清理干净之前，创建一个Hold-Fix脚本和低速时钟测试用例以进行初始SDF反标过程开发。这样可以更早地开始带SDF时序仿真。

  B）在启用时序检查的情况下运行SDF。如果Din的变化过于接近时钟边沿，则SDF中的时序检查会导致DFF的输出变为X。这个X通过芯片传播，并且X的波形追踪比尝试比较两个波形文件的差异更容易。时序违规信息被打印到日志文件中。

  C）使用有限的仿真环境。虽然内部BFM对GLS测试很有用，但内部BFM通常很难与SDF时序一起使用。使用带有时钟模块的SystemVerilog接口的BFM使SDF中的BFM更容易，但仍然很困难。

  D）编译SDF文件以加快编译时间。

总体而言：在通过更简单，更容易调试的模型之前，切勿在更复杂的DUT模型上运行测试用例。应在最简单的运行和调试环境（RTL DUT环境）上开发和调试测试用例，然后再将这些测试用例转移到较慢，更复杂的门级网表上进行仿真。在进行SDF时序仿真之前，请在最小的最简单的零延迟或单位延迟GLS网表上调试初始GLS问题（用于编译库，X，性能等的）。

---

3.仿真性能-GLS的编译时间

调试时间是重新编译模型并重新运行测试用例所需的时间。这将极大地影响解决GLS错误所需的时间。

Gate模型的编译要比RTL编译长得多。

在大型芯片中，如果测试平台和RTL DUT的编译时间在完整芯片级大约为15分钟，则对于0延迟的门网表，它可能会接近1小时；对于具有SDF时序的门网表，它通常会运行4-6小时。与之相比，使用Gate的速度要慢4倍，而使用SDF的速度要慢16倍24倍。您必须尽早进行工作，以减少0延迟和SDF门级模型的调试时间。在项目的最后阶段，在流片之前完成的可能性可能取决于您的工作时间。如果时间太长，则有必要创建其他更小的模块级GLS环境。

• 在需要的地方使用子单元GLS
  具有DDR的芯片始终是GLS面临的挑战，由于在Gates中仿真其PHY的复杂性以及DDR验证IP中通常具有的细粒度时序检查器。用于单个DDR控制器和PHY的子单元GLS环境允许更快的调试时间，并允许更快，更轻松地解决所有GLS问题。然后可以将子单元GLS env利用到芯片级GLS中。

• 您的SDF是否可以一次编译一次
  编译SDF反标文件会使使用SDF进行的DUT总体编译减少约25％。每个网表SDF发布，都编译一下，这会很快收回成本。

• 初始化时间长的GLS中的Stub Off块
  在任何仿真中，DDR初始化都可能非常长。将DDR单元用DDR BFM替换，可以进行除专门于DDR测试以外的所有测试，从而跳过此耗时的仿真步骤。

• 使用常识对您的编译进行分区
  由于大多数需要重新编译的更改都在测试平台中，并且大部分编译时间都耗在了DUT中，因此，假设将这个功能分为以下两个部分，则可以创建一个分为两个分区（测试平台和DUT）的环境，这将非常有帮助。您的Verilog / VHDL仿真器支持。 所有的仿真器供应商都会告诉您，他们可以像这样对编译进行分区，但事实是有些方法比其他方法要好，并且必须更稳定。

• 并非所有Verilog / VHDL供应商都具有内存容量
  运行Gate网表的仿真器在处理非常大的设计和以合理的性能进行编译方面进行了重大改进。但是他们需要大量的RAM来执行此操作-特别是对于GLS SDF编译。必须在给出门级网表的情况下自己测量仿真器的RAM需求，并确保能够将gatesim编译安排给没有其他工作竞争读取该RAM的服务器上。还要确保您的工作不会拖延其他工作。并非所有仿真器都具有其销售员声称的能力。

---

4.仿真性能-GLS的仿真时间

获得足够好的仿真速度可能是GLS如此挑战的最大原因。

长时间的GLS测试会导致进度极其缓慢。测试必须足够短，通常需要几个小时才能运行完，因此，在存储波形时，大多数测试可以在一夜之间完成。总会有一些真的很长的测试，对于不带快捷方式的全复位初始化，或者无法缩短的全芯片高活动性测试。

• GLS性能测试，DUT，测试平台和服务器
  GLS计划的第一步是为GLS中的门级模型确定仿真速度。 VCS / Questa / IES Verilog仿真器处理大型设计的能力差异很大。 GLS推动了仿真器的大小限制。

  从历史上看，仿真速度已经达到一定程度，但是最近EDA工具的发展使这些仿真器在具有大量RAM的服务器上具有更高的可扩展性。如果仿真器的RAM大小小于仿真器的限制，则切换活动似乎是GLS性能的关键。导致大量活动的GLS测试往往运行时间最长。

  验证团队要做的一个技巧是运行几台非常大型的服务器，这些服务器具有大量的CPU和内存，可以长时间运行GLS测试。

  另一个技巧是在本地磁盘上运行以加快GLS波形存储时的速度，因为它会占用服务器互连的高带宽。这有助于您的GLS测试，但也有助于防止GLS测试影响计算集群上运行的其他仿真。

• 回归测试调度器，确定性能瓶颈和“ RAM还是IO？”
  确保您的回归测试调度程序和运行脚本旨在处理GLS测试运行。必须确定这些大型仿真的内存需求，并且作业调度程序必须确保运行这些作业的计算机将为您的仿真提供所需的RAM和IO带宽-否则页面交换和IO瓶颈会破坏您GLS测试以及在这些计算机上运行的其他测试的性能。

  • 创建和标记一些非常短的GLS测试
    在芯片上运行第一个GLS是一个里程碑。其他测试应以该第一个测试确定的起点为基础。每个新网表都应首先在一些非常短的测试中运行，以使DUT退出复位状态并进行一些基本的活动性测试。

  • 删除大型和/或高活动性块
    使用内部BFM从您的编译中删除巨大和高活动性的块。最好的选择通常是DDR，PCIe等。

• 寻找适合GLS的仿真器选项
  每个仿真工具（Synopsys的VCS，Cadence的IES，Mentor的Questa）都有许多专有的仿真器选项。与SNPS / CDNS / MENT AE讨论的重点是，对于所使用的仿真器版本，零/单位延时GLS和SDF反标GLS的最佳性能的选项都有哪些。通常零延迟比单位延迟快，但是可能需要更多的工作来解决仅在零延迟或执行不佳的单位延迟中出现的任何delta延迟竞争冒险问题。

• 部分存储波形-时间/分层切片，无需重新编译
  许多失败的测试将需要波形文件进行调试。从0时刻开始存储整个层次结构会使门级仿真比RTL的仿真慢得多。仅存储调试所需的内容。

  同样，由于门编译时间比RTL长得多，因此您希望波形转储具有灵活性，以便可以更改波形存储而不必重新编译整个测试平台和DUT设计。

  而是创建一种可配置的方式来存储设计的各个阶层和区域而无需重新编译。创建无需重新编译即可在其他时间打开存储的功能。警告：请注意，波形存储会导致某些GLS仿真器优化被关闭。这有两个效果：

  1）性能-波形存储时运行较慢
  2）不同的功能-仿真器有时会出错，而这些错误往往来自性能优化。

  为了保持一致性，最好在转储或不转储时使用相同的仿真器优化选项来运行。如果发现仿真错误，请尝试更改优化。还请告知供应商，因为他们可能已对此进行了修复。

  重要信息：在关闭库单元的情况下运行波形存储。在GLS中存储库单元会使仿真速度降低多达2倍。结构转储是可以的，但一定要确保多维数组转储已关闭（这是您的大量RAM）。

---

5.与子模块Gatesim的权衡

许多团队在DUT的“所有”模块中执行模块级别GLS。这是一个成本效益的决定。虽然迫使每个子模块所有者在时间和工程上花费大量的GLS成本，但好处是它使人们更熟悉逻辑及其测试用例，从而可以在更小，更快的环境中调试难以发现的GLS错误。缺点是，由于仍然需要芯片级GLS测试，因此会导致需要更多的GLS测试平台-至少对于复位初始化而言。

• 适用于您的少量高风险模块的子模块GLS
  为了节省工程成本，一些团队只对他们认为有风险或可能存在性能问题的几个关键模块进行子模块GLS测试。这些模块对于大型SoC中的dut是非常有风险。未知/虚假IP，PHY，DDR和高速串行逻辑位于列表顶部。

  由于这是预计会出现问题的地方，因此您的团队需要投入额外的工时，以确保为这些问题模块提供了具有快速调试时间和高仿真速度的GLS环境，以便能够按预期证明工作有效。

---

6.功能测试，GLS和内部BFM

采用内部BFM的环境用于模拟模块边界处的内部DUT接口，以简化测试激励的生成。假定该模块将与硅中的BFM完全相同。利用现有测试用于GLS对于提高GLS成本效益至关重要。必须重写新的测试以在没有BFM的情况下运行非常昂贵。但是，将BFM添加到您的GLS测试平台是很棘手的，特别是对于SDF GLS，但这是可能的。SystemVerilog添加了带有时钟块的接口，这些时钟块允许非常轻松地设置建立和保持时间整个信号组的应用，并使GLS中的BFM变得相当可行。

• 利用现有测试并简化测试生成
  与从头开始生成测试套件相比，获取现有测试集要容易得多。即使不存在现有的测试，从BFM生成激励也更容易创建，维护和调试。警告：但是您必须信任BFM。如果您的BFM中有细微的错误，则GLS和RTL仿真都不会捕获bug。

• 较短的测试
  使用BFM进行的测试较短，因为它们可以跳过它们替换逻辑的初始化过程，并且使用BFM代替门中的设计模块可以更快地仿真。警告：使用BFM会绕过芯片上那些块的复位初始化测试-这也是芯片致命bug经常出现的地方。

BFM使创建测试的速度越来越快，它们通过仿真，但是可能隐藏模块中的时序和功能性错误。

---

7.使能时间检查情况下运行GLS SDF

这就是GLS的回报。 SDF gatesims针对的就是以下四种其他任何方法都找不到的关键错误类型。

• a）物理设计中的时序约束不正确/不完整
  综合来说，您的时序约束告诉工具如何对设计中的所有路径进行计时，以及它们需要多快。但是，静态时序分析（STA）也使用这些相同的约束来检查那些相同的路径是否正确时序检查。因此，这是一个错误的检查。这就是为什么对时序约束进行大量人工复查的原因。 GLS SDF发现了这些错误，

• b）GLS SDF和时钟毛刺
  您的芯片时钟必须非常干净。 DFT，后端布局和布线，门级修复，电源门插入，BIST，BISR都可能引入致命故障，这是GLS SDF可以捕获的。

• c）CDC，异步时钟和GLS SDF
  从一个时钟到另一个时钟的异步信号和总线总是至关重要的，因为这种类型的错误在没有重新旋转的情况下不可能得到修复，并且因为简单的0延迟RTL和简单的GLS测试无法找到它们中的大多数。尽管甚至不能保证具有SDF的GLS都能找到所有异步时钟交叉的问题，但它的确趋向于找到许多通过所有其他检查都找不到的问题。

• d）多周期路径，断言和GLS SDF
  芯片设计人员使用多周期路径来简化时序，而无需更多的门或功率。不幸的是，错误地执行MCP可能会导致亚稳态或不正确的功能，而在0延迟RTL或简单的GLS中无法检测到。您必须使用断言来检查建立和保持时间的多周期错误。执行GLS SDF会捕获MCP错误。警告：如果不执行GLS SDF，您将使芯片处于危险之中，并且人为地错过任何源或任何MCP目标DFF上的一个断言。

同样，请注意GLS SDF如何捕获上述四种时序错误。其他两个技巧：

• 亚稳性将X从Qout传播到失败测试
  当DFF的D输入在时钟边缘附近的建立或保持时间窗口内更改时，将标记时序违规。警告消息将打印到日志文件，并且DFF可能是亚稳态，DFF的输出在的整个时钟周期内被驱动为X。

  通常，此X会传播到整个设计并导致测试失败。如果是这样，这是一个实际问题，必须对其进行调试。

  如果X不传播，则手动查看设计的X缩减逻辑是否有效或您是否很幸运也不会受到伤害。

• X更容易调试
  调试这些故障非常容易，因为您不必追溯到问题的根源。日志文件中的时间违规警告将您带到源头。即使有太多警告，与尝试比较没有X的通过的Gatesim和失败的Gatesim相比，在波形中调试X要容易得多。

---

8.您必须手动检查日志文件中的所有时序违规

我知道这可能会让人感到麻木，但是流片之前，即使在测试用例通过，您的工程师也必须对所有时序违规警告进行排序并检查所有警告，以找到不会因测试失败而传播的次时序问题。创建一个脚本，以在释放复位之前过滤掉时序违规。

您必须以波形定位显示时序违规的门的端口，以弄清楚测试对此发出警告的原因。确定起点和终点，并与STA进行检查，以查看该终点为什么不应该违反时序，以及为什么确实如此。

即使由于时序违规而产生的X不会传播到设计的其余部分而导致测试失败，也可能存在真正的问题。 Gatesim回归的覆盖范围极为有限。由于覆盖范围有限，时序检查中检测到的时序违规很可能不会传播到任何小型GLS回归测试中。在GLS中未测试的模式下，这种时序冲突可能仍会导致致命的芯片故障。

上面的这两张图显示了启用和禁用时序检查的SDF反标时序，仿真之间的差异。两者都会对设计中的信号施加延迟，但是请注意，只有通过启用时序检查才能使时序违规警告打印到日志文件，而Qout变为X。

---

9.GLS性能的捷径

大多数芯片都有需要很长的复位初始化程序的模块，DDR初始化，PLL稳定，BISR运行，BIST运行，引导代码加载等。这些仅需要在一个GLS测试中运行。 您的大部分测试可以简化这些重置初始化过程，而后门启动加载则可以更快地进入GLS测试的“有趣”部分。

---

10.Lint，LEC，STA和GLS

请！请勿对破坏的网表进行痛苦的GLS调试，这些网表由于更早的时序或功能等效而被破坏-除非您只想练习。

• 在零延迟门之前做Lint和LEC
  确保您的门级网表是通过RTL设计创建的，该设计通过Lint检查并且在运行0延迟gatesims之前*是LEC干净的。网表在Lint和LEC完成之前可能会有功能上的差异。

• 在GLS SDF之前确保STA保持时间干净
  在网表保持时间干净状态之前，请不要在带有注释后的SDF延迟的情况下运行GLS，否则测试将不会以任何时钟速度通过。

• 在全速GLS SDF之前确保STA建立时间干净
  只要您的GLS仿真运行足够慢的时钟，建立时间冲突就可以了。网表准备就绪时，请先低速运行，然后再以全速运行。

---

11. 对带有SDF的GLS使用“假”保持时间

要使带有SDF反标的GLS起作用，需要花费大量的工时。并且必须在您的网表在保持时间违规清除干净之前开始这项工作。但是由于SDF Timing GLS不能在没有保持时间干净的网表的情况下运行，因此，一个窍门是制作一个脚本来假修复您的网表。该脚本使用您的STA时序报告来列出有失败保持时间的DFF。然后，脚本在这些DFF的Dinput处添加仅足够的延迟以修复这些路径的保持时间违规。

• Verilog GLS SDF会吞下短脉冲
  进行Verilog SDF仿真的工具不会通过比该单元的传播延迟短的脉冲。例如，对于具有延迟时间为5 ns的缓冲的芯片，任何4 ns的脉冲将在GLS SDF运行中消失。为了平衡未完成的时钟树，有时设计师会只放置一个

     assign＃20 clock_666_in = clock_666__delayed_out;
  

  以为他们只是在时钟树的一个分支上增加了20 ns。这样做是为了使小于20纳秒的脉冲不会传播！因此，要在假的修订保留脚本中解决这种脉冲吞咽行为，必须使用多个级联的较小延迟而不是一个较大的延迟来完成延迟的添加。否则，您的SDF时序会错过某些脉冲。

---

12.首先创建慢时钟GLS测试

在每个项目中，我发现门级网表仅在设计过程的后期才制定时序规范。通常直到流片前才将它们“清理干净”。但是必须能够更早地运行SDF仿真。解决方法是在测试中创建一个旋钮，使所有Gatesim测试以半速或四分之一时钟频率运行。这使您的项目可以早日解决那些早期的GLS错误，但是在需要时，您可以全速前进。

---

13.在RTL仿真中更轻松，更快地找到那些Gate Bug

您可以在RTL仿真中使用X传播来查找GLS错误。任何有助于在RTL中而不是GLS中找到错误的方法都是胜利。 在设计过程的后期GLS中发现错误-当时调试和修复错误的成本要高得多。

• A）在RTL仿真中查找复位初始化错误
  许多设计通过在数据路径中使用不可复位的DFF来减小尺寸和功耗。有时，不可复位的DFF偶然用于控制逻辑-由于在实际的硅片中，这些DFF会随机从电源上电变为0或1，所以这些reset-init漏洞实际上可能是芯片杀手级的漏洞。

  警告：RTL仿真非常乐观地对待X，而Gates非常悲观地对待它们。最近，仿真器添加了X传播模式，该模式使RTL仿真传播X的更像门级中 传播X，并具有以RTL速度运行且易于调试代码的好处。尽可能使用这些新的悲观的X传播RTL Sims。它的运行速度比GLS快6到24倍。

  RTL仿真也从未初始化的SRAM中吞噬X。由于大多数SRAM不会自动初始化，因此需要识别此类错误，这可以在X传播的GLS之前完成。

• B）RTL仿真中的CaseX或CaseZ错误
  有时，设计师需要优化代码以提高速度，然后他使用casex告诉其综合工具不要检查某些输入。为使此工作有效，大小写必须不重叠。如果存在重叠，则可能导致多种不同的综合结果-并且由于将case语句仿真为优先级编码器，因此RTL仿真始终仅选择第一个匹配项，这是一个错误。此错误使综合功能可以选择直到GLS才被仿真的网表。SystemVerilog现在具有“unique case”，如果在可综合的RTL中使用，则有助于避免这种情况。

---

14. RTL仿真中通常不会出现delta-delay race

当您的Veilog仿真器不能正确模拟DFF时，称为delta-delay race。而不是在时钟沿之前在D输入上获取值，而是偶然地在时钟沿之后*使用D输入值。在仿真中，Din和Qout会同时变化，这看起来像是快速路径保持时间失败。

如果在您的RTL仿真中发生这种情况，这是一个无声的杀手;。因为您的RTL功能与综合逻辑的功能不同。Lint没有捕获这个。 LEC对此不了解。唯一可以肯定的方法是通过GLS SDF运行。

一种解决方法是，设计团队可以在设计中的每个DFF上声明一个断言，但这将是一个巨大的维护问题。一个更好的解决方案是让仿真器添加一个选项，以在设计中的每个DFF上自动放置一个断言，以动态检查delta-delay race。

对于如此罕见的事件，这实在是太过分了，因此，等待完整的GLS SDF运行可能是可以的。

---

15.使用GLS处理X传播

我听到的关于GLS的最大抱怨是必须处理其对X的悲观传播。每个项目都必须经过乏味的搜索，以寻找所有X来源-并以不会使GLS任务无效的方式消除它们。我的建议：

• 在所有floating输入上添加上拉或下拉
  测试平台中存在数量惊人的无法将所有输入驱动到DUT的情况。 Z在GLS中很快变成X。

• 将所有不可复位的元素初始化为全0，全1和随机
  如果可用，请在仿真器中使用初始化模式。这会将设计中的所有寄存器在时间0设置为全0，全1或随机。传递已知的随机种子，以便每次测试运行的随机模式都不同-如果您需要重复它，则可以重复使用。然后对所有测试使用全0一次，全1一次和随机多次运行所有回归。

• Treat X-gobblers as Sketchy
  工程师喜欢将X-gobblers放在门级仿真模型（如RAM，fuses和PLL）上，因为RAM模型作者喜欢将X驱赶出其RAM。在RTL仿真中这是可以的，但是使用GLS时，一切都会变为X。
  仅将X-gobbler代码添加到已知导致X传播不正确的RAM模型中。 您的X-gobblers应该被编码为gatesims上的* only * gobbleX。 并且由仿真器初始化命令创建的plus-arg还可以控制这些模型中的X-gobblers如何将X转换为全0，全1或随机。
  注意：GLS中的X-gobblers不仅会像RTL Sims一样吞噬X。他们将X的值更改为0、1或随机数-从而正确检查错误行为的测试将失败。另一种方法包括以1 ps的时间在RAM上存储随机值。

• 禁用那些用于GLS SDF的0时序检查器
  一些库模型的检查在模型的输入为X时在时间0失败。在SDF时序仿真中，芯片的输入不会使其在时间0进入设计更深的任何模块-因此这些输入为X，直到信号通过延迟传播。您必须编辑模型以禁用这些检查，直到信号有时间传播为止。通常在您的GLS运行中大约需要50 ps。

• 不存在具有良好X追踪的Wave调试器
  大多数GLS调试是通过调试wave文件执行的。市场上有许多工具，它们都具有X跟踪功能。我花了太多时间来寻找X。我非常擅长，但是如果有人可以在wave调试工具中创建良好的X-trace功能，我会愿意永远放弃它。 虽然您的EDA销售人员会声称他们的wave调试工具具有x跟踪功能，但事实并非如此。

  Wave调试器的X跟踪失败是因为Wave太慢了，通常不会将其与GLS中的完整层次结构一起转储。

  当我追踪一个X并降到低于转储的水平时，我会上移一个水平，直到再次产生波形，然后将该模块的所有输入都放到查看器中，并寻找大约在正确的时间出现的X，并继续。如果输入中没有X，则需要在该模块上进行更深的转储，以重新运行。

  对于GLS调试而言，可以通过部分转储自动执行这种简单的X跟踪算法的工具将是一个巨大的胜利。

---

16.零延迟GLS中的棘手Delta-Delay Race

如我在技巧14中所述（上文），当仿真器未正确模拟DFF时，就会发生delta-delay race。与其在时钟边沿之前在D输入上获取值，不如在时钟边沿之后使用值-看起来像仿真中的“快速路径”保持时间失败。

这些问题通常发生在0延迟GLS中，因为使用0延迟，所有功能信号都在时钟沿同时变化。仿真器通过将时钟的上升沿置于零时间窗口的阻塞部分（较早）来处理此问题，而功能信号则限制为零时间窗口的NBA（非阻塞分配或延迟）一半。仿真器知道如何执行此操作的方法是查看信号的生成方式。假定时钟由阻塞分配（=）生成，而功能逻辑Qout由非阻塞分配（<=）生成。

不幸的是，由于当今大多数时钟是由使用DFF的时钟分频器生成的，因此这些时钟是由DFF的Qout生成的。这些都使用DFF UDP（用户定义的原语）在门中建模。最初，UDP DFF模型默认为阻塞赋值，但几年前，Verilog LRM将默认更改为非阻塞赋值。

无论哪种方式，由相同的DFF仿真模型驱动时钟和功能DFF都会带来问题。您如何告诉仿真器哪个是时钟，哪个不是？仿真器通常在大多数时间都能正确处理。这使我怀疑该工具在设计编译期间正在识别时钟，并确保这些信号始终在“阻塞赋值”区域中。

但是似乎总是有一些情况-特别是在硬宏或怪异编码的RAM模型中，由于 delta-delay
races，延迟0的GLS失败了。通常，当发现这些故障时，可以使用 单独 模型修复DFF驱动时钟。另一个解决方法是在D-in的输入上放置一个#delay，但是 单独 模型方法将修复时钟网络上的所有DFF。愿望清单：最好有一个编译选项，该选项将在RTL设计中的所有DFF上自动放置一个断言，该断言将在仿真运行时动态标记任何delta-delay故障。必须手动执行此操作是维护的麻烦。

---

17.使您的RTL，测试平台和Gate网表保持同步

上面较早的技巧2指出，为了轻松调试失败的测试，必须使三个DUT模型以相同的方式运行，以便调试失败的测试更加容易-通过将通过波形与失败波形进行比较。如果您的RTL DUT与Gate DUT不同，则此方法将无效。

问题：物理设计师需要花费几周的时间才能从RTL生成新的Gate Netlist。在冻结设计之前，这是一个实际的问题，因为RTL一直在变化。请注意，您的测试平台和测试用例存在相同的问题-它们还需要匹配Gate Netlist。

解决方案：当PD传递网表时，它们提供RLT DUT被提取进行综合的存储库标签。当您收到一个新的Gate Netlist时，您将从存储库中的主分支以PD创建相同的RTL标签checkout，这些标签是他们提取RTL进行综合时制作的。它是GLS储存库分支的并行分支。这在GLS世界中非常标准。

• 存档每个网表更加容易
  在某些时候，有必要检查您的GLS更改。通常，验证团队不能容忍在他们的测试平台上四处散布的“ `ifdef GLS”。如果您检查GLS对主存储库所做的更改，则这些GLS内容将进入主存储库测试台代码。

  还要另外设置一组“ temp`ifdefs”。您必须更新到主存储库分支才能checkin-破坏了该网表上的GLS，因为它引入的更改与现在非常老的Gate网表不匹配。这些也必须是“ temp ifdef”，以允许GLS测试通过。因此，两组“ ifdefs”污染了存储库的主分支。
  

  相反，可以将GLS分支与主分支分开-参见上图。切勿将其合并或checkin到主分支。保持GLS存储库分支为并行分支，该分支从Master提取每个新网表以更新testbench和芯片RTL，但从不合并。将每个网表的最后checkin标记为存档。仅在流片之后，您才合并回去。

• 将您的GLS储存库与RTL储存库搅动隔离
  GLS的另一个大问题是Master Branch存储库有很大的客户流失。checkin是恒定的，并且存储库经常损坏。由于Gate仿真的速度太慢，无法包含在最新发布的回归中，因此Gate测试是最不完善的测试。

  而且，由于GLS的调试要比RTL仿真的调试困难得多，因此最好将GLS分支与进入Master分支的所有更改隔离开来。 GLS分支会自动为您执行此操作，因为仅通过每个新的门级网表从主服务器引入更改。

---

18.仅在物理块模块边界上使用probe和force

在RTL综合过程中，门网表会重命名DUT内部的大多数信号，因此在测试平台中无法probe来自DUT的内部信号。这也会影响“force”命令的使用。

通过让您的物理设计团队安排其综合脚本来计划您要从测试平台中探查到的信号的名称，从而为此进行计划。大多数PD组通过保留物理模块边界上的所有端口来实现此目的。然后，测试人员必须遵循以下规则：所有测试平台接口必须仅连接到这些模块的端口上。

---

19.您所有的GLS检查和回归必须为PASS或FAIL

为了使事情可以批处理，您的所有这些测试用例必须是完全自检和可回归的，以便可以在服务器池中连夜运行。

至于检查，有两种类型的Gatesim测试。

• a）C代码，十六进制或汇编代码GLS测试
  这些是代码激励，检查器用C编写，然后编译为十六进制文件，然后将其检入到存储库中。测试平台释放DUT上的复位，然后将此十六进制文件加载到测试平台中的外部RAM或ROM模型中，或者后门在DUT内部加载SRAM。测试平台释放DUT上的复位，并等待握手。

  握手通常是DUT和测试平台都可以访问的内存中的位置，或者是使用IO在测试台和DUT之间进行通信。 DUT从十六进制代码启动并自行执行测试。

  注意：这些十六进制测试应使所有外设均不复位，并检查RAM，寄存器，DDR，外设等是否可以通过芯片中的所有互连正确读取和写入。这是通过先写后读来完成的，以便十六进制代码可以自检。

  如果数据正确，它将继续。如果不正确，则通过写入测试已通过的握手“PASS/FAIL”位置立即使测试失败和测试完成的“DONE”握手位置来使测试结束。同时测试平台验证自释放复位以来，一直在轮询读取DONE位置，当它被视为是真的时，完成测试，将PASS / FAIL和尽可能多的信息写到日志文件中。

• b）GLS BFM测试
  这些是monitor检查测试，将BFM与GLS混合使用以激励和检查正确性。这些测试比汇编十六进制代码驱动的测试更容易编写和调试，因为它们通常是从早期的RTL回归中得到利用的。

  问题是它们需要在您的DUT中使用Cross Module References（force和probe）-这对于Gate Simulation非常棘手。您的门级网表必须保留每个版本中要probe和force执行的所有信号，或者每个网表必须有一个映射文件，可以轻松地将信号连接到测试平台。

  正如我们稍后在下一个技巧（第20条提示）中讨论的那样，GLS SDF时序仿真甚至更加棘手。

  GLS挑选测试用例的4个目标
  这听起来似乎很明显，但是通常，测试用例检查DUT功能正确性的方式可能会使您的GLS工作成败。选择GLS测试用例有4个目标。按优先顺序：

  • GLS测试目标1：没有假的fails
    您的测试必须检查正确性。它必须健壮。您必须能够更改GLS上的时钟频率和偏斜，而不会导致测试错误地标记失败。追逐这些“假的fails”的代价非常高，并且可能很快使GLS失去成本效益。

  • GLS测试目标2：没有假的passes
    显然，假的pass可能会使错误进入芯片。您需要知道，如果在测试中获得GLS PASS，则该测试确实进行了充分的检查，以确保您知道逻辑是否按要求工作。您必须知道PASS表示实际上已通过。

    注意：许多人感到惊讶的是，我将健壮的测试优先于更高级别的功能检查。这是因为GLS错误通常是症状很大的严重错误，因此检查不需要细粒度。

    Gatesims比细粒度检查更重要，它需要细微激励，尤其是围绕着时钟。这些测试必须能够处理时钟的偏移和相互之间的时钟抖动而不会出现False Fails。否则，您将无法运行那些时钟偏斜，并且GLS的很多值都将丢失。

  • GLS测试目标＃3：使fail的测试用例易于调试
    失败的测试用例应易于调试。这意味着它们不应该只是hang。当测试失败时，应该有一些指示失败时间和位置的信息。确保您的代码驱动测试具有检查点以显示关键步骤。当内核完成复位，完成DDR初始化，完成时钟切换等时，写入日志文件。监视器应在日志文件中显示信息，而不必通过转储重新运行。

  • GLS测试目标4：选择低端移植成本测试
    必须将检查程序从RTL转换为Gates可能非常昂贵。不要将所有内容都移植到willy-nilly上。相反，您必须计算出每个端口要花费多少工时。 （不过有一个例外：如果您的RTL测试用例确实具有良好的易调试性或“No False Passes”功能，则可以移植它们。）
    而且，每次测试方式的转换效果更差。例如，必须从BFM转换为GLS代码驱动，这非常昂贵。

---

20.棘手的Verilog“clocking…end clocking”，BFM和GLS SDF

大约10年前，对Verilog标准进行了更改，以允许使用时钟块。它们用于BFM接口中，以使BFM在具有Hold和Setup检查的SDF反标门级网表中驱动和探测信号以及总线。使GLS SDF中的内部BFM运行更容易。否则，您将必须创建一个定时环并更改每个新网表的信号延迟-有时甚至在逐个信号的基础上。

• GLS BFM时序问题
  BFM用由测试平台中的任务和序列驱动的简单读/写接口替换复杂的内核。但是，只有在时钟和数据之间的时序拥有建立时间和保持时间的情况下，该BFM才有效。在0时刻RTL和0延迟GLS中，数据和时钟同时出现，并且在“阻塞”时钟沿之后发生“非阻塞”数据信号变化。但是，当尝试在GLS中使用内部BFM且向网表上应用了带有反标的SDF时序时，将BFM绑定到DUT以probe并force数据信号的点将获得任意时序。

  根据路径中选择的节点，时钟和数据的绑定点两侧均存在延迟。

  这会导致在两个方向上发生保持时间冲突。

• DUT到Testbench，Testbench到DUT。
  利用SystemVerilog时钟模块，您可以在时钟沿之前的某个时间将数据从DUT捕获到Testbench。这是总线上的所有位都同步并且稳定，可以捕获并发送到Testbench（在时钟沿之前用#SETUP_TIME指定）。

  同样，当Testbench将总线驱动到DUT时，时钟块使您可以在所有Testbench输出上设置#HOLD_TIME延迟，以确保DUT在相同时钟上捕获所有这些数据。

警告：SystemVerilog时钟模块是BFM时序问题的快速修复，但是它会带来了难以解决的意外问题。

---

21.手动检查测试台中的所有“force”

Verilog的“forces”结构通常在验证中用作临时解决方法。这些可能会错误地留在您的测试或Testbench中，从而掩盖了真正的硬件错误。

因为GLS网表通常会更改RTL DUT中的信号名称，所以GLS大多会解决这些剩余的“force”问题。使混乱的交叉模块引用文件使编译失败。

但是，由于现在有更多的网表保留模块端口信号和层次结构，因此在以后的GLS运行中，您仍然必须针对所有“force”执行搜索和销毁任务。

• 关闭所有force，并至少1次复位初始化测试
  确保至少对整个芯片进行一次完整的GLS完全复位初始化，而完全没有“force”。

• 滚动您自己的动态可追踪“force”宏
  创建一个宏，该宏使用时，每次在DUT中force信号时，都会在日志文件中打印一条消息。当您要查找DUT中潜伏的任何剩余“force”时，请使用此宏。

---

22.使那些GLS失败测试更快调试

运行时性能是调试失败的Gatesim测试的关键。当获得新的门级网表时，将其测试平台移植到该平台上，并在服务器池上以批处理模式对其运行gatesim回归。

以最快的方式运行此程序，且不dump波形以优化CPU和磁盘空间。如果您尚未完成0延迟GLS运行，请不要浪费时间进行SDF反标GLS。

第二天会有大量失败的测试。调试通常涉及使用Wave Dump重新运行失败的测试，而这又要花费一天的时间。如果在关键点上将监视器拼接到网表中，则有可能快速识别故障源，而不必重新运行失败的测试并dump wave。

---

23.使用GLS SDF验证时钟bug

任何芯片中最关键的部分之一就是时钟。良好的时钟将使芯片性能稳定。错误的时钟会导致芯片挂起和错误的行为。不幸的是，在我们针对性能进行了调整的理想0延迟RTL仿真器中，很难进行时钟验证。您必须通过四种危险类型来解决时钟错误。首先，创建检查时钟错误的程序并在RTL中运行它们。然后，将它们移植到0延迟的GLS，然后移植到带有SDF反标的GLS。

• 时钟毛刺和GLS
  毛刺不太可能出现在您的RTL仿真中，因为毛刺通常在综合，布局和布线阶段被引入到您的芯片中。为了进行测试，将毛刺检查器对准时钟和复位逻辑（任何其他毛刺问题），然后运行0延迟GLS，然后运行带SDF反标的GLS。

• GLS SDF和最大频率违规
  最大频率错误是指两个时钟边沿比使用该时钟定时处理的逻辑靠得更近时。这导致逻辑挂起。将最大频率检查器放在时钟上，然后直接使用SDF运行GLS。在这里不要为0延迟而烦恼。

• 带有GLS SDF的异步时钟交叉
  当今任何设计中风险最高的部分是其异步时钟交叉。GLS SDF测试并不能保证发现所有问题，但是通过这种方式却发现了令人惊讶的问题。

  确保异步时钟通过质数分频器或非常随机的产生，不会产生谐波。测试中的时钟关系越多样化，并且随着时间运行的SDF corner越多，则SDF GLS发现错误的可能性就越大。

• 动态频率变化和SDF GLS
  当今的低功耗设计需要动态改变频率而无需使逻辑保持静止。使用高频动态时钟更改创建自检测试用例，并使用SDF时序在门级网表上运行它们。确保您的基本时钟频率彼此重叠。

---

24.使用GLS SDF复位时序

当今许多大型设计的时钟是如此之复杂，不可能在同一时钟上使所有DFF都退出复位状态。如果多个DFF在复位后第一个时钟沿上改变状态，这将是一个问题。在具有SDF时序的GLS上运行复位初始化测试可以发现这些错误。但是，当已知您的逻辑存在此问题时，必须小心地将其设计为“reset aware”，然后供您以后验证逻辑是复位正确与否。

---

25.使用GLS进行功耗分析

低功耗设计要求在流片之前对功耗进行非常精确的分析。有一些工具可以估算这种能力，但是许多团队需要更精确的度量。这些工具在高功率模式下需要芯片的GLS完整存储波形文件。使用带有SDF时序的GLS创建波形存储，以获得最真实的功率测量。

---

26.存档每个网表和“How To”

通常，每当物理设计团队为他提供一个GLS网表时，就会有一位工程师知道GLS环境并负责新网表的移植。该移植过程是GLS进展的关键，因为在此步骤中插入仿真问题非常容易，且GLS仿真问题很难调试。

GLS负责人必须详细的了解从一个网表到另一个网表的所有更改，尤其是围绕IP的更改。对于每次移植，他的移植过程中的步骤应有充分的记录，因为他的下一个网表移植将以这些完全相同的步骤开始。

至少要有两个知道如何执行移植操作的人员很重要。有时，与晶圆厂一样，使用GLS，您可以“放弃配方”。您可能会从PD获得新的严重破坏的网表；或测试平台或仿真器版本更改，导致一切崩溃。能够提取过去pass的网表的功能使调试新网表的新问题变得更加容易。您必须标记并存档每个网表，并带有清晰的移植说明。该存档必须包括如何为所有先前的网表提取GLS验证环境的先前标签，如何以其最稳定的标签运行先前的网表回归，通过哪些测试，运行了多长时间以及哪些仿真选项和工具版本被使用。

这可能是通常被忽略的最重要的步骤。

---

27.不要在最终流片前三周开始修复GLS问题

有了第一个RTL模型，您应该开始创建将在该芯片上使用的GLS环境。通过早期的网表版本清除网表级别的模型问题。

请记住，在20个gatesim测试失败中，有19个是由于仿真问题而不是网表错误引起的。

GLS环境的目标是确保最终的网表在流片前2周到达时，您可以运行最后17个网表的回归-并解决所有GLS仿真问题。在此关键的最后阶段，您应该只处理实际的错误。

---

28.弄清楚为什么您没有更早地发现那个致命的bug

在纸面上，GLS永远不会发现任何错误。我们今天使用的所有过程（LEC，Lint，STA，Formal，ABV等）都确保我们为硅制造而生成的门能够按预期运行。但是，GLS是对其他工具所做的事情进行的非常经济有效的正交检查。

但是根据我的经验，GLS一直存在我发现的芯片杀手级错误。由于这些错误是在设计过程的后期发现的，因此很明显没有 GLS的情况下不会发现它们-它们的修复通常是昂贵的Gate Level Fix-或重新编译通常会延迟流片。这使您可以突然发现问题并引起管理人员的注意，从而检查该bug如何逃过了您现有的工具和验证过程。

利用这次危机对您有利。用它来改善整体芯片设计和验证过程。

---

29.找到合适的人

GLS将所有工具推到了极限。它一直在与性能问题，奇怪的工具问题和库问题作斗争。 GLS工程师的大部分时间都花在寻找不影响设计相关问题的变通方法的解决方法上。

您希望工程师有信心做出艰难的决定。在多条进展路径之间做出选择一直是令人头疼的问题，需要具备了解替代方法风险的能力；因为某些变通办法可以节省大量的工作而几乎没有风险，而其他变通办法则会使GLS失效。

当您的仿真工具或Wave Viewer出现错误时，EDA供应商通常不会及时为您修复。即使他们做到了，您也不太可能在流片之前就愿意使用其工具的较新版本。所以你会寻找解决方法。您的GLS工程师必须知道如何找出这些解决方法和/或“吸引”其他人（同事，FAE，他的IT部门，他的管理人员，无论谁）来获得此解决方法。

多天的RTL和GLS仿真需要具有并行处理许多事物的能力。组织是关键。我经常一次要工作20多个工作。因此，有一种方法可以跟踪每个事件的发生，这是上下文切换而又不会丢失的唯一方法。通常，我将一次尝试许多实验来解决问题，因为要花一天的时间才能查看是否有任何效果，而连续尝试则需要一周的时间。

通常，工程师将为一个芯片开发GLS，而再也不想这样做了。这个人很可能不适合这种工作，或者他的环境不能胜任这项工作，或者两者兼而有之。

• MGMT提示1：如果您找到了一位精通GLS的工程师，那么明智的做法是让他们在公司中工作变得值得。 😃

• MGMT技巧2：确保为Gatesim团队留出额外的磁盘空间。通常是他们给别人的东西的5到10倍。对于GLS验证团队来说，一个或两个单独的分区会很好，因为它们可以快速填充满磁盘。

个人保证：正如我之前所说，通过这里概述的技术，我个人在我职业生涯中流片的22个芯片中至少发现了一个致命bug。