日常记录（77）翻译2、功能覆盖率、测试计划

功能覆盖率

功能验证的目的是确定我们规范中定义的设计要求是否按预期运行。但是，您如何知道所有指定的功能是否都实际实现了呢？此外，我们如何知道是否所有指定的功能都经过了真正的测试？代码覆盖率指标无法帮助我们回答这些问题。

在本节中，我们将介绍一种称为功能覆盖率的显式覆盖率指标，它可以与设计规范书或实现覆盖率空间相关联。测量功能覆盖率的目的是测量与设计功能要求相关的验证进度。也就是说，功能覆盖帮助我们回答这个问题：是否所有指定的功能需求都已实现，然后在仿真过程中执行？关于如何创建功能覆盖模型的详细信息将在功能覆盖率测试计划一章中单独讨论。

优点:

功能覆盖的起源可以追溯到20世纪90年代，当时出现了受约束的随机仿真。显然，受约束的随机激励生成的价值主张之一是，仿真环境可以自动生成数千个测试，这些测试通常需要大量的手动工作来创建定向测试。然而，受约束的随机激励生成的一个问题是，如果没有在仿真运行后冗长乏味地检查波形的努力，你永远无法确切知道测试了哪些功能。因此，功能覆盖率被发明为一种测量方法，以帮助准确确定仿真回归测试的功能，而无需对波形进行目视检查。

如今，功能覆盖的采用不仅限于受约束的随机仿真环境。事实上，功能覆盖率提供了一种在仿真期间执行需求跟踪的自动方法，这通常是DO-254合规性检查所需的关键步骤。例如，功能覆盖可以通过链接到规范书中定义的特定需求的机制来实现。然后，在仿真运行之后，通过特定的定向或受约束的随机测试检查的需求，可以自动被测量，从未测试过的需求得到自动确定。

局限:

由于功能覆盖率不是一个隐含的覆盖率指标，所以无法自动提取。因此，这需要用户手动创建覆盖率模型。从上层来看，创建功能覆盖模型需要考虑两个不同的步骤：

1. 确定您要测量的功能或设计意图
2. 实现测量功能或设计意图的机制

第一步是通过验证计划来解决，详细内容将在从测试计划到功能覆盖的部分中介绍。

第二步涉及对验证计划步骤中确定的每个覆盖项目的机制进行编码（例如，为验证计划中确定的每个验证目标编码一组SystemVerilog CoverGroup）。在覆盖模型实施阶段，还需要考虑许多细节，例如：确定触发测量的适当点，以及为了测量而定义的可控性（禁用/启用）方面。这些和许多其他细节将在详细的覆盖率示例中解决。

由于功能覆盖率必须手动创建，因此在覆盖率模型中始终存在某些指定功能缺失的风险。

功能覆盖率指标的类型

任何设计的功能行为，至少从验证环境中的任何接口观察到的，都由数据和时序组件组成。因此，从高上层来看，我们需要考虑两种主要类型的功能覆盖度量：覆盖组和覆盖属性。

覆盖组建模

关于功能覆盖率，设计模型内或接口上状态值的采样可能是最容易理解的。我们将这种形式的功能覆盖称为覆盖组建模。它由总线上观察到的状态值、接口控制信号分组以及寄存器组成。关键是，被测量的值出现在一个单独的显式或隐式采样的时间点上。SystemVerilog covergroups是我们通常用于构建功能数据覆盖模型的机制的一部分，详细信息将在块级设计示例以及相应covergroups实现的示例讨论中讨论。

覆盖属性建模

就功能覆盖而言，在事件序列之间的时序关系可能是最难解释的。然而，确保对这些事件序列进行适当测试是很重要的。我们使用覆盖属性建模来度量事件序列之间的时序关系。覆盖属性最流行的例子可能涉及总线协议上控制信号之间的握手序列。其他示例包括与验证低功耗设计相关的电源状态转换覆盖率。断言和覆盖属性是我们用来构建时序覆盖模型的机制的一部分，它们在总线协议监视器示例中进行了说明。。

断言覆盖率

断言覆盖率一词在当今行业中有很多含义。例如，有些人将断言覆盖率定义为断言数与RTL代码行数的比率。然而，断言密度通常是一个用于此度量的更准确术语。在我们的讨论中，我们使用术语断言覆盖率来描述使用断言的覆盖率属性的实现。

覆盖组和覆盖属性的不同之处

