检查总线验证的方法与装置以及电子设备和存储介质

技术领域

本公开的实施例涉及一种检查总线验证的方法与装置以及电子设备和存储介质。

背景技术

随着集成电路工艺的不断进步，集成电路的规模和复杂度也在不断地提高，验证的难度也越来越大，验证时间也越来越长。在集成电路设计中，验证工作已经占到了整个研发周期的一半以上，而验证的效率直接关系到芯片的质量和上市速度，例如总线的验证质量也成为集成电路成功与否的重要因素，所以对验证方法、验证质量和其他相关技术都提出了越来越高的要求。

发明内容

本公开的实施例提供了一种检查总线验证的方法与装置以及电子设备和存储介质，根据总线验证的各种场景进行建模，将场景映射成多个覆盖仓，基于建立的模型生成覆盖率代码，并使用仿真工具自动地进行功能覆盖率的收集，从而自动化地实现总线验证的完备性的检查，解决了人工统计检查的工作量大以及质量低的问题。

本公开至少一实施例提供了一种检查总线验证的方法，包括：

根据总线验证的多个场景建立模型，其中，所述模型被配置为将所述多个场景分别映射成用于计算覆盖率的多个覆盖仓，用以收集所述多个场景的功能覆盖率；

根据所述模型，生成覆盖率代码；

将所述覆盖率代码应用于仿真工具，使得所述仿真工具自动地进行所述功能覆盖率的收集，得到所述多个场景的功能覆盖率的收集结果，以检查所述总线验证的完备性。

例如，在本公开至少一实施例提供的一种检查总线验证的方法中，所述多个场景中每个包括：响应于所述总线验证，与被验证的总线通信的至少两个设备之间通过所述总线进行信息传输的场景。

例如，在本公开至少一实施例提供的一种检查总线验证的方法中，所述模型被配置为将所述多个场景分别映射成用于计算覆盖率的多个覆盖仓，用以收集所述多个场景的功能覆盖率，包括：

根据所述多个场景，分别通过多层级关系映射建立所述多个覆盖仓，其中，每个所述覆盖仓是用于收集所述功能覆盖率的最小单位；

获取所述多个覆盖仓中被命中的覆盖仓的数目；

基于所述被命中的覆盖仓的数目占据所述多个覆盖仓的总数的百分比，以及所述多层级关系映射，得到所述多个场景的功能覆盖率。

例如，在本公开至少一实施例提供的一种检查总线验证的方法中，根据所述多个场景，分别通过多层级关系映射建立所述多个覆盖仓，包括：

建立用于所述多个场景中一个或多个的覆盖组，其中，所述覆盖组用于对所述多个场景进行分组以实现覆盖率的分组；

建立用于每个所述覆盖组的一个或多个覆盖点，其中，每个所述覆盖组的覆盖点作为所述覆盖组的下一层级映射目标；

建立用于每个所述覆盖点的覆盖仓，其中，每个所述覆盖点的覆盖仓作为所述覆盖点的下一层级映射目标。

例如，在本公开至少一实施例提供的一种检查总线验证的方法中，基于所述被命中的覆盖仓的数目占据所述多个覆盖仓的总数的百分比，以及所述多层级关系映射，得到所述多个场景的功能覆盖率，包括：

使得每个所述覆盖点的覆盖率等于所述覆盖点对应的多个覆盖仓中被命中的覆盖仓的数目占据所述多个覆盖仓的总数的百分比；

根据每个所述覆盖组对应的一个或多个覆盖点各自的覆盖率，得到所述覆盖组的覆盖率；

根据每个所述覆盖组的覆盖率，得到所述多个场景的功能覆盖率。

例如，在本公开至少一实施例提供的一种检查总线验证的方法中，所述总线验证，包括：

使用一个或多个验证单元组件作为被验证的所述总线的至少部分的主设备和/或从设备，其中，被配置作为所述主设备的验证单元组件产生各种不同类型的事务并将产生的所述事务通过所述总线的主设备接口送至所述总线，被配置作为所述从设备的所述验证单元组件通过所述总线接收来自所述主设备接口的事务并给予响应，且将产生的响应事务通过所述总线的从设备接口返回至所述总线；

将监视器连接到所述总线的监视端口，其中，所述总线的监视端口包括所述总线的主设备接口和从设备接口，所述监视器用于收集并还原通过所述监视端口的所有事务；

创建记分板，其中，所述记分板分别接收来自所述验证单元组件和所述监视器的事务，并对来自所述验证单元组件的事务进行预测得到预测的响应事务，响应于所述监视端口监测到事务，所述记分板比对所述预测的响应事务和所述监视器的所有事务中的响应事务，判断两者是否一致，以实现所述总线验证。

例如，在本公开至少一实施例提供的一种检查总线验证的方法中，根据所述模型，生成覆盖率代码，包括：根据所述模型，通过脚本自动化地生成所述覆盖率代码或者手动编写以生成所述覆盖率代码。

例如，在本公开至少一实施例提供的一种检查总线验证的方法中，根据所述模型，通过脚本自动化地生成所述覆盖率代码，包括：

提供被验证的所述总线的配置文件；

