一种支持SOC设计全流程开发的软件和硬件协同仿真系统的制作方法

一种支持soc设计全流程开发的软件和硬件协同仿真系统
技术领域
1.本发明涉及集成电路技术领域，具体为一种支持soc设计全流程开发的软件和硬件协同仿真系统。


背景技术：

2.随着国家对集成电路(ic)产业的投入和支持不断加大，近年来fabless(无晶圆)公司越来越多，虽然大家做的方向不尽相同但是对于所有的设计公司而言遵循的是同样的开发流程如图1所示，其中搭建仿真和验证平台是一项必不可少的重要环节。从图1可以看到一个soc(片上系统)芯片的设计通常包括9个环节，去掉项目一开始方案的制定和规划环节，流程又可以分为两个开发阶段，分别是front end和back end，其中几乎每个阶段都伴随着对仿真和验证的需要。正是由于仿真验证环节的存在才能把控复杂的控芯片设计的质量，才能最大限度的控制设计中引入的缺陷，保证后续生产出来的芯片可以正常工作。随着产品功能的不断提高提升，芯片上集成的处理器数量和ip(intellectual property，直译为知识产权。在集成电路设计中，ip核是指已验证的、可以重复使用的具有某种确切功能的集成电路设计模块)数量也在不断增加，同时ip本身的复杂度也在提高。如果可以将芯片中各个ip考虑成一个组合矩阵中的单元，那么每个单元的复杂度提升对于整个芯片来讲将造成仿真和验证难度的指数级提升，所以仿真和验证占整个芯片设计流程的比例越来越大。目前验证的工作量已经占到了整个soc研发周期的70％到80％。这是因为soc的集成开发速度随着ip技术和工具的发展得到显著的提高但是对验证工作而言一直没有捷径。随着soc芯片规模越来越大这对仿真验证工作的时间和人力都是极大的挑战，一个团队中开发工程师和验证工程师的比例通常达到1：3甚至1：4。所以提高芯片验证的效率已变得至关重要，soc开发流程中拥有一个强大、高效、灵活、可扩展性好的验证系统是芯片成功的关键。
3.从交付物来看ic设计就是把芯片产品系统方案的内容转化为rtl(寄存器传输级)代码，再把rtl代码转为netlist(门级网表文件)，最后把netlist转换成二进制的gdsⅱ文件交给foundry(晶圆代工厂)，由foundry代工生产出实际的芯片，这个转换流程如图2所示。所以现在专业的ic设计公司都有自己专门的芯片仿真验证团队。团队的工作就是针对流程中不同环节(如图1所示)交付的dut(design under test)搭建相应的仿真平台并进行仿真验证，尽可能的通过仿真验证的手段来保证如图2所示的转换流程，确保各个环节在转换中引入的问题都在可控范围内，使缺陷收敛到可以流片的标准，然而，目前的芯片的仿真验证系统平台都存在各种各样的问题，模块级的开发涉及到的技术很多，不同的模块用到不同的接口和协议，由于验证工程师的水平和经验的差异每个人花费的时间就不相同，经常会出现接手的工程师要花费大量的时间去研究前人搭建的仿真验证平台，看似以前项目留下了经验积累却无法有效的提升工作效率，还有同样是使用uvm方式搭的模块级仿真验证平台但是平台的组织结构和使用方法却各不相同，这必将对技术的传递和继任者的使用带来不便。所以在整个soc的开发流程中搭建模块级验证平台的工作量依然无法得到有效的控制，而且产生的劳动成果也很难得到继承和复用。另外系统级的平台一直和模块级平
台存在天然的隔阂。原因是系统级的软硬件协同仿真平台需要根据使用的处理器对相关软件环境的进行处理，最终搭建成一种不带操作系统(bare metal)的软件环境用于处理软件激励从而实现软件和硬件的融合。虽然这种方式是最接近实际芯片的一种仿真手段，但是由于平台独特的结构特点和传统的模块级平台一直无法统一。


技术实现要素：

