跨平台移植复用篇之三终跨平台的验证结构考量.docx

跨平台移植复用篇之三终跨平台的验证结构考量.docx

《跨平台移植复用篇之三终跨平台的验证结构考量.docx》由会员分享，可在线阅读，更多相关《跨平台移植复用篇之三终跨平台的验证结构考量.docx（4页珍藏版）》请在冰豆网上搜索。

跨平台移植复用篇之三终跨平台的验证结构考量

跨平台移植复用篇之三（终）：

跨平台的验证结构考量

在之前关于验证的各个平台介绍中，我们涵盖了包括virtualprototyping、simulation、formal、emulation和FPGAprototyping这几种验证平台。

除了formal需要较为不同于其它平台的算法和技术之外，其余的平台之间都天然存在着可以共通测试平台和用例的可能性。

接下来我们主要就目前已经为行业所应用的混合仿真或者跨平台的验证方式：

virtualprototyping与simulation的混合仿真simulation与emulation的混合仿真以及跨平台验证virtualprototyping与FPGAprototyping的混合仿真virtualprototyping于emulation的混合仿真

在介绍这些不同验证平台组合后的混合验证方法前，我们先来回顾这些验证方式的主要应用场景，以及在什么情况下需要这样的混合验证和跨平台验证方式呢？

virtualprototyping（由SystemC/C/C++构成）这种验证方式往往服务于在硬件RTL还未稳定前给软件开发提供一个早期的平台，便于软件可以在其平台上开发，解耦硬件与软件之间的依赖关系，使得软件开发可以较为提前，而不会严重依赖于硬件开发的进度。

simulation则是主要为RTL功能验证服务，使得在流片之前尽量保证硬件实现的低缺陷率。

emulation的速度较simulation要快10到100倍，同时由于它丰富便捷的调试特性，这使得它可以为性能测试提供平台，协助simulation的工作，另外一方面，它较为出色的性能，也能够协助post-silicontest，使得以往的流片以后的硬件单元测试可以在更早期完成。

这可以提前片后测试的工作，以往只有片后测试发现的问题（可能是致命的缺陷），现在便有了更多的机会在流片前暴露出来，可以说这种手段不但降低了风险和同时也减轻了片后测试的负担。

FPGAprototyping的性能较emulation又要高出一个数量级，然而它的调试性也随之下降。

从目前的应用情况来看，受限于它的partition、clocking和memory等问题，如果要下载到FPGA的系统越大，一旦出现硬件问题，需要调试的难度会与之倍增。

从FPGAprototyping中受益最多的客户是软件开发，一旦FPGA的环境建立起来，软件开发即可以在流片前从virtualprototyping转换到FPGAprototyping上，而由此带来的不但是性能的提高，同时也是将前期开发的软件在“接近”真实的硬件逻辑上进行测试和后续开发。

通过上面对各种验证方式的梳理，读者其实可以看到这几种验证平台之间存在的交叠的情况，或者说，验证平台之间可以作为互相的补充，为彼此收益，继而从更高的层面实现硬件的加速验证和软件的早期开发。

这些互为补充收益的关系表现在：

virtualprotoyping的高抽象级硬件原型可以在simulation阶段作为referencemodel，从而节省testbench开发的时间。

或者某些virtualmodel也可以在早期RTL的一些硬件设计还未发布之前，嵌入到RTL系统中。

无论是virtualmodel嵌入到testbench或者是RTL系统中，都需要实现virtualprototyping与simulation之间的协同仿真。

simulation与emulation之间有着天然的联系，这表现在两者之间不但都有着丰富的调试特性，还有着验证测试用例在不同平台上实现的跨平台运行的可能。

例如SV/UVM/C的测试用例可以从simulator平台移植到emulator，这种跨平台的复用不但节省了时间，也将这两种验证平台紧紧绑定在一起，更好地为前端验证服务。

无论是跨平台验证的复用问题，还是simulation与emulation的混合仿真，都离不开testbench的重新考量，使得一个testbench可以实现这两种验证平台的公用。

virtualprototyping往往较RTL开发更为早期，使得软件开发可以在前期准备一些算法和通用的软件开发（面向处理器的软件应用），而更底层的硬件驱动，则需要由RTL稳定之后的FPGAprototyping来实现。

因此从virtualprototyping到FPGAprototyping的切换显得很自然，而且主要是为软件开发服务，同时这一切换有时候也有混合prototyping的需要，即virtualprototyping和FPGAprototyping的混合实现。

virtualprototyping与simulation的混合仿真在上面提到的virtualprototyping中的SystemCmodel嵌入到RTLmodel中时需要考虑下面的一些问题：

尽管SystemC的建模抽象级可以到pin一级，然而通常的SystemC模型并不会将边界具体到pin一级，而是采取TLM通信的方式。

这就使得当SystemC模型要嵌入到RTL系统中时，需要为其准备RTLwrapper。

该wrapper（（SVmodule）的作用即是将RTLinput转换为TLMinput，或者将TLMoutput转换为RTLoutput。

这种转换需要TLM的非时序性到RTLpin的时序性关系的映射。

即便完成了RTLwrapper，使得嵌入之后可以完成RTLpin到TLM之间的转换，仍然也要考虑SystemCmodel本身的时序精确性。

