CN113343617B - 软硬件协同仿真方法 - Google Patents

Abstract

本发明公开了一种软硬件协同仿真方法，包括软件测试代码、硬件测试平台和硬件仿真平台；将软件测试代码加载到FPGA或芯片上，并设置状态标志位用于判断软件测试代码的运行状态；硬件测试平台用于运行软件测试代码，同时提供读取内部存储单元的手段；硬件仿真平台用于获取软件测试代码在运行时产生的状态标志，从而判断软件测试代码的运行状态。本发明提供了一种全新的低成本的软硬件协同仿真方法，不需要多余硬件接口、仿真器及存储设备就可以通过仿真复现硬件行为，有效地解决了现有方案中需要专用接口，大量存储，设备价格昂贵等关键问题，非常有利于软件人员进行硬件测试和问题定位；而且可靠性高，效率较高。

Description

软硬件协同仿真方法

技术领域

本发明属于芯片设计领域，具体涉及一种软硬件协同仿真方法。

背景技术

随着半导体技术的发展，集成电路(以下简称IC)工艺的节点随着摩尔定律一步步发展，至今已经到nm级。工艺节点的快速发展，已经使得大规模集成电路，甚至超大规模集成电路变成了现实；一颗芯片包含几亿颗晶体管已经非常普遍。然而，庞大的逻辑电路如何正常工作，如果出现异常如何定位问题，已经成了工程师经常面对的问题。数字电路工程师通过工具对设计进行仿真，验证功能是否正确；同时软件工程师也需要验证下载到FPGA的设计，或者对芯片功能进行验证。然而，与数字电路工程师不同的是，软件工程师没有仿真专用的软件仿真工具，也无法像数字电路工程师那样，验证完成就可以保证软件***工作的正确性和稳定性。如何解决硬件工程师和软件工程师同时验证功能的准确性和一致性，就成为了现在FPGA设计或者芯片设计研发的关键点。比如，当软件工程师发现某一个功能有问题，然而硬件工程师又无法得知软件工程师的配置是否正确，或者软件工程师使用场景是否显露了隐藏的问题，此时软硬件协同仿真就显的尤为重要。

在FPGA设计领域，现有的软硬件协同仿真，通过采用FPGA厂商提供的内部***针对设定信号进行逻辑采样，再通过JTAG链将采样数据下载到本地，通过波形查看电路工作行为，从而判断是否工作正确。但是，这种方法局限性很大：首先，采样信号是提前设定好的，如果再添加其他采样信号，则需要重新编译，有很大的时间成本；其次，存储采样数据完全依赖FPGA内部的存储单元，如果FPGA设计庞大，已有的功能所使用的FPGA存储单元已经很多，则没有多余的存储单元提供给协同仿真；最后，添加采样逻辑，在编译阶段给时序带来很大的困难，随着设计规模越来越大，时序要求也越来越高，采样逻辑有很大可能由于时序问题无法保证采样信号的正确性。当然，现在很多EDA厂商，比如Synopsys提供了完整的debug技术，可以解决存储问题，时序问题，但是需要的设备价格昂贵，而且实时性也无法做到同步。

在ASIC领域，当软件工程师在使用芯片的过程中，会遇到各种各样的问题，而且往往是***层面遇到的问题。然而，硬件工程师针对***的仿真相对比较简单，对于软件工程师提出的问题，也无法通过一个模块或者几个模块仿真得到结果。通过现在常用的方法简化软件的操作，从***层面抽离出一种场景，甚至针对某一个模块进行仿真。这种方法会造成仿真条件不一致，无法定位真实问题，还有可能给软件工程师生成错误的debug方向。目前也有EDA厂商提出了解决方案，比如Cadence的Palladium，可以解决***层面仿真慢的问题。但是这种设备昂贵，而且仿真效率也相对较差。

发明内容

本发明的目的在于提供一种成本低廉，不需要额外的设备和接口，而且可靠性高，效率较高的软硬件协同仿真方法。

本发明提供的这种软硬件协同仿真方法，包括软件测试代码、硬件测试平台和硬件仿真平台；将软件测试代码加载到FPGA或芯片上，并设置状态标志位用于判断软件测试代码的运行状态；硬件测试平台用于运行软件测试代码，同时提供读取内部存储单元的手段；硬件仿真平台用于获取软件测试代码在运行时产生的状态标志，从而判断软件测试代码的运行状态。