为了帮助说明使用覆盖组和覆盖属性建模的覆盖之间的区别，让我们看一个简单非流水线的总线示例，如图1所示。

非流水线总线协议的一个写和读总线序列如图2所示。

为了验证我们的总线示例，测试地址总线的写序列和读序列的边界条件（即addr中某些点位包含全零和全一）很重要。此外，在回归过程中，我们在地址总线上覆盖了足够多的非边界条件，这一点也很重要。我们只感兴趣的是在从机被选中且选通使能激活时（即sel==1'b1&&en==1'b1）对地址总线进行采样。最后，我们希望跟踪这些覆盖项的单独写入和读取事件，以确保我们已经充分测试了这两个操作。

这是使用覆盖组对功能覆盖建模的一个示例（例如SystemVerilog covergroup构建）。此外，我们可以使用相同的数据覆盖率方法来测量读写数据总线。

现在，让我们看看这个例子中的覆盖属性。写入和读取周期都遵循标准顺序。例如，让我们检查一个写周期。在时钟1，由于从机选择（sel）和总线启用（en）信号都被取消断言，我们的总线处于INACTIVE状态。写入序列的第一个时钟称为总线START状态，主机通过断言一条从选择线（sel==1'b1）来启动总线初始化。在START状态期间，主机在总线上放置有效地址和有效数据。数据传输（称为总线ACTIVE状态）实际上发生在主机断言总线启用选通信号（en）时。在我们的例子中，它是在时钟3的上升沿检测到的。地址、数据和控制信号在整个ACTIVE状态下都保持有效。

当ACTIVE状态完成时，总线使能选通信号被总线主机取消断言，从而完成当前的单次写入操作。如果主设备已完成将所有数据传输至从设备（即，不再有写入操作），则主设备将取消断言从设备选择信号（sel）。否则，从机选择信号保持断言状态，总线返回到总线START状态以启动新的写入操作。多个背对背写入操作（不返回总线INACTIVE状态）称为突发写入。

从时序覆盖的角度来看，可以编写一组断言，以确保对总线上的状态序列的正确。例如，图3显示了唯一合法的总线状态转换。此外，测试单个写入和读取周期以及写入操作中的突发读取非常重要。事实上，我们可能想要测量各种突发写入和读取周期。

通过组合覆盖组和覆盖属性，我们能够实现更高忠实原设计的覆盖模型，从而更准确地测量设计的关键特征。

APB3总线协议监视器示例中介绍了如何对时间覆盖进行编码的详细信息。

典型功能覆盖率流程

在许多方面，典型的功能覆盖率流程与典型的代码覆盖率流程非常相似。收集和分析功能覆盖率指标的目的是从规范书中识别当前验证环境和在其上运行的测试用例尚未执行的特性和需求。从项目的角度来看，通常最好等到与覆盖率相关的测试用例的实现接近完成，然后才开始认真地收集和分析功能覆盖结果。否则，您可能会浪费大量的周期去试图从不断变化的激励中理解移动的目标。话虽如此，我们建议您至少在项目周期的早期（即，在认真收集覆盖指标之前）运行一些捕获覆盖率指标的仿真，以解决覆盖流程中的任何潜在问题。

从高层次的角度来看，功能覆盖率流程通常参与了四个主要步骤，包括：

1. 创建功能覆盖模型Create a functional coverage model
2. 如果使用断言，则测试RTL模型收集覆盖率
3. 运行仿真以捕获和记录覆盖率指标
4. 报告并分析覆盖结果

分析步骤的一部分是识别覆盖盲区，并确定覆盖盲区是否由以下三种情况之一造成：

1. 缺少激活未覆盖功能所需的输入激励
2. 设计（或testbench）中的一个缺陷，阻止输入激励激活未覆盖的功能
3. 某些IP配置未使用的功能，或在正常运行条件下预期无法实现的相关功能

第一个条件要求您要么编写额外的定向测试，要么调整随机约束，以生成针对未覆盖功能的所需输入激励。第二个条件显然要求工程师修复阻止未覆盖功能运行的缺陷。第三种情况可以通过设置覆盖工具在覆盖记录和报告步骤中排除未使用或无法访问的功能来解决。

 

 

规格书到测试计划

测试计划创建方法

