依稀还记得今年SNUG上海参展时，关于2017版本的VCS已经内生支持了并行仿真，而且从卖相来看来颇具吸引力。作为一个暂时也没有应用过VCS这个特性的吃瓜群众如果从科普的角度来看，就是说VCS最新的工具版本已经可以支持通过用户自行编译，工具自动编译分析来得解构链接模型，使其可以在多核上面进行仿真。那份介绍时的报告我当时记得拍了照片，大致来看就是模型越大效果越明显，这就对于SoC肥胖式仿真很有吸引力。那么这种并行式的仿真在计算机结构上面有了很久的历史，为什么之前一直无法运用到仿真领域呢？

呵呵哒，并不是不想，而是从AE的介绍来看，很久之前就做过尝试，然而以前的仿真引擎架构对于并行仿真计算支持得不好，而待公司从外面挖来一个专家对架构重构以后使得并行仿真性能得到了"可以单独贩卖"的水准，恩，就是酱紫，然后这个feature就单独推出来了，而且从AE口中可以得知，这个feature除了要单独购买license之外，还可以享受到加速定制的服务。AE会在编译器给出的默认生成配置上，继续进行优化，直到性能得到最好的提升。额，突然觉得有钱真得可以买到好多服务，而且是”第二最好“的。为什么是”第二最好“呢？因为路桑依然觉得，最合脚的，还是要独家定制的，当然性能和效率之间的比较，是EDA提供得出色还是自己做得漂亮，那还要具体情况具体看待。

我们本次来看得这篇论文来自于AMD上海的同仁，从论文的摘要和结论来看（也包括近些年AMD上海的论文），问题的出发点都无不与它的业务领域相关，那就是重IP验证，再考虑从大型IP到各个SoC级别的垂直复用问题。简单来将，文章想说的是如何实现从IP级的验证系统到SoC级别的复用和加速问题。相比较而言，本文的重点侧重于加速，是为了实现加速，继而复用了IP级别的验证环境。有兴趣的读者可以下载原文来看看，或许对你有启发。

路桑接下来试图还原文章的问题提出、问题分析、问题解决，最后给出一点评论，以供技术消遣。

问题提出：

• 从IP验证（各个IP）到最后的SoC级别过程中，速度是直线降低的。如何让仿真器负重这么多还能跳起舞来就是一个有意义的命题。

• 同时，就现有的集成经验，IP环境要集成到SoC系统还要做不少的移植工作。另外在一个SoC环境中往往存在好多个IP环境，那么如何协调，如何使得可以取得更好的整体性能也要顶层环境架构师考虑这样的问题（路桑也在为此头疼啊，每个SoC环境都要为此一个月难产加班，协调各个IP验证模块真得伤不起）。

问题分析和解决：

• 这篇论文一改通常的IP环境拼盘的样式，不再哭着喊着要将IP验证模块都集成到一起（如果是标准IP环境还好集成，如果来自于不同风格的verifier，那么集成精力和功力的要求得加倍/(ㄒoㄒ)/~~）。

• 那么有没有可能让原有的各个IP验证环境可以不加修改，就直接嵌入到顶层环境呢？换句话说，就是让各个环境各自为政，互不干涉。等等，喂喂喂，吃瓜群众可能会问，我没文化不要骗我，路桑你不是讲，顶层环境在整个测试环境中应该只有一个吗？root层下应该只有一个test，继而一个env..昂，是的，可这篇论文讲得是，让各个验证环境独立运行在各个独立的处理器上面。恩，蛮好玩的话题。

• 要解决让不同仿真运行在独立的处理器上，需要解决下面几个问题。

• 首先就结构层面，不同处理器上面可以运行各自的验证环境（env+IP hardware），那么如何实现各个独立仿真进程和主要的TB进程之间的同步呢？本文通过UVMC（UVM connect）实现了进程间通信（IPC inter-process communication），即将SystemC通信代理内置到原有的IP验证环境中；另外一方面，UVMC可以结合ZeroMP实现不同独立仿真进程之间的通信问题。那么这样的方案可以具体解决什么场景呢？如果IP验证环境同主要的TB之间独立运行，那么TB中也会置入UVMC通信代理，用来捕获总线传输事务，然后通过ZeroMP将消息发送至独立的IP验证仿真进程，而IP仿真进程的UMVC代理接收到之后会通过总线UVC将其翻译为硬件时序行为，送至真正的IP硬件。额，可能听起来有点绕口对不对，简而言之，就是这样一个跋山涉水的过程实现了独立仿真进程的通信问题，继而使得并行仿真从理论上成为了可能。

