EDA厂商一直致力于开发集成度更高的调试流程，以使得工具执行引擎同硬件和软件的结合更加紧密，但是这样就足够了吗？

EDA行业在验证的流程中花费了大量的时间和精力，包括新的语言，新的工具，新的库，新的验证方法。调试是整个验证流程中的一个环节，开发团队在调试的过程中花费了大半的时间，并且问题还在不断增加。

一个原因是设计和调试不仅仅是一个纯功能性问题，而是扩展到性能，功耗和安全性等其他领域。 这使得调试工作不仅仅是一个硬件电路的问题，还牵扯到很多相关的领域，所有这些领域可能需要不同的数据，不同的可视化形式以及不同的分析工具。

扩展执行引擎

过去，逻辑模拟器是唯一附带有调试器的工具，可以交互式的查看结果，也可以将结果保存到跟踪文件中以进行离线的查看和分析。 从那时起，我们已经走过了很长一段路，但是每个新的执行平台都会有一个之前那样的逻辑调试器。

Mentor Graphics公司首席验证科学家Harry Foster说：“我们已经扩展了形式验证，仿真，FPGA原型测试和一些其它的模拟方式。FPGA原型测试就是一个例子，现在大多数的合理大小的SoC都使用原型测试。十年前，用于FPGA调试的资源非常简略，就像一些FPGA供应商提供的那样，它们基本上就是小型逻辑分析仪的内核。但是这些解决方案是有问题的，用户必须重复四到六次才能重新测试。每次运行前他们都必须添加那些需要监视的信号。现在，我们做到了监测更多的信号，我们可以处理64,000个信号，用户可以动态选择信号子集并且不必消耗一整夜时间重新编译设计。

设计人员渴望一致性，对于在开发周期的不同阶段的同一任务他们不想使用不同的调试工具。 验证专家Lauro Rizzatti说：“传统的硬件验证是通过古老的HDL仿真器进行的，在设计周期的早期阶段将继续作为选择。 但是在IP，模块和子系统层面，系统验证（包括嵌入式软件与底层硬件的交互）对HDL仿真器来说是一个巨大的挑战。 对于这个任务，设计者需要一个硬件模拟器。 它可以在短时间内处理数十亿个周期。 它可以启动一个操作系统，并将设计带入‘感兴趣的状态’进行测试。 而且它必须继续具有类似仿真器的调试功能，可以跟踪跨越硬件和软件两个领域来跟踪故障。”

并且一致性不仅仅是外观和感受，Agnisys公司首席执行官Anupam Bakshi表示：“当使用工具对信号命名时，信号的跟踪和调试就成了一个问题。统一的验证环境要求将开发各个阶段的规范不断进行完善：虚拟原型，仿真，模拟，FPGA原型和真实芯片（的验证）。 这有助于减少调试的负担。 当工具相互连接时，也应该可以进行交叉探测。

Imperas公司首席执行官Simon Davidmann完全同意需要更多的一致性，因为更多的领域被添加到调试问题中，并且需要许多的执行引擎。 “有一些公司已经开始使用模拟进行软件验证。 许多公司正在使用模拟或FPGA原型测试在RTL上解决这个问题，但是这要求硬件设计几乎完成。 在开发流程之前，虚拟原型测试提供了一个更好，更快的平台。”

抽象层次的扩大

引入软件领域增加了一大堆挑战。 Synopsys验证组高级营销总监Michael Sanie表示：“当你把软件和硬件联系到一起时，将增加一个全新的维度。 对于正在尝试调试的一行软件，它可能与数百个事务相关联。 一行软件命令需要在事务级别上有许多命令，然后每个都与数千行代码和RTL信号相关联。 ”

处理这个问题唯一的办法是进行抽象，这将在多方面有所帮助。Oski Technology首席运营官Dave Parry解释说：“结果数据的抽象可以在一个更加概念性的层次上暴露出问题的所在，从而帮助我们更好的理解和调试错误的行为。实际上，这可以让工程师看到整个森林，而不仅仅是单个树木。 数据和结果抽象也会使得对比通过与失败测试用例的行为更加容易。”

为了使系统级的调试更加顺利，硬件和软件工程师必须能够在同一个问题上一起工作，这是一个传统的问题。然而，在很多系统公司里这是一个长久以来的行业笑话，硬件和软件团队只有在EDA厂商试图向他们推销混合领域工具的时候才会了解彼此。虽然那些日子已经过去了，但是两个团队的工作方式还是有很大的差异，这使得整合起来更加困难。

让我们考虑一个典型的软件方法。“如果你有一个gdb任务与一个处理器通话，另一个gdb任务与另一个处理器通话，那么整个系统控制起来将变得非常困难。”Davidmann指出，“多线程和多处理器意味着程序会并行进行，这使得它变得复杂。当你有事物因并行进行而相互影响的时候，你需要对发生的事情有一个完整的看法。 考虑一下如果使用了许多Verilog中的always块描述了一个电路，但是在同一时间你只能看到一个always块的行为，这将让你很难去做任何事情。今天复杂的嵌入式系统正是如此，你不仅仅想看到一个处理器中发生的事情，还希望看到其它处理器和硬件中发生了什么。