创建覆盖率模型电子表格或测试计划的目标是捕获关于功能覆盖率的设计意图和行为的子集。这是一个耗时的手动过程，需要梳理各种设计规范文件，并一次提取一个必要的需求。最好由一个由架构师、设计师、固件和验证工程师组成的跨职能团队来完成，以获得多个观点和不同的输入。如果没有跨职能方面，设计意图的各类子集很容易被忽略。创建测试计划的最佳方式是召开多次会议，每次会议针对一个特定的设计区域（xyz区块），并持续一段固定的时间（1小时，下周每天早上9点）和一个目标（50个要求）。一般来说，可以采取两种方法：

1.自下而上：逐块或逐接口检查

2.自上而下：遵循芯片的使用模型或数据流。

两种方法

	自下而上	自上而下
定义	从可用的低级别详细设计和实施规范中提取需求。这种方法更面向设计。	从高层架构中提取需求，并使用模型规格书。这种方法以客户/验证/用户为导向。
赞成的意见	•     低垂果实：最容易找到、提取和按重要性处理。 •     更容易链接到覆盖率。 •     更容易达成覆盖率目标。 •     因为你梳理了每个块和接口，被提取的关键的、高度具体的和重要的覆盖率，可能会被自上而下的方法覆盖。	•     可以提供更有用、更高级别、更有趣的覆盖率信息，如利用率，以探索权衡。 •     可在设计规范完成之前完成，无需实现细节 •     使用流程图实现智能testbench自动化(ITA - Infact)。 •     强制以客户为中心看待设计。
反对的意见	•     需要完善的规范和实施细节。 •     可能导致需求激增。太多而无法在合理的时间内实施。需要考虑优先级。 •     倾向于低层级的无趣的覆盖率。大量的数据，很少有有用的信息来探索权衡。	•     需要接入具有明确使用模型定义的高层级规格书或架构。 •     使用模型有时会呈指数增长，导致迭代次数过多，覆盖空间巨大。 •     覆盖范围更倾向于上游、面向覆盖率的生成，而不是面向下游DUT或计分板的覆盖率。这可能会产生误导
Approach	召开一系列会议，每次会议的重点是设计的一个子集，如块或接口，并聚集合适的的规格书和工程人员以提取需求，细化需求，确定优先级，并将其与电子表格中的某个覆盖组、覆盖点或交叉点相联系。	与架构师举行一系列认真的会议，首先提出一个单独的高层级用例模型，然后创建一个用例模型文档。使用大量的图表（表格、图等）和最少的文字，深入讨论更多细节。然后把这份文件改成电子表格格式。

在自下而上和自上而下的方法之间选择

自下而上	自上而下
小型设计	大型设计
良好的设计规格书	良好的架构规格书
良好的实现规格书	使用模型信息访问
控制设计	数据转移设计
通用的(多)应用，被许多客户使用	单一应用，专门由一个或几个客户使用

通常可以使用自上而下和自下而上的组合。你可以从一个自上而下的流程开始，绘制出主要的流程，自然地产生类别，然后对每个类别进行自下而上的操作。在项目开始时，一旦某种形式的设计规范书准备好，那这样做是明智的。首先提取几百个需求，将它们放入电子表格，然后随着项目的进展添加更多需求。一些团队在提取和细化每个需求时，会立即将每个需求和覆盖元素相链接。其他人则将所有需求输入电子表格，然后进行第二次检查以添加随后的覆盖率链接。没有哪一种方法比另一种好，重要的是在你对特定需求细节记忆犹新的时候完成覆盖率链接。将链接留到项目的后期，意味着您必须重新查看每个需求及其相关文档，这将花费更长的时间。

自下而上的例子

下面是带有TX和RX路径的以太网芯片的框图。每条路径都有以太网帧通过的块管道。在各种配置下，其中一些块可以被复用输入或复用输出。此外，还有各种时钟配置，每个模块都有自己的配置设置细节。通过自下而上的方法，我们将检查每个模块的设计规范，并提取出该模块的需求。我们还将检查全局块和时钟多路复用设置，并提取出每个设置的要求。关键是将工作划分为小的、可消化的块或子块，以便在合理的时间内轻松提取详细的需求和行为。