所述的软件测试代码，通过编译工具转换为二进制文件，并加载到FPGA或芯片上；同时设置状态标志位，用于判断软件测试代码的运行状态。

所述的软件测试代码，不包括用于输出的打印字符和延时，从而提高协同仿真的效率。

所述的硬件仿真平台包括现有的硬件仿真工具，以及与FPGA或者芯片***功能相同的仿真模型；硬件仿真工具用于在进行功能设计时进行仿真；与FPGA或者芯片***功能相同的仿真模型与硬件测试平台的硬件功能一致，用于获取软件测试代码在运行过程中的状态标志。

所述的软硬件协同仿真方法，包括如下步骤：

S1.针对测试项进行测试程序编写；

S2.将步骤S1编写得到程序进行编译生成二进制文件，保证所述二进制文件能够运行在FPGA或芯片上；

S3.将步骤S2生成的二进制文件加载到硬件测试平台上，并通过运行的状态标志判断对应的验证项是否通过：

若通过，则返回步骤S1，并进行下一个测试项的测试；

若不通过，则进行后续的步骤；

S4.对步骤S1编写的程序进行修改，保证程序适配硬件仿真平台，并将修改后的程序编译为二进制代码；

S5.将步骤S4得到的二进制代码加载到硬件仿真平台，进行仿真，并查看程序是否运行正确：

若正确，即与S3现象相同，则进行下一步S6；

若不正确，即与S3现象相同，则返回步骤S4，重新修改编写的程序；

S6.对硬件测试平台和硬件仿真平台的运行结果进行对比：

若对比一致，则进行问题分析，即S7；

若对比不一致，则返回S1；

S7.硬件设计人员进行问题分析。

所述的软硬件协同仿真方法，软件工程师在编写软件测试代码时，每完成一项功能点测试，就向存储空间写一个状态标志；若存储空间能够找到这些标识，则代表这一个功能点测试完成；若没有某状态标志，则代表该状态标志所对应的功能点测试失败；当某一个功能测试点的状态标识没有被读到时，软件工程师需要检查测试流程是否正常：通过CPU的指针进行比对；软件工程师检查完测试流程，确认是由于功能问题导致，指令执行失败，或者是指令执行未完成，导致状态标志未被写入到内部存储单元；然后，软件工程师修改软件测试代码，删除打印指令和延时指令，同时保证删除打印指令和延时指令后的软件测试代码能够在硬件测试平台执行，而且程序运行状态和状态标志写入状态与修改前的软件测试代码相同；至此，第一轮软件测试完成；

在第一轮测试完成后，问题集中在一个测试点，但是无法定位CPU执行出错的指令；则进行第二轮软件测试：第二轮软件测试的起点为第一轮软件测试时最后一次正确写状态标志的位置，在该位置之后再***更多的写状态标志指令，再检查第二轮的写状态失败指令流程是否正确；然后，软件工程师再次修改代码，用于硬件仿真平台；

重复上述步骤，直至达到设定的要求。

所述的软硬件协同仿真方法，若状态标志出现未写入的错误，但是与测试代码在硬件测试平台上不一致，则软件工程师检查代码在测试平台执行过程是否和仿真平台执行过程相同，同时硬件工程师检查这种错误是否是配置或者不期望的操作造成，并通知软件工程师进行修改；软件工程师再次确认代码的正确性，修改并提供给硬件工程师；如果是硬件功能出现错误，则断定是流程不同造成或者配置错误造成；此时完成软硬件第一次交互；

若硬件仿真平台正确的复现测试平台上出现的问题，硬件工程师则检查逻辑功能，此时完成软硬件的第二次交互；

在FPGA平台中，通过若干次软硬件交互，发现软件测试代码问题，同时发现硬件逻辑功能问题，并通过修改软件代码或者硬件代码完成；

在芯片测试平台，发现了相同的错误状态标志，而硬件工程师又确认配置或者使用没有问题，则确定芯片逻辑功能出现问题；

最后，再次进行软硬件交互，从而解决问题。

本发明提供的这种软硬件协同仿真方法，提供了一种全新的低成本的软硬件协同仿真方法，本发明方法不需要多余硬件接口、仿真器及存储设备就可以通过仿真复现硬件行为，有效地解决了现有方案中需要专用接口，大量存储，设备价格昂贵等关键问题，非常有利于软件人员进行硬件测试和问题定位；而且可靠性高，效率较高。