但问题不止于此。 “如果涉及真正的硬件，那么你还必须处理X态和竞争问题，”Davidmann继续说道，“每次用软件运行某些东西，你都不知道将会发生什么事情，这使得调试变得更加复杂，特别是当问题是由执行顺序造成的时候。我们仍然看到有人试图用gdb来调试这些复杂的事情，就像试图用示波器调试一个复杂的芯片。首先，你看不到发生的一切。 其次，当你把探头加到某个地方时你改变了这个系统，有可能碰到了电源，然后就会出现各种新的问题。 软件正在变得比硬件更复杂，但通过为硬件团队提供各种功能，可以改善软件的调试。”

迈向一个集成的调试平台

自然想到的解决办法是将软件系统迁移到一个虚拟平台，在这个虚拟平台上，许多这样的问题将消失，并且可以具有完全可控性，确定性和可视性。 Cadence公司系统和软件实现部产品营销高级总监Frank Schirrmeister指出：“这样的软件解决方案存在着一定程度的干扰性，特别是使用JTAG或者Vstream将调试器连接到内核的时候。但是当你把虚拟平台同仿真、模拟、FPGA原型相连接时，这些问题将消失。在虚拟化解决方案中，我们可以在不改事务变状态的情况下对其进行查询。”

虽然有些人可能仍然不满意虚拟引擎的运行速度，但还有的其他方式可以进行调试。 “你是指哪些用户？”Schirrmeister问道。 “是试图研究硬件的软件人员，还是因为软件在硬件上执行，试图处理软件的硬件人员？对于自下而上的人来说，你可以在硬件中选择你想要看的内核图像，而且大部分都可以在后处理阶段完成。可以通过仿真运行生成所有时间戳轨迹，从而拥有所有的硬件运行痕迹。 现在，你可以查看每个内核，并理解它们作用在流水线的哪个部分。”

后处理也可以用于性能分析，特别是对于单个运行无法发现的问题。 Sonics首席技术官Drew Wingard说：“我们的设计环境中有一个性能分析数据库，我们可以从中获得用于RTL或者SystemC模拟的事务级数据，并将其加载到SQL数据库中。由此我们可以提取基本的事务数据，系统可以将来自启动器的原始事务同事务流的可视化联系起来，我们可以看到事务流入网络，然后作为响应的事务从网络流出。我们可以用图形的方式来展示这些流程，这样他们就可以看到在不同地方发生的事情之间的因果关系。 如果有什么东西没有达到预期的性能，你就可以调查一下哪个环节发生了问题。”

为了将这两个领域紧密结合起来，我们付出了很多努力，例如将硬件调试器与流行的软件环境Eclipse集成在一起。 Sanie说：“当模拟时间光标在波形中移动时，相应的软件语句可以在软件视图中突出显示。 同样的，如果用户进入软件视角，则硬件视角中的仿真时间将自动同步。 用户可以在整个模拟时间范围内自由前进或后退。 用户还可以设置断点以快速跳转到感兴趣的点。 Verdi提供了一种自动建立波形和执行软件指令之间关系的机制，并允许程序员同时查看多个内核。”

出于对性能，功耗和其它架构方面的考虑，以及将多个IP内核集成到一个系统上之后的验证问题，硬件世界中使了用事务级别的执行和调试。Aldec硬件部门总经理Zibi Zalewski表示：“验证世界向事务级别的迁移对这一任务有很大的帮助。在消息级别工作对于软件开发人员来说也更自然，并简化了与硬件团队的合作。 拥有双方都能理解的通用数据格式是一件大事。 它还允许您将基于事务的协议监视器和检查器插入验证平台。 这不仅有助于调试，还能自动检测和缩小问题。 消息级调试无疑是现代SoC项目最常见的调试任务之一。”

Agnisys的Bakshi提醒我们，开发过程本身可能带来需要用户理解的意外。 “需要进行调试是由于设计过程中一步步细化的过程不够精确。 通常，产品设计团队从设计规范开始，将规范转换为IP或芯片。 当转换失败时，工程师需要追踪发现转换不正确的地方。”

上下文敏感性

验证IP在调试过程中有非常重要的作用。Sanie说：“如果你正在看一个协议，它必须是上下文敏感的。例如USB有一整套不同的数据包和接口，你需要将这些信息嵌入到调试环境中，让用户不必成为接口方面的专家就能使用它们，这是非常有必要的。”

断言在IP的集成过程中也非常有价值。Sanie继续说：“如果你没有以正确的方式使用IP，你可能会触发断言。断言还能帮助你标记以前遇到的问题，如果你尝试从6个月以前的波形中发现问题，那将是十分困难的，断言可以尽快的找到问题所在。”