要开始自下而上的方法，你需要做的第一件事是尽可能多地聚集了解设计的人，包括架构师、设计师、验证团队、各种接口的专家等等。接下来，一个团队需要将工作细分为一些逻辑上的、可管理的规模。这可以通过我的头脑风暴图来完成，也被称为思维导图。微软的Visio和类似的软件可以在团队一起集思广益时轻松捕获这些类型的图表。每个主题或子模块可以根据需要被进一步分解，它们都在头脑风暴图中相互关联。下面的头脑风暴图显示了以太网芯片的一个简单示例。对于更复杂的设计，头脑风暴图将有更多的子类别从每个块分支出来，将需求提取工作划分为可管理的数量。头脑风暴图中的每个分支可能最终成为以太网测试计划中相应的一个类别或子类别，或者如果很大，可能是它自己的分层电子表格。一些思维导图软件可以利用这些头脑风暴图，将信息导出到电子表格中，其中包含每个类别和子类别的章节号。这为您的测试计划提供了一个很好的起点和现成的框架。

头脑风暴图是一个很好的开始。然后可以分解每个分组或分支，并召开测试计划创建会议，以充实该特定主题的需求。在每次会议上，收集所有可用的设计和实现规范，以及该区块或主题的任何行业规范，以便参考。

一旦你有了一个主题，你就可以使用黄色粘滞法[1]，给一个团队提供便利贴，他们花20分钟把需求提取到黄色的便利贴上，然后把便利贴都贴在白板上，以便进一步分类。规则和特征被提取到详细的需求中，然后每一个都作为一行输入到一个带有标题的电子表格中，以及一个描述该需求本质的简要描述。请参阅下面关于需求的注意事项部分。

在每个需求中添加某种独特的字母数字需求标签号是一个好主意，尤其是当您有多个级别的需求时。然后可以使用这些标签将更高级别的需求与更低级别的需求联系起来，反之亦然。需求跟踪工具，比如ReqTracer，可以通过自动跟踪所有需求来进一步控制需求标签的命名和帮助。另一个好主意是添加其他有用的信息，这将有助于指导每个需求的进一步工作。这些额外的有用信息可能是需求来自规范中的位置、作者、注释、优先级、估计的工作量、稍后要回答的问题，等等。最后，每个需求都需要链接到一些特定的闭包元素，比如covergroup、coverpoint、cross、assertion、test、，等等。对每个被细化的需求进行第二次检查，并确定优先级是个好主意。有关推荐格式的描述和示例，请参见测试计划格式页面。

覆盖率烹饪书中的apb监视器、uart和datapath示例使用自下而上的规划方法。

[1] The Yellow Sticky Method is described in more detail in the book - Verification Plans: The Five-Day Verification Strategy for Modern Hardware Verification Languages by Peet James, Springer 2003.

关于编写需求的指导原则可以在“需求编写指南”一文中找到。在开始规划过程之前，核查小组最好先编制一份这样的清单，并将其分为规则（必须遵守）和建议（好主意）。实际上，这是为编写需求定义需求。

自上而下的例子

自上而下的方法可用于和自下而上相同的通用以太网设计。我们开发并遵循设计如何被用于实际应用的流程，而不是逐块进行。我们遵循芯片的使用模式，或者有时候叫做芯片的“生命中的一天”。电源接通了。先发生什么？然后呢？等等。对于这种以太网芯片，高层次使用模型有以下流程：

1。设置/配置

-块多路复用器配置

-时钟多路复用器配置

-然后配置每个块

2.数据路由

3.意外事件（LOS、错误等）

接下来，拓展这个基本的高级流程，展开更多细节。你可以一行一行地做，或者通过路径或模式来做。例如，可能某些块和时钟组合被命名为模式，因此您可以按模式深入了解更多细节。你也可以遵循一条路径，比如系统到线路，线路到系统。

这种方法的一个常见问题是，即使采用这种以太网流水线的设计，其流程简单，需求也很容易呈指数级爆炸，形成看起来太多的组合。这是很常见的，因此需要将爆炸重新处理为一些逻辑故障，如下图所示：

当你看上图中的两个部分时，左边的指数图看起来像一个巨大的不可关闭的覆盖组，而右边的覆盖组和覆盖点则是每个表格或图表的自然沉降物。因此，你取高层次使用模型流程的每个部分，然后你用任何表格或图表来展开每个部分，这些表格或图表对包含那些指数增长的特定的部分很有用。例如，在设置/配置的上述块muxing部分中，您可以开发一个潜在有用的设置表，并对每个设置进行命名。在其他情况下，Y-树、序列、气泡图或其他一些图表会更有用。通常，最好将高层次的使用模型流程和所有这些图表收集到一个新的使用模型文档中，并用最少的文字混合。

使用最能体现使用模型的每个领域指数性质的表格、图表或图表：

