由SystemC/C++实现的系统级模型（SLM，System Level Model）可以提供诸多好处，尤其在一些复杂数据处理算法的应用上面可以提高算法模型的快速实现。又比如信号和图像处理的应用也经常会使用SLM来建立模型。不过呢，与SLM相对照的的RTL模型在实现时，经常会有不少的延迟，除了需要额外的人力实现以外，较长的仿真时间也使得在后期验证算法性能时候受到不少阻碍。而untimed SLM或者loosely timed SLM，这两种较少规范时序限制的模型除了可以显著加速仿真，尽早使得SLM投入到前期性能和软件开发之外，还可以通过高层综合工具（HLS，High-Level Syntheiss tool）来自动生成RTL的代码，使得更高层的系统设计人员只要在了解规范化的SystemC/C++可综合代码以后，就可以将算法实现到抽象了的SLM中。而在利用HLS时，只需要进一步关注系统层面的几个标准，即面积、性能和时序的要求。这么看来，SystemC可以尽早进入硬件构建阶段，横跨结构设计、硬件实现、软件开发，可以说很好地实现了shift-left策略，即将软件开发尽早介入到硬件开发阶段，利用SystemC/C++模型来进行基于虚拟原型系统之上的开发，同时，又因为统一模型源的原因，RTL代码和综合网表都可以基于SystemC/C++来得到，看起来是有百利而无一害？

真是这样的吗？我们是不是漏掉了哪一个环节？没错，功能验证找不到介入的时间点和位置了。一般来说，目前的验证方法学都是基于RTL层面或者网表层面的，还没有尝试迁移到SLM上面。面对HLS的流程，验证层面需要开脑洞了。如果HLS被越来越多的公司买单（还好，这还没有成为现实，不然不少verifier得领盒饭了），那么验证的流程需要改变的选择有以下几种可能：

• 将现有的验证方法学迁移到SystemC/C++一侧，这可能使得出现更多的例如UVM Connect插件的，或者直接基于SystemC/C++的UVM新的库模式，使得SV和SC可以更好的互相兼容，继而在仿真器或者virtualizer工具上面实现仿真。这是方法学和两种语言的融合过程，为的是保证测试平台在开发过程中的复用性和测试用例的可移植性。对于EDA公司来讲，是一个“左一点”的过程，即逐渐往SLM一侧偏移重心的过程，对于verifier而言，除了要学习SC之外，也需要应变“左一点”的验证策略，逐渐适应先从SC开始构建验证平台，继而复用到RTL层面。不过SC和RTL两个层面的验证侧重点会有很大不同，前者往往是不注重时序而注重功能，后者则可以重点关注集成时模块之间的交互时序等方面。

• 另外一种可能则是会出现强化了SLM阶段的“软件测试”过程，这样的话，软件和硬件的门槛可能就进一步打破了，大量的软件测试人员会破门而入，他们即便缺少RTL、时钟、时序等重要的硬件知识，也完全可以依赖软件测试观点来实现测试。那么现有的verifier除了可以选择“往左一点”学习软件测试知识之外，也可以待在原地，因为RTL阶段的时序验证仍然不可避免，不过RTL的验证工作量会因此减少很多。Verifier至此，除了将自己的知识领域再拓宽到SLM级的软件测试领域之外，似乎再没有更多的选择，一个字“苦”。而且这种可能的职业领域衍变会彻底改变验证目前在RTL领域的侧重，也由此开启了验证更加软件化的方式，不过，同样苦的人也包括硬件设计人员吧。

以上两种可能的转变无论是哪一种，目前都没有广泛实践后的流程或者方法学，究其原因还是HLS主要还停留在少数的设计公司和EDA公司的推广阶段，买单的人还不多，不过依然值得大家的注意，因为一个重要的风向就是SLM的应用伴随着在跨平台验证（仿真平台、模拟平台和FPGA）上的优势和在早期软硬件系统的特点进入了不少大公司的视野。至于SLM开发的人和RTL开发的人在几年以后会不会在各自利益上殊死搏斗，值得一边吃瓜一边下注。

那么在暂时没有好的SLM验证流程的时候，来看看verifier这个时候可以自己提出一些什么东西来提高自身的话语权。理论上看，门级验证的效率低于RTL验证，而再次之于SLM测试。当正如之前谈到的，这三个不同阶段的验证暂时缺一不可，再讲一遍，缺一不可。也就是说，如果照顾到了SLM的“左一点”的优势，将硬件设计向左偏移到SLM级别，那么verifier需要照顾的领域也就更宽了，因为又需要重新考虑验证平台的一致性、测试用例的移植性和不同级别（SLM，RTL，GATE）在验证目标上的侧重。