提供用于所述覆盖率代码的代码模板以及代码生成脚本；

将所述配置文件和所述代码模板，输入到所述代码生成脚本，生成与所述模型对应的覆盖率代码。

例如，在本公开至少一实施例提供的一种检查总线验证的方法中，所述多个场景包括第一场景、第二场景、第三场景或第四场景，N个主设备和M个从设备被配置为与所述总线通信，N和M为大于1的整数，所述第一场景表示所述N个主设备的其中每一个访问所述M个从设备中每个从设备的公共空间，所述第二场景表示所述N个主设备中的至少两个主设备访问所述M个从设备中每个从设备的非公共空间，所述第三场景表示响应于所述N个主设备中的至少两个主设备分别访问源地址，将对所述源地址的访问映射成对多个不同的目标地址的访问，其中，每个所述目标地址表示被访问的所述从设备的地址，所述第四场景表示配置寄存器，其中，所述寄存器用于配置所述总线的至少部分特性。

例如，在本公开至少一实施例提供的一种检查总线验证的方法中，根据所述第一场景和所述第二场景，通过多层级关系映射建立多个覆盖仓，包括：

建立用于所述第一场景和所述第二场景的第一覆盖组；

建立用于所述第一覆盖组的第一覆盖点、第二覆盖点、第三覆盖点以及第四覆盖点，其中，每个所述第一覆盖点包括一个所述主设备发出事务的类型，每个所述第二覆盖点包括一个所述主设备访问被允许访问的空间，每个所述第三覆盖点包括一个所述主设备访问不被允许访问的空间，每个所述第四覆盖点包括所述第一覆盖点和所述第二覆盖点的交差覆盖率点；

建立分别用于每个所述第一覆盖点、所述第二覆盖点、所述第三覆盖点以及所述第四覆盖点的n1个第一覆盖仓、n2个第二覆盖仓、n3个第三覆盖仓以及n4个第四覆盖仓，n1、n2、n3和n4为大于1的整数，其中，每个所述第一覆盖仓对应一种事务类型，每个所述第二覆盖仓对应所述被允许访问的空间的一个分段，每个所述第三覆盖仓对应所述不被允许访问的空间的一个分段，每个所述第四覆盖仓对应对所述被允许访问的空间的读或写操作。

例如，在本公开至少一实施例提供的一种检查总线验证的方法中，所述被允许访问的空间包括至少部分的所述公共空间和/或至少部分的所述非公共空间，所述不被允许访问的空间包括至少部分的所述非公共空间。

例如，在本公开至少一实施例提供的一种检查总线验证的方法中，根据所述第三场景，通过多层级关系映射建立多个覆盖仓，包括：

建立用于所述第三场景的第二覆盖组；

建立用于所述第二覆盖组的第一覆盖点，其中，每个所述第一覆盖点包括访问一个所述源地址；

建立用于每个所述第一覆盖点的多个第一覆盖仓，其中，每个所述第一覆盖仓对应一个被映射且待访问的所述目标地址。

例如，在本公开至少一实施例提供的一种检查总线验证的方法中，根据所述第四场景，通过多层级关系映射建立多个覆盖仓，包括：

建立用于所述第四场景的第三覆盖组；

建立用于所述第三覆盖组的第一覆盖点，其中，每个所述第一覆盖点包括一个寄存器；

建立用于每个所述第一覆盖点的多个第一覆盖仓，其中，每个所述第一覆盖仓对应所述寄存器被配置的一个域。

例如，在本公开至少一实施例提供的一种检查总线验证的方法中，响应于所述覆盖率代码应用于所述仿真工具，所述仿真工具自动地进行功能覆盖率的收集，包括：配置为在监测到有响应返回到所述主设备时进行信息采集，通过将采集的所述信息还原成对应的场景，用以实现所述功能覆盖率的收集。

例如，在本公开至少一实施例提供的一种检查总线验证的方法中，还包括：基于当前得到的所述多个场景的功能覆盖率的收集结果，以及设定的验证计划，迭代优化所述模型，以优化所述覆盖率代码，其中，每一次迭代包括：

将所述总线验证中无法实现验证的场景，映射成不用于计算覆盖率的多个可忽略的仓。

本公开至少一实施例提供了一种检查总线验证装置，包括：

建模单元，被配置为根据总线验证的多个场景建立模型，其中，所述模型被配置为将所述多个场景分别映射成用于计算覆盖率的多个覆盖仓，用以收集所述多个场景的功能覆盖率；

仿真工具，被配置为根据所述模型自动收集所述多个场景的功能覆盖率，其中，所述仿真工具被配置为运行根据所述模型生成的覆盖率代码，使得所述仿真工具自动地进行所述功能覆盖率的收集，得到所述多个场景的功能覆盖率的收集结果，以检查所述总线验证的完备性。

本公开至少一实施例提供了一种电子设备，包括：处理器和存储器，其中，所述存储器上存储有计算机程序，所述计算机程序被所述处理器执行时，实现如上述任一示例中的检查总线验证的方法。

本公开至少一实施例提供了一种计算机可读存储介质，其中，所述存储介质内存储有计算机程序，所述计算机程序被处理器执行时，实现如上述任一示例中的检查总线验证的方法。