• 表格适用于小空间，如寄存器字段的几位或行为列表。
• 气泡图可以很好地显示任务或项目之间的关系，如电源区域及其设置。
• Y树图有助于显示选择和决策、and和or、优先级。
• 序列图显示了进展、因果、握手
• 始终可以将图表组合在一起，如上面的一组表格，通过线连接

参见WB SOC设计示例，了解这些图表在覆盖率上下文中如何使用的使用模型。

一旦你将你的使用模型分解成一个有用的图表和表格的渐进集合，最好将它们放在一个文档中，以便于查看和传播。有些团队将它们组合成一个大的图表;其他人将图表放在一起，在图之间用描述性的信息幻灯片进行演示。这些图表的其他格式包括文档（作为设计架构或实现规范的一章分割或添加）或作为项目网站的html文件。演示格式是最常见、最有用的。收集文件可以有许多名称，例如：

• UMD: Use model document（使用模型文档）
• DITL: Day in the life document（生命文档中的日期）
• CAD: Coverage Architecture Document（覆盖架构文件）

无论您如何称呼该文档，该文档通常都非常有用，可以将新的团队成员引入到设计中，为他们提供清晰的概述。随着验证项目的进展，团队通常会回到本文档和这些图表，以充实更多细节。

一旦你有了UMD，你的验证团队就可以把它作为编写测试计划的指南。他们可以对其进行梳理，提取出需求，并将其放入测试计划中。他们可以将流程图、曲线图和表格制作成电子表格中的一个部分或子部分，如果很大，也可以将其分解成自己的分层电子表格。关键是要划分类别和子类别，以便每个电子表格行针对单个需求，并且可以有效地链接到某个覆盖元素。另一个关键是在大致相同的级别编写每个需求。气泡图中的每个气泡可能是单个需求，也可能是整个需求的一个子部分。Y树图上的每个选项可能是一个或多个需求。每个表可以是一个覆盖范围组、每行或每列、一个覆盖点。

从UMD中提取需求通常遵循与上述相同的自底向上提取过程。由于UMD及其图表的固有流程，UMD通常使其更容易实现。通过实践，验证团队将开始更容易地可视化覆盖组和覆盖点，只需查看其UMD中的所有图表。就像自下而上的方法将链接和类型添加到覆盖组一样，coverpoint、cross、assertion或test最好在编写需求时完成。

有关如何获取UMD内容和创建测试计划电子表格的更多详细信息，请参见Wishbone SOC示例部分。

测试计划审查

验证过程有许多重要方面，需要验证小组投入时间和精力。testbench的构建、测试的运行、时间表等，往往优先于覆盖模型测试计划电子表格，其开发被推迟。通常，会创建一个初步的测试计划，但忽略了与实际功能覆盖要素的链接。结果是覆盖率实施不佳，覆盖率结果很低。团队最终在黑暗中验证，让随机生成发生，但不使用覆盖率作为反馈指导验证得出任何结论或关闭验证。他们采用了一种“足够好”的覆盖率方法，而不是基于任何真实的覆盖率指标数据。有一个良好的测试计划，其中包含定义良好的需求，每个需求都与真实的覆盖率元素链接是关键。花时间制定这个测试计划从长远来看会有回报。在编写需求时添加链接是最好的方法。它还确保团队不必重新查看获取灵感的每个需求的所有文档。为了避免这个问题，成熟的验证团队按照良好的文档或代码审查流程实现了一个测试计划审查流程。三阶段流程通常效果良好：

1. 初步审查：尽早制定测试计划，并尽早进行第一次审查。这是一个快速的回顾，以确保测试计划已经创建，有覆盖率链接和类型，并且在正确的道路上。它不需要是完美的，但需要是当时能做到的最好的。它将在项目过程中不断发展。
2. 主要评审：在一个项目中大约三分之二的时间里，真正的评审会发生。测试计划是覆盖模型，它定义了设计行为和意图的一个优先子集。这里的目标是确保优先级和选择的子集是正确的。你不能包罗万象。你不可能核实每件事。团队必须选择他们的子集，并在分配的时间内进行最多的验证和覆盖。这项检查需要一些时间，通常需要2-5天。对测试计划进行了详细审查，确保每一行的要求都是明确的，并通过覆盖率链接得到满足。所有问题都得到了解决，并输入到错误跟踪工具中。通常需要某种形式的需求重组来更新测试计划。它可能需要添加内容以适应缺失的内容或设计更改，但通常必须减少，以便在剩余的计划时间内实际完成。通常会发生优先级调整，一些工作会转移到未来的流程中。审查的目标是发现并修复覆盖率模型测试计划电子表格中的任何重大问题或缺失部分。
3. 最终审查：该审查在项目的最后几周进行，如果其他两次审查都做得很好，则是对该计划有效性的最终确认。所有重大问题都应该被发现并解决。在最终评审中，将添加异常细节，并在测试计划结束前解决所有最终问题。