另外一方面，现有的SC语言缺少像SV必要的coverage定义方式、random约束和产生机制等重要的方式，这就造成了SC天生是侧重于系统侧面的应用测试，或者更高层的测试，同时由于SC/C++在调试方面的短板，使得verifier很难在SLM阶段捕捉到所有的功能漏洞。所有这么看来，比较理想的是一套跨SLM、RTL和GATE的仿真测试平台，但在不同的开发阶段需要有不同侧重的测试目标和用例来对应。

讲到这里，一个有趣的话题是，除了仿真平台需要进一步延展到SLM阶段，还需要考虑如何实现SLM和RTL之间的覆盖率收集和合并，以及一些现有的EDA工具也需要延展到SLM阶段。比如形式验证和Linting工具就是一个很好的例子，原有的形式验证工具和Linting工具都是针对于RTL的，那么硬件开发阶段一旦迁移到SLM侧，意味着什么？当然是机会了，比如Onespin现在做的将原来用于RTL linting的检查同时也可以支持SC的可综合linting规则，协助检查一些潜在的SC编码问题，例如变量未初始化、死锁等问题；再比如原本用来做ECO之后必要的一步LEC（逻辑一致性检查），在引入了SLM之后，因为面临着每次不同的area/timing/performance的要求，使得同一个SLM在经过不同的综合target之后会生成不同的RTL代码，为此将不同的RTL代码之间做sequential LEC（时序性一致性检查）就又成为了新的话题，这里要注意了，sequential LEC不同于往常的LEC，因为前者面对的不再是时序相同的两个功能模块了，因此检查的方面将着眼于功能和时序两个部分，例如由于不同target使得HLS流程生成的两组代码A和B，A的性能要优于B，那么A的FIFO/MEM要优于B，而时序和位宽也可能优于B，那么这种sequential的LEC检查就不同于往常的LEC了，因为就逻辑而言，两组的逻辑是有显著差异的，在这一方面，Cadence就走到了前面。

Anyway，路桑言归正传，回到本文的话题，先来看看目前SLM投入项目实际应用的模型有哪些呢？

• 有的时候做的算法是MATLAB/Simulink的模型，然后再自动产生C++代码，这些算法代码会由designer来理解继而人为实现成RTL代码。

• 又比如在开发算法的时候直接由SC/C++构建，由于这些代码很可能无法实现HLS综合，因此需要进一步修改为可以HLS综合的SC代码。

• 还有的时候，designer和虚拟建模（virtual prototyping）的两组人马是分开的，那么RTL designer在实现代码之后，由SC建模人员再反向抽象为SLM，继而实现虚拟模型系统协助软件人员进行开发。

• 在有了可HLS综合的SC代码之后，这些代码可能是untimed，loosely timed或者cycle accurate级别的模型，都可以通过HLS来自动生成RTL代码。

不过需要注意的是，HLS工具提供商往往指定了一套自己用来识别可综合SC代码的规范，例如Cadence Stratus的cynw_开头的代码前缀或者NEC Cyber-Workbench提供的ap_开头的代码前缀，与SC一般的sc_(u)int相比，不同的HLS工具对于可综合的SC代码仍然有自己的规范。

那么从这么多的SLM应用模型来看，verifier需要准备什么呢？如果SC的触角逐渐紧密延伸到RTL层，那么如路桑之前提到的，软件开发人员就会就可以更好地进入到硬件早期的一侧玩耍，软件测试人员也有了广阔天地，而verifier可以撸什么呢？

如果不想死，就只能适应变化，这是每个工程师被动或者主动需要做的。从上面这张图来看，verifier除了依然需要在RTL层面进行验证，还需要在早期和SLM designer一起进行非时序层面的功能测试，目前这一部分还没有相应的标准和方法学。也就是说，verifier需要完成转型，再左一点，更彻底地左一点成为软件测试人员，同时还能精通RTL阶段以后的仿真调试，只有这么大包大揽才能保障自己的地位。

不过，反之看一下designer就没有现在这么具备优势了，因为SLM到RTL的代码是自动输出的。如果采用了SLM流程，那么几乎没有designer在RTL阶段的什么事儿了（DFT是另外一码事），但是verifier需要照顾RTL阶段的验证环节。因此一个最悲观的预测是，designer需要转换为SC coder，继而在更高的层面进行可综合的SC输出。考虑到输出的层次越加抽象，一些常见的FIFO，MEM，算法模块都可能直接从库里引用提取，设计的工具也逐渐会朝向软件化。如果硬件研发的科技树朝着这个方向走，那么AI介入恐怕不是不可能了，希望那一天能晚一点到来，至少能在路桑退休之后吧。

下一节可能会专门谈一谈SystemVerilog interface class的特性，或者其它UVM比较偏门儿的组件，如果你有什么想让路桑谈的，可以留言收集20个赞。

谢谢你对路科验证的关注，也欢迎你分享和转发真正的技术价值，你的支持是我们保持前行的动力。