附图说明

为了更清楚地说明本公开实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本公开的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为一种总线架构的示意图；

图2为本公开一些实施例提供的一种检查总线验证的方法的流程图；

图3为本公开一些实施例提供的一种总线验证的方法的流程图；

图4为本公开一些实施例提供的一种基于场景映射收集场景的功能覆盖率的流程示意图；

图5为本公开一些实施例提供的一种根据场景通过多层级关系映射建立多个覆盖仓的流程示意图；

图6为本公开一些实施例提供的一种总线验证中主从设备访问的场景的示意图；

图7为本公开又一些实施例提供的一种总线验证中主从设备访问的场景的示意图；

图8为本公开一些实施例提供的一种基于覆盖仓得到场景的功能覆盖率的流程示意图；

图9为本公开一些实施例提供的一种检查总线验证装置的示意框图；以及

图10本公开一些实施例提供的一种电子设备的示意框图。

具体实施方式

下面将结合本公开实施例中的附图，对本公开实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本公开一部分实施例，而不是全部的实施例。基于本公开中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本公开保护的范围。

除非另有定义，本公开实施例使用的所有术语(包括技术和科学术语)具有与本公开所属领域的普通技术人员共同理解的相同含义。还应当理解，诸如在通常字典里定义的那些术语应当被解释为具有与它们在相关技术的上下文中的含义相一致的含义，而不应用理想化或极度形式化的意义来解释，除非本公开实施例明确地这样定义。

本公开实施例中使用的“第一”、“第二”以及类似的词语并不表示任何顺序、数量或者重要性，而只是用来区分不同的组成部分。“一个”、“一”或者“该”等类似词语也不表示数量限制，而是表示存在至少一个。同样，“包括”或者“包含”等类似的词语意指出现该词前面的元件或者物件涵盖出现在该词后面列举的元件或者物件及其等同，而不排除其他元件或者物件。“连接”或者“相连”等类似的词语并非限定于物理的或者机械的连接，而是可以包括电性的连接，不管是直接的还是间接的。本公开实施例中使用了流程图用来说明根据本公开实施例的方法的步骤。应当理解的是，前面或后面的步骤不一定按照顺序来精确的进行。相反，可以按照倒序或同时处理各种步骤。同时，也可以将其他操作添加到这些过程中，或从这些过程移除某一步或数步。

图1为一种总线架构的示意图。系统级芯片(SoC，System-on-a-Chip，也可称片上系统)指一个有专用目标的集成电路。系统总线(Bus)是集成电路，其是SoC中的重要组成部分，如图1所示，总线连接了芯片中的各个设备(如主设备和从设备)，类似于人体的血管连接了人体的各个器官，其中，主设备(Master)可以发出各种事务(Transaction)通过总线访问从设备(Slave)。主设备(Master)是指发起访问请求的设备并且这些请求通过总线到达要访问的设备(例如从设备)，从设备(Slave)是指接收访问请求并给出响应的设备并且这些请求来自于总线。

随着芯片中设备的增加以及事务类型的增加，总线的复杂度也会大幅地增加。在大规模SoC系统中，主/从设备通过总线相互访问的场景数量巨大，则总线的验证质量也成为芯片成功与否的重要因素，例如，在总线工作正常的情况下，是不是所有主/从设备都已经进行了验证以及验证的场景是不是充分，这都决定了总线验证的质量。如何保证总线验证的完备性，成为了决定总线验证质量的关键问题。

在总线验证中，可以使用验证单元组件(VIP，一般是指已开发好并具有完备功能的验证单元组件)来替换各个主从设备(Master/Slave)，从而实现更多场景的仿真。在制作验证计划时，需要规划出需要进行验证的场景，最后通过统计所规划的场景是否都被验证到，以判断总线验证的质量。例如，功能覆盖率(Functional Coverage)作为一种判断总线验证充分性的手段，比如用于检查所规划的场景是否遍历(也即覆盖)。

发明人发现，例如总线上一个主设备和另一个从设备之间访问、响应的场景是典型场景，而这类场景的总数随着设备数量的增加而呈几何级数的增加，最终导致场景统计的工作量非常大。例如，在以往的总线验证中，场景总数一般由人工清点统计，首先，统计的时候由于场景数量比较大，导致计数的准确性存在疑问，其次，在评审功能覆盖率报告(即统计收集到的功能覆盖率结果的汇总报告)的时候，评审人员也不容易判断功能覆盖率报告上数据的准确性。当然也有些方法是采用v-plan等统计工具去获取功能覆盖率，但是本质上还是需要人工去统计计数，并没有减少太多工作量，也没有提高报告上数据的质量。

本公开至少一实施例提供了一种检查总线验证的方法，包括：

根据总线验证的多个场景建立模型，其中，该模型被配置为将多个场景分别映射成用于计算覆盖率的多个覆盖仓，用以收集多个场景的功能覆盖率；

根据模型，生成覆盖率代码；

将覆盖率代码应用于仿真工具，使得仿真工具自动地进行功能覆盖率的收集，得到多个场景的功能覆盖率的收集结果，以检查总线验证的完备性。

