提升
仿真速度，一直是各EDA厂商努力的目标，原因自然都是
time to Market。但是，既然已经有了非常快的硬件仿真器（如Z1），以及比非常快更快的
FPGA原型验证环境（如S1），为什么还要提升Simulation的速度呢？这个问题暂且放一放，我们先思考另一个问题。
在Formal、Simulation、Emulation、FPGA Prototype中，验证工程师会选择哪种方法作为其最主要的验证手段？
我相信大部分的验证工程师会说：Simulation。因为：
Simulation 的验证方法最完备（功能覆盖率、代码覆盖率等）；
Simulation 的验证积淀最深厚（Feature List、Checklist、VIP等）；
Simulation 的验证流程最成熟（版本管理与发布流程等）；
Simulation 的验证平台最可控（验证组件修改方便）；
Simulation 的验证环境最可视（查看波形，打印信息等）。
Simulation 在整条产业链中，涉及到芯片项目中如版本管理、项目沟通等方方面面内容，因此具有一定的不可替代性。对Simulation进行加速，非常必要。
多核并行如何让仿真快起来
Linux工作站一般使用的是64bit通用的处理器。通用处理器处理的是通用的业务，在工作站上，我们会运行仿真，也会做综合，会做布局&布线等各种工作。通用处理器不会像GPU那样，基于图像处理那样的特定任务，做针对性的指令优化（如指令集并行ILP）。因此，EDA厂商只能从仿真的算法上下功夫。
上图中，左边“Dependency Graph”为“依赖图”，即某些程序的启动，依赖于之前程序的结果。基于Xcelium的算法（Algorithm），在不违背数据依赖关系的前提下，仿真验证过程可以被分配到多个核上去执行。
至于Xcelium如何实现将程序分配到多个核去执行，研讨会推荐的材料，给出了一些提示。在研讨会推荐的第二篇文章《Four Keys to Successful Multicore Optimization》中，提到了“Multithreading is especially well suited for multicore PCs（多线程特别适合多核程序）”。通过应用优化（application optimization），算法优化（tool optimization），系统性能调度（tuning for overall system performance），以及软件对核个数的适应性（software portability）共4种方法，达到性能的最优。虽然文章的例子不是仿真验证，但是基本思路估计是一致的。
核数并非多多益善
《Multicore Processors Create Software Headaches》是2010年4月20日MIT的一篇文章（研讨会推荐的第3篇文章），其中，介绍了多核软件面临的问题。其中，引用了当时惠普的副总裁的观点：“如果不解决程序的问题，用户无法从更多的核中获得收益”，因为，写出高效和稳定的多核程序，是一件困难的事情。本文的结论是，五年以内，很难有面对多核程序友好的编译器（compiler）。不过，从这篇文章算起，已经过去了7年，多核程序的编译器应该获得了一些成就，厚积薄发，才有了Xcelium这样的仿真工具。
但是，程序本身的“依赖关系”是很难破除的，程序的优化能力，受技术限制存在上限。这应该就是研讨会上，推荐使用并行8~10核的原因，更多的核很难良好的调度。
研讨会上，还有工程师提问是否可以让程序利用不同工作站上的核，达到更大的并行，答案是不推荐。因为跨设备之间的程序并行执行，比单设备的程序并行，又复杂了不少，单就软件调度而言，其额外增加的开销，可能就可以抵消多核带来的收益。
总之，单个服务器内，提供8~10个核做并行处理，是对Xcelium“恰恰好”的一种配置方式。
单双核任务划分
Xcelium并非可以对所有仿真程序进行加速，某些行为级模型就是在单核上执行。我对Xcelium的理解是：一个单核作为主核进行行为级模型仿真，并调度多核；其它多核作为副核进行RTL、网表等仿真，实现多核仿真加速。
单核的范围包括：testbench（如UVM），low power（低功耗），mixed signal（模拟数字混合信号），VHDL；
多核的范围包括：gate-level（门级），RTL，X-prop（X态传播），以及SVA等。
其中，Xcelium将SVA与testbench独立出来，可以使SVA获取更大的性能提升。对验证工程师来说，非常有益。
另外，Xcelium会自动完成单/多核的划分，不需要人工参与，用户不用设置哪些功能在单核模式执行，哪些功能在多核模式下执行。
单双核切换
本节的切换，可以理解为两个概念：
1、原有的单核验证环境（Incisive），切换到多核验证环境（Xcelium）；
2、仿真过程中，资源不够时，本可以多核运算的程序，还是放在单核上执行；资源增加时，原本在单核上执行的多核程序，重新被分配到多个核去执行。
对于第一种验证环境的切换，需要做的事情不多，基本上仅需要将脚本中的irun，修改为xrun；
对于第二条根据资源情况，动态切换，我认为如果仿真器做的更优秀的话，应当支持该功能，会非常有利于工作站的资源管理。
不过，我目前的认知是：“Xcelium资源一旦分配，如果线程没有执行完成，与该线程相关的CPU资源不会被释放” ，即不支持处理器资源占用动态可调。
算法适应性
Xcelium根据算法，对仿真验证程序进行优化。而这个算法，对不同的程序，优化效果是存在差异的。一般的经验数据为：
1、RTL仿真提升3X的速度；
2、门级网表仿真提升5X的速度；
3、门级完备+DFT仿真提升10X的速度。
对于不同的业务，其加速比率也不相同，事件密度较高的场景，往往可以获得更大的性能提升。例如，多核SOC仿真，在RTL层面，就可以达到5X的提升。
磨刀不误砍柴工
仿真程序需要根据Xcelium的算法合理的规划。而这个过程，需要对仿真程序进行深入的分析，做细致的分解。这些工作都会消耗编译的时间，即使用稍多的编译时间，换取更快的仿真速度。
别小看单核
此次Xcelium的升级，不仅仅是多核并行仿真，而是一次显著的升级。除了多核提供的仿真速度提升外，单核也提升了仿真速度。根据场景不同，可以获取平均2X的速度提升。在某些场景下，甚至可以达到3.9X的仿真速度提升。
总结
Xcelium有可能采用了多线程的仿真加速方法；
Xcelium根据设计不同，可以提供3X-10X的仿真速度提升；
Xcelium的单/双核划分是自动化的；
Xcelium的验证环境可以方便的从Incisive获取；
Xcelium的单/双核的资源，还不能自由调度；
Xcelium的仿真加速特征值为：RTL-3X，GLS-5X，GLS-DFT-10X；
Xcelium的推荐核数为8~10颗；
Xcelium需要对程序进行深入分析，即用编译/细化时间，换取仿真提速；
Xcelium的单核性能，也得到了显著的提升。
原作者：吴杉 IC VEngineer
