芯片验证方法及平台与流程

1.本公开涉及芯片验证技术领域，具体涉及一种芯片验证方法及平台。


背景技术：

2.芯片验证是数字ic(integrated circuit，集成电路)设计过程中的关键步骤，通常可利用各类验证平台实现，例如uvm(universal verification methodology，通用验证方法)验证平台。相关技术中，在利用验证平台进行芯片验证时，验证时间较长，导致芯片研发周期拉长。


技术实现要素：

3.为提高芯片验证效率，本公开实施方式提供了一种芯片验证方法及平台、电子设备、存储介质。
4.第一方面，本公开实施方式提供了一种芯片验证平台，包括：
5.激励数据组件，被配置为基于待测用例生成激励数据，并将所述激励数据发送至待验证组件；
6.计数控制组件，被配置为在验证过程中，实时检测所述待验证组件输出的每个结果数据的目标信号并计数，并且响应于所述目标信号的数量满足预设条件，确定所述待测用例验证结束；所述目标信号表示所述结果数据的时序相关信号。
7.在一些实施方式中，所述计数控制组件被配置为：
8.预先基于所述待测用例确定所述结果数据的预期数量；
9.响应于所述目标信号的数量达到所述预期数量，确定所述目标信号的数量满足预设条件。
10.在一些实施方式中，所述的芯片验证平台，还包括：
11.参考模型组件，被配置为接收所述激励数据，并输出对应的预期结果数据；
12.对比组件，被配置于验证环境中，用于在所述验证过程中，实时将所述待验证组件输出的每个所述结果数据与所述预期结果数据进行对比，得到所述结果数据对应的对比结果；响应于所述结果数据的对比结果错误，停止所述验证过程。
13.在一些实施方式中，所述结果数据包括数据信号和时序信号；所述对比组件被配置为：
14.对于每个所述结果数据，将所述数据信号与预期结果数据的预期数据信号进行对比，得到第一结果；
15.将所述时序信号与预期结果数据的预期时序信号进行对比，得到第二结果；
16.根据所述第一结果和所述第二结果确定所述结果数据对应的所述对比结果。
17.在一些实施方式中，所述激励数据组件包括：
18.数据生成组件，被配置于验证环境之外，用于基于所述待测用例生成所述激励数据；
19.激励组件，被配置于验证环境中，用于接收所述激励数据，并将所述激励数据发送至所述待验证组件；
20.其中，所述数据生成组件被配置为将所述激励数据发送至所述参考模型组件，所述参考模型组件被配置于验证环境之外。
21.在一些实施方式中，所述对比组件被配置为输出代理组件。
22.在一些实施方式中，所述的芯片验证平台，还包括：
23.配置代理组件，被配置于验证环境中，用于根据所述激励数据生成并向所述待验证组件发送配置信息；
24.覆盖检测组件，被配置于验证环境中，用于检测所述配置信息，并根据所述配置信息确定所述待测用例的功能覆盖率信息。
25.第二方面，本公开实施方式提供了一种芯片验证方法，包括：
26.基于待测用例生成激励数据，并将所述激励数据发送至待验证组件；
27.在验证过程中，实时检测所述待验证组件输出的每个结果数据的目标信号并计数；所述目标信号表示所述结果数据的时序相关信号；
28.响应于所述目标信号的数量满足预设条件，确定所述待测用例验证结束。
29.在一些实施方式中，所述响应于所述目标信号的数量满足预设条件，确定所述待测用例验证结束，包括：
30.预先基于所述待测用例确定所述结果数据的预期数量；
31.响应于所述目标信号的数量达到所述预期数量，确定所述目标信号的数量满足预设条件。
32.在一些实施方式中，本公开所述的方法，还包括：
33.将所述激励数据发送至参考模型组件，得到所述参考模型组件输出的预期结果数据；
34.在所述验证过程中，实时将所述待验证组件输出的每个所述结果数据与所述预期结果数据进行对比，得到所述结果数据对应的对比结果；
35.响应于所述结果数据的对比结果错误，停止所述验证过程。
36.在一些实施方式中，所述结果数据包括数据信号和时序信号；所述在所述验证过程中，实时将所述待验证组件输出的每个所述结果数据与所述预期结果数据进行对比，得到所述结果数据对应的对比结果，包括：
37.对于每个所述结果数据，将所述数据信号与预期结果数据的预期数据信号进行对比，得到第一结果；
38.将所述时序信号与预期结果数据的预期时序信号进行对比，得到第二结果；
39.根据所述第一结果和所述第二结果确定所述结果数据对应的所述对比结果。
40.在一些实施方式中，所述基于待测用例生成激励数据，并将所述激励数据发送至待验证组件，包括：
41.验证平台的数据生成组件将基于所述待测用例生成的所述激励数据发送至验证环境中的激励组件，在所述验证环境中，所述激励组件将所述激励数据发送至所述待验证组件；
42.所述将所述激励数据发送至参考模型组件，得到所述参考模型组件输出的预期结
果数据，包括：
43.所述数据生成组件将所述激励数据发送至所述参考模型组件，所述参考模型组件将所述预期结果数据发送至所述验证环境。
44.在一些实施方式中，所述在所述验证过程中，实时将所述待验证组件输出的每个所述结果数据与所述预期结果数据进行对比，得到所述结果数据对应的对比结果，包括：
45.在所述验证环境中，输出代理组件分别接收所述结果数据和所述预期结果数据，并且实时将每个所述结果数据与所述预期结果数据进行对比，得到所述对比结果。
46.在一些实施方式中，本公开所述的方法，还包括：
47.在验证环境中，检测发送至所述待验证组件的所述激励数据的配置信息，并根据所述配置信息确定所述待测用例的功能覆盖率信息。
48.在一些实施方式中，所述目标信号包括有效信号、准备信号、行开始信号、行结束信号中的一种或多种。
49.第三方面，本公开实施方式提供了一种电子设备，包括：
50.处理器；
51.存储器，存储有计算机指令，所述计算机指令用于使所述处理器执行根据第二方面任意实施方式所述的方法。
52.第四方面，本公开实施方式提供了一种存储介质，存储有计算机指令，所述计算机指令用于使计算机执行根据第二方面任意实施方式所述的方法。
53.本公开实施方式的芯片验证平台，包括激励数据组件和计数控制组件，激励数据组件用于基于待测用例生成激励数据，并将激励数据发送至待验证组件，计数控制组件用于在验证过程中，实时检测待验证组件输出的每个结果数据的目标信号并计数，并且响应于目标信号的数量满足预设条件，确定待测用例验证结束。本公开实施方式中，可以准确对激励数据的处理进度进行检测，并且准确确定验证流程的结束时间，既避免提早结束导致验证失败，又避免延时较长导致验证效率降低，提高芯片验证效率。
附图说明
54.为了更清楚地说明本公开具体实施方式或现有技术中的技术方案，下面将对具体实施方式或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图是本公开的一些实施方式，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
55.图1相关技术中的uvm验证平台的结构原理图。
56.图2是根据本公开一些实施方式中芯片验证平台的结构原理图。
57.图3是根据本公开一些实施方式中芯片验证方法的流程图。
58.图4是根据本公开一些实施方式中芯片验证方法的流程图。
59.图5是根据本公开一些实施方式中芯片验证方法的流程图。
60.图6是根据本公开一些实施方式中芯片验证方法的流程图。
61.图7是根据本公开一些实施方式中芯片验证平台的结构原理图。
62.图8是根据本公开一些实施方式中电子设备的结构框图。
具体实施方式
63.下面将结合附图对本公开的技术方案进行清楚、完整地描述，显然，所描述的实施方式是本公开一部分实施方式，而不是全部的实施方式。基于本公开中的实施方式，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施方式，都属于本公开保护的范围。此外，下面所描述的本公开不同实施方式中所涉及的技术特征只要彼此之间未构成冲突就可以相互结合。
64.图1中示出了传统的uvm(universal verification methodology，通用验证方法)验证平台的结构原理图，下面结合图1对芯片验证的过程进行简述。
65.如图1所示，在uvm验证环境中，平台架构主要包括：激励产生组件(sequence)、输入代理组件(input agent)、输出代理组件(output agent)、待验证组件(dut，device under test)、参考模型组件(reference model)以及计分板(scoreboard)。
66.激励产生组件用于产生针对待测用例(case)的激励数据，例如以isp(image signal processing，图像信号处理)芯片验证为例，激励产生组件所产生的激励数据可以为随机产生的图像数据。
67.输入代理组件用于根据待验证组件所要求的相关配置信息，将激励数据按照一定的时序发送至待验证组件。例如激励数据以单帧图像数据为例，输入代理组件可以按照预定的时序将图像所包括的像素数据逐帧发送至待验证组件。
68.待验证组件表示与芯片功能模块完全一致的rtl(register-transfer level，寄存器传输级)设计组件，其可对接收到的激励数据按照预设功能进行处理，并将处理后的执行结果数据输出至输出代理组件。
69.输出代理组件用于检测待验证组件的输出数据，并将输出的执行结果数据发送至计分板。
70.参考模型组件表示与待验证组件的预期功能相对应的参照模型，输入代理组件将激励数据发送至参考模型组件，从而参考模型将得到的预期结果数据发送至计分板。
71.计分板可接收到参考模型组件发送的预期结果数据和输出代理组件转发的实际执行结果数据，通过对比两者是否一致，即可确定待验证组件的功能是否实现，也即得到待验证组件的验证结果。
72.在上述传统uvm验证过程中，对于一个待测用例的验证过程，一般是通过objection机制来控制验证的开始和结束。也即，以激励产生组件发送激励数据作为验证开始，在激励数据发送完成或者延时一段周期后作为验证结束，但是，这种方式对于例如isp等计算量大的复杂芯片验证难以适用。
73.以isp芯片验证为例，激励数据的数据量庞大，例如对于720p的图像数据，其输出就会产生1280*720个像素数据，从激励数据发送完毕到待验证组件的输出数据输出完毕，之间的时间难以准确得知。若每个待测用例均是针对某一固定分辨率图像数据而言，或许可以通过多次试验的方式得到大致上准确的延时周期，但是，不同待测用例所产生的图像数据的分辨率各不相同，难以利用试验的手段得到延时周期。
74.因此，若是设置的延时周期较短，将会导致验证提前结束，造成验证失败；反之，若是设置的延时周期很长，则会导致验证时间被拉长，降低验证效率。由此可知，相关技术中的uvm验证平台的完备性不高，芯片验证的鲁棒性不佳。
75.针对上述相关技术存在的缺陷，本公开实施方式提供了一种芯片验证平台及方法、电子设备、存储介质，旨在合理确定芯片验证的验证结束时间，提高验证平台的准确性和鲁棒性。
76.图2示出了本公开一些实施方式中芯片验证平台的结构原理图像，下面结合图2对本公开一些实施方式中的芯片验证平台进行说明。
77.如图2所示，在一些实施方式中，本公开示例的芯片验证平台包括激励数据组件100、输入代理组件200、待验证组件300、参考模型组件400、对比组件500以及计数控制组件800。
78.激励数据组件100用于根据待测用例产生激励数据，并将激励数据发送至输入代理组件200，输入代理组件200基于设定的配置信息将激励数据按时序发送至待验证组件300和参考模型组件400。待验证组件300将处理得到的结果数据发送至对比组件500，参考模型组件400将处理得到的预期结果数据发送至对比组件500。对比组件500根据结果数据和预期结果数据进行对比，得到待测用例的对比结果。
79.可以理解，在芯片验证过程中，输入代理组件200向待验证组件300输入激励数据是按照时序逐个进行输入，同样，待验证组件300输出的结果数据也是按照时序逐个输出。
80.以isp芯片验证为例，在一个示例中，激励数据组件100根据一个待测用例产生的完整激励数据表示的是一帧1280像素*720像素的图像数据，从而输入代理组件200逐像素将每个像素数据输入至待验证组件300中。待验证组件300对每个像素数据进行处理之后，也是逐像素输出每个像素数据对应的结果数据。
81.因此，本公开实施方式中，在验证环境中设置计数控制组件800，计数控制组件800用于实时检测待验证组件300输出的结果数据中的目标信号并计数，也即，计数控制组件800每检测到1次目标信号，即可在前次计数结果上加1。
82.可以理解，目标信号的作用是用于对每个结果数据进行统计，因此，在实际实施场景中，目标信号可以是结果数据中包括的与时序统计相关的信号，也即本公开所述的时序相关信号。
83.例如，valid/ready(有效信号/准备信号)握手机制是芯片验证通用的数据通信协议，其基本原理是，当上级模块(发送方)置高valid信号表示已经成功发送数据给下级模块(接收方)，下级模块置高ready信号表示已经做好接收数据的准备。因此，当待验证组件300输出的结果数据中包括valid信号或者ready信号时，即可表示该结果数据对应的像素数据已经被处理完成。
84.本公开一些实施方式中，计数控制组件800即可检测待验证组件300输出的每个结果数据中的valid信号或者ready信号，也即valid信号或者ready信号即可作为目标信号。当计数控制组件800检测到一次目标信号时，表示一个像素数据被处理完成并输出对应的结果数据，从而计数控制组件800即可在前次统计结果的基础上加1，以此类推，直至目标信号的统计数量达到预设条件，则可以确定验证结束。
85.仍以isp芯片验证为例，一个待测用例所产生的激励数据表示一帧1280像素*720像素的图像数据，也即待验证组件300共需处理1280*720个像素数据，对应输出1280*720个结果数据。在验证过程中，计数控制组件800即可实时检测每个结果数据的目标信号，当检测到一次目标信号，即可将计数结果加1，直至计数结果达到1280*720，即可确定针对待测
用例的验证流程结束。
86.在计数控制组件800确定验证流程结束时，计数控制组件800即可向激励数据组件100发送结束信号，从而控制激励数据组件100结束数据产生和发送(drop objection)，整个验证流程停止。
87.当然，可以理解，目标信号并不局限于上述示例中的valid信号(有效信号)或者ready信号(准备信号)，还可以是其他任何适于标记结果数据数量的时序相关信号，例如行开始信号、行结束信号、帧开始信号、帧结束信号等等，本公开对此不作限制。但是，也可以理解，valid信号和ready信号具有更好的通用性，可以适用各种类型的芯片验证。
88.在图2所示的验证平台的基础上，本公开一些实施方式提供了一种芯片验证方法，下面结合图3进行说明。
89.如图3所示，在一些实施方式中，本公开示例的芯片验证方法包括：
90.s310、基于待测用例生成激励数据，并将激励数据发送至待验证组件。
91.本公开实施方式中，待测用例可以理解为对待验证组件300进行功能验证的任务(case)，针对不同的待测用例，激励数据组件100可以生成不同的激励数据。
92.例如一个示例中，某个待测用例表示利用待验证组件300对图像进行去噪处理，激励数据组件100可根据待测用例的相关配置信息随机产生待去噪图像的图像数据，也即激励数据，并将激励数据发送至输入代理组件200，然后输入代理组件200按照相应的时序逐像素将每个像素数据发送至待验证组件300中。
93.s320、在验证过程中，实时检测待验证组件输出的每个结果数据的目标信号并计数。
94.仍以上述示例为例，待验证组件300依次对接收到的每个像素数据进行处理，得到该像素数据对应的结果数据并输出。如图2所示，计数控制组件800对待验证组件300输出的结果数据中的目标信号进行检测，当检测到一次目标信号即可将计数结果加1，从而实时对待验证组件300的数据处理进度进行统计。
95.s330、响应于目标信号的数量满足预设条件，确定待测用例验证结束。
96.本公开实施方式中，计数控制组件800在验证过程中，持续检测待验证组件300输出的目标信号的数量，直到目标信号的数量满足预设条件，也即证明针对待测用例产生的激励数据已经全部处理完成，验证流程可以结束。
97.具体而言，如图4所示，在一些实施方式中，确定目标信号的数量满足预设条件的过程，包括：
98.s331、预先基于待测用例确定结果数据的预期数量。
99.s332、响应于目标信号的数量达到预期数量，确定目标信号的数量满足预设条件。
100.例如一个示例中，基于待测用例所产生的激励数据表示一帧1280像素*720像素的图像数据，从而可确定该激励数据对应的结果数量的预期数量为1280*720。
101.结合前述过程，在待验证组件300持续对激励数据进行处理过程中，计数控制组件800持续检测输出的结果数据中的目标信号数量并计数，当目标信号的数量达到1280*720，即表示该激励数据中所有像素数据均处理完成，因此可以确定针对待测用例的验证流程结束。
102.在计数控制组件800确定验证流程结束时，计数控制组件800即可向激励数据组件
100发送结束信号，从而控制激励数据组件100结束数据产生和发送(drop objection)，整个验证流程停止。
103.通过上述可知，本公开实施方式中，在芯片验证流程中，通过检测待验证组件dut输出的结果数据中的目标信号数量，可以准确对激励数据的处理进度进行检测，并且准确确定验证流程的结束时间，既避免提早结束导致验证失败，又避免延时较长导致验证效率降低。并且，本公开方法可适用于任何芯片验证场景，不受芯片类型限制，提高验证平台的鲁棒性。
104.参见图1所示，在传统芯片验证方法中，计分板对于参考模型组件输出的预期结果数据和输出代理组件发送的执行结果数据的对比，往往是在对待测用例完全处理完成之后才开始对比。例如一个示例中，激励数据表示1280像素*720像素的图像数据，在传统验证过程中，待验证组件需要将1280*720个像素数据全部处理完成，得到执行结果数据，然后计分板利用执行结果数据和参考模型组件输出的预期结果数据进行对比，确认两者是否一致。但是，对于isp芯片来说，处理一帧图像数据的过程是很长的，可以达到几小时甚至几十小时，导致数据对比需要等待的时间很长。
105.另外，在此过程中，当某个像素数据出现报错时，则需要在verdi(自动化调试系统)上回追波形图，找出存在错误的代码。但是对于例如isp芯片产生的庞大数据量，该过程十分耗时耗力，并且需要等数据处理完成才可以开始找bug(错误)，isp芯片处理一帧图像的时间也非常长，导致验证效率低下。
106.基于此，如图5所示，在一些实施方式中，本公开示例的芯片验证方法，还包括：
107.s510、将激励数据发送至参考模型组件，得到参考模型组件输出的预期结果数据。
108.结合图2所示的验证平台，激励数据组件100产生的激励数据，通过输入代理组件200配置后发送至参考模型组件400，参考模型组件400对激励数据处理后输出预期结果数据。
109.s520、在验证过程中，实时将待验证组件输出的每个结果数据与预期结果数据进行对比，得到结果数据对应的对比结果。
110.在本公开实施方式中，对比组件500接收到参考模型组件400输出的预期结果数据和待验证组件300输出的结果数据。但是，本公开实施方式中，并非是等到待验证组件300将所有结果数据全部输出之后才进行对比，而是实时对接收到的每个结果数据，与预期结果数据进行对比。
111.例如一个示例中，激励数据表示一帧1280像素*720像素的图像数据，参考模型组件400对图像数据进行处理，即可得到所有像素数据对应的预期结果，也即预期结果数据。而待验证组件300逐像素对像素数据进行处理，从而逐像素输出每个像素数据对应的结果数据。对比组件500在接收到一个结果数据时，立即将该结果数据与该像素数据对应的预期结果数据进行对比，得到两者的对比结果，无需等到所有像素数据全部处理完成。
112.s530、响应于结果数据的对比结果错误，停止验证过程。
113.本公开实施方式中，对比组件500实时对比每个结果数据与预期结果数据，从而确定两者的对比结果。若两者对比结果一致，则说明待验证组件300对该像素数据的处理功能正确，验证流程继续进行，等待下一个结果数据的对比结果。若两者对比结果不一致，则说明待验证组件300对该像素数据的处理功能存在错误，则可以马上停止验证过程并报错。
114.通过上述可知，本公开实施方式中，无需等待全部的激励数据处理完成，即可实时对结果数据进行对比，从而在发现对比结果错误时，立刻停止验证流程报错，无需耗费大量时间查找出错位置和回追波形，仅需通过回追较少的波形即可确定错误代码，提高芯片验证效率。
115.如图1所示，在传统的芯片验证方法中，计分板进行数据对比的过程中，仅针对数据信号进行对比，而忽视了对时序信号进行对比。待验证组件300输出的结果数据中，时序信号的错误或许对rtl设计的当前组件无太大影响，但是可能对下级组件产生致命影响，随着rtl设计逐渐完善，时序错误可能导致芯片整个流程出错。
116.因此，本公开实施方式中，对比组件500不仅对结果数据的数据信号进行对比，还需要对结果数据的时序信号进行对比，下面结合图6实施方式进行说明。
117.如图6所示，在一些实施方式中，本公开示例的芯片验证方法中，对比组件500进行数据对比，得到对比结果的过程，包括：
118.s610、对于每个结果数据，将数据信号与预期结果数据的预期数据信号进行对比，得到第一结果。
119.s620、将时序信号与预期结果数据的预期时序信号进行对比，得到第二结果。
120.s630、根据第一结果和第二结果确定结果数据对应的对比结果。
121.结合图2所示，本公开实施方式中，对比组件500每接收到一个待验证组件300输出的结果数据时，将结果数据包括的数据信号与预期结果数据的预期数据信号进行对比，从而得到两者的第一结果。在此基础上，对比组件500同时将结果数据包括的时序信号与预期结果数据的预期时序信号进行对比，得到第二结果。然后综合第一结果和第二结果，确定该结果数据对应的对比结果。
122.在一些实施方式中，可以在对比组件500中预先配置时序检测模型，利用时序检测模型对结果数据的时序信号进行对比，从而确定结果数据的时序信号的输出位置和输出个数是否正确，也即得到第二结果。
123.可以理解，第一结果表示的是结果数据的数据信号的正确性，第二结果表示的是结果数据的时序信号的正确性，从而综合两者得到的对比结果同时包括对数据信号和时序信号的结果。当两者其中任一存在错误时，则表示结果数据的对比结果为错误，基于前述实施方式停止验证流程并报错。反之，若两者均为正确结果时，则表示结果数据的对比结果正确，继续执行验证流程。
124.通过上述可知，本公开实施方式中，在对结果数据与预期结果数据对比时，不仅针对数据信号进行对比，同时对时序信号进行对比，保证时序信号的准确性，提高芯片验证的准确性。
125.图7示出了本公开一些实施方式中的验证平台的结构原理图，下面结合图7对本公开实施方式进一步说明。
126.在一些实施方式中，相较于图2实施方式的验证平台，在图7示例中，将激励数据组件100拆分为数据生成组件110和激励组件120，并且，将数据生成组件110分离出验证环境之外。
127.这是由于，在芯片验证过程中需要预先配置验证环境，而在芯片验证时，针对不同的待测用例需要配置不同的激励数据，尤其对于isp芯片等复杂芯片，在验证过程中修改激
励数据是非常常见且频繁的。而在例如图1所示的传统uvm平台中，由于产生激励数据的激励产生组件被配置于验证环境中，因此修改激励数据时，需要对整个验证环境进行重新编译，编译过程耗时耗力，导致整个验证流程效率低下。
128.而在本公开图7示例的实施方式中，将数据生成组件110分离于验证环境之外，也即激励数据在验证环境之外产生，这样，当需要修改激励数据时，仅仅需要对数据生成组件110进行重新编译即可，无需对整个验证环境和rtl进行重新编译，缩短验证时间。
129.另外，由于数据生成组件110分离于验证环境之外，则表示该组件不再受限于采用system verilog硬件设计语言编译，可以使用其他编程语言进行编译，例如python、perl、c 等，这样更加缩短了配置时间，同时更加适用于部分利用system verilog硬件设计语言难以产生数据的场景，大大缩减开发时间。
130.参见图7所示，在本公开实施方式中，验证环境内的激励组件120则不再作为数据产生的功能，而是仅仅作为数据转发。也即，位于验证环境之外的数据生成组件110产生激励数据，并将激励数据发送至验证环境中的激励组件120，激励组件120将激励数据发送至输入代理组件200。
131.在一些实施方式中，继续参照图7所示，由于将数据生成组件110分离出了验证环境，因此，同样也可以将参考模型组件400分离出验证环境。这样做的好处在于：首先，由于数据生成组件110和参考模型组件400均分离出验证环境，从而产生的激励数据无需经过输入代理组件200转发，可在验证环境之外，由数据生成组件110直接发送至参考模型组件400，这样在验证流程开始之前，参考模型组件400即可执行工作，较早地为后续的对比过程提供预期结果数据；其次，由于参考模型组件400分离出验证模型，从而验证环境内的激励组件120和输入代理组件200无需考虑向参考模型组件400发送数据的过程，避免调用传输数据接口，同时验证环境减少了组件模块，提高验证环境的编译速度。
132.数据生成组件110在验证环境之外产生激励数据，并且在验证环境之外直接将激励数据发送至参考模型组件400，参考模型组件400通过数据处理得到预期结果数据，并将预期结果数据发送至验证环境中。
133.在一些实施方式中，如图7所示，相较于图1所示的传统uvm验证平台，本公开实施方式中将计分板的数据对比功能以及上述的时序信号对比功能集成于输出代理组件510中，也即利用输出代理组件510实现图2中对比组件500的全部功能。
134.这是考虑到，由于参考模型组件400已经分离出验证模型，因此不必在计分板中执行数据信号的对比。另外，通过本公开上述实施方式可知，本公开不仅对结果数据的数据信号进行对比，还对时序信号进行对比，而计分板对于时序信号的对比过程非常繁琐。
135.因此，本公开实施方式中，将数据信号和时序信号的对比功能集成于输出代理组件510中，对输出代理组件510重新编译，在实现上述对比功能的基础上，可以提高芯片验证的效率，缩短验证周期。
136.在一些实施方式中，如图7所示，本公开示例在验证环境中为待验证组件300的数据输入设置单独的配置代理组件210。
137.输入代理组件200用于接收激励组件120转发的激励数据，并且按照预设的时序将激励数据逐像素发送至待验证组件300。配置代理组件210的作用是对待验证组件300的数据处理提供配置参数，配置参数可例如待验证组件300的寄存器配置参数、针对像素数据的
处理参数等。
138.当然，本领域技术人员可以理解，配置代理组件210的相应功能可以集成于输入代理组件200中，而本公开单独设置配置代理组件210的目的在于，可以更好地检测待测用例对待验证组件300的功能覆盖信息。
139.具体而言，如图7所示，本公开示例的验证平台，在验证环境中设置有覆盖检测组件700，覆盖检测组件700用于实时检测配置代理组件210配置的激励数据的配置信息，该配置信息可反映激励数据对待验证组件300的功能覆盖情况，例如，覆盖检测组件700可以检测配置代理组件210的寄存器配置参数，通过检测寄存器配置情况，反映验证过程中对待验证组件300的功能覆盖情况。覆盖检测组件700可以根据激励数据的配置信息实时记录各个覆盖点(cover point)的执行情况，从而得到功能覆盖率信息。
140.功能覆盖率信息可以反映待测用例对待验证组件300的功能覆盖情况，若覆盖率很低，则说明待测用例无法较好地对待验证组件300的完整功能进行验证，从而需要重新调整激励数据，也即上述的修改激励数据的过程。换句话说，本公开实施方式中，通过覆盖检测组件700得到的功能覆盖率信息，可以有效指导对待测用例的激励数据进行有针对地修改，提高芯片验证效率。
141.结合图7所示，下面对本公开实施方式中的芯片验证平台的搭建和验证流程进行说明。
142.如图7所示，首先需要根据待验证组件300的rtl设计和参考模型组件400确定代理组件，例如输入代理组件200、配置代理组件210和输出代理组件510。其次构建与代理组件同级别的计数控制组件800和覆盖检测组件700，然后就可以根据环境变量(env)将前述的各个功能组件实例化。之后构建激励组件120和验证环境，最后构建数据生成组件110和参考模型组件400的可执行文件，完成验证平台的构建。
143.在验证过程中，数据生成组件110产生激励数据，并将激励数据发送至参考模型组件400，参考模型组件400对激励数据进行处理得到预期结果数据，并将预期结果数据发送至验证环境中的输出代理组件510。
144.同时，数据生成组件110将激励数据发送至验证环境中的激励组件120，激励组件120将激励数据分别转发至输入代理组件200和配置代理组件210。输入代理组件200和配置代理组件210将激励数据分别按照时序发送至待验证组件300，同时覆盖检测组件700检测配置代理组件210输出的配置信息，记录各个覆盖点的执行情况，得到功能覆盖率信息。
145.待验证组件300按照时序逐一对激励数据进行处理，并输出对应的结果数据至输出代理组件510，输出代理组件510基于预先得到的预期结果数据实时对接收到的结果数据的数据信号和时序信号进行对比，得到该结果数据对应的对比结果。同时，计数控制组件800实时检测结果数据中的目标信号并统计，当目标信号数据满足预设条件时，向激励组件120发送停止信号，整个验证流程停止。
146.通过上述可知，本公开实施方式中，在芯片验证流程中，通过检测待验证组件dut输出的结果数据中的目标信号数量，可以准确对激励数据的处理进度进行检测，并且准确确定验证流程的结束时间，既避免提早结束导致验证失败，又避免延时较长导致验证效率降低。并且，本公开方法可适用于任何芯片验证场景，不受芯片类型限制，提高验证平台的鲁棒性。无需等待全部的激励数据处理完成，即可实时对结果数据进行对比，从而在发现对
比结果错误时，立刻停止验证流程报错，可以马上发现错误代码，无需大量的回追波形操作，提高芯片验证效率。在对结果数据与预期结果数据对比时，不仅针对数据信号进行对比，同时对时序信号进行对比，保证时序信号的准确性，提高芯片验证的准确性。
147.在一些实施方式中，本公开实施方式提供了一种电子设备，包括：
148.处理器；和
149.存储器，存储有计算机指令，计算机指令用于使处理器执行上述任意实施方式的芯片验证方法。
150.在一些实施方式中，本公开实施方式提供了一种存储介质，存储有计算机指令，计算机指令用于使计算机执行上述任意实施方式的芯片验证方法。
151.具体而言，图8示出了适于用来实现本公开方法的电子设备600的结构示意图，通过图8所示电子设备，可实现上述处理器及存储介质相应功能。
152.如图8所示，电子设备600包括处理器601，其可以根据存储在存储器602中的程序或者从存储部分608加载到存储器602中的程序而执行各种适当的动作和处理。在存储器602中，还存储有电子设备600操作所需的各种程序和数据。处理器601和存储器602通过总线604彼此相连。输入/输出(i/o)接口605也连接至总线604。
153.以下部件连接至i/o接口605：包括键盘、鼠标等的输入部分606；包括诸如阴极射线管(crt)、液晶显示器(lcd)等以及扬声器等的输出部分607；包括硬盘等的存储部分608；以及包括诸如lan卡、调制解调器等的网络接口卡的通信部分609。通信部分609经由诸如因特网的网络执行通信处理。驱动器610也根据需要连接至i/o接口605。可拆卸介质611，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器610上，以便于从其上读出的计算机程序根据需要被安装入存储部分608。
154.特别地，根据本公开的实施方式，上文方法过程可以被实现为计算机软件程序。例如，本公开的实施方式包括一种计算机程序产品，其包括有形地包含在机器可读介质上的计算机程序，计算机程序包含用于执行上述方法的程序代码。在这样的实施方式中，该计算机程序可以通过通信部分609从网络上被下载和安装，和/或从可拆卸介质611被安装。
155.附图中的流程图和框图，图示了按照本公开各种实施方式的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。
156.显然，上述实施方式仅仅是为清楚地说明所作的举例，而并非对实施方式的限定。对于所属领域的普通技术人员来说，在上述说明的基础上还可以做出其它不同形式的变化或变动。这里无需也无法对所有的实施方式予以穷举。而由此所引伸出的显而易见的变化或变动仍处于本公开创造的保护范围之中。