该实施例的检查总线验证的方法根据总线验证的各种场景进行建模，将场景映射成多个覆盖仓，并基于建立的模型生成覆盖率代码，使用仿真工具自动地进行功能覆盖率的收集，自动化地实现总线验证的完备性的检查，解决了人工统计检查的工作量大以及质量低的问题。

本公开至少一实施例还提供了一种检查总线验证的装置。

图2为本公开一些实施例提供的一种检查总线验证的方法的流程图。

例如，在图2的示例中，该检查总线验证的方法包括步骤S1至步骤S3。

步骤S1、根据总线验证的多个场景建立模型，其中，该模型被配置为将多个场景分别映射成用于计算覆盖率的多个覆盖仓(也称Bin)，用以收集多个场景的功能覆盖率；

步骤S2、根据模型，生成覆盖率代码；

步骤S3、将覆盖率代码应用于仿真工具，使得仿真工具自动地进行功能覆盖率的收集，得到多个场景的功能覆盖率的收集结果，以检查总线验证的完备性。

图3为本公开一些实施例提供的一种总线验证的方法的流程图。

例如，在图3的示例中，对于步骤S1，总线验证进一步包括：

S101、使用一个或多个VIP作为被验证的总线的至少部分的主设备和/或从设备，其中，被配置作为主设备的VIP产生各种不同类型的事务并将产生的该事务通过总线的主设备接口送至总线，被配置作为从设备的VIP通过总线接收来自主设备接口的事务并给予响应，且将产生的响应事务通过总线的从设备接口返回至总线；

S102、将监视器连接到总线的监视端口，其中，总线的监视端口包括总线的主设备接口和从设备接口，监视器用于收集并还原通过监视端口的所有事务；

S103、创建记分板，其中，记分板分别接收来自验证单元组件和监视器的事务，并对来自验证单元组件的事务进行预测得到预测的响应事务，响应于监视端口监测到事务，记分板比对预测的响应事务和监视器的所有事务中的响应事务，判断两者是否一致，以实现总线验证。

例如，在图3示例中，对于监视器用于收集并还原通过监视端口的所有事务，进一步包括：事务可以不完全等于通过接口的信号，VIP可以将事务转换成接口上的信号，也可以将接口上的信号还原成事务，本公开对此不作限制和赘述。另外，响应于监视端口监测到事务，其含义包括：在监视器监视到监视端口的信号变化并根据协议发现该信号变化能构成一个事务的时候。例如，在一些示例中，VIP可以通过软件、硬件或者两者的结合等实现，本公开对此不作限制。

下文所述的检查总线验证的方法主要是基于图3示例的总线验证方法进行的功能覆盖率收集，该检查总线验证的方法是在图3示例的总线验证方法验证结束后进行，例如，该检查总线验证的方法中用于映射的多层级关系以及各层级的覆盖单元等具体内容与总线验证相适配，并且需要说明的是，本公开的检查总线验证的方法适用的总线验证方法不仅限于此，还可以适用于其他任意方式的总线验证方法，本公开在此不作限制，也不再赘述。

图4为本公开一些实施例提供的一种基于场景映射收集场景的功能覆盖率的流程示意图。

例如，在图4的示例中，对于步骤S1，模型被配置为将多个场景分别映射成用于计算覆盖率的多个覆盖仓，用以收集多个场景的功能覆盖率，进一步包括：

步骤S11、根据多个场景，分别通过多层级关系映射建立多个覆盖仓；

步骤S12、获取步骤S11的多个覆盖仓中被命中的覆盖仓的数目；

步骤S13、基于步骤S12中被命中的覆盖仓的数目占据多个覆盖仓的总数的百分比，以及多层级关系映射，得到多个场景的功能覆盖率。

图5为本公开一些实施例提供的一种根据场景通过多层级关系映射建立多个覆盖仓的流程示意图。

例如，在图5的示例中，对于步骤S11，根据多个场景，分别通过多层级关系映射建立多个覆盖仓，进一步包括：

步骤S1101、建立用于多个场景中一个或多个的覆盖组(Covergroup)，其中，覆盖组用于对多个场景进行分组以实现覆盖率的分组；

步骤S1102、建立用于每个覆盖组的一个或多个覆盖点(Coverpoint)，其中，每个覆盖组的覆盖点作为该覆盖组的下一层级映射目标；

步骤S1103、建立用于每个覆盖点的覆盖仓(Bin)，其中，每个覆盖点的覆盖仓作为该覆盖点的下一层级映射目标。

例如，在一些示例中，覆盖组(Covergroup)是SystemVerilog里的一个语法结构，用于对覆盖率进行分组并收集，其中，SystemVerilog是编写验证环境时使用的一种面向对象的高级语言。例如，在一些示例中，覆盖点(Coverpoint)是SystemVerilog里的一个语法结构，用于对覆盖组中的测试点进行覆盖率的收集。例如，在一些示例中，覆盖仓(Bin)是SystemVerilog里的一个语法结构，用于对上述测试量中的具体项目进行覆盖率的收集。