这个测试计划评审过程通常与一个类似的三步代码评审过程结合在一起，在这个过程中，rtl和testbench代码被评审。

 

可执行测试计划格式

测试计划是一份文档，它捕获了设计的重要特性，以及如何验证这些特性。

创建测试计划的目的

功能验证被描述为SoC设计中的一个主要挑战，许多人认为验证过程的可见性不足是导致这一挑战的主要因素。

这种可见性的缺乏会影响设计质量、进度可预测性和成本（资源/工具/基础设施）。

验证经理需要回答的典型问题是：我们什么时候完成验证？是否验证了系统的所有关键要求？我们是否充分利用所有验证资源来满足项目进度？

通过制定一个可执行计划，捕获我们验证意图的优先列表，我们能够做到以下几点：

• 更好地组织自己。不可能完全验证设计的所有状态，但我们可以确定所有关键、重要和较好的特性，然后制定计划，确保所有关键和一些重要特性在计划内得到充分验证。如果时间表允许，还可以验证其他功能
• 在验证项目的日常执行过程中，可执行计划可以帮助您了解当前状态。现在可以立即跟踪进度，因为您可以确切地看到相对于您想要验证的内容，您处于什么位置。您可以根据里程碑、功能的优先级，甚至资源来可视化这个进度
• 在项目执行过程中，帮助管理功能覆盖率关闭。验证工程师可以将他们的覆盖率关闭工作集中在已被确定为漏洞的关键特性上，然后是重要特性，然后是“较好的”特性

创建测试计划

在许多情况下，功能将在仿真中验证，并使用代码覆盖率或功能覆盖率记录为已验证。测试计划还可以包括有关实验室验证和固件/硬件集成测试的信息。对于包含代码覆盖率和功能覆盖率的测试计划，测试计划和仿真之间的连接可以自动化。要使测试计划可执行，必须遵循特定的文档格式。Questa的验证管理解决方案使用的格式如下所述。

捕获测试计划

灵活性是将测试计划连接到仿真器的关键。在Questa验证管理的案例中，几种不同的源文件格式是有效的。唯一的要求是源文档必须能够导出为XML文档。例如，Microsoft Word、Microsoft Excel、OpenOffice Writer、OpenOffice Calc和Adobe FrameMaker都可以轻松输出XML文档，这些文档可以进行处理并使其可执行。事实上，在Word和Excel中分别捕获测试计划的一部分是完全可以接受的。然后，这些不同的部分可以组合在一起，正如下面重用现有测试计划部分所述。

在不同的输入选项中，电子表格是最常用的，并且非常适合测试计划中捕获的数据类型。电子表格格式为可视化验证意图提供了一种简洁明了的方法。本文的其余部分将描述电子表格中所需的信息，以及如何灵活地添加额外的信息，以便在整个测试计划的生命周期中使用。

测试计划的内容

将测试需求捕获到计划中是一个过程。这个过程在规范书到测试计划一文中有定义。该过程包括对规范书的严格分析、架构、设计和验证团队之间的协作，以及确保不遗漏任何内容的评审。这个过程中产生的所有需求都需要在测试计划中使用一些必需的结构进行捕获。所需的结构允许测试计划成为可执行的，并成为验证周期的一部分。

所需的计划结构

Questa的验证管理解决方案需要为每个捕获的需求提供四条不同的信息。它们是章节、标题、链接和类型。此外，其他信息是开箱即用的。每个需求的附加信息包括描述、权重和目标。虽然这些附加字段不是必需的，但它们大部分时间都在使用。Questa的验证管理解决方案还具有允许用户定义字段的灵活性。

如果我们查看电子表格格式中通常使用的字段，每个字段都由电子表格中的一列表示。

 

电子表格中的每一行对应于测试计划创建过程中捕获的需求。在Questa的验证管理解决方案中，每一列都有特定的含义。

章节（Section）和标题（Title）

章节和标题列协同工作，在测试计划中创建命名和层次结构。

章节

