目录
操作FV工具依赖于用户输入，包括：
- 选择/划分设计：大多数FV的形式需要在全芯片下的某个单元或集群级别上运行，或者在全芯片下运行，并对下面的许多单元进行黑盒处理，因此用户总是要决定FV的实际目标。
- RTL（和/或示意图）模型：用户选择要编译的正确设计文件作为验证的基本输入（ primary inputs），并选择一组正确的编译设置，如参数或 `define 标志；通常包括用户编写的核心文件和其他部门或公司提供的用于定义标准可重用功能的库文件。
- 属性：FV的另一个关键输入是用户正在验证的属性集。形式属性验证（FPV）和相关方法中，断言属性是关键的验证目标，而假设提供了主要的约束；形式等价性验证（FEV）中，可以将信号从一个模型连接到另一个模型（映射属性）。
- 抽象概念：FV最初在设计中表现不佳，用户必须抽象或简化设计的某些部分，使其更易于处理。
- 工具旋钮：FV工具有许多必须由用户选择的设置，例如要使用的引擎类型、有界运行的证明界限，以及有效的IEEE SystemVerilog断言（SVA）标准版本。
人类运行FV也会犯错误，最危险的错误类型是误报（假阳性，false positives），即报告设计是正确的，但后来发现包含错误，这通常是因为过度约束，用户假设或纠正措施会阻止工具考虑所有合法行为。
FV的另一类常见错误：假阴性（false negatives），假阴性是验证过程中预期的一部分，最初的FV运行不包含所有需要的假设，最后找出它们不是真正错误的原因，并添加适当的假设或工具约束。假阴性的危险性明显低于假阳性，因为它们可能会导致额外的工程时间，但不会导致错误设计被标记为正确。假阴性通常是欠约束的结果，工具正在考虑不应该在验证空间中的行为。
接下来将讨论应该采取什么措施来防止许多类别的误报。
一、SVA语言的误用
一种简单的假阳性可能来自对SystemVerilog或SVA断言语言的误解。
1、缺少分号
实际上，SVA语言可以在缺少分号的情况下有效地否定断言，从而在实际设计项目中跳过FPV证明。
assert property (foo)
assert property (bar) else $error(“Bar problem.”);断言没有标签：SVA断言以 label:开头，在assert关键字之前。
完整的SVA断言语法基本上如下所示：
[<label>:] assert property (<prop>) [<pass_action>] [else<fail_action>];在断言的属性表达式之后，有两个可选的操作块：pass_action，在断言通过时执行的SystemVerilog命令；断言失败时执行fail action，分号表示所有动作块结束。
如果一个断言缺少分号，则接下来出现的SystemVerilog语句将被视为其传递操作，即使该语句是另一个断言。因此对于上面的第一个断言：
- Assertion condition=foo
- Pass action=assert property (bar) else $error (“Bar problem.”);
第二个断言已成为第一个断言的传递操作，在模拟中没问题，因为每当第一个断言通过时，就会检查下一个断言作为其通过操作。但FPV工具通常会忽略动作块，这些动作块主要用于模拟。
2、双时钟边沿的断言
看下面的断言，该断言表明每当请求信号到来时，至少保持六个周期：
hold_request: assert property (@(clk1))
$rose(req) |=> ##6 (!$fell(req));上述断言的时钟参数指定普通的时钟信号，而没有指定时钟的边缘。断言应该使用@（posedge clk1），而不是@（clk1）。
在这种情况下，断言对时钟的正负边缘都敏感。简单的布尔断言对正负边缘都敏感只会导致额外的检查，不会产生性能代价；但有重复或延迟时，如在##6 延迟操作符中，计数六个阶段，相当于三个周期（正负边沿都算一次）。
这种类型的断言会被检查，甚至可能捕获一些真正的错误。例如，如果请求仅在一个周期或两个阶段后失败，则上面的断言将成功捕获问题。在实际案例中，在使用该断言运行FPV时发现了真正的错误，但在项目后期运行的模拟报告中，使用独立的检查器发现了错误，其中一个请求在五个而不是六个周期后消失，同样需要仔细检查代码才能正确识别这个问题。
3、带断言的短路函数
当断言放置在函数中，且对该函数的某些调用位于复杂逻辑表达式中时，则断言实际上得不到检查，如：
function bit legal_state(
bit [0:3] current, bit valid;
bit_ok: assert #0 (!valid || (current != '0));
legal_state = valid && $onehot(current);
endfunction
. . .
always_comb begin
if (status || legal_state(valid, state)) . . .由于always_comb中的程序 if 在每个周期都会根据定义执行，因此该代码的编写者确信断言bit_ok 将始终被检查。但SystemVerilog语言有一个特性——短路：在某些类型的逻辑表达式中，可以在不检查所有术语的情况下计算出最终结果。SystemVerilog在语言参考手册（LRM）中明确规定了：如果or 的第一项为1或 and 的第一项为0，则不应计算表达式的其余项。
在上述例子中，status 是通过调用legal_state进行or 运算。如果status==1，则工具不需要评估函数调用（不需要去计算 || 符号后面内容是否为1）。如果status==0，在这些情况下断言功能正常，甚至可以检测到bug，但EDA工具在status==1时会忽略这一断言。
4、信号采样的细微影响
为断言变量定义的采样行为。在下面的代码片段中，仔细查看传递给断言的信号：
input logic[31:0] index;
. . .
current_pos_stable: assert property ($stable(req[index]));并发断言和采样值函数（如$stable）始终使用每个变量的采样值，实际上是前一时间步结束时变量的最终值。上面的属性表达式中有两个采样值：req和index，$stable 函数使用它们中每一个的最后一个值进行检查。因此，如果索引刚刚更改，实际上会将req 当前位置的当前值与不同位置的最后一个循环值进行比较！图9.2中的波形举例说明了导致假阴性的情况，其中向量的每个元素都是稳定的，但移动的索引会导致表达式$stable（req[index]）不稳定。
实际上这种情况很危险，因为它会产生意外的假阴性和意外的假阳性。在很多情况下，索引没有移动的情况下，断言可以成功地帮助检测许多真正的RTL错误。
每次比较时索引保持不变，req向量作为正常值进行采样，然后通过使用generate循环将索引定义为编译时常量来解决这个问题，创建一系列断言，检查每个常量索引，如果它当前处于活动状态，是否满足稳定性条件：
generate for (genvar i = min; i < max; i++) begin
current_pos_stable: assert property ( (i == index) |->
$stable(req[i]));
end5、不活跃的活性属性
分析潜在无限长度轨迹的“活性”属性，断言声明一个请求最终会得到一个响应：
response_good: assert property (
request |-> s_eventually(response));即使没有有限反例，也可以被一个无限痕迹伪造，该跟踪进入一个等待的条件从未发生的循环。这与弱性质形成对比，弱性质只能通过有限反例来证伪，如果不存在这样的有限反例，则认为弱性质为真。在SVA中，属性在默认情况下是弱的，除非使用显式强运算符。这意味着，即使下面的属性在概念上与上面的属性相似，但在FPV中永远不会失败；当查看任何有限的“反例”时，您无法确定响应是否会在结束后的几个周期内到达：<这一段看不懂欧-_->[The final SVA issue we describe relates to an advanced feature of FPV, the ability to analyze “liveness” properties on traces of potentially unbounded length. For example, as we have seen in earlier chapters, this assertion states that a request will eventually get a response:
The s_ before the eventually indicates that it is a strong property: even if it has no finite counterexamples, it can be falsified by an infinite trace that enters a loop in which the awaited condition never happens. This contrasts with weak properties, which can only be falsified by a finite counterexample, and are considered true if no such finite counterexample exists.
In SVA, properties are weak by default, unless an explicitly strong operator is used. This means that the property below, even though it might seem conceptually similar to the one above, can never fail in FPV; when looking at any finite “counterexample,” you cannot be sure whether the response would have arrived a few cycles after it ended:]
response_weak: assert property (
request |-> ##[1:$](response)); 在2005年的LRM中，强弱属性的概念没有明确定义，最终在2009年的修订版中引入。在此之前，上面的response_weak这样的属性是表示活跃性的唯一实用方法，因此大多数为SVA 2005构建的FPV工具都被设计为：将##[1:$] 属性视为隐式强属性。
最初移植时，以##[1:$]形式编写的所有活性属性似乎都很好，它们在升级前后都传递了现有（已验证）模型。
实际上所有的活性属性都是不可伪造的，因为在新标准下默认为弱属性。所以自升级以来，以旧的2005风格编写的属性活性证明都无效，必须修改代码来修复所有此类情况，或者让工具供应商稍微违反LRM，并将2005风格的活性断言视为强断言。
6、预防SVA相关假阳性
对RTL进行良好的绒毛检查（run good lint checks），Linting是一种运行软件工具的过程，该工具对RTL进行结构检查，以发现具有意外行为的法律代码的常见案例，在业界已经变得非常标准和成熟。要始终对开发的任何RTL代码运行lint检查。
如果用户需要依靠其他团队成员或多层脚本来完成RTL lint检查，请仔细检查linting中是否包含断言代码。早期的lint 工具生成了一些关于SVA断言的虚假警告，许多项目在RTL linting中表现出良好的纪律性，但将SVA代码完全排除在流程之外。
linting中的另一个关键因素是确保实现了一组良好的lint规则：
- 标记完全存在于另一个断言的操作块中的任何断言
- 标记在两个时钟边缘都处于活跃状态的任何断言
- 标记任何包含在逻辑表达式的可短路位置调用的函数的断言
- 标记在断言或采样值函数中将采样变量用作向量索引的任何情况
- 标记任何似乎以活性为目标，但由于采用SVA 2005风格而较弱的属性
有关更完整的SVA相关lint规则集，请参阅[Laurence S. Bisht, Dmitry Korchemny, and Erik Seligman, “SystemVerilog Assertion Linting: Closing Potentially Critical Verification Holes,” Design and Verification Conference (DVCon) 2012.]，并与EDA供应商联系，以确保实现了一套良好的SVA lint规则。
虽然linting 可以检测到各种各样的问题，但SVA语言确实包含许多陷阱和机会，可以编写断言，但这些断言并不能确切说明用户的意图。因此每个单元在RTL设计结束之前，也与SVA专家一起计划断言评审。
二、真空问题
进行FV时，一个重要的考虑因素是真空度：用户可能无意中过度约束了环境。验证空间中的重要行为将被假设或验证设置的其他参数排除，在最坏的情况下，如果创建了一个定义了全局错误条件的假设，例如（1==0），那么所有可能的输入都可能被排除，并且由于根本没有任何合法输入，所有断言都被认为是正确的，FV证明被报告为通过，但可能会忽略关键错误。
1、重置错误的误导覆盖点
检查形式环境的一个重要技术是证明覆盖点，小心覆盖点的重置条件，在设计的重置阶段，许多内部元素通常可能获得不代表实际计算的临时“垃圾”值，SVA语言为断言语句提供重置功能（disable iff），以便在重置期间关闭。
由于重置期间看到的垃圾值，重置错误的覆盖点可能会被报告为已覆盖，但可能在重置外无法到达覆盖点，且此覆盖报告隐藏了真正的真空问题。以下是一个基于Intel设计的真实案例的覆盖点示例：
c1: cover property (disable iff (interface_active_nn)
(data_bus != 64’b0));上述覆盖点是检查数据总线是否能够达到非零值，这种检查类型可以包含在任何形式环境中。重置信号名称 interface_active_nn 遵循：以nn结尾的信号在0值而不是1值上起作用，disable术语应该基于！interface_active_nn 。这会导致不正确的报告，称该条件已被涵盖，而实际上在接口处于活跃状态的情况下，一些错误的FPV工具指令阻止了任何非零数据，这个问题通过模拟报告设计中“已验证”部分的错误时发现。
预期相反极性的重置，设计的某些部分被停用，在具有多个重置信号的设计中特别危险，其中一些子集可能是正确的，而另一些是错误的。
另一个关键问题是FPV环境“ cheats ”以简化重置过程的情况，许多工具都有一个选项：查找复位后没有确定值的任何触发器，并自动将此类触发器设置为0（或1）。在重置复杂的块上，这通常可以在设置FPV的早期阶段节省时间，但这也会隐藏一类错误，如果有不确定启动状态的失败，用户需要确保模型行为正确，不管他们假设什么值。
2、模拟失败的内存控制器经过验证
这是一个接收请求的块，与在特定内存地址执行某些操作有关，并根据传入的操作码进行处理，如图9.3所示。
最初证明这种设计的断言时发现，操作码和地址会指定多周期操作，但在操作完成之前，地址总线上的地址会发生变化。经讨论发现，更改挂起（pending，待处理）请求的地址是使用内存控制器的一种荒谬方式，因此可以通过假设排除这种可能性。一旦添加这个假设，属性得到充分验证，在过程中发现一些RTL错误，从而以很高的可信度完成了FPV的工作。
地址总线在操作期间会改变。在发出请求的周期之后，控制器可能已经在本地内存中捕获了地址，因此操作进行时，不关心地址总线上是否出现垃圾值。向该模型提供输入的单元实际上会更改挂起请求的地址，从而导致一些初始FPV证明无效，排除这些输入的假设实际上排除了真实问题空间的一部分。
FPV假设包括在全芯片模拟回归中，这些回归检测到失败的假设，提醒验证团队这与需求脱节。如果在请求挂起时地址总线发生变化，设计就会出现错误，RTL代码和FPV环境都需要修复。
3、假设与约束的矛盾
空间包含内在矛盾，任何形式工具都是在当前的一组假设和工具约束下分析合法信号值的空间。如果这个空间是空的（当前设计没有合法的输入集），那么形式工具可以报告一个不重要的“成功”，因为任何输入集都不能违反正在检查的条件；如果证明空间为空，大多数现代形式工具都会报告错误。
有各种各样的工具指令隐式地创建假设，其中许多映射也可以创建隐式假设。例如，查看一对多映射：
sig -> sig_dup_1 sig_dup_2这表示RTL设计中的一个触发器 sig 在原理图（电路）中复制了两次，RTL中考虑单个信号sig在逻辑上是合理的，但在物理上需要两个复制版本来驱动芯片的不同部分，在本例中还隐式地创建了一个假设等价于：
implicit_assume: assume property (sig_dup_1==sig_dup_2);每当有一对多映射时，用户都会暗中告诉工具，假设右侧的所有信号都有相同的值。
目前正在讨论的FEV故障中，一个映射如下所示：
myflop -> myflop_dup_1 myflop_inv_1RTL 设计中的一个触发器myflop在原理图中复制了两次。如果一个触发器被复制两次，以将其信号驱动到芯片上的不同位置，则可以更有效地实现高速电路（high-speed circuit）。如果其中一个复制的触发器被逻辑反转，如其名称中有_inv_。通常需要一个逆映射：
myflop -> myflop_dup_1 ~myflop_inv_1在触发器翻转之前忽略了~符号，没有反转，这种映射在myflop_dup_1和myflop_inv_1之间创建了一个隐式等价。但在设计的其他地方，两个信号myflop_dup_1和myflop_inv_1彼此相反：
a1: assume property (myflop_dup_1 == ~myflop_inv_1);上面的假设告诉FEV工具，唯一的合法情况是myflop_dup_1等于myflop_inv_1，且是myflop_inv_1的相反值，因此合法输入集为空。但验证被报告为通过，因为任何一组合法输入都不会违反等价属性，这个传递状态是空（真空）的，实际上什么都不检查。
大多数现代FEV工具都具有自动报告上述这种完全空（真空）证明的功能，意外的过度约束排除了所需行为的大部分空间。
4、永远不会填满的队列，因为它永远不会启动
芯片组接口设计中，一组传入的事务请求被放置在一个大小是有限的队列中，控制逻辑会定期从队列中删除下一个事务以进行处理。但每个事务所花费的时间不同，因此当太多消息在错误的时间到达时，队列可能会溢出；当队列几乎满时，它会发送一个背压（反压力）信号，指示不应再发送事务。
接口的设计约束非常严格：设计师希望队列永远不会溢出，但也不希望发出过于谨慎的背压（反压力）信号，而过早停止流量并降低有效带宽。
图9.4 从较高的层面说明了验证挑战。
设置FPV的设计时，验证器创建了一套好的断言来防止队列溢出，并添加了许多与合法操作码和其他事务控制信号相关的假设。调试了验证环境和一些约束的初始问题后，这些断言在FPV中被证明是正确的。
添加各种覆盖点，包括观察已完成事物的覆盖点。假设中要求操作码是非法的而不是合法的，因此排除了所有普通事物。该缺陷与以下类似：
// Variable transaction_check is 1 if transaction is BAD
assign transaction_check = ((opcode != LEGAL1) && (opcode ==LEGAL2) . . .)
// Assertion missing a ~
a1: assert property (transaction_check);一旦发现覆盖点故障，设计师和验证者就能够识别出有缺陷的假设并进行修复。
在FPV工作中包括一组良好的覆盖点，可以帮助检测和纠正过度约束。
5、防止真空（vacuity）：工具和用户责任
linting和手动检查技术可以检测到各种各样的情况，其中编写错误的断言会在验证中留下漏洞。正确使用这些方法，可以很早地发现有不良重置极性的覆盖点。还有几种更有效的方法也可以用来防止真空。
最常用的真空预防方法是在模拟环境中包含FV断言和假设，实际情况下，都需要运行全芯片模拟，以获得对全芯片集成和流程的基本信心，而FV是在较低级别或部分模型上运行的。虽然模拟所覆盖的空间比FV小得多，但模拟会基于实际预期执行流，主动驱动值，可以发现有缺陷的假设，应该尽可能在模拟环境中包含FV断言和假设。
许多EDA FV工具包含内置的真空度检测，排除了整个验证空间的情况下，可以检测出一组相互矛盾的假设。大多数FPV 工具还提供“触发器检查”，即在不满足断言前提条件时，在单个断言级别自动检测覆盖点。一些形式工具还提供覆盖率检查功能，可以尝试识别当前FV环境中包含和未包含的RTL代码的行、分支点或其他重要部分。如果当前工具中有这些功能，请务必启用它们。
同时也要注意工具的自动检查的小问题。例如，自动真空检查可能会报告证明空间不是空的，同时排除了大量有趣的数据流；空间并非完全真空，因为设计可以参与扫描协议（scan protocols）、断电和其他次要任务。设计中最重要的部分——交易的处理，实际上被错误的假设所禁用。
添加覆盖点：尝试为设计考虑典型的良好数据流，并覆盖每个常见流的示例。当这些被报告为已涵盖时，可以查看结果波形，在当前的形式约束下，设计者的预期行为确实是可能的。
注意使用的重置顺序以防止真空。首先确保所使用的复位信号的极性是正确的；让FV重置序列尽可能通用。要特别小心允许在非重置节点上全局设置0/1的工具选项。
在前几章中，建议使用故意过度约束来降低复杂性或阶段验证过程。这些建议仍然适用，需要指出的是，确保用户完全了解任何故意的过度约束，或不完全通用的重置和初始化条件，并且可以证明和记录为什么这些不会在验证过程中产生分歧。
三、隐含或未陈述的假设
通常工具或库可能自带隐式约束，用户需要在当前环境中正确使用这些工具。在某些情况下，这些隐含的假设导致了在项目后期发现的问题。
1、具有图解假设的库
电路网表通常基于标准元件、基本逻辑元件（如and门、or 门和多路复用器）组成，这些元件在晶体管级已预设计，可以实例化以实现所需的逻辑。这些库已预验证过了，如果一个元件声称是一个and门，FEV工具可以不必在晶体管级进行验证。这使FEV更实用化和普及化。
在某些情况下，库元件可能包括优化，这取决于对其输入的某些假设。图9.5显示了这种情况的一个例子。
这是一个简单的选择器，它驱动上限值输出iff信号b为高，并驱动下限信号输出iff信号a为高。如果a和b都不为高，out 是一个浮动节点；如果a和b都为高电平，那么两条输入线就会短接在一起。如果我们能够始终保证这些值中的一个精确为1，另一个精确为0，那么这个单元格在实践中是可以接受的。
因此在交付库中，可能需要对某些单元进行一些必要的假设，这样使用库需要保证：如果使用这些元件，这些假设将得到满足。因此，在包含此类库的设计的FEV过程中，需要额外的步骤：电路图假设验证。这本质上是一个小型FPV运行，主要关注库中的一组属性，如果省略了这一点，则无法信任库提供所声称的功能。
2、对多驱信号的期望
工具做出一些隐含假设，并误解了设计意图。例如，带有多个驱动器的RTL信号，许多工业综合和FEV工具都使用多驱动RTL信号作为“线与（wired AND）”信号处理。综合工具生成驱动器与AND组合以生成总体值的电路，这在许多工具中都是默认的。
一项设计中对原理图的后期检查显示，顶层的连接与设计师预期的不同。仔细检查后发现，其中一根线（wire）在集群接口上被声明为“inout”，从逻辑上讲，它应该是一个输入。这意味着驱动它的顶级逻辑变成了多重驱动，因为它可以从真正的驱动程序或输入输出信号中获取值。然后，综合工具可以为这个网络综合AND逻辑。尽管RTL和netlist之间存在这种差异，FEV工具默认将多路驱动信号视为线与门（wired AND），最终设计还是通过了FEV。
更改FEV工具的设置，以更保守地处理多个驱动程序：它将检查每个驱动程序，并确保每个节点的RTL和netlist之间的精确驱动程序集相匹配，这将自动发现网络被综合工具综合成有线门的情况，再重新运行FEV，证明在现在更强大的等价定义下，没有进一步的错误。
3、不可到达的逻辑元素：需要还是不需要？
不可到达点是设计中不能影响任何输出的节点，这通常是因为逻辑功能的某些子集在逻辑上被绑定，也可能是以前的设计中不再存在的某些模式的实现。
另一种情况是逻辑元件完全断开,这可能是因为插入了“额外元件”（在当前设计中不起任何作用的额外逻辑），但被放置在芯片上具有额外开放空间的区域，以防需要对逻辑进行后期修复。
图9.6说明了可达点和不可达点的概念。一般希望所有点都应该报告，用户可以反复检查以确保列表合理，识别任何看起来可疑的点。如果将RTL与原理图（schematics）进行比较，且一些已知模式在设计中被限制或禁用，那么一些不可到达点是合理的。但如果在一个小改动前后比较一个原理图设计，则不可到达点非常罕见，每一个都应该仔细检查。
事实证明FEV工具的一个默认设置：会报告由于绑定逻辑而不可到达的点，但会忽略完全断开的节点。
4、防止误解
用户会误解形式工具和库的基本行为，有一些好的策略可以最小化这些问题。
了解在设计中使用并由另一个团队交付的任何外部组件或IP的验证预期，如果由其他人提供RTL-netlist FEV 运行中使用的元件库，检查与原理图假设检查相关的所有要求。如果集成外部提供的IP或相似模块并信任其功能，而不是重新验证，确保设计符合其接口要求。
这里所需的专业知识不在设计本身的内容中，而是在设计中使用的工具中。在完成项目之前，与相关工具和库的专家一起查看FV环境和工具控制文件。
如果不完全理解某些验证步骤，如上面其中一种情况下的原理图假设步骤，保守的选择是默认打开它，除非确定它可以安全关闭；允许对某些设计结构进行较弱检查的选项，例如将多驱动网络视为有线与门，或忽略某些类别的不可访问单元，这些选项本质上是危险的，应该小心。
FV工具提供的选项，应尝试选择保守的检查，而不是较弱的检查，除非清楚为什么较弱的选项适用于特定情况。
四、分工（细分）
通常无法同时在大型设计上运行FV任务，细分问题是FV的关键促成因素。某些情况下，设计的一部分，必须通过其他方式单独验证；细分问题时，需要确保验证过程的总和验证了设计的所有部分。
1、粘合逻辑（glue logic）的缺失
如上所述，出于FV的目的，模拟块被黑盒化是非常常见的。在我们的一个测试芯片设计中，我们遇到了这样一个案例，FEV所有者负责验证RTL和原理图从顶层到模拟块边界是否匹配，而模拟块所有者负责一个单独的（基于模拟的）验证过程，以确保该块原理图网表的正确性。
模拟块的实际实例化类似于图9.7，少量的粘合逻辑将实际的模拟逻辑（analog logic）连接到设计。
粘合逻辑看起来像可综合的块，一组很容易通过标准FEV工具分析的门；但从综合FEV所有者的角度来看，粘合逻辑是模拟块的一部分，因此验证黑盒位于图9.7中的外边界级别。尽管这是一个相对简单的少数门，但它被一个反转关闭，导致第一步的功能不正确。
只要正确地包含了胶水逻辑，这在pre-silicon FEV期间很容易检测到错误。
2、有漏案的案例拆分
另一种常见的FV任务复杂度细分方法：案例拆分。对不同的模式进行细分很方便。例如，在芯片组设计中，支持PCI Express（PCIE）协议（一种流行的总线接口协议），有几种模式支持不同程度的并行通信，称为x4、x8和x16模式。
几年前，在一个芯片组设计的PCIE模块中，设计师担心为改善时序和面积而进行的一些复杂更改可能会导致功能上的缺陷。因此他请FPV专家帮助建立一个验证环境，并检查该模块是否仍能按预期工作。最初描述验证需求时，再次出现了一个轻微的沟通错误问题：“我们更改了x8模式的功能”被解释为“我们只需要验证x8模式”。FPV专家建立了初始验证环境，帮助证明和调试了许多关于设计功能的断言，甚至在过程中发现了一些非常有趣的RTL错误。最终他报告：所有的断言都得到了证实，核查工作已经完成。在审查“完整”验证时，发现FPV环境仅涵盖x8模式。此外还需要验证x4和x16模式。
另一个非常类似的例子：验证一个具有6位指数的算术块，为了简化问题，将其分为两种情况：一种是指数值在0到31之间，另一种是指数值在33到64之间。但验证器忘记了临界值32，这特别危险且是一个实现错误的案例，这个错误被发现的时间比预期的要晚得多。
3、解除临时黑客攻击
当团队的一部分认为他们拥有一份验证辅助资料时，可能会发生与分工有关的额外危险，因此可以自由地对其进行黑客攻击，以方便各种EDA工具。“黑客”指的是对辅助文件的更改，这些更改在逻辑上可能不可靠，但由于工具的古怪或缺陷，使得验证过程的某些部分更加方便。
在一个芯片组设计中，一些团队成员使用了一个新的计时工具，发现它与一堆库单元有问题。库中有一些由一对背靠背触发器组成的单元，这是跨时钟域同步的常见情况；由于软件缺陷，这个新的计时工具在处理这些情况时遇到了问题。计时工程师注意到库单元有两种格式：一种是专用格式（用于计时工具），另一种是标准Verilog。他们认为自己是唯一使用这种专有格式的人，于是对文件进行了黑客攻击，使每一对翻牌都被一个翻牌所取代，然后将修改后的文件签入存储库以备将来使用。
但计时只是工程师的假设，并不完全正确。综合和FEV工具可以选择使用这些文件来代替Verilog，而损坏文件的存在导致整个设计中的许多双触发器同步器，在设计和验证流程中被悄悄地替换为单触发器。因为综合和FEV都使用了损坏的文件，所以直到项目后期才发现问题。一个团队认为基于Verilog表示的等价性检查是最安全的，这样真正的问题才能被发现，设计可以在退出之前得到纠正。
4、安全细分
在大多数情况下，验证问题必须分解为许多子问题，由适当的专家和工具负责每个部分。团队中应该有一个具有全面视野的人、了解如何划分问题的人；能够发现验证不同部分的所有者之间存在脱节的情况，在每个主要层级和整个芯片上都应该有验证审查，包括子问题的所有者和理解全局的全面验证所有者。
了解所涉及的工具也很重要，最好让对所涉及的工具有很好理解的人参与评审。
499
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