应该理解的是，本文任一示例中的覆盖组、覆盖点和覆盖仓是指针对总线验证的场景的覆盖率并利用语法结构所规定的三个维度的概念，这意味着覆盖组、覆盖点和覆盖仓的具体含义需要本领域技术人员根据本公开全文的内容去理解，而不能单单地从命名上与其他技术方案一概而论，例如用功能覆盖率描述是否集成电路设计的所有的预期功能在验证中都得到了验证，其技术背景、目的和方案均与本公开的实施例不同。

例如，针对本公开的实施例的总线验证的场景，使用SystemVerilog语言中的功能覆盖率进行建模，比如当收集到100％的覆盖率时，可以认为针对该类场景，设计师所构造的场景数量是足够的。由此，本公开实施例的方法为检查验证完备性提供了可执行的方式，为抽象的场景提供了有效的建模方式，并减少了人工的工作量。而且，目前还未有文献记载记载将总线验证的多个场景映射成多个覆盖仓并基于生成的覆盖率代码使用仿真工具自动地进行功能覆盖率的收集。

例如，在检查总线验证中可以用不同层级的功能覆盖单元进行覆盖，例如上述示例的覆盖组、覆盖点和覆盖仓这三层。例如，一个覆盖组可以包括至少一个覆盖点，一个覆盖点可以包括至少一个覆盖仓，覆盖仓(bin)是用于收集场景的功能覆盖率的最小单位。例如，根据System Verilog的语法，当满足了有关一个覆盖仓设定的条件的时候就称为命中，并且在命中的时候进行覆盖率收集，则仿真工具认为该覆盖仓已被覆盖。

例如，在一些示例中，针对某个或某些场景建立的各个覆盖组，分别建立的多个覆盖仓的总数记为P，其中，P为大于1的整数。

需要说明的是，本公开实施例的建模方式不仅限于覆盖组、覆盖点和覆盖仓这三个层级，还可以采用其他数目的层级，例如采用四个层级的功能覆盖单元进行覆盖，比如在覆盖组这一层级之上再增设一个覆盖单元层级，本公开对此不作限制和赘述，具体可以实际需要进行自由调整。由此，本公开实施例的方法具体良好的通用性和可扩展性。

图6为本公开一些实施例提供的一种总线验证中主从设备访问的场景的示意图。图7为本公开又一些实施例提供的一种总线验证中主从设备访问的场景的示意图，其中，图7的场景是主从设备进行Multi-cast(广播式)访问的场景，Multi-cast是指一种访问方式，例如主设备访问特定地址时，访问会被映射成对多个目标地址的访问。

例如，在图6的示例中，总线上连接N个主设备和M个从设备，N和M为大于1的整数。例如，在一些示例中，上述步骤S1中的总线验证的多个场景包括第一场景、第二场景、第三场景或第四场景。

例如，在图6的示例中，第一场景A表示N个主设备的其中每一个访问M个从设备中每个从设备的公共空间，即图6所示的任一主设备出发的所有虚线箭头。例如，在图6的示例中，第二场景B表示N个主设备中的至少两个主设备访问M个从设备中每个从设备的非公共空间(例如私有或配置空间)，而其它的主设备不能访问，即图6所示的多个主设备出发的所有虚线箭头表示第二场景(比如图6所示的所有的虚线箭头组成了第二场景)。

例如，在图7的示例中，第三场景C表示响应于N个主设备中的至少两个主设备分别访问各个源地址a(也可称为特定地址)，分别将对每个源地址的访问映射成对多个不同的目标地址b的访问，其中，图7中的源地址a可以是任意的地址，图7标记的位置处仅仅是一种示意图，另外，每个目标地址b表示被访问的从设备的地址，每个从设备都有自己的地址。

例如，在一些示例中，第四场景D表示配置寄存器(未图示)，比如，总线的某些特性是在使用总线之前通过寄存器配置的。

需要说明的是，上述第一场景、第二场景、第三场景、第四场景都是一些典型场景，但是本公开对总线验证的场景不作限制，还可以是其他任何的场景，本公开不做穷举和赘述。

发明人还发现，例如总线验证中使用的VIP可以自带一些功能覆盖率的统计，但是该统计仅能针对某一个设备发出的事务的类型及得到的响应进行统计，无法满足对整个总线网络的场景进行统计的需求。

而对于本公开实施例的步骤S1，例如，在一些示例中，多个场景中每个包括：响应于总线验证，与被验证的总线通信的至少两个设备(例如主设备和从设备)之间通过总线进行信息(例如数据或操作指令等)传输的场景，比如上文涉及的第一场景、第二场景、第三场景、第四场景。由此，本公开的检查总线验证的方法可以满足对整个总线网络的场景进行统计的需求，还具体良好的通用性和可扩展性，例如，本公开可以适用于所有主从设备之间产生的任何场景，本公开能够应用到任何不同形式的总线网络(如JTAG网络、PCI网络)中基于场景的验证的检查。

对于步骤S1，例如，在一些示例中，根据第一场景和第二场景，通过多层级关系映射建立多个覆盖仓，包括：

(i)建立用于第一场景和第二场景的第一覆盖组；