具有上下文敏感的协议仍然不足以应付所有任务。Davidmann说：“当你试图调试系统级别的问题是你并不想关注太多的细节，即使它可能帮你节省一些时间，比如当你在驱动中遇到某些明确的问题时。但是当你调试软件的时候你总想站在最高的抽象层次上进行调试。你希望能够在系统级别或者应用程序级别上进行调试，因为这样你可以看到它们是如何相互作用的。这时候就需要将相关的技术内置到调试器中，让调试器知道有这样一个系统并将该抽象级别呈现给用户。这样用户就可以提出诸如‘哪个函数占用了最大的功耗？’之类的问题了。”

路桑说

不得不说路桑在写的一篇论文，关于系统监测和性能评估的解决方案跟这篇技术报道不谋而合。我们推出这些技术趋势的目的在于让小白和老白们都能认识到验证跟上下游的联系、协作的方向性。不少的verifier或者还满足于信号级的调试，也许有一些已经尝到了不少的苦楚，但又找不到更好的办法。在这篇技术采访中可以看到，提高抽象级是一个大的趋势。因为抽象级一旦提高了，上下游的工程师们就有了一致交流的基础，否则的话，那真是鸡同鸭讲，谁都看不上谁。同时，提高抽象级也能够应对日益复杂的硬件系统。

SoC现在的高度集成已经让硬件工程师吃不消，昨天还报出了CPU的漏洞，这个锅估计又得辗转到verifier那里。但是，作为verifier，我们需要清醒地认识到，现在验证的要求已经无法局限于信号级和事务级了，而还应该上升到驱动层、系统层和应用层。以后verifier的从事范畴会跨越到从系统架构定义（虚拟建模）到RTL实现（仿真、形式、模拟、FPGA）到硅后（测试），这需要一个更广义的验证团队，不只是人数的增多，还应该需要知识交叉融合，比如参与到了硅后测试阶段，与软件人员可以直接联系，有了软件的思维再来反哺到RTL阶段的仿真验证。

我们之前也谈到了各个验证工具之间由于技术和抽象级的不同，都有了各自的引擎和调试手段，但不同工具之间的调试手段同质化较重，而且与软件开发工具（Eclipse等IDE）之间还存在硬件调试和软件开发之间的流程断裂。简单而言，就是verifier不熟悉软件开发的手段，软件人员不懂使用硬件调试的方法。这种隔断的工作方式也软硬件协同工作一直成为大公司的技术顽疾。

在提出解决建议之前，我们可以回顾在这之前我们做了哪些验证平台的一致化努力？

• portable stimulus standard，便携式的激励标准还在制定中，但已有的工具都在尝试解决硬件验证和软件测试方法学中不同语言和抽象级的障碍。更多详情可以进传送门跨平台移植复用篇之一：Portable Stimulus Standard
  

• 跨平台验证方案，旨在联合不同验证方法对验证平台的要求，例如虚拟平台和RTL仿真、RTL仿真和硬件模拟器之间。一样这里有传送门跨平台移植复用篇之三（终）：跨平台的验证结构考量

• 统一的验证衡量标准。在硬件开发阶段，我们依赖代码覆盖率和功能覆盖率来量化，但是代码覆盖率需要另行寻找方法在硅后测试中收集，功能覆盖率又无法在形式验证中得到更多收益，更多的是，不同工具之间如何合并这两种覆盖率，而在硅后测试中，需要提前将覆盖率定义通过可综合的代码植入到硬件中，这与DFT的测试覆盖思想类似，可谓脑洞大开！关于覆盖率这一部分，路桑只能在著书的第二版中系统论述了。

那么除了从测试便携性（sequence/test）、平台复用性（testbench）和验证量化一致性（coverage）之外，调试（debug）也进入了verifier的痛点范畴和EDA公司的工具范畴之内。Verifier们确实不想因为切换了验证方法就再重新熟悉一套调试工具，因为这本身不会带来更多的收益而是受限于EDA公司的工具之间缺少统筹规划才买的单。

在这里路桑有一种预感，觉得Verdi这家伙能成事儿。它从出身就是为了设计调试纠错而生的，很多verifier都熟悉它，喜欢它，为什么？好用呗。提供了各种硬件的调试能力，而在OVM、UVM和工具被Synopsys收购之后，就逐渐转向了软件层面的调试能力，不但体现在类似软件的验证环境调试方面，其也逐渐推出了一些针对性的特性，例如面向ARM的多核调试跟踪特性，可以预见到的是，以后该工具会逐渐成为自下而上，逐渐弥补软件开发调试流程短板，成为链接硬件调试和软件开发的工具。

讲到这里，我们有时间可以再收集一下国内几家优秀EDA公司的发展现状和业务规划。在前端设计仿真领域内，国内EDA虽然是后发，但也有后发的优势，没有太多技术陈代包袱，只要有一个前瞻性的系统规划，例如10年以内大致的工具和特性推广战略，同时也能考虑如何解决我们上面提到的验证一致化的障碍，那么就会有自己的闪光点。这就跟网购是美国泊来的，但是阿里巴巴现在成为了全世界的一样。路桑希望未来的十年内会出现这样一家EDA公司的前端设计仿真工具可以同大陆的IC设计企业一起繁荣生长！