章节列通常是一个数字，用于在测试计划中创建层次结构，并将相关的测试计划项以父/子关系组合在一起。在电子表格中，用户负责输入这些信息。通常，您将以数字“1”开始对节进行编号，然后按顺序继续。然后，该部分下的一个子部分将被编号为“1.1”，以此类推，其中每一个额外的层级将通过添加“.”来表示在分区号之间。

标题

标题列描述要验证的需求或设计特征的名称。这是将出现在Questa中测试部分的名称。此处选择的名称应有其含义，因为它将通过工具流程可见。

当Questa提取测试计划时，它使用章节和标题列中的信息为testplan的每一行创建层次名称和唯一标记。例如，考虑到上面简单的测试计划示例，第1.1节将有一个分层名称/testplan/Parent_1/Child_1。

描述

描述列允许向电子表格中添加更多详细信息。这可能包括对其他文件的引用，以允许工程师收集更多信息，也可能是对需求存在原因的简单解释。任何文本都可以在此列中引起注意。它在技术上是可选的，但在实践中，测试计划中需注意的需求应该在描述列中有一个条目。

链接和类型

链接和类型列用于明确指出和需求链接的代码或功能覆盖率项。一个需求可以链接到多个不同的覆盖率指标，包括不同类型的指标。Questa支持链接到CoverGroup、Coverpoints、Cross、Assertions、Cover指令、定向测试和代码覆盖度量类型。这些列还允许像重用现有测试计划一节中描述的那样，导入其他测试计划。

链接

在该列中，您可以指定在覆盖率数据库中链接到相应测试计划项的实际覆盖率对象的名称。这可能包括一个特定的covergroup实例、一个assertion等。

类型

在这个列中，您指定了链接列中指定的覆盖率对象的类型。

链接和类型列信息一起用于高效地在覆盖率数据库中找到相应的覆盖率对象，并在测试计划和指定的覆盖率对象之间创建链接。这些列使测试计划成为可执行的。

权重

权重列记录一个整数，该整数反映当前测试计划项在其同级中相对于其父测试计划部分的相对重要性。如果未指定，则默认值为1。Questa使用“加权平均”计算算法计算测试计划的覆盖率时，会考虑这些权重。有关Questa如何计算测试计划覆盖率的更多信息，请参阅Questa关于验证管理的文档。

此外，权重列可以通过为需要排除的测试计划节/项目行指定0值来排除测试计划的部分。

目标

此列指定特定测试计划部分的验证目标。合法值的范围为1到100，如果未指定，默认值为100。Questa使用此信息确定测试计划部分/部件被视为涵盖的点。它不会改变覆盖率的计算方式。

使用Questa理解其它列

覆盖率测试计划中还可以使用其他特殊用途的列。这些列都是可选的，但是当它们出现时，Questa会利用它们的内容。

路径

链接到covergroup的特定实例时，存在两个选项。可选地，可以将覆盖组的完整分层路径添加到链接列中。如果在该设计层次结构的级别上只访问一个coverge项，那么这种方法非常有效。但是，如果多个覆盖项被链接到同一层次的设计结构中，则“路径”列允许指定设计路径，该路径将被添加到“链接”列中的条目之前，以创建完全限定的引用。

未实现的

随着测试计划的定义，在testbench或设计中还不存在相应的覆盖项的情况，捕获需求是很常见的。为了处理这种情况，可以通过在未实现的列中添加一个值“是”或一个大于零的数字，将一个需求设置为未实现。这将导致测试计划覆盖率计算准确地反映存在的需求，该需求的覆盖率为零，而该需求尚未覆盖。默认情况下，除非指定了此列，否则假定实现了需求的覆盖范围。

用户定义的列

为了确保用户能够灵活地记录与需求相关的其他重要信息，Questa的验证管理解决方案还允许创建用户定义的列。这允许对任何需要跟踪的内容进行规范。它还可以让您更好地了解验证过程。通常添加的一些列包括哪个工程师负责测试需求，以及需求或设计特征的优先级。

这些新增的列有助于回答以下问题：

• 我的高优先级测试计划项目进展如何？
• 在实现当前项目时间表方面，我在哪里？
• 我的资源状况如何？

系统级功能覆盖示例中使用的电子表格添加了所有者和优先级用户定义列。

重用存在的测试计划

通常，能够在其他上下文中使用现有的测试计划是很有用的。以下几种常见情况下，这会变得有用：