(ii)建立用于第一覆盖组的第一覆盖点、第二覆盖点、第三覆盖点以及第四覆盖点，其中，每个第一覆盖点包括一个主设备发出事务的类型，每个第二覆盖点包括一个主设备访问被允许访问的空间，每个第三覆盖点包括一个主设备访问不被允许访问的空间，每个第四覆盖点包括第一覆盖点和第二覆盖点的交差覆盖率点；

(iii)建立分别用于每个第一覆盖点、第二覆盖点、第三覆盖点以及第四覆盖点的n1个第一覆盖仓、n2个第二覆盖仓、n3个第三覆盖仓以及n4个第四覆盖仓，n1、n2、n3和n4为大于1的整数；例如，每个第一覆盖仓对应一种事务类型(例如读操作，写操作，原子操作)，每个第二覆盖仓对应被允许访问的空间的一个分段(比如被允许访问的空间被分成了若干段，当第二覆盖仓命中，则表示主设备成功访问这个空间内的地址)，每个第三覆盖仓对应不被允许访问的空间的一个分段(比如不被允许访问的空间被分成了若干段，当第三覆盖仓命中表示主设备访问了这个空间内的地址并得到了译码错误的响应)，每个第四覆盖仓对应对被允许访问的空间的读或写操作(比如使用自动建仓)。

例如，在一些示例中，被允许访问的空间包括至少部分的公共空间和/或至少部分的非公共空间，不被允许访问的空间包括至少部分的非公共空间。

对于步骤S1，例如，在一些示例中，根据第三场景，通过多层级关系映射建立多个覆盖仓，包括：

(i)建立用于第三场景的第二覆盖组；

(ii)建立用于第二覆盖组的第一覆盖点，其中，每个第一覆盖点包括访问一个源地址，即为每一个源地址建立一个覆盖点；

(iii)建立用于每个第一覆盖点的多个第一覆盖仓，其中，每个第一覆盖仓对应一个被映射且待访问的目标地址，即将对映射到的每一个目标地址的访问作为一个覆盖仓，若该覆盖仓命中，则说明访问源地址时目标地址被访问了。

由于总线的特性配置对应寄存器里的域，当配置了寄存器的域，就表示对该域对应的总线特性进行验证，由此，对于步骤S1，例如，在一些示例中，根据第四场景，通过多层级关系映射建立多个覆盖仓，包括：

(i)建立用于第四场景的第三覆盖组；

(ii)建立用于第三覆盖组的第一覆盖点，其中，每个第一覆盖点包括一个寄存器，即为每个寄存器建立一个覆盖点；

(iii)建立用于每个第一覆盖点的多个第一覆盖仓，其中，每个第一覆盖仓对应寄存器被配置的一个域，即为寄存器中每个域建立一个覆盖仓，若该覆盖仓命中，则表示配置过寄存器的该域并对此域配置的特性进行了验证。

图8为本公开一些实施例提供的一种基于覆盖仓得到场景的功能覆盖率的流程示意图。

例如，在图8的示例中，对于步骤S13，基于被命中的覆盖仓的数目占据多个覆盖仓的总数的百分比，以及多层级关系映射，得到多个场景的功能覆盖率，进一步包括：

步骤S1301、使得每个覆盖点的覆盖率等于该覆盖点对应的多个覆盖仓中被命中的覆盖仓的数目Q占据多个覆盖仓P的总数的百分比Q/P；

步骤S1302、根据每个覆盖组对应的一个或多个覆盖点各自的覆盖率，得到覆盖组的覆盖率；

步骤S1303、根据每个覆盖组的覆盖率，得到多个场景的功能覆盖率。

值得注意的是，图8仅仅为示例性的，本公开对场景的功能覆盖率的具体计算方式不作限制，具体可以根据实际需要进行自由调整，本公开对此不作限制和赘述。

对于步骤S2，例如，在一些示例中，根据模型，生成覆盖率代码，进一步包括：根据模型，通过脚本自动化地生成覆盖率代码或者手动编写以生成覆盖率代码。

具体地，根据模型，通过脚本自动化地生成覆盖率代码，进一步包括：

(1)提供被验证的总线的配置文件；

(2)提供用于覆盖率代码的代码模板以及代码生成脚本；

(3)将配置文件和代码模板，输入到代码生成脚本，生成与模型对应的覆盖率代码。

例如，在一些示例中，对应被验证的总线的配置文件包括设计中总线的各种配置信息(比如地址位宽、数据位等宽)，其中，由于场景涉及多个主从设备，但是对于建模来说主设备和从设备整体比较类似，例如只是部分参数不同(比如传输能力等等)，则可以将这些区别提取出来并写成配置文件。例如，在一些示例中，代码模板可以按照System Verilog的标准进行编写。

由上可知，通过为生成覆盖率代码专门制作了代码生成脚本，既可以减小工作量和代码维护的难度，也能更好地保证功能覆盖率的完整性，同时，收集场景的功能覆盖率的流程也便于集成到整个验证流程中，提高整体验证工作的自动化的程度。

需要说明的是，虽然生成与场景对应的覆盖率代码的作用是为了收集覆盖率，但是覆盖率采集的过程可以是仿真工具按照System Verilog的语法具体执行实现。例如，该仿真工具是指进行覆盖率收集的工具，仿真工具可以是仿真软件，例如是各家EDA厂商的仿真软件，本公开对此不作限制，只要能够实现覆盖率的收集即可。