附图说明

图1为本发明方法的原理示意图。

图2为本发明方法的流程示意图。

具体实施方式

如图1所示为本发明方法的原理示意图：本发明提供的这种软硬件协同仿真方法，包括软件测试代码、硬件测试平台和硬件仿真平台；将软件测试代码加载到FPGA或芯片上，并设置状态标志位用于判断软件测试代码的运行状态；硬件测试平台用于运行软件测试代码，同时提供读取内部存储单元的手段；硬件仿真平台用于获取软件测试代码在运行时产生的状态标志，从而判断软件测试代码的运行状态。

具体实施时：

无论FPGA设计还是ASIC芯片验证，验证的结果都是基于软件出的测试代码，因此软件测试代码是验证的基本；通过将软件测试代码运行在FPGA或者芯片上，验证功能是否正确；这些代码可以是裸代码，也可以是基于操作***的代码；软件测试代码通过编译工具，将代码编译成二进制文件形式，这个二进制文件可以通过加载到FPGA或者芯片上执行，通过CPU或者代码设立的状态标志位判断代码运行状态，通过这些状态标志位，软件工程师可以很容易的断定当前程序运行是否符合预期，判断当前运行状态是否正确；软件测试代码必然包括用于输出的打印字符，软件工程师需要可以很方便的将这些打印去掉，但是需要保证这些操作不会影响正常功能的运行，必要时可以选择其它可替换操作。这样做的原因是，在硬件仿真平台中，这些打印是很浪费时间的，去掉可以提高硬件仿真平台。

硬件测试平台包括已经烧写好功能的FPGA或者ASIC芯片，它们可以运行软件工程师编写的软件测试代码同时硬件测试平台需要提供给软件工程师可以读取内部存储单元的手段，这些存储单元仅仅用于存放程序运行的状态标识，而不是大量的信号采样数据。

硬件仿真平台是通常意义上硬件设计工程师进行功能设计时的仿真工具，例如基于UVM的仿真环境，基于HDL的编译仿真工具VCS等，这些仿真工具在硬件工程师进行原始功能设计时得到了大量的使用；硬件仿真平台还包括与FPGA或者芯片***功能相同的仿真模型，这些模型的功能与实际硬件测试平台的硬件功能完全一致；这些模型可以很容易的跟测试硬件的厂商拿到；通过仿真环境，硬件工程师可以在类存储单元的仿真模型中拿到程序运行的状态标志，这些标识的作用跟软件测试代码跑在硬件测试平台上得到的状态标识意义相同；通过比较状态标志，工程师可以很容易的判断程序运行的过程是否符合预期，运行的是否正确。

如图2所示为本发明方法的流程示意图：

软硬件协同仿真方法，包括如下步骤：

S1.针对测试项进行测试程序编写；

S2.将步骤S1编写得到程序进行编译生成二进制文件，保证所述二进制文件能够运行在FPGA或芯片上；

S3.将步骤S2生成的二进制文件加载到硬件测试平台上，并通过运行的状态标志判断对应的验证项是否通过：

若通过，则返回步骤S1，并进行下一个测试项的测试；

若不通过，则进行后续的步骤；

S4.对步骤S1编写的程序进行修改，保证程序适配硬件仿真平台，并将修改后的程序编译为二进制代码；

S5.将步骤S4得到的二进制代码加载到硬件仿真平台，进行仿真，并查看程序是否运行正确：

若正确，即与S3现象相同，则进行下一步S6；

若不正确，即与S3现象相同，则返回步骤S4，重新修改编写的程序；

S6.对硬件测试平台和硬件仿真平台的运行结果进行对比：

若对比一致，则进行问题分析，即S7；

若对比不一致，则返回S1；

S7.硬件设计人员进行问题分析。

具体实施时，软硬件协同仿真方法主要包括了问题定位和软硬件交互：

问题定位：

采用本方法的硬件测试平台CPU必须是可以正常运行二进制可执行文件的，其次硬件测试平台或者硬件仿真平台必需有可以让CPU进行读写的空间。