4.本发明的目的在于提供一种支持soc设计全流程开发的软件和硬件协同仿真系统，以解决上述背景技术中目前工程中使用的仿真和验证系统不管是模块级还是系统级都存在严重的缺点无法高效的支持soc芯片的开发的问题。而对一个soc项目来说不管是人力上的投入还是工程时间上的消耗都希望得到有效的控制，因此克服以上仿真验证系统的缺点必将带来巨大的效益。
5.为实现上述目的，本发明提供如下技术方案：一种支持soc设计全流程开发的软件和硬件协同仿真系统，包括testbench，testcase和result，所述testbench的内部包括有software和hardware，所述testcase的内部包括有software、hardware和uvm，所述result的内部包括有wave、log和coverage；
6.testbench：该testbench中存放的是仿真和验证系统用到的一些公用的内容，这一部分内容由本系统专职维护人员来负责，团队中的其他验证工程师不需要关注。这一部分中又可以分为两个部分按照对软硬件的支持划分为software(软件)和hardware(硬件)，分别负责对系统中软件环境和硬件环境的处理；
7.testcase：该testcase和testbench同属于仿真验证系统的一部分共同构建成仿真环境。不同的地方在于testcase可以由系统使用者自由构建激励。由于testbench已经准备好了完善的hardware和software环境，此处验证工程师具有很高的灵活性，可以充分利用软件和硬件的方式来产生激励，并且testcase中预留了uvm的部分给验证工程师灵活的构建sequence，作为对testbench中hardware的uvm sequence的补充。所以本系统的激励有三种类型可选，验证工程师可以根据需要决定选择其中的一种、两种或者全部类型去构建并实现各种复杂场景的仿真；
8.result：该部分用于存放仿真中产生的各种结果，wave里面存放本系统运行后生成的各种波形文件，支持主流的fsdb、vpd等格式，方便验证工程师利用自己熟悉的波形文件和debug工具定位问题。log目录存放系统编译和仿真阶段产生的打印报告，coverage目录存放仿真的覆盖率相关的文件用于cdv(覆盖率驱动验证)仿真使用。验证工程师可以使用代码覆盖率、断言覆盖率以及coverage group任意的方式去检查所关注的覆盖率类型，灵活地采用各种方式去保证验证的收敛。
9.优选的，所述一种支持soc设计全流程开发的软件和硬件协同仿真系统，其使用步骤如下：
10.步骤
①
：需要使用者准备好各种所需的激励，如：software里放置使用c代码和汇编代码编写的激励，hardware里放置verilog类型代码激励，uvm内则放置使用uvm的sequence，然后启动开始命令指定需要仿真的testcase，运行本系统；
11.步骤
②
：系统会自动判断仿真的类型，判断依据是根据激励中是否有软件类型的激励来进行分类，这里根据soc仿真的流程可以分为模块级仿真和系统级仿真两类：情况1
当需要的做的是模块级仿真时，由于这种仿真是不需要软件激励的所以当系统判断步骤
①
的输入文件中没有软件激励的时候，系统都会自动判断为需要进行的是模块级仿真或者不带处理器的子系统仿真。如图5的
②
所示此时的激励可以是hardware和uvm中的一种或者两种时。系统进行判断后会自动跳过步骤
③
和
④
进入到步骤
⑤
。情况2如果在步骤
①
判断激励中含有c代码等软件激励则会向下执行，进入步骤
③
；
12.步骤
③
：系统此时识别到要需要处理软件激励，会自动调用testbench的software(如图5所示
①
)内的文件对软件代码进行编译处理，产生可以用于软件和硬件协同仿真的二进制文件，整个过程如图3所示。此阶段可以看作是software的处理阶段没有硬件参与；
13.步骤
④
：这个阶段系统已经完成了软件代码的处理，系统会自动把软件编译好的二进制文件进行放在result中对应testcase名字的目录下，其中也会包括编译的过程文件如汇编文件等。如图3所示。这个阶段系统会把处理后的软件和硬件准备好形成一套可以使用软件激励驱动的系统级的仿真环境；
14.步骤
⑤
：系统会根据使用者的需要添加仿真需要的硬件模型。可选的模型存放在图5中
④
所示的model当中。不管是模块级仿真还是系统级在这步都有模型可以进行选择。唯一不同的是如果流程是从步骤
②
跳转到步骤
⑤
，此时想仿真处理器的操作就只能选择处理器的行为级模型。而对于经历了步骤
③④
再到
⑤
的流程是不需要选择处理器的行为级模型，因为软件仿真的流程和步骤
③④
的准备工作都是针对处理器的仿真来做的，经过
③④
的处理平台中已经具备了处理器仿真所需要的硬件和软件不再需要处理器的模型。对于处理器模型以外的外设模型无论是模块级仿真还是系统级仿真都可以根据自己的情况选择或者不选择；
15.步骤
⑥
：这个阶段系统会把使用者选择添加的硬件模型加入到硬件环境当中。使所选模型和soc芯片的代码结合起来形成一个整体成为可以被仿真的dut如图9所示，图中所有的内容都被称作dut(design under test)，是系统仿真的直接对象。其中bfm代表一个处理器的功能模型，下面的model1则可以代表任意一个外设的模型。由于本系统testbench中的hardware部分(见图5的
④
)对各种硬件模型具有良好的支持，因此这里可选的模型覆盖soc开发各阶段工作的需要，可提供verilog和systemverilog等各种类型的模型供仿真使用；
16.步骤
⑦
：系统会自动对dut进行编译操作，这个过程中还会包括对硬件环境的代码规则检查，产生的结果会存在result下对应仿真的testcase名字的log目录(如图5的
③
所示)方便查询相关的信息。一般来说没有错误提示的结果不影响后续的操作，所以本系统的自动化流程会继续执行下一步的操作。如果这个阶段发生了错误本系统会自动停止后续的操作，使用者需要去result中查看log中错误信息，解决后重新开始仿真。如果没有任何错误发生系统会自动向下进入步骤
⑧
；
17.步骤
⑧
：系统在这个阶段会对之前构建的软件和硬件协同仿真环境(完成步骤
③④⑤⑥⑦
操作后形成)或者单独的硬件仿真环境(完成步骤
⑤⑥⑦
操作后形成)进行仿真(simulation)。本系统会根据使用者在步骤
①
输入的命令选择对应的仿真器(simulator)，也会根据命令来选择进行前仿真(front
‑
end simulation)或者后仿真(back
‑
end simulation)。所以不管是模块级仿真还是系统级仿真，不管是rtl仿真还是netlist仿真此处都能完成，本系统因此支持对soc全流程开发的仿真需求；
18.步骤
⑨
：这个阶段是判断仿真结果是否正常的阶段，主要是手段通过log中打印信息给出相关错误信息的提示供工程师分析。打印信息的手段可以是硬件通过$display函数打印的信息的信息也可以是通过systemverilog assert方式打印的信息，在有软件激励参与的系统仿真中还可以使用软件的打印信息作为补充。使用者可以根据激励中预先设置的信息来判断仿真结果。这部分的内容和结果文件保存在result(如图5的
③
所示)当中，除了log外系统还给使用者提供wave和coverage等文件帮助分析仿真结果。使用者通过对result中仿真结果文件分析准确判断仿真是否通过，并可以通过debug工具定位问题后重新返回步骤
①
再次进行仿真直到获得正确的结果；
19.步骤
⑩
：这个阶段表示单个testcase仿真流程的结束，但是并不意味着模块级仿真或者系统级仿真的结束，所以这是一个必不可少的阶段。见图5的
③
，这个阶段根据系统运行的不同的testcase会在result目录下产生不同的testcase名称的目录，每个testcase的目录下又包含各自wave、log和coverage的目录用于存放仿真后的分类结果。对于cdv(覆盖率驱动的验证)来说单独的用例一般无法满足code coverage(代码覆盖率)或者function coverage(功能覆盖率)的要求，因此这里专门设置了coverage的目录存放相关的仿真结果，随着testcase仿真场景的增加可以使覆盖率不断得到完善，最终完成对功能覆盖率和代码覆盖率的要求。
20.优选的，所述hardware是硬件的公共部分包括了对传统的verilog语言编写的硬件激励的支持，同时也包括对uvm方法学搭建的仿真环境的支持。当仿真需要软件或者硬件相关的文件时，系统会自动在testbench下的software和hardware中调取相关的文件。
21.优选的，所述testbench中的hardware部分把通用接口和协议的模型包含了进来存放在专门的model目录下，所述testbench的hardware目录下专门设置了uvm的下级目录用于存放相关文件。
22.优选的，所述software的目录会发生变化，里面不仅保留了之前项目对risc
‑ⅴ
的支持也增加对arm的支持。
23.与现有技术相比，本发明的有益效果是：该支持soc设计全流程开发的软件和硬件协同仿真系统提供了一套通用的仿真系统支持soc的全流程的仿真和验证工作，具有简单的结构和使用方法，可以有效的避免soc模块级平台开发过程中由于工程师个人经验的问题所引入的错误，缩减了了模块级平台搭建的时间。系统本身便考虑了项目之间的继承和复用因此便于技术的积累和传递。验证工程师在进行模块级验证期间可以把主要的精力和时间放在构建激励上面，既提升了效率又可以有效的控制了仿真验证的质量。
24.本发明兼容传统方式的硬件仿真和硬件模型，如verilog类型的模型，同时也支持先进的uvm验证方法学和systemverilog等模型，并且可以充分发挥二者的优点。如图5的
④
所示testbench中的model存放传统的硬件模型，uvm下面则存放了各种uvm的env，使用本系统的时候验证工程师可以根据需要来选择模型的种类，模型在本系统的架构层面得到充分的考虑和支持，大大方便了使用者对模型的使用。本发明实现了系统仿真验证阶段两种主流方式的统一，既可以使用软件和硬件协同仿真技术来实现较高层次的激励，又可以发挥uvm的优点。如图5的
②
所示，在testcase当中验证工程师可以自由的选择需要施加激励的类型，在不同的目录下构建自己的激励文件系统会自动识别并加载这些文件并形成激励。这样既克服了uvm在系统级验证方面缺少真实的处理器代码和软件操作，又克服了软件和
硬件协同仿真技术中无法使用uvm丰富的sequence来作为激励的不足。本发明实现了模块级和系统级平台的统一。在一个soc芯片项目中不会再出现大量形式各异的平台。本系统通过科学合理的架构实现了对模块级和系统级平台的融合，soc芯片验证工程师可以在同一套系统下灵活的切换模块级和系统级的仿真，不维护多种不同类型的平台，避免了平台环境切换、testcase移植等可能带入的问题。有效的提升了工作效率降低了出错的可能
25.在本发明使用中不需使用者去考虑前仿真和后仿真在环境设置时的差异性问题，本系统具备支持soc全流程开发仿真的能力。本发明提出的支持soc全流程开发的软硬件系统仿真系统具有结构简单，功能划分清晰的优点便于不同人员对本系统的使用。
附图说明
26.图1为本发明soc芯片开发流程示意图；
27.图2为本发明soc芯片开发流程交付物变化示意图；
28.图3为本发明soc芯片软件和硬件协同仿真系统示意图；
29.图4为本发明soc芯片开发中两种系统级dut对比示意图；
30.图5为本发明系统架构示意图；
31.图6为本发明testbench中software结构变化示意图；
32.图7为本发明多种类型激励输入的仿真示意图；
33.图8为本发明系统仿真流程示意图；
34.图9为本发明添加了硬件模型的soc系统dut结构示意图。
具体实施方式
35.下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
36.请参阅图1
‑
9，本发明提供一种技术方案：一种支持soc设计全流程开发的软件和硬件协同仿真系统，包括testbench，testcase和result，testbench的内部包括有software和hardware，testcase的内部包括有software、hardware和uvm，result的内部包括有wave、log和coverage；
37.testbench：该testbench中存放的是仿真和验证系统用到的一些公用的内容，这一部分内容由本系统专职维护人员来负责，团队中的其他验证工程师不需要关注。这一部分中又可以分为两个部分按照对软硬件的支持划分为software(软件)和hardware(硬件)，分别负责对系统中软件环境和硬件环境的处理；
38.testcase：该testcase和testbench同属于仿真验证系统的一部分共同构建成仿真环境。不同的地方在于testcase可以由系统使用者自由构建激励。由于testbench已经准备好了完善的hardware和software环境，此处验证工程师具有很高的灵活性，可以充分利用软件和硬件的方式来产生激励，并且testcase中预留了uvm的部分给验证工程师灵活的构建sequence，作为对testbench中hardware的uvm sequence的补充。所以本系统的激励有三种类型可选，验证工程师可以根据需要决定选择其中的一种、两种或者全部类型去构建
并实现各种复杂场景的仿真；
39.result：该部分用于存放仿真中产生的各种结果，wave里面存放本系统运行后生成的各种波形文件，支持主流的fsdb、vpd等格式，方便验证工程师利用自己熟悉的波形文件和debug工具定位问题。log目录存放系统编译和仿真阶段产生的打印报告，coverage目录存放仿真的覆盖率相关的文件用于cdv(覆盖率驱动验证)仿真使用。验证工程师可以使用代码覆盖率、断言覆盖率以及coverage group任意的方式去检查所关注的覆盖率类型，灵活地采用各种方式去保证验证的收敛。
40.本发明中：hardware是硬件的公共部分包括了对传统的verilog语言编写的硬件激励的支持，同时也包括对uvm方法学搭建的仿真环境的支持。当仿真需要软件或者硬件相关的文件时，系统会自动在testbench下的software和hardware中调取相关的文件。
41.本发明中：testbench中的hardware部分把通用接口和协议的模型包含了进来存放在专门的model目录下，testbench的hardware目录下专门设置了uvm的下级目录用于存放相关文件。
42.本发明中：software的目录会发生变化，里面不仅保留了之前项目对risc
‑ⅴ
的支持也增加对arm的支持。
43.工作原理：该支持soc设计全流程开发的软件和硬件协同仿真系统使用前，步骤一为需要使用者准备好各种所需的激励，如：software里放置使用c代码和汇编代码编写的激励，hardware里放置verilog类型代码激励，uvm内则放置使用uvm的sequence，然后启动开始命令指定需要仿真的testcase，运行本系统。
44.步骤二随后系统会自动判断仿真的类型，判断依据是根据激励中是否有软件类型的激励来进行分类，这里根据soc仿真的流程可以分为模块级仿真和系统级仿真两类：情况1当需要的做的是模块级仿真时，由于这种仿真是不需要软件激励的所以当系统判断上一步的输入文件中没有软件激励的时候，系统都会自动判断为需要进行的是模块级仿真或者不带处理器的子系统仿真。如图5的
②
所示此时的激励可以是hardware和uvm中的一种或者两种时。系统进行判断后会自动跳过步骤三和四进入到步骤五。情况2如果在步骤一判断激励中含有c代码等软件激励则会向下执行，进入步骤三后，系统此时识别到要需要处理软件激励，会自动调用testbench的software(如图5所示
①
)内的文件对软件代码进行编译处理，产生可以用于软件和硬件协同仿真的二进制文件，整个过程如图3所示。此阶段可以看作是software的处理阶段没有硬件参与；
45.步骤四这个阶段系统已经完成了软件代码的处理，系统会自动把软件编译好的二进制文件进行放在result中对应testcase名字的目录下，其中也会包括编译的过程文件如汇编文件等。如图3所示。这个阶段系统会把处理后的软件和硬件准备好形成一套可以使用软件激励驱动的系统级的仿真环境；步骤五中系统会根据使用者的需要添加仿真需要的硬件模型。可选的模型存放在图5中
④
所示的model当中。不管是模块级仿真还是系统级在这步都有模型可以进行选择。唯一不同的是如果流程是从步骤二跳转到步骤五，此时想仿真处理器的操作就只能选择处理器的行为级模型。而对于经历了步骤三、四再到五的流程是不需要选择处理器的行为级模型，因为软件仿真的流程和步骤三、四的准备工作都是针对处理器的仿真来做的，经过步骤三、四的处理平台中已经具备了处理器仿真所需要的硬件和软件不再需要处理器的模型。对于处理器模型以外的外设模型无论是模块级仿真还是系
统级仿真都可以根据自己的情况选择或者不选择，步骤六这个阶段系统会把使用者选择添加的硬件模型加入到硬件环境当中。使所选模型和soc芯片的代码结合起来形成一个整体成为可以被仿真的dut如图9所示，图中所有的内容都被称作dut(design under test)，是系统仿真的直接对象。其中bfm代表一个处理器的功能模型，下面的model 1则可以代表任意一个外设的模型。由于本系统testbench中的hardware部分(见图5的
④
)对各种硬件模型具有良好的支持，因此这里可选的模型覆盖soc开发各阶段工作的需要，可提供verilog和systemverilog等各种类型的模型供仿真使用；
46.系统会自动对dut进行编译操作，这个过程中还会包括对硬件环境的代码规则检查，产生的结果会存在result下对应仿真的testcase名字的log目录(如图5的
③
所示)方便查询相关的信息。一般来说没有错误提示的结果不影响后续的操作，所以本系统的自动化流程会继续执行下一步的操作。如果这个阶段发生了错误本系统会自动停止后续的操作，使用者需要去result中查看log中错误信息，解决后重新开始仿真。如果没有任何错误发生系统会自动向下进入步骤八，系统在这个阶段会对之前构建的软件和硬件协同仿真环境(完成步骤三、四、五、六、七操作后形成)或者单独的硬件仿真环境(完成步骤五、六、七操作后形成)进行仿真(simulation)。本系统会根据使用者在步骤一输入的命令选择对应的仿真器(simulator)，也会根据命令来选择进行前仿真(front
‑
end simulation)或者后仿真(back
‑
end simulation)。所以不管是模块级仿真还是系统级仿真，不管是rtl仿真还是netlist仿真此处都能完成，本系统因此支持对soc全流程开发的仿真需求；
47.步骤九这个阶段是判断仿真结果是否正常的阶段，主要是手段通过log中打印信息给出相关错误信息的提示供工程师分析。打印信息的手段可以是硬件通过$display函数打印的信息的信息也可以是通过systemverilog assert方式打印的信息，在有软件激励参与的系统仿真中还可以使用软件的打印信息作为补充。使用者可以根据激励中预先设置的信息来判断仿真结果。这部分的内容和结果文件保存在result(如图5的
③
所示)当中，除了log外系统还给使用者提供wave和coverage等文件帮助分析仿真结果。使用者通过对result中仿真结果文件分析准确判断仿真是否通过，并可以通过debug工具定位问题后重新返回步骤一再次进行仿真直到获得正确的结果，步骤十这个阶段表示单个testcase仿真流程的结束，但是并不意味着模块级仿真或者系统级仿真的结束，所以这是一个必不可少的阶段。见图5的
③
，这个阶段根据系统运行的不同的testcase会在result目录下产生不同的testcase名称的目录，每个testcase的目录下又包含各自wave、log和coverage的目录用于存放仿真后的分类结果。对于cdv(覆盖率驱动的验证)来说单独的用例一般无法满足code coverage(代码覆盖率)或者function coverage(功能覆盖率)的要求，因此这里专门设置了coverage的目录存放相关的仿真结果，随着testcase仿真场景的增加可以使覆盖率不断得到完善，最终完成对功能覆盖率和代码覆盖率的要求。
48.综上所述：该支持soc设计全流程开发的软件和硬件协同仿真系统提供了一套通用的仿真系统支持soc的全流程的仿真和验证工作，具有简单的结构和使用方法，可以有效的避免soc模块级平台开发过程中由于工程师个人经验的问题所引入的错误，缩减了了模块级平台搭建的时间。系统本身便考虑了项目之间的继承和复用因此便于技术的积累和传递。验证工程师在进行模块级验证期间可以把主要的精力和时间放在构建激励上面，既提升了效率又可以有效的控制了仿真验证的质量。
49.本发明兼容传统方式的硬件仿真和硬件模型，如verilog类型的模型，同时也支持先进的uvm验证方法学和systemverilog等模型，并且可以充分发挥二者的优点。如图5的
④
所示testbench中的model存放传统的硬件模型，uvm下面则存放了各种uvm的env，使用本系统的时候验证工程师可以根据需要来选择模型的种类，模型在本系统的架构层面得到充分的考虑和支持，大大方便了使用者对模型的使用。本发明实现了系统仿真验证阶段两种主流方式的统一，既可以使用软件和硬件协同仿真技术来实现较高层次的激励，又可以发挥uvm的优点。如图5的
②
所示，在testcase当中验证工程师可以自由的选择需要施加激励的类型，在不同的目录下构建自己的激励文件系统会自动识别并加载这些文件并形成激励。这样既克服了uvm在系统级验证方面缺少真实的处理器代码和软件操作，又克服了软件和硬件协同仿真技术中无法使用uvm丰富的sequence来作为激励的不足。本发明实现了模块级和系统级平台的统一。在一个soc芯片项目中不会再出现大量形式各异的平台。本系统通过科学合理的架构实现了对模块级和系统级平台的融合，soc芯片验证工程师可以在同一套系统下灵活的切换模块级和系统级的仿真，不维护多种不同类型的平台，避免了平台环境切换、testcase移植等可能带入的问题。有效的提升了工作效率降低了出错的可能
50.在本发明使用中不需使用者去考虑前仿真和后仿真在环境设置时的差异性问题，本系统具备支持soc全流程开发仿真的能力。本发明提出的支持soc全流程开发的软硬件系统仿真系统具有结构简单，功能划分清晰的优点便于不同人员对本系统的使用。
51.需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。
52.本系统中涉及到的相关模块均为硬件系统模块或者为现有技术中计算机软件程序或协议与硬件相结合的功能模块，该功能模块所涉及到的计算机软件程序或协议的本身均为本领域技术人员公知的技术，其不是本系统的改进之处；本系统的改进为各模块之间的相互作用关系或连接关系，即为对系统的整体的构造进行改进，以解决本系统所要解决的相应技术问题。
53.尽管已经示出和描述了本发明的实施例，对于本领域的普通技术人员而言，可以理解在不脱离本发明的原理和精神的情况下可以对这些实施例进行多种变化、修改、替换和变型，本发明的范围由所附权利要求及其等同物限定。