对于步骤S3，例如，在一些示例中，响应于覆盖率代码应用于仿真工具，仿真工具自动地进行功能覆盖率的收集，包括：仿真工具被配置为在监测到有响应返回到主设备时进行信息采集，通过将采集的信息还原成对应的场景，用以实现功能覆盖率的收集。例如，仿真工具被配置为在监测到有响应返回到主设备时进行信息采集可以理解为利用覆盖率代码告知仿真工具在何种时机进行信息的采集，因为仿真工具不会在整个阶段中时刻进行收集，该部分的具体作用也是会编写在覆盖率代码中，另外，此处被配置在监测到有响应返回到主设备时进行信息采集只是一种时机的示例，例如，仿真工具可以进行密集性地采集，也可以进行稀疏性地采集，本公开并不仅限于此，在此不再赘述。

例如，在监测到有响应返回到主设备时进行采集的信息如下所示：

(一)对于第一覆盖组，采集的信息包括但不限于：(1)发起事务的主设备名；(2)事务的类型；(3)目标地址；(4)响应的类型；由此收集到主设备访问从设备、访问是读还是写以及是访问成功还是被从设备拒绝等信息。

对于(一)具体而言，例如，在一些示例中，针对第一场景所采集的信息，若要想描述一个主设备访问从设备的场景，需要收集的信息：(a)发起事务的主设备名；(b)事务的类型；(c)目标地址；(d)响应的类型；则被拼接还原的场景是指：(1)发起了(2)类型的事务，访问了(3)，并得到了(4)类型的响应。

(二)对于第二覆盖组，采集的信息包括但不限于：(1)发起事务的主设备名；(2)源地址；(3)各映射的目标地址是否收到事务请求(4)响应的类型；由此收集到各个映射的目标地址是否通过该方式被访问过等信息。

(三)对于第三覆盖组，采集的信息包括但不限于：(1)被配置设备；(2)寄存器地址；(3)配置值。由此可以根据寄存器地址得到寄存器的名字，并且根据配置值得到某些寄存器的域被配置成的一些特性。

值得注意的是，本公开对上述采集的具体信息不作限制，上述仅为示例性的，而非对本公开的限制。应该理解的是，仿真工具收集场景的覆盖率是指对上述信息的采集，并且不同场景所对应的信息也不同，通过覆盖率代码可以将这些信息还原成对应的场景，即收集到这些信息，即可知道总线验证仿真中出现过什么样的场景，从而可以知道需要验证的场景是否都出现进行验证过，以及是否还存在想验证但是还没有验证的场景，最终利用仿真工具进行自动收集得到场景的功能覆盖率的收集结果，例如生成功能覆盖率的报告。例如，针对上文所述的在监测到有响应返回到主设备时进行信息采集，其具体作用也是会编写在覆盖率代码中，并且该部分的内容主要为原理解释，而在实际操作时，例如，基于业界通用的语言去生成覆盖率代码，直接将编写好的覆盖率代码在仿真工具上运行即能实现功能覆盖率的收集，并得到功能覆盖率的报告。

由此，本公开实施例生成的功能覆盖率的报告，更适合后期对验证工作的验收和评审，并且为总线验证的完备性检查设立了可衡量的标准，例如，验收的目标可以清晰地定义成一个覆盖率数值，评审人员也很容易知道哪些场景经过验证，以及哪些场景还没有被覆盖，而且由于报告数据是由仿真工具收集，这时只需要详细地评审覆盖率代码，就可以保证该数据的质量，减少人为统计出错的概率，因此，提高了数据的准确性和可靠性，降低了评审的难度，提高了评审的质量。

例如，在一些示例中，功能覆盖率等于通过仿真工具运行后得到已覆盖的场景数目除以预设的理想场景数目(即上述的需要进行验证的场景)，比如该预设的理想场景数目等于建模中所有覆盖组包括的所有覆盖点对应的覆盖仓的总数。值得说明的是，例如此处所述的得到已覆盖的场景和需要进行验证的场景中的场景均可以是指上述采集的信息拼接形成的每一个具体场景，和上文所述第一场景A、第二场景B、第三场景C、第四场景D的含义并非完全相同，不能单单地从命名上直接等价，具体要根据本公开全文的内容去理解，本公开在此不作赘述。

例如，若存在两个主设备以及两个从设备，考虑主设备访问任一从设备的场景，则预设的理想的场景数目应该是四个场景，若通过仿真工具运行后得到已覆盖的场景数目是三个场景，则功能覆盖率等于75％，则后续需要进行评审分析，例如分析哪个场景没有被覆盖到。

例如，在一些示例中，检查总线验证方法还包括：基于当前得到的多个场景的功能覆盖率的收集结果，以及设定的验证计划，迭代优化模型，以优化覆盖率代码。例如，每一次迭代包括：将总线验证中无法实现验证的场景(例如不支持的场景或者达不到的场景)，映射成不用于计算覆盖率的多个可忽略的仓(ignore_bin)。需要说明的是，该迭代优化的步骤一般发生在进行某次的功能覆盖率分析后并在对覆盖率代码进行优化时执行，比如，在检查验证的过程中，验证人员会收集覆盖率数据并进行分析，然后优化后再收集以及再分析，反复迭代，直至达到验证计划。