由于RTL是cycleaccurate模型，而SystemCmodel往往是loosetiming模型，这就对RTL测试用例本身提出了要求。

那就是，测试用例本身不能严格检查SystemCmodel的时序，而主要关注与内在的逻辑关系，例如registeraccess、dataformat等。

在上面谈到的SystemCmodel到RTLmodel中的混合真正存在的限制，在SystemCmodel到SV/UVMtestbench中的混合仿真中就不存在了。

这要感谢UVM的TLM2的通信接口与SystemCTLM2通信接口之间的天然对接，以及双方均侧重于transaction级别的通信验证方式。

关于SystemC在UVM环境中的混合仿真接口应用，我们将在下一章《SV及UVM接口应用篇》中详细介绍。

virtualprototyping与FPGAprototyping的混合仿真再来看看virtualprototyping与FPGAprototyping的混合仿真方式。

如今，开发者使用的基于TLM通信的virtualprototyping和物理方式的FPGAprototyping较为独立。

前者可以在RTL开发之前就准备好TLM环境便于软件开发和调试，而FPGAprototyping则提供了更精确、高性能和与真实物理环境的接口。

那么将这两者进行混合，为带来什么不一样的呢？

这种混合方式在于更早期能够建立模型，同时又能够与真实世界的物理接口完成连接。

可以将SoC系统进行拆分（partition），分别实现到virtualprototyping环境中和FPGAprototyping环境中，使得整个prototype的性能最大化。

由于可以将processor子系统整个都划分到virtualprototyping环境中，从而提高调试的可视性和软件的可控性。

这一优势很好地弥补了往常依赖于硬件processor子系统的开发周期以及在FPGA上进行软件调试的各种限制（例如无法设置断点、查看寄存器等）。

由于目前processor子系统很大一部分都在使用ARM系列，而为此开发的ARM系列virtualprocessor模型、AMBAtransactor以及其它验证IP分别在virutalprototyping和FPGAprototyping两个平台之间的快速建模使得系统建模更加简单。

这些主流的验证平台存在于三大EDA公司完成的工具套件上，而且他们也在针对跨平台的验证效率提高提出一些类似的实现方式。

例如上图中Synopsys就针对自家的virtualprototyping平台Virtualizer的开发环境套件VDK与FPGAprototyping的开发套件HAPS系列提出了混合建模的方案。

从建模的通信方式来看，是基于AMBATLMtransactor以及与真实世界的UMRBus，而模型的构建采取的是Virtualizer与ProtoCompiler，运行时的分析调试手段则依赖于ProtoCompilerRTLDebugger和Virtualizer。

从Synopsys给出的一个典型的SoCprototyping混合建模解决方案来看，其关键在于需要将整个SoC进行合适的拆分。

有了合适的拆分，就能进一步为软件开发提供更易调试和更早期的环境。

正如之前介绍的该混合方式融合了两种prototyping的优点，软件开发不但可以通过更快构建的virtualprocessor来进行软件调试开发，也能够在早期实现同真实世界例如PHYs和测试设备的连接。

这种混合方式给了开发者更多的选择，使之可以在TLM级的SystemC模型和RTL模型之间进行选择，而伴随着项目周期，又可以实现这些模型在两个平台之间的移动。

要实现这两种平台的高效混合仿真，高性能的通信方式是一个重点。

除了要考虑同物理世界的通信连接，在virtualprototyping与FPGAprototyping之间的连接方式，这里主要采用了AMBA通用总线例如AHB/APB/AXI3/AXI4等transactor（C++library），完成了从virtualprocessor到FPGA一侧的高效通信。

如果用户对于这种混合建模的方式感兴趣，可以从Synopsys的官方介绍中获得更多的细节。

当然，这种混合建模方式也存在于其它EDA公司的解决方案中。

simulation与emulation的混合仿真emulation之所以可以作为simulation的好伙伴之一就是，它俩的仿真速度差距没有差到太远，以至于emulation根本无法“带动”simulation一起仿真。

换句话来讲，如果我们对simulation的环境做出更好的优化，则可以实现simulation与emulation在混合仿真的情况下，simulation不会拖emulation太多的后腿。

在平常的仿真模式下，无论是testbench还是design，都有相当多的时钟驱动进程块，这些活跃的时钟进程块正是拖慢整体仿真速度的元凶。

而当我们有条件将design的部分都移植到emulator一侧后，design则要比之前在simulator一侧运转得快得多，这要归功于硬件上的仿真加速。

但在这种co-simulation模式下，原本的testbench运转方式如果还是基于时钟的事件交换方式，则不能再跟上design一侧的速度，这样就会明显拖慢整体的仿真进程。

这里读者需要注意的是，在simulator一侧的testbench和在emulator一侧的design，它们之间的通信如果基于testbench一侧的时钟进程块，则就会使得design只能放慢太多的速度，等待simulationy一侧的速度。

所以，无论是我们在这里就MentorGraphics给出的混合仿真加速方案TBX，还是Synopsys和Cadence给出的解决方案，对于本节中提到的混合仿真，首要考虑的就是不同仿真平台的性能调和。

简单来看，性能上的调和就是慢的一方必须