芯片验证系统及方法与流程

1.本技术涉及芯片技术领域，尤其涉及一种芯片验证系统及方法。


背景技术：

2.所谓芯片验证，是指采用相应的验证语言、验证工具、验证方法，在芯片生产之前验证芯片的设计是否符合芯片的预期功能，并发现相应的缺陷。
3.目前，针对芯片验证，主要是基于通用验证方法学(universal verification methodology，uvm)进行前端验证。具体来说，通过代码确认与验证技术(verification ip，vip)产生激励驱动，使得待验证模块中的芯片的内部信号翻转，进而触发相关功能点，产生输出。接着，将该输出与对比模块的输出进行对比，进而根据对比结果确定芯片是否通过验证。
4.然而，不同的芯片之间存在一定的差异。例如：各芯片的位宽、寄存器地址等存在差异。采用同一个芯片验证系统，在对不同的芯片进行验证时，由于所要实现的细节会所有不同，因此在对不同芯片实际进行验证前，需要根据当前待验证的芯片的硬件情况对芯片验证系统中某些功能点进行取舍，才能满足对不同芯片的同一个功能的验证。这样，就会增加芯片验证工作操作的复杂程度，降低芯片验证的效率。


技术实现要素：

5.本技术实施例的目的是提供一种芯片验证系统及方法，以降低芯片验证工作的复杂程度，提高芯片验证的效率。
6.为解决上述技术问题，本技术实施例提供如下技术方案：
7.本技术第一方面提供一种芯片验证系统，所述系统包括：测试事件模块，用于发出测试指令，所述测试指令是基于脚本生成的指令，所述测试指令用于验证待测芯片的功能；信号生成模块，用于根据所述测试指令生成与所述待测芯片相适应的硬件信号；待测模块，用于放置所述待测芯片，使得所述待测芯片接收所述硬件信号，并响应所述硬件信号生成输出数据；对比模块，用于获取所述输出数据，并根据所述输出数据和预设数据的对比结果确定所述待测芯片是否通过验证，所述预设数据为所述待测芯片在功能正常的情况下响应所述硬件信号输出的数据。
8.本技术第二方面提供一种芯片验证方法，所述方法应用于第一方面中的芯片验证系统，所述方法包括：发出测试指令，所述测试指令是基于脚本生成的指令，所述测试指令用于验证待测芯片的功能；根据所述测试指令生成与所述待测芯片相适应的硬件信号；控制所述待测芯片接收所述硬件信号，并响应所述硬件信号生成输出数据，所述待测模块用于放置所述待测芯片；获取所述输出数据，并根据所述输出数据和预设数据的对比结果确定所述待测芯片是否通过验证，所述预设数据为所述待测芯片在功能正常的情况下响应所述硬件信号输出的数据。
9.相较于现有技术，本技术第一方面提供的芯片验证系统，通过设置测试事件模块
和信号生成模块，在验证内容确定后，测试事件模块就能够将软件化的测试指令发送至信号生成模块，而信号生成模块就能够基于软件化的测试指令生成与待测芯片相应的硬件信号，进而使待测芯片处理该硬件信号，从而对待测芯片的相应功能进行验证。这样，无论待测芯片的硬件信息如何变化，信号生成模块都能够基于测试指令生成与待待测芯片相适应的硬件信号，从而实现对待测芯片的相应功能进行验证。从而，无需测试人员逐个修改系统中与待测芯片相关的接口，降低验证工作的复杂程度，提高芯片验证效率。
10.本技术第二方面提供的芯片验证方法，与第一方面提供的芯片验证系统具有相同或相似的有益效果。
附图说明
11.通过参考附图阅读下文的详细描述，本技术示例性实施方式的上述以及其他目的、特征和优点将变得易于理解。在附图中，以示例性而非限制性的方式示出了本技术的若干实施方式，相同或对应的标号表示相同或对应的部分，其中：
12.图1为本技术实施例中芯片验证系统的结构示意图一；
13.图2为本技术实施例中芯片验证系统的结构示意图二；
14.图3为本技术实施例中芯片验证系统的结构示意图三；
15.图4为本技术实施例中扫描单元的结构示意图；
16.图5为本技术实施例中芯片验证系统的结构示意图四；
17.图6为本技术实施例中测试环境模块的结构示意图；
18.图7为本技术实施例提供的芯片验证方法的流程示意图一；
19.图8为本技术实施例提供的芯片验证方法的流程示意图二。
具体实施方式
20.下面将参照附图更详细地描述本技术的示例性实施方式。虽然附图中显示了本技术的示例性实施方式，然而应当理解，可以以各种形式实现本技术而不应被这里阐述的实施方式所限制。相反，提供这些实施方式是为了能够更透彻地理解本技术，并且能够将本技术的范围完整的传达给本领域的技术人员。
21.需要注意的是，除非另有说明，本技术使用的技术术语或者科学术语应当为本技术所属领域技术人员所理解的通常意义。
22.在现有的芯片验证系统中，基于同一功能模块以及同一功能规范，对不同芯片进行测试时，实现的细节会所有不同，可能会有功能点的取舍，并不一定实现全部功能。这样，会增加芯片验证工作的复杂程度，降低芯片验证的效率。
23.有鉴于此，本技术实施例提供了一种芯片验证系统，通过使用高级语言生成测试指令，进而通过硬件信号生成工具将测试指令转换为硬件信号，提高验证效率。特别是使用脚本语言，即写即用，无需编译，其效率可以比拟汇编语言、c/python等语言的开发效率。这样，当基于同一功能模块，对不同芯片进行测试时，上述硬件信号生成工具就能够基于上述脚本化测试用例生成适用于当前芯片的硬件信号，以对当前芯片进行测试。无需逐个修改芯片验证系统中与待测芯片相关的各接口的信息，提高芯片验证的效率。
24.这里需要说明的是，在实际应用中，芯片中待测的功能模块可以是调试模块。当
然，还可以是其它的功能模块。对于芯片中待测的功能模块的具体类型，此处不做限定。
25.接下来，详细说明本技术实施例提供的芯片验证系统。
26.图1为本技术实施例中芯片验证系统的结构示意图一，参见图1所示，该系统可以包括：测试事件模块101、信号生成模块102、待测模块103、对比模块104。
27.其中，测试事件模块101连接信号生成模块102，信号生成模块102连接待测模块103，待测模块103连接对比模块104。
28.测试事件模块101，用于接收并保存用户输入的测试指令，并将测试指令发送至信号生成模块102。
29.这里的测试指令是基于脚本生成的指令。也就是说，该测试指令为脚本化的指令。在该测试指令中，包含有对芯片的某一个或某几个功能进行测试的指令。也就是说，通过该测试指令，能够对芯片的一个或多个功能进行验证。
30.举例来说，当需要对芯片的功能a进行验证时，用户将编辑好的测试功能a的脚本指令输入至测试事件模块101中。测试事件模块101将该脚本指令发送至信号生成模块102，信号生成模块102就能够基于该脚本指令生成相应的硬件信号，以输入至待测芯片，进而对待测芯片的功能a进行验证。这里的功能a可以是待验证的任一功能模块的功能。对于功能a的具体内容，此处不做限定。
31.当然，测试指令还可以是实现其它功能的指令，以上单步功能测试指令仅为举例。测试指令的具体内容需要根据验证内容编辑，即采用脚本语言对测试内容进行抽象化描述。对于测试的具体内容，此处不做限定。
32.在实际应用中，测试指令可以以通用工具语言(tool control language，tcl)脚本的形式存储于测试事件模块101中。当然，还可以以其它脚本语言或其他高级类型编程语言的形式存在。对于测试指令的具体表现形式，此处不做限定。
33.信号生成模块102，用于接收测试事件模块101发送的测试指令，并根据接收到的测试指令生成与待测芯片相适应的硬件信号。
34.由于本技术实施例中的芯片验证系统是对芯片的硬件功能进行测试，因此输入芯片的信号也是硬件信号。而测试事件模块101中接收到的是软件化的测试指令，所以，需要将软件化的测试指令转换为硬件信号，以输入至待测芯片，对待测芯片进行测试。
35.而信号生成模块102就能够根据软件化的测试指令生成硬件化的测试信号，即硬件信号。在实际应用中，信号生成模块102可以是任意一种能够将软件化的指令转换为硬件化的信号的工具。例如：开源片上调试器(open on chip debugger，openocd)、uvm开发的驱动(driver)或通过深度报文检测(deep packet inspection，dpi)方式调用的c driver等能够实现信号转换功能的工具。对于信号生成模块102的具体类型，此处不做限定。
36.在信号生成模块102中，能够基于软件化的测试指令生成与待测芯片相适应的硬件信号。也就是说，信号生成模块102不仅能够基于测试指令生成测试相应功能的硬件信号，生成的硬件信号还能够适应于当前的待测芯片。
37.举例来说，假设当前待测芯片的位宽为32位。信号生成模块102在接收到测试指令后，根据测试指令生成与待测芯片相匹配的硬件信号，并将该硬件信号发送至待测芯片。此时生成的硬件信号就是32位对应的硬件信号，而不是64位对应的硬件信号。
38.而信号生成模块102究竟生成何种类型的硬件信号，是根据待测芯片的硬件信息
确定的。而此处对信号生成模块102获取待测芯片的硬件信息的具体方式不做限定，可以是信号生成模块102主动对待测芯片进行扫描获得的，也可以是信号生成模块102从其它模块中被动接收到的。
39.待测模块103，用于放置待测芯片，使得待测芯片能够接收信号生成模块102发送的硬件信号，进而基于该硬件信号生成输出数据。
40.也就是说，当需要对待测芯片进行功能验证时，首先，需要将待测芯片放置于待测模块103中。由于待测模块103与信号生成模块102连接，因此，在信号生成模块102基于测试事件101发送的测试指令生成硬件信号后，待测模块103就能够接收到信号生成模块102生成的硬件信号。然后，待测模块103将硬件信号传输给放置于其中的待测芯片。最后，待测芯片对接收到的硬件信号进行处理，产生输出，即生成输出数据。进而后续通过对比待测芯片的输出数据和预设数据，根据对比结果确定待测芯片的相应功能是否通过验证。
41.对比模块104，用于获取输出数据，并根据输出数据和预设数据的对比结果确定待测芯片是否通过验证。
42.预设数据为待测芯片在功能正常的情况下响应硬件信号输出的数据。
43.举例来说，假设需要验证待测芯片的指示功能是否正常。输入待测芯片的是硬件信号a，待测芯片基于硬件信号a生成输出数据a’，对比输出数据a’与预设数据，预设数据用于触发相应的指示灯亮起，若对比结果为一致，则确定待测芯片的指示功能通过验证；若对比结果为不一致，则确定待测芯片的指示功能没有通过验证。
44.而对比模块104中用于与输出数据进行对比的预设数据，可以从测试事件模块101的测试用例中获得，也可以是开发人员或测试人员基于待验证功能直接在对比文件104中输入的。对于预设数据的具体来源，此处不做限定。
45.由上述内容可知，在芯片验证系统中，通过设置测试事件模块和信号生成模块，在验证内容确定后，测试事件模块就能够将软件化的测试指令发送至信号生成模块，而信号生成模块就能够基于软件化的测试指令生成与待测芯片相应的硬件信号，进而使待测芯片处理该硬件信号，从而对待测芯片的相应功能进行验证。无论待测芯片的硬件信息如何变化，信号生成模块都能够基于测试指令生成与待待测芯片相适应的硬件信号，从而实现对待测芯片的相应功能进行验证。无需测试人员逐个修改系统中与待测芯片相关的接口，降低验证工作的复杂程度，提高芯片验证效率。
46.进一步地，为了提高测试指令的生成效率和准确性，进而提高芯片验证系统的验证效率和验证准确性，作为对图1所示系统的细化和扩展，本技术实施例还提供了一种芯片验证系统。
47.图2为本技术实施例中芯片验证系统的结构示意图二，参见图2所示，该系统可以包括：测试事件模块101、信号生成模块102、待测模块103、对比模块104。
48.这里的信号生成模块102、待测模块103和对比模块104与图1中的信号生成模块102、待测模块103和对比模块104的结构和功能相同或类似，所以此处不再赘述。这里主要针对测试事件模块101中的具体结构进行说明。
49.测试事件模块101可以包括：第一接收单元1011、存储单元1012、调用单元1013和第一发送单元1014。
50.其中，第一接收单元1011和存储单元1012分别连接调用单元1013，调用单元1013
连接第一发送单元1014。
51.第一接收单元1011，用于接收用户输入的目标测试项目标识。这里的目标测试项目标识用于表征不同的测试内容。
52.在一次的芯片功能验证中，可能需要验证芯片的多种功能，也可能仅验证芯片的一种功能。所以，一个目标测试项目标识可以对应一个测试内容，也可以对应多个测试内容。
53.举例来说，假设需要对待测芯片进行功能a、功能b、功能c的验证。那么，当目标测试项目对应一个测试内容时，用户就需要输入功能a对应的标识a、功能b对应的标识b以及功能c对应的标识c。而当目标测试项目标识对应多个测试内容时，用户可以直接仅输入功能a、功能b、功能c对应的标识abc即可。
54.以上标识为字母仅仅是一种示例，标识也可以是数字、测试内容对应的中文/英文名称等。只要能够基于标识的内容唯一的确定测试内容即可。对于标识的具体形式，此处不做限定。
55.存储单元1012，用于存储各个测试项目标识以及各个测试项目标识对应的测试指令。
56.调用单元1013，用于从第一接收单元1011中获取目标测试项目标识，并从存储单元1012中调取目标测试项目标识对应的目标测试指令。
57.当需要基于测试指令对待测芯片进行相应功能的验证时，基于测试内容直接编写测试指令，效率较低，并且容易出错。为了提高测试指令的生成效率以及准确性，可以预先编辑好各种测试项目对应的测试指令，然后将各种测试项目对应的测试指令及其对应的标识存储在存储单元1012中。这样，当需要进行某一项或某几项功能的验证时，调用单元1013就可以通过功能对应的标识从存储单元1012中直接获取到功能对应的测试指令。
58.举例来说，存储单元1012中存储有测试功能a对应的测试指令a及其标识a，测试功能b对应的测试指令b及其标识b。当第一接收单元1011接收到用户输入的目标测试项目标识为a，那么，调用单元1013就可以根据第一接收单元1011中接收的标识a从存储单元1012中直接找出标识a对应的测试指令a，而无需再编写测试指令a，提高测试指令的生成效率和准确性。
59.第一发送单元1014，用于将目标测试指令发送至信号生成模块102。
60.在提取出当前测试需要的目标测试指令后，通过第一发送单元1014将目标测试指令发送至信号生成模块102，以便信号生成模块102基于目标测试指令生成相应的硬件信号，并输入至待测芯片，以验证待测芯片的功能。
61.由上述内容可知，本技术实施例提供的芯片验证系统，在测试事件模块中，通过存储单元预先存储有各个测试项目标识以及各个测试项目标识对应的测试指令。这样，当需要验证待测芯片的某一项或某几项功能时，用户仅需在第一接收单元中输入待验证的功能对应的目标测试项目标识。而调用单元就会根据第一接收单元中接收的目标测试项目标识，从存储单元中调用出目标测试项目标识对应的目标测试指令，进而通过第一发送单元将目标测试指令发送至信号生成模块，以实现待验证功能对应的测试指令的自动生成，避免人工多次编写测试指令，能够提高测试指令的生成效率和准确性，进而提高芯片验证的效率和准确性。
62.进一步地，为了更快更准确地基于测试指令生成与待测芯片相适应的硬件信号，作为对图1所示系统的细化和扩展，本技术实施例还提供了一种芯片验证系统。
63.图3为本技术实施例中芯片验证系统的结构示意图三，参见图3所示，该系统可以包括：测试事件模块101、信号生成模块102、待测模块103、对比模块104。
64.这里的测试事件模块101、待测模块103和对比模块104与图1或2中的测试事件模块101、待测模块103和对比模块104的结构和功能相同或类似，所以此处不再赘述。这里主要针对信号生成模块102中的具体结构进行说明。
65.信号生成模块102可以包括：扫描单元1021和信号生成单元1022。
66.其中，扫描单元1021与信号生成单元1022连接。
67.扫描单元1021，用于扫描待测芯片的硬件信息，并将符合预设条件的硬件信息发送至信号生成单元1022。
68.当待测芯片放置于待测模块103中时，由于信号生成模块102与待测模块103连接，故而信号生成模块102可以监测到待测模块103中放置了待测芯片，或者待测模块103可以主动向信号生成模块102发送信息，以告知待测模块103中放置了待测芯片。进而扫描单元1021就可以被触发，开始对待测芯片进行扫描，获取待测芯片的硬件信息。这样，能够更快地获得待测芯片的硬件信息，进而更快地生成与待测芯片相适应的硬件信号，提高芯片验证速度。
69.或者，当测试事件模块101获取到测试指令时，测试事件模块101可以向信号生成模块102发送消息，以告知扫描单元1021可以开始对待测芯片进行扫描，或者信号生成模块102可以对测试事件模块101进行监测，一旦测试事件模块101获取到测试指令，扫描单元1021就可以开始对待测芯片进行扫描，直到扫描出待测芯片的全部硬件信息为止。
70.或者，当信号生成模块102接收到测试指令时，扫描单元1021才开始对待测芯片进行扫描，获取待测芯片的硬件信息。
71.对于扫描单元1021开始扫描的时机，可以是以上时机中的任意一种，此处不做限定。
72.通过扫描单元1021对待测芯片的硬件信息进行扫描，相比于从系统外部获取待测芯片的硬件信息，在硬件信息的传输过程中容易出现数据丢失，在从系统外向系统内传输数据时传输速度较慢等问题，通过系统内部的扫描单元1021直接对待测芯片的硬件信息进行扫描，能够更快更准确地获取待测芯片的硬件信息，进而更快更准确地生成与待测芯片相适应的硬件信号，进而提高芯片验证系统的验证速度和准确性。
73.在扫描单元1021中，为了避免扫描单元1021发生故障，扫描出错误的硬件信息，进而影响芯片验证的准确性，可以对扫描单元1021的扫描结果进行检测，当确定扫描结果无误时，再将扫描的硬件信息发出，能够提高芯片验证的准确性。
74.图4为本技术实施例中扫描单元的结构示意图，参见图4所示，扫描单元可以包括：扫描子单元1021a、判断子单元1021b、发送子单元1021c和提示子单元1021d。
75.其中，扫描子单元1021a连接判断子单元1021b，判断子单元1021b分别连接发送子单元1021c和提示子单元1021d。
76.扫描子单元1021a，用于扫描待测芯片的硬件信息。
77.扫描子单元1021a能够实现扫描单元1021中的部分功能，即扫描功能，具体内容可
参见前述对于扫描单元1021的说明，此处不再赘述。
78.判断子单元1021b，用于判断预设硬件信息中是否存在扫描子单元1021a扫描出的硬件信息；若是，则触发发送子单元1021c；若否，则触发提示子单元1021d。
79.其中，预设硬件信息为各种类型芯片的硬件信息的集合。
80.示例性的，在预设硬件信息中，包含有32位宽、64位宽、寄存器地址a、寄存器地址b等不同类型的芯片的各种硬件信息。
81.当扫描子单元1021a扫描出的硬件信息不存在于预设硬件信息中时，由于预设硬件信息中已包含了各种类型的芯片的各种类型的硬件信息，因此，说明扫描子单元1021a可能出现扫描故障，扫描出的硬件信息是存在问题的，或者，被扫描的芯片本身存在问题。接下来，就触发提示子单元1021d。提示子单元1021d能够触发终止指令，并生成提示信息。通过提示子单元1021d触发的终止指令，能够终止此次芯片的验证过程。通过提示子单元1021d生成并显示的提示信息，能够告知用户被扫描的芯片的硬件存在问题，或者扫描子单元1021a在扫描待测芯片的硬件信息时出现了故障。此时，终止芯片验证，能够提高芯片测试的稳定性。
82.当扫描子单元1021a扫描出的硬件信息存在于预设硬件信息中时，说明扫描子单元1021a正常，扫描出的硬件信息也是没有问题的。接下来，就触发发送子单元1021c，通过发送子单元1021c将扫描子单元1021a扫描出的待测芯片的硬件信息发送给信号生成单元1022，使得信号生成单元1022继续根据测试指令生成与待测芯片相适应的硬件信号。
83.信号生成单元1022，用于根据测试指令生成硬件信息对应的硬件信号。
84.在扫描单元1021扫描到待测芯片的硬件信息后，信号生成单元1022就能够根据测试事件模块101发送的测试指令和扫描单元1021扫描到的待测芯片的硬件信息生成与待测芯片相适应的硬件信号，将该硬件信号输入至待测芯片，待测芯片能够对该硬件信号进行处理。
85.举例来说，假设扫描单元1021扫描出待测芯片的位宽为64位，寄存器地址为地址b。那么，信号生成单元1022基于测试指令生成的硬件信号适用于64位，硬件信号发送至地址b。
86.由上述内容可知，本技术实施例提供的芯片验证系统，在信号生成模块中，通过扫描单元扫描出待测芯片的硬件信息，相比于从系统外部获取待测芯片的硬件信息，在硬件信息的传输过程中容易出现数据丢失，在从系统外向系统内传输数据时传输速度较慢等问题，通过系统内部的扫描单元直接对待测芯片的硬件信息进行扫描，能够更快更准确地获取待测芯片的硬件信息，进而更快更准确地生成与待测芯片相适应的硬件信号，进而提高芯片验证系统的验证速度和准确性。
87.进一步地，在传统的芯片验证中，在芯片验证系统中采用仿真环境对芯片进行验证后，还需要将芯片安装在电路板中进行测试，即板上测试。然而，在板上测试的过程中，如果检测结果出现问题，是无法针对出现的问题进行定位，进而增加芯片的调试难度。
88.有鉴于此，作为对图1所示系统的细化和扩展，本技术实施例还提供了一种芯片验证系统，通过在系统中1比1复现板上测试环境，使得在芯片验证系统中也能够进行板上测试，实现芯片的前端测试与后期测试的合一。这样，当芯片在板上测试出问题时，由于在板上无法针对问题进行定位，更不便于调试，因此，再将芯片置入本技术实施例提供的芯片验
证系统中，通过复现板上测试环境，对芯片进行测试，在此过程中，能够调用出中间数据，进而针对问题芯片进行定位，便于芯片的调试。
89.图5为本技术实施例中芯片验证系统的结构示意图四，参见图4所示，该系统可以包括：测试事件模块101、信号生成模块102、待测模块103、对比模块104、测试环境模块105和处理模块106。
90.这里的测试事件模块101、信号生成模块102、待测模块103和对比模块104与图1、2或3中的测试事件模块101、信号生成模块102、待测模块103和对比模块104的结构和功能相似，可参见相关说明，此处不再赘述。后面主要针对测试环境模块105和处理模块106进行说明。
91.其中，测试环境模块105连接处理模块106，处理模块106分别连接待测模块103和对比模块104。
92.测试环境模块105，用于发出程序指令。
93.这里的程序指令是基于待测芯片的板上测试环境生成的。也就是说，芯片在板上测试的过程中，板上使用了哪些器件，这些器件都是哪个版本，程序指令就模拟板上这些器件的版本。板上运行时采用的是哪些软件，这些软件是哪个版本，程序指令就模拟这些软件。
94.然而，程序指令也不是模拟板上所有的硬件以及软件，而是模拟板上一部分硬件以及软件的一部分内容。这一部分硬件以及软件的一部分内容与芯片实际在板上测试时出现的问题相关的。例如：芯片实际在板上测试中，芯片没有按照步骤a、步骤b、步骤c的顺序输出。那么，程序指令仅模拟板上与执行步骤a、步骤b、步骤c相关的硬件以及软件即可，而无需模拟声卡等与执行步骤无关的硬件及软件。这样，能够针对芯片在板上出现的问题更快地在系统中进行板上环境验证，进而更快地定位出问题所在。
95.图6为本技术实施例中测试环境模块的结构示意图，参见图6所示，测试环境模块可以包括：第二接收单元1051、指令生成单元1052、指令优化单元1053和第二发送单元1054。
96.其中，第二接收单元1051连接指令生成单元1052，指令生成单元1052连接指令优化单元1053，指令优化单元1053连接第二发送单元1054，第二发送单元1054连接处理模块106。
97.第二接收单元1051，用于接收用户输入的硬件版本和程序版本。
98.这里的硬件版本为待测芯片进行板上测试时板上各硬件的版本。程序版本为待测芯片进行板上测试时板上运行的程序的版本。
99.举例来说，芯片在前端进行完验证后，后期将芯片安装在电路板上进行测试。假设电路板上安装有硬件a、b、c，版本分别为1.0、1.0、2.0。电路板运行的是软件d，版本为3.0。那么，用户(可以是测试人员)就可以按照电路板的实际情况，将其上所有的硬件版本(硬件a，版本1.0；硬件b，版本1.0；硬件c，版本2.0)以及软件版本(软件d，版本3.0)输入至第二接收单元1051。第二接收单元1051就接收到了芯片后期测试时所在板的所有硬件版本和程序版本。
100.指令生成单元1052，用于根据硬件版本和程序版本生成程序指令。
101.在接收到硬件版本和程序版本后，根据硬件版本和程序版本就能够模拟出板级测
试环境的程序指令，从而在芯片前期验证的芯片验证系统中也能够模拟后期的板上测试环境。
102.基于硬件版本和程序版本进行板上测试环境仿真，建立板级仿真环境，可以采用现有的仿真技术。例如：电子设计自动化(electronic design automation，eda)。具体使用何种技术，此处不做限定。
103.指令优化单元1053，用于将程序指令中与测试指令无关的指令删除，得到目标程序指令。
104.由于在芯片验证系统中并不需要模拟出板上所有的环境，仅仅模拟出实际板上测试时出现问题的相关部分即可，因此，可以根据测试指令，确定芯片验证系统中实际需要模拟的板上的环境，进而将之前生成的能够模拟板上所有环境的程序指令中与此次测试无关的指令删除。
105.举例来说，在实际的板上测试中，假设发现板上的显卡没有输出，而声卡有输出，此时需要将芯片再次放入芯片验证系统中进行测试。系统中的测试指令仅仅是与显卡相关的测试指令。指令生成单元1052生成的程序指令是板上与显卡、声卡相关的所有指令。那么，指令优化单元1053就是将所有指令中，与声卡相关的指令删除，仅保留与显卡相关的指令。这样，在系统中，仅模拟板上的显卡环境，实现芯片与显卡相关功能的测试，进而实现对芯片所出现问题的定位。
106.第二发送单元1054，用于将目标程序指令发送至处理模块106。
107.在得到目标程序指令后，第二发送单元1054将目标程序指令发送至处理模块106，使得处理模块106模拟板上环境，实现芯片验证系统复现板上测试环境，以便于抓取测试的中间数据，对芯片问题进行定位，以便于芯片调试。
108.处理模块106，用于运行程序指令，并将生成的板上指令发送至放置于待测模块中的待测芯片，使得待测芯片模拟在板上测试环境中运行。
109.在处理模块106运行目标程序指令的过程中，芯片验证系统就模拟出了板上真实的测试环境，从而实现芯片的板上仿真测试。在此测试中，能够抓取到芯片中间产生的数据，通过中间数据，能够对芯片的问题快速准确地进行定位，从而便于芯片的调试。
110.在实际应用中，处理模块106可以是中央处理器(central processing unit，cpu)。cpu中执行的程序指令可以是c程序。
111.此外，本技术实施例提供的芯片验证系统还能够与程序调试工具(gnu symbolic debugger，gdb)互联，通过系统还能够实现板上软件功能的测试。
112.由上述内容可知，本技术实施例提供的芯片验证系统，通过在系统中增加环境测试模块和处理模块，通过环境测试模块产生能够模拟板上测试环境的程序指令，运行该程序指令，使得系统中模拟出板上环境，进而在仿真系统中实现板上测试。由于在系统中能够调取芯片测试中产生的中间数据，通过中间数据能够对板上测试出现问题的芯片的问题点进行定位，从而便于芯片的调试。
113.基于同一发明构思，作为图1所示系统的实现方法，本技术实施例还提供了一种芯片验证方法。该芯片验证方法是基于前述的芯片验证系统实现的。图7为本技术实施例提供的芯片验证方法的流程示意图一，参见图7所示，该方法可以包括：
114.s701：发出测试指令。
115.所述测试指令是基于脚本生成的指令，所述测试指令用于验证待测芯片的功能。
116.s702：根据所述测试指令生成与所述待测芯片相适应的硬件信号。
117.s703：控制所述待测芯片接收所述硬件信号，并响应所述硬件信号生成输出数据。
118.所述待测模块用于放置所述待测芯片。
119.s704：获取所述输出数据，并根据所述输出数据和预设数据的对比结果确定所述待测芯片是否通过验证。
120.所述预设数据为所述待测芯片在功能正常的情况下响应所述硬件信号输出的数据。
121.进一步地，作为图7所示方法的细化和扩展，本技术实施例还提供了一种芯片验证方法。图8为本技术实施例提供的芯片验证方法的流程示意图二，参见图8所示，该方法可以包括：
122.s801：接收用户输入的目标测试项目标识。
123.s802：存储各个测试项目标识以及所述各个测试项目标识对应的测试指令。
124.步骤s801与步骤s802可以同时执行，也可以先后执行。对于步骤s801与步骤s802的执行顺序，此处不做限定。
125.s803：从所述存储单元中调取所述目标测试项目标识对应的目标测试指令。
126.s804：将所述目标测试指令发送至所述信号生成模块。
127.s805：扫描所述待测芯片的硬件信息。
128.在扫描所述待测芯片的硬件信息的过程中，具体可以包括：扫描所述待测芯片的硬件信息，判断预设硬件信息中是否存在扫描得到的所述硬件信息。若是，则执行s806；若否，则触发终止指令，并生成提示信息，所述终止指令用于终止所述芯片的验证，所述提示信息用于指示所述芯片的硬件存在问题。所述预设硬件信息为各种类型芯片的硬件信息的集合。
129.s806：根据所述测试指令生成所述硬件信息对应的硬件信号。
130.s807：发出程序指令。
131.所述程序指令是基于所述待测芯片的板上测试环境生成的。
132.在发出程序指令的过程中，具体可以包括：接收用户输入的硬件版本和程序版本，其中，所述硬件版本为所述待测芯片进行板上测试时所述板上各硬件的版本，所述程序版本为所述待测芯片进行板上测试时所述板上运行的程序的版本。然后，根据所述硬件版本和所述程序版本生成所述程序指令。接着，将所述程序指令中与所述测试指令无关的指令删除，得到目标程序指令。最后，将所述目标程序指令发送至所述处理模块。
133.s808：运行所述程序指令，并将生成的板上指令发送至放置于所述待测模块中的所述待测芯片，使得所述待测芯片模拟在板上测试环境中运行。
134.s809：控制所述待测芯片接收所述硬件信号，并响应所述硬件信号生成输出数据。
135.s810：获取所述输出数据，并根据所述输出数据和预设数据的对比结果确定所述待测芯片是否通过验证。
136.这里需要说明的是，步骤s801
‑
s806与步骤s807
‑
s808是两条方法路线。步骤s801
‑
s806是通过脚本化的形式实现芯片验证，步骤s807
‑
s808是模拟芯片的板上测试环境。两条路线最终的目的都是对芯片的功能进行更为真实的测试。
137.这里还需说明的是，上述步骤s701
‑
s704、s801
‑
s810所述方法的执行主体可以是芯片验证系统中相应的各模块，也可以是各模块之外的处理器，此处不做具体限定。
138.最后，以一个测试硬件调式模块的具体实例对本技术实施例提供的芯片验证系统的芯片验证方法再次进行说明。
139.芯片验证系统包括被测试件(device under test，dut)、驱动层(openocd)和应用层。这样，就将芯片验证软件化。
140.在应用层中，包括：c程序和tcl测试点。
141.在驱动层中，包括：扩展后的openocd。
142.在系统中，当然还包括：cpu(用于仿真板级测试环境、待测模块(debug module，用于放置dut)、自动对比模块(uvm基础环境)。
143.具体的验证步骤为：
144.1、分析测试点，撰写c程序和tcl脚本；
145.2、编译c程序生成二进制文件；
146.3、启动uvm仿真环境，将c程序灌入cpu，将tcl脚本灌入openocd；
147.4、由openocd进一步生成控制流，并驱动openocd与dut之间的jtag接口，最终控制dut；
148.5、通过cpu与dut的信息通信与数据交互，完成测试点测试并生成结果文件；
149.6、通过分析结果文件中的关键数据、特定信号判断结果是否符合预期，并输出pass/fail。
150.通过c程序构建运行在cpu上的基础指令流，通过openocd触发导入测试激励流，debug模块与cpu相连，能够基本复现后期板级测试情景。cpu与debug模块均在寄存器转换级电路(register transfer level，rtl)仿真环境，且通过tcl脚本自动导入测试激励流，能够替代后期板级环境中的人为敲入命令。
151.这里需要指出的是，以上方法实施例的描述，与上述系统实施例的描述是类似的，具有同系统实施例相似的有益效果。对于本技术方法实施例中未披露的技术细节，请参照本技术系统实施例的描述而理解。
152.以上所述，仅为本技术的具体实施方式，但本技术的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本技术揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本技术的保护范围之内。因此，本技术的保护范围应以所述权利要求的保护范围为准。