例如，在一些示例中，当设置可忽略的仓后，这些可忽略的仓会从覆盖率计算中除去。比如，针对某次功能覆盖率分析，当前一共是有5个场景，若根据收集结果得知仅仅覆盖到了3个场景，还有2个场景没有被覆盖到，例如根据任一合适的功能覆盖率计算方法得到功能覆盖率为60％，并且对没被覆盖到的2个场景进行分析后发现其可以忽略(例如这两个场景属于不支持的场景或者达不到的场景)，因此，将这两个场景映射成多个可忽略的仓进行优化，然后再次收集功能覆盖率，此时只计算有关3个场景的覆盖率，最终根据收集结果可知覆盖到了这3个场景，对应的功能覆盖率达到100％，所以，有关设置可忽略的仓的步骤是对功能覆盖率结果进行优化的步骤，至于是否需要该优化步骤，具体需要根据需要进行自由调整，本公开对此不作限制。

例如，在一些示例中，要求达到的功能覆盖率是在验证计划时进行设定，本公开对要求达到的功能覆盖率不作限制(例如100％的功能覆盖率)，也对验证计划的制定标准不作限制，具体可以根据实际需要进行自由调整。

本公开上述实施例的检查总线验证的方法将验证的各个场景分别映射成多个覆盖仓，基于生成的覆盖率代码，使用仿真工具自动地进行功能覆盖率的收集，自动化地实现总线验证的完备性的检查，解决了人工统计检查的工作量大以及质量低的问题。本公开至少一实施例应用在SoC系统配置总线的验证中，为主设备访问从设备及权限、广播式访问场景、功能特性验证等，提供了验收的依据，也可以通过本公开实施例检查出验证中的不足之处，并增加相应的验证测试项目。

图9为本公开一些实施例提供的一种检查总线验证装置的示意框图。在图9所示的示例中，该检查总线验证装置100包括建模单元110和仿真工具120。建模单元110被配置为根据总线验证的多个场景建立模型，其中，模型被配置为将所述多个场景映分别射成用于计算覆盖率的多个覆盖仓，用以收集多个场景的功能覆盖率。仿真工具120被配置为根据模型自动收集多个场景的功能覆盖率，其中，仿真工具120被配置为运行根据模型生成的覆盖率代码，使得仿真工具120自动地进行功能覆盖率的收集，得到多个场景的功能覆盖率的收集结果，以检查总线验证的完备性。

需要注意的是，在本公开的实施例中，该检查总线验证装置100可以包括更多或更少的模块，并且各个模块之间的连接关系不受限制，可以根据实际需求而定。各个模块的具体构成方式不受限制。关于检查总线验证装置100的技术效果可以参考本公开上述实施例中提供的检查总线验证的方法的技术效果，这里不再赘述。

以上实施例中的各个模块可被分别配置为执行特定功能的软件、硬件、固件或上述项的任意组合。例如，这些模块可对应于专用的集成电路，也可对应于纯粹的软件代码，还可对应于软件与硬件相结合的模块。

需要说明的是，尽管以上在描述检查总线验证装置时将其划分为用于分别执行相应处理的模块，然而，本领域技术人员清楚的是，各模块执行的处理也可以在检查总线验证装置不进行任何具体模块划分或者各模块之间并无明确划界的情况下执行。

例如，在一些示例中，本公开实施例的检查总线验证的方法可被记录在计算机可读记录介质中。具体地，本公开实施例可提供一种存储有计算机可执行指令的计算机可读记录介质，当计算机可执行指令被该计算机的处理器执行时，可促使该计算机处理器执行如上所述的检查总线验证。计算机可读记录介质的示例可包括磁介质(例如硬盘、软盘和磁带)；光学介质(例如CD-ROM和DVD)；磁光介质(例如，光盘)；以及特别配制用于存储并执行程序指令的硬件装置(例如，只读存储器(ROM)、随机存取存储器(RAM)、闪存等)。

图10本公开一些实施例提供的一种电子设备的示意框图。如图10所示，本公开至少一实施例还可提供一种电子设备200，该电子设备200包括处理器210和存储器220，存储器220用于存储非暂时性计算机可读指令(例如一个或多个计算机程序模块)，处理器210用于运行非暂时性计算机可读指令，非暂时性计算机可读指令被处理器210运行时可以执行上文的检查总线验证的方法中的一个或多个步骤。需要说明的是，本公开的实施例中，电子设备200的具体功能和技术效果可以参考上文中关于检查总线验证的方法的描述，此处不再赘述。

有以下几点需要说明：

(1)本公开实施例附图只涉及到本公开实施例涉及到的结构，其他结构可参考通常设计。

(2)在不冲突的情况下，本公开的实施例及实施例中的特征可以相互组合以得到新的实施例。

以上所述，仅为本公开的具体实施方式，但本公开的保护范围并不局限于此，本公开的保护范围应以所述权利要求的保护范围为准。