• 其次，从UVM仿真的phase调度来看，也有同步的需要。这解决的问题时，尽管独立的仿真进程更加不受拘束，无忧无虑，然而仍然需要从全局进行phase的整体调度。这就需要一个独立的phase协调服务进程（phase alignment server process）来同步独立仿真进程之间的UVM phase。如果不这么做的话，路桑可以负责任地告诉你，会有各种surprise等着你，而且蜂拥而至 - 囧。

• 再者，添加UVMC进程通信代理还会带来一个问题就是使得timing变得宽松（loose），因为信号的捕捉和传递不再是时钟级别，而是transaction级别，这就使得对于一些严重依赖于timing的测试用例无法在这个方案上面测试。不过，在SoC级别的测试大范围的都属于应用或者性能层面的测试，一小部分对于时序检查严格的测试可能就需要使用传统的SoC验证平台结构，即不使用这种并行的仿真方案，而是只有一个SoC TB，DUT即是整个SoC。那么问题又来了，如何实现这两种测试平台之间的切换？昂，配置文件、编译选项就是用来搞定这个事情的，不过，还得花费精力是实现验证平台的灵活性。

结果展示：

• 在性能分析方面，文章从发包所需的时间和端到端的延迟两个方面来说明，添加了IPC通信代理和总线UVC之后对性能数据的分析都有影响。不过，文章似乎并没有将实际硬件性能在这两方面的数据同本方案的数据进行比对，当然即使比对也并不能说明什么问题，因为如果要严格测试性能，仍然需要依赖于单验证环境的方案才能得到准确数据。

• 从仿真速度来看，首先编译时间没有多少改善，而从关键的仿真时的负载来看，本案的并行仿真，使得两个独立仿真环境将原有环境的负载一分为二，而且几乎平分，而从仿真速度来看，整体性能也相应地提高了近一倍。这样计算的前提是假设主要活跃的进程是SoC TB端，也因此将并行后SoC端的性能与未被分离前的SoC TB性能进行比对。

  
  

路桑说

• 本‘案的可贵之处在于提供了一个完整的并行仿真方案，而且从性能来看也有显著的提高。从垂直复用的角度来看，使得UVM结合UVMC、ZeroMP可以来实现各个IP验证环境到SoC系统的分散式维护（解放SoC验证架构师，让他可以早一点下班喽）。

• 不过文章在最后也点明了，本案还并未推广经验实现到实际的SoC项目中去。这一点也再正常不过，因为从IP的经验出发，除了有特殊的历史原因以外，要将经验推广到整个项目中，还得考虑几个重要的部分，那就是时间和人。时间方面的话，该种方案从采纳到被使用，需要额外引入多少精力；人力方面来看，这也提出了不小的挑战，其它同事还需要学习UVMC和ZeroMP，继而将这个长而复杂的进程间通信链路移植到原有环境。从这两点来看，要大规模推广，本文的方案还不够轻便化，或者换个方式来讲，如果可以将UVMC和ZeroMP整体打包，或者将IPC通信代理可以做成针对不同总线UVC的可复用包，也能够在SoC团队内部大规模使用，那就可以扩大它的价值。

• 那么在VCS这些EDA大魔王提出了内生的并行仿真加速方案之后，本案在加速方面的价值就需要考虑人力投入和产出回报的性价比了。而本文在IP到SoC验证环境的复用依然是个新颖的例子，毕竟这种并行式独立仿真的模式路桑之前也设想过。而对于复杂SoC模型的解构如果能自动化，那么就完美了，但EDA工具商提供仍然是对于以后标准验证环境的拆解加速，也就是编译器通过运算分析，将SoC结构自动分配到几个处理器上面，依靠升级的引擎实现整体的并行加速，但依然不能提供在一个仿真环境中实现多个并行独立的UVM环境。当然，这也恐怕难为了EDA厂商，从应用层面分析，这种高级的应用场景最好的解决方案是提供一个基于UVM的多环境支持软件包。

• ...嗯哼，一个基于UVM的多验证环境并行运行的软件包，这样一个有趣的论文话题就想出来了。

先就讲到这里喽，火车还在返回家的路上，今天在成都的方所书店买到两本不错的诗集，在到家哄大蒙喂小蒙之前，还能有点时间读一读。