• 测试计划是在块级开发的，需要纳入芯片或系统级测试计划。
• 测试计划随IP或验证IP一起交付。例如，特定于协议的验证IP应包含完整的协议测试计划，以确保协议得到完全验证。
• 将自动生成的测试计划纳入我们的子系统或SoC级计划。例如，对于电源感知仿真，仿真器应该能够创建测试计划，以确保电源场景完全可用。
• 将不同编辑工具捕获的测试计划合并到一个主测试计划中。

在这些情况下，现有的测试计划可以分层导入到正在创建的顶级测试计划中，从而可以可视化整个验证工作的深度。

当创建这样一个测试计划时，Type列将被赋予一个值“XML”，以通知Questa该部分不引用覆盖率对象，而是引用另一个测试计划文档。“链接”列将用于指定包含被导入的测试计划的实际测试计划文件（通过文件的相对路径或完整路径）。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

测试计划到功能覆盖率

到达功能覆盖关闭是一个从设计功能规范书开始的过程，并通过分析确定：

导出功能覆盖模型并不是一个自动过程，它需要对可用规范进行解释，模型的实现需要仔细考虑。

• 需要测试哪些功能
• 在什么条件下需要测试功能
• 驱动和监控设计接口需要什么样的testbench基础设施
• testbench将如何检查功能是否正常工作

导出功能覆盖模型并不是一个自动过程，它需要对可用规范进行解释，模型的实现需要仔细考虑。

过程

生成功能率覆盖模型的过程通常是迭代的，随着测试平台的每个部分和刺激的构建，模型会随着时间的推移而建立。每次迭代都从相关的和可用的功能规范文档开始，这些文档被分析，以识别需要在测试平台中通过配置和激励生成的一些组合检查的特性。

一般来说，测试平台有两个方面，一条控制路径用来刺激被测试的设计，使其进入不同的状态，以便检查其特性；还有一个分析面，用来观察设计对激励的反应。应在测试平台中实现自检机制，以确保设计正确运行，这通常被称为记分板。功能覆盖率模型的作用是确保DUT通过的测试检查了所有相关条件下的设计特征。功能覆盖率模型应基于对设计行为的观察，而不是它被要求如何行为，因此应该在分析路径中实现。考虑这一点最简单的方法是，在测试平台上，必须开发运行在其上的激励和记分板来测试设计的所有特性，并使用功能覆盖模型来确保这些测试的所有预期变化都已成功完成。

验证是一个不完整的过程，即使是“简单”的设计，也很难及时验证所有可用的内容。对于大小合理的设计，在可验证的内容和可用于实现、运行和调试测试用例的时间之间存在权衡，这导致基于项目的技术和商业背景进行优先级排序。明智的验证策略是从最高优先级的项目开始，并确定优先级顺序，同时准备随着项目的进展重新确定列表的优先级。功能覆盖模型应随着每个设计特征的测试而发展，功能覆盖模型的每个附加部分应在激励之前就位。

过程指南

功能覆盖模型基于功能需求

测试平台用于测试设计的特征。功能覆盖模型的作用是检查这些不同变体的特征是否正常工作。特征也可以被称为需求，或者在某些情况下被称为故事。

例如，DUT生成带有CRC字段的数据包。CRC基于数据包的内容，比如说有10个变体。测试平台产生刺激，使DUT产生数据包，记分板检查CRC字段，确保DUT正确计算。在这种情况下，功能覆盖率监视器的作用是确保所有10个数据包变体都已通过检验。

选择最合适的实现

在决定如何实现功能覆盖模型时，可以选择如何实现功能覆盖。SystemVerilog语言支持两种主要类型的功能覆盖：

 

覆盖率类型	被实现为	用于
覆盖组建模	SystemVerilog Covergroups	当获得已知结果时，检查条件和状态的排列
覆盖属性建模	SystemVerilog Assertions - sequences and properties	检查是否观察到一组状态转换

Covergroup 功能覆盖率依赖于对一个或多个数据字段的值进行采样，以统计这些值出现的不同排列的次数。

Cover Property或基于时序的覆盖率，是基于计算测试期间特定状态和/或条件序列发生的次数。时间覆盖通常用于获得控制路径或协议上的覆盖，其中时间关系可能会发生变化。例如：

• FIFO是否已进入溢出或下溢状态
• 是否观察到特定类型的总线循环完成

开发功能覆盖模型的第一步是决定针对每个关注领域应采取这两种方法中的哪一种。