软件工程师在编写软件测试代码时，每完成一项功能点测试，就可以向存储空间写一个状态标识，这些标识可以是简单的顺序计数，比如，1，2，3，……，当在存储空间可以找到这些标识之后，代表这一个功能点测试完成。如果没有这些标识，代表这一个功能点测试失败。这些内部的存储单元也可以通过CPU很容易的读到。

当某一个功能测试点的状态标识没有被读到时，软件工程师需要检查测试流程是否正常，此时可以通过CPU的指针进行比对，通常写状态标识这些指令是汇编指令，从CPU的指令过程是很容易看到汇编指令的执行过程的。软件工程师检查完测试流程，确认是由于功能问题导致，指令执行失败，或者是指令执行未完成，导致状态标识未被写入到内部存储单元。

之后，软件工程师需要修改软件测试代码，将用于打印的指令删除，因为这些指令在硬件仿真平台上执行时间很长，影响效率；还需要将一些较大的延时去掉。软件工程师需要保证去掉打印指令和延时指令之后的二进制文件仍然可以到硬件测试平台执行，而且程序运行状态，包括状态标志是否正确写入，需要保证跟之前相同。

至此，第一轮软件测试完成，此时可以定位问题。

如果第一轮测试完成，问题集中在一个测试点，但是无法更确切知道CPU执行哪条指令出错，可以采用第二轮的软件测试。在第二轮测试中，起点在第一轮测试时最后一次写状态标识，之后再***更多的写状态标志指令，再检查第二轮的写状态失败指令流程是否正确，软件工程师再次修改代码，用于硬件仿真平台。

之后可以进行第三轮，甚至第四轮的软件测试。

问题定位的关键点在于时间片上的颗粒度，颗粒度更小，程序运行出错的位置越精细，相反颗粒度越大。

软件工程师可以定位出错的指令，但是无法得到原因。在软件工程师修改完代码之后，就可以到硬件仿真平台进行仿真，在硬件仿真平台可以检查硬件行为，这样就可以确认逻辑功能是否正确。

软硬件交互：

软件工程师通过定位错误指令，得到出错的时间点，但无法得知出错原因，通常最有效的办法是通过硬件功能仿真，找到相同的时间点，查看此时硬件信号状态。软件硬件交互机制的关键点在于运行软件相同的程序，同样也可以得到出错误的标识，表明仿真复现在FPGA或芯片运行的软件程序状态。通过将软件程序下载到存储模型中即可。

硬件仿真平台必需包含硬件测试平台所有测试需要的仿真模型，这些模型必需跟真实的器件行为一致。

硬件仿真平台必需包含存储模型，CPU可以从这些存储模型中读取指令并执行。

软件工程师提供给硬件工程师的测试代码或者二进制可执行文件不包含打印指令或者延时指令，因为这些指令在硬件仿真平台执行时间长，无必要复现。在仿真平台上，硬件工程师可以查看CPU执行的指令过程，检查运行流程是否正确。在这个过程中，可以简单的从仿真模型中，查看状态标志是否正确。

如果有些状态标志出现未写入的错误，但是与测试代码在硬件测试平台上不一致，需要软件工程师检查代码在测试平台执行过程是否和仿真平台执行过程相同，也需要硬件工程师检查这种错误是否是配置或者不期望的操作造成，进而通知软件工程师进行修改。软件工程师再次确认代码的正确性，修改并提供给硬件工程师；如果是硬件功能出现错误，基本可以断定是流程不同造成或者配置错误造成。此时完成软硬件第一次交互。

如果硬件仿真平台正确的复现测试平台上出现的问题，即相同的状态标志未写入到存储模型中，硬件工程师可以检查逻辑功能，此时完成软硬件的第二次交互。

在FPGA平台中，通过几次软硬件交互，可以发现软件测试代码问题，也可以发现硬件逻辑功能问题，可以修改软件代码或者硬件代码完成；如果是芯片测试平台，发现了相同的错误状态标志，而硬件工程师又确认配置或者使用没有问题，基本可以确定芯片逻辑功能出现问题。

此时再次进行软硬件交互，讨论解决方案。

Claims (5)

1.一种软硬件协同仿真方法，其特征在于包括软件测试代码、硬件测试平台和硬件仿真平台；将软件测试代码加载到FPGA或芯片上，并设置状态标志位用于判断软件测试代码的运行状态；硬件测试平台用于运行软件测试代码，同时提供读取内部存储单元的手段；硬件仿真平台用于获取软件测试代码在运行时产生的状态标志，从而判断软件测试代码的运行状态；

所述的硬件仿真平台包括现有的硬件仿真工具，以及与FPGA或者芯片***功能相同的仿真模型；硬件仿真工具用于在进行功能设计时进行仿真；与FPGA或者芯片***功能相同的仿真模型与硬件测试平台的硬件功能一致，用于获取软件测试代码在运行过程中的状态标志；

软硬件协同仿真方法，包括如下步骤：

S1. 针对测试项进行测试程序编写；

S2. 将步骤S1编写得到程序进行编译生成二进制文件，保证所述二进制文件能够运行在FPGA或芯片上；

S3. 将步骤S2生成的二进制文件加载到硬件测试平台上，并通过运行的状态标志判断对应的验证项是否通过：

若通过，则返回步骤S1，并进行下一个测试项的测试；

若不通过，则进行后续的步骤；

S4. 对步骤S1编写的程序进行修改，保证程序适配硬件仿真平台，并将修改后的程序编译为二进制代码；

S5. 将步骤S4得到的二进制代码加载到硬件仿真平台，进行仿真，并查看程序是否运行正确：

若正确，则进行下一步骤S6；

若不正确，则返回步骤S4，重新修改编写的程序；

S6. 对硬件测试平台和硬件仿真平台的运行结果进行对比：

若对比一致，则进行步骤S7；

若对比不一致，则返回步骤S1；

S7. 硬件设计人员进行问题分析。

2.根据权利要求1所述的软硬件协同仿真方法，其特征在于所述的软件测试代码，通过编译工具转换为二进制文件，并加载到FPGA或芯片上；同时设置状态标志位，用于判断软件测试代码的运行状态。

3.根据权利要求1所述的软硬件协同仿真方法，其特征在于所述的软件测试代码，不包括用于输出的打印字符和延时，从而提高协同仿真的效率。

4.根据权利要求3所述的软硬件协同仿真方法，其特征在于所述的软硬件协同仿真方法，软件工程师在编写软件测试代码时，每完成一项功能点测试，就向存储空间写一个状态标志；若存储空间能够找到这些标识，则代表这一个功能点测试完成；若没有某状态标志，则代表该状态标志所对应的功能点测试失败；当某一个功能测试点的状态标识没有被读到时，软件工程师需要检查测试流程是否正常：通过CPU的指针进行比对；软件工程师检查完测试流程，确认是由于功能问题导致，指令执行失败，或者是指令执行未完成，导致状态标志未被写入到内部存储单元；然后，软件工程师修改软件测试代码，删除打印指令和延时指令，同时保证删除打印指令和延时指令后的软件测试代码能够在硬件测试平台执行，而且程序运行状态和状态标志写入状态与修改前的软件测试代码相同；至此，第一轮软件测试完成；

在第一轮测试完成后，问题集中在一个测试点，但是无法定位CPU执行出错的指令；则进行第二轮软件测试：第二轮软件测试的起点为第一轮软件测试时最后一次正确写状态标志的位置，在该位置之后再***更多的写状态标志指令，再检查第二轮的写状态失败指令流程是否正确；然后，软件工程师再次修改代码，用于硬件仿真平台；

重复上述步骤，直至达到设定的要求。

5.根据权利要求4所述的软硬件协同仿真方法，其特征在于所述的软硬件协同仿真方法，若状态标志出现未写入的错误，但是与测试代码在硬件测试平台上不一致，则软件工程师检查代码在测试平台执行过程是否和仿真平台执行过程相同，同时硬件工程师检查这种错误是否是配置或者不期望的操作造成，并通知软件工程师进行修改；软件工程师再次确认代码的正确性，修改并提供给硬件工程师；如果是硬件功能出现错误，则断定是流程不同造成或者配置错误造成；此时完成软硬件第一次交互；

若硬件仿真平台正确的复现测试平台上出现的问题，硬件工程师则检查逻辑功能，此时完成软硬件的第二次交互；

在FPGA平台中，通过若干次软硬件交互，发现软件测试代码问题，同时发现硬件逻辑功能问题，并通过修改软件代码或者硬件代码完成；

在芯片测试平台，发现了相同的错误状态标志，而硬件工程师又确认配置或者使用没有问题，则确定芯片逻辑功能出现问题。

Images