Effective FPV for design exercise 形式验证 第五章

目录

一、本章的例子：交通灯控制器

二、创建design exercise FPV

1、design exercise 目标

2、design exercise的主要属性

3、复杂度分级计划

4、退出标准

5、总结

三、设置design exerciseFPV环境

1、覆盖点（cover points）

2、假设（assumptions）

3、断言

4、时钟和复位（clocks and resets)       

5、健壮检查(sanity-checks)

四、修改（wiggling）设计

1、wiggling过程

2、wiggling阶段1：第一个短波形

3、调试另一个短波形

五、探索更多有趣的行为

1、回答一些新问题

2、证明断言

六、消除简化，探索更多行为

1、面临复杂度问题

---

        下面是一些考虑使用design exercise FPV的情况：

1. 希望查看正在编写的新的RTL在简单情况下的行为或验证其基本功能；
2. 在所需的辅助设备（如相邻单元或testbench）准备就绪之前进行早期验证
3. FPV在新RTL设计上的适用性，作为寻找bug hunting or full proof FPV的初步步骤
4. 想看看部分设计如何与一些关于未实现部分的已知假设相结合。

        本章介绍了设置design exercise FPV环境，并在模型上有效使用它的实际问题，接下来通过一个示例设计来说明这个过程。

一、本章的例子：交通灯控制器

本章的例子是：交通灯控制器，故意带有一些缺陷的简单设计来说明FPV的使用。

        上图是一个有交通灯的四向交叉路口：

• 在任何给定的时间，只有一个方向必须有非红灯（从那个方向驶来的汽车在直行和左转时都有优先权）
• 等待的车辆，最终会得到绿灯
• 带有“紧急”信号的救护车可以迫使特定方向在两个周期内变绿

        使用状态机来实施这个系统，每个交通灯带有一个顶层模块，该模块实例化四个交通状态机中的每一个，处理顶层环境输入和输出，并将它们正确连接，以便控制可以在灯之间安全传递。

        上图是控制器的顶层设计。

 

         上图是在交通灯的状态机。

        使用一组状态机来实现这个系统，每个状态机对应一个交通信号灯，并使用一个top模块来实例化四个交通状态机中的每一个，处理顶级环境输入和输出，并将它们正确连接，以便控制可以在信号灯之间安全传递。

module light_fsm(input int index,
input logic clk,rst,cars_waiting,emergency,request_in,global_emergency,yield_in,
output logic request_out,yield_out,output t_light light);
t_state cur_state, next_state;
always @(posedge clk) begin
cur_state <= next_state;
end

always_comb begin
    //非紧急情况
case (cur_state)
    RED : next_state = (yield_in) ? GREEN : RED;
    GREEN : next_state = (!cars_waiting && request_in) ?YELLOW : GREEN;
    YELLOW: next_state = RED;
    default: next_state = BOGUS;
endcase
    //紧急情况
if (emergency) begin
    next_state = GREEN_EMERGENCY;
    end 
else if (cur_state == GREEN_EMERGENCY) begin
    next_state = GREEN;
    end 
else if (global_emergency) begin
    if (cur_state == GREEN)
    next_state = YELLOW;
    end
end

always_comb begin
    request_out = (cur_state == RED) && cars_waiting;
    yield_out = (cur_state == YELLOW);
    light = (cur_state == RED) ? L_RED :(cur_state == YELLOW) ? L_YELLOW :L_GREEN;
end
endmodule

        上述代码中，该系统包含实现一种循环协议的四个状态机，其中一个灯一次可以是绿色或黄色，每个灯根据以下情况决定下一个灯是否变绿：

• 由于车辆在该方向等待，下一个灯的有限状态机（FSM）发出请求，这与request_out/request_in信号一起显示；
• 没有车辆从当前方向驶来，这显示在cars_waiting信号中。

        这个设计相对较小，但存在多个通信状态机，这种情况通常会导致意外的交互。因此要在早期设计阶段进行某种形式的简单测试和健全性检查，这也是使用FPV进行设计探索的理想情况之一：可以指定想要看到的特定情况或状态组合，不需要像仿真那样逐个周期地计算出达到这些期望状态所需的输入。

二、创建design exercise FPV

        开发的早期阶段，能快速对设计的基本功能产生信心；design exercise 的规划是相对轻量级，不需要投入与全面验证计划相同的精力。

        概述将要研究的属性类型，如何逐步增加复杂性的阶段计划，以及确定何时进行充分design exercise的成功标准。

1、design exercise 目标

        处理状态机设计，最重要的目标是保证能够访问每个合法的状态。所以交通灯控制器的第一个目标：确保每个FSM都能达到每个合法的状态。进一步考虑，则在上述模型中的四状态机上尝试使用多个状态的所有可能的交叉积（向量积）。

        在本例设计中，由于在任何给定时间只有一个灯处于非红色状态，实际上没有太多有意义的交叉积，所将从计划中省略状态交叉积。

       另一个目标是：观察设计中的典型流（flows），典型流有时由于验证时过分关注断言而被忽视。规格（specification)文档可能包含一些显示典型行为的波形图，要想让设计能够实现这些行为，因此验证的第一个目标是能够看到显示交通灯系统正常行为的波形。

        上图显示了四个灯周围的交通控制“流”，我们希望在FPV环境中复制该流程。

        注意：这并不是完全验证设计，只是给验证人员带来基本的信心，表示设计目前能满足规格书最基本的功能需求。

2、design exercise的主要属性

        design exercise的第一个也是最关键的属性是覆盖点(cover_points)，对于FPV的应用，覆盖点比断言更重要。

       要定义一个cover属性，以达到spec波形中描述的有趣的行为。假设唯一的spec波形是图5.5所示的转向灯变化波形：每盏灯变成绿色，黄色，红色，从上面基于状态的覆盖点得到的波形来说明转向灯变化情况。

        接下来定义遵守上述定义的规格的安全属性，在本例中的属性对应于最初描述的三个主要规格点：

• 在任何给定的时间，只有一个方向必须有非红灯
• 等待的车辆，最终会得到绿灯
• 带有“紧急”信号的救护车可以迫使特定方向在两个周期内变绿

        注意：这里的目标是验证典型行为的基本安全性，而不一定要对模型的正确性进行完整的形式化证明，不需要包含规范所暗示的100%的属性，只需要简单属性的合理子集。

        此时可以考虑一些对输入约束作用的假设，但是现在只是验证早期，可能不会想到所有的假设；在调试过程的早期阶段“wiggling”，或者检查故障波形并使用它们来改进假设。

       如果有一个公共端口，该端口已经在其他经过形式验证（FV）的设计中使用过，那么预写的属性集是可用的。例如，有的公司出售FV属性包，用于常用的总线协议；因此，在设计一个包含公共协议的设计时，一定要利用可用的属性集。这些属性集中的断言很可能比design exercise阶段所需的更详细，但这些假设可以帮助验证人员快速创建功能性FPV环境。

        交通灯例子中，由于没有看到任何明显的需要的输入假设，将不定义任何输入假设。

3、复杂度分级计划

       FPV对于大型或复杂的设计会具有挑战性。当准备在模型上运行FPV时，需要对潜在的复杂度问题进行一些预先考虑。

        设计可能包含一些元素，例如嵌入式缓存（embedded caches），这些元素本质上会增加很多逻辑上无趣的状态，验证时要确保这些元素不会阻碍FPV的运行。

        在此阶段，以下是可能会使用的复杂度方法：

• 黑盒（blackbox）：黑盒是模型FV忽略的一部分，通常是一个独立的子模块，如内存或计数器。黑盒模型的一部分有效地消除了其逻辑的考虑，FPV工具的作用就像任意值可以出现在其输出上一样。
• 切点（cut points）：切点是模型中驱动逻辑被忽略的单信号，例如，假设正在输出一个复杂数学计算的结果，但只想检查数据是否正确传输，而不是重新检查数学。在这种情况下，可以将结果信号设为一个切点。FPV工具的作用就像结果可以获得任意值一样。

        以上两种技术都没有约束（欠约束问题可能会导致false negative），使证明更普遍。由于没有考虑逻辑中某些部分的细节，而过于接近模型。如果能在一个带有黑盒或切点的模型中证明一个断言，那么整个模型也是如此。

        在为design exercise建立模型时，检查是否有机会使用黑盒或切点方法可以安全地降低复杂性。

        这些方法的主要缺点是：

• 验证差距（Validation gaps）：没有检查黑盒中逻辑的属性，则要清楚地了解：在验证的流程中，这些设计在哪得到验证。
• False negatives/covers：FPV可能会生成实际中无法出现的波形，通过为切点或黑盒输出分配不现实的值。如果不关心特定的信号值，应小心仅仅只使用这些方法。

        在这个阶段，如果能找到机会使用上述方法来消除正在练习的设计中的无趣逻辑，那么FPV运行可能会更有效率，而且生产效率可能会显著提高。

        在交通灯控制器这个例子中，是否考虑上述方法？黑盒化或者在状态机之间切断一些信号？但状态机之间需要交互，不能使用任何黑盒和切断点。

        存在另一类复杂度优化：过度约束（overconstraint），为设计中的某些信号分配常值或有限范围值，与上述欠约束方法一样，它可以降低FPV的复杂性，增加工具处理模型的机会。但与欠约束不同，这种方法使模型更具体（独特），可能会导致遗漏一些有趣的潜在行为或错误。过度约束也会产生有益效果：限制了被测试的行为集，使工具更容易在开始时专注于较小的问题集。

        对于design exercise，并不要求为设计提供完全地正确性，使用初始过度约束来简化用户的问题。从一个包含有限行为集的简单模型开始，理解和调试这些行为要简单得多。在练习了简单模型并观察和调试了各种行为之后，可以逐渐减少过度约束，并添加对更复杂行为的支持。

        一些常见的过度约束简化示例，通常用于实现更方便的design exercise：

• 关闭特殊模式，如低功耗、扫描或时钟选通。
• 限制可用操作码或事务类型的集合。
• 假设不会发生错误或异常情况。
• 强制数据总线的几乎所有位为0，这样只有少数携带现有数据（实际数据）。

        在上述交通模型中，可以做一个明显的简化来排除“特殊”模式：假设紧急输入始终为零。这使验证时能先了解和验证交通灯控制器在典型非紧急情况下的行为，当验证了基本功能后，可以消除这种过度约束，并验证紧急情况。

        使用命名约定（例如前缀fv_overconstrain）来标记故意添加的过度约束，这些过度约束允许进行早期design exercise，但稍后应删除以进行更严格的验证。

4、退出标准

        既然已经指定了目标、属性和阶段计划，还需要定义退出标准：什么时候完成design exercise？

        合理退出标准的一些例子可能是：

• 时间限制：花一周时间做设计练习，在这段时间里尽可能多地发现和解决错误行为。
• coverage：确保已经涵盖了覆盖点目标中表达的所有基本行为，但不一定保证已经验证了所有断言。
• Full Exercise：在将设计提交给验证团队之前，希望形式验证exercise
  plan（练习计划）中的所有属性。

5、总结

       交通灯控制器的design exercise计划如表5.1所示。与真正的验证计划相比，相对简单，因为design exercise是一个相对轻量级的过程。

目标	表明可以到达交通FSMs的每个状态。 重复在规范波形中显示的行为。 验证我们遵守三个关键规范。
属性	覆盖状态机的每个状态。 从规范中覆盖交通切换波形。 断言在任何给定时间，仅一个方向有非红灯。 断言如果一辆车在等待，则最终会等到绿灯。 断言紧急信号可以迫使特定方向在两个周期内变绿。
复杂度阶段	没有好的黑盒或切点机会。过度约束：增加初始假设，global_emergency为0值。 在基本覆盖和非紧急相关断言得到证明后，我们可以释放这一假设。
退出标准	想使用所有覆盖，在紧急和非紧急情况下，证明上述定义的三个目标断言。

三、设置design exerciseFPV环境

        建立一个有用的FPV环境有几个组成部分：（ 详情见：Formal property verification 形式验证 第四章_想喝奶茶啾啾的博客-CSDN博客）

• 可综合的SystemVerilog模块
• 用于探索有趣行为的覆盖点
• 用于约束输入的假设
• 用于检查所需属性的断言
• 设计中合适的时钟和复位

1、覆盖点（cover points）

        将抽象概念转化为实际的SVA代码，从覆盖所有FSM状态的要求开始，通过定义要插入到每个状态机的覆盖点：

generate for (i=RED; i <= GREEN_EMERGENCY; i++) begin :g1
state1: cover property (cur_state == i);
end
endgenerate

       接下来从我们的规范中介绍交通切换波形，波形如图5.5所示：

         我们看到每个灯依次变绿，还需要决定如何精确匹配波形中的计时：真的打算精确指定绿灯之间的2个周期间隔，还是实际计时略有变化？必须根据规范文档中的文本来判断这一点。在这种情况下，允许时间稍微变化，并确定以下顶层覆盖点很好地体现了验证的意图：

cover_wave: cover property ((lights[3] == L_GREEN)##[1:4]
                            (lights[2] == L_GREEN)##[1:4]
                            (lights[1] == L_GREEN)##[1:4]
                            (lights[0] == L_GREEN));

2、假设（assumptions）

        首先强制交通灯控制器进入非紧急状态，所以设置一个假设：

fv_overconstrain_emergency: assume property
(global_emergency == 0);

3、断言

      在合理的情况下，可以在每个断言中加入几行建模代码，但如果编写了大量额外的代码，我们应该质疑该断言是否适用于design exercise。

• 断言在任何给定的时间，只有一个方向必须有一个非红灯。这个断言应该放在模型顶层，因为它涉及来自多个方向的信号 ：

  //计算num_greens和num_yellows
  always_comb begin
  num_greens = 0;
  num_yellows = 0;
  for (int i=0;i<4;i++) begin
  if (lights[i] == L_GREEN) num_greens++;
  if (lights[i] == L_YELLOW) num_yellows++;
  end
  end
  safety1: assert property ((num_greens1 + wnum_yellows) == 1);

• 断言 如果一辆车在等待，它最终会等到绿灯。这个断言应该出现在每个单独的交通状态机（FSM）中：

  liveness1: assert property (
  ((cur_state == RED) && cars_waiting) |->
  s_eventually(cur_state == GREEN));

• 断言 紧急信号可以迫使特定方向在两个周期内变绿。这是属于每个交通状态机的另一个断言:

  emergency1: assert property (emergency |->
                              ##2 (light == L_GREEN));
  
  

        还需要根据RTL的细节所暗示的安全条件来创建一个断言，在图5.4中的状态机代码中，定义了一个伪状态来指示无效的状态机值；我们应该确保永远不会碰到这个：

nobogus: assert property (cur_state != BOGUS);

4、时钟和复位（clocks and resets)       

        需要为模型定义时钟和复位条件。在交通灯控制器这个例子中，只有简单的顶层输入clk和rst，只需要使用适当的工具特定命令来告知FPV工具。

5、健壮检查(sanity-checks)

        在建立design exercise环境后，启动工具并加载模型。在后续操作之前，需仔细检查设计的复杂度是否合理，大多数FPV工具在编译模型后都有一个显示结构复杂度的命令，目前的指导方针是针对少于40000个状态元素的模型，在交通控制器例子中，是310个寄存器，不需要担心复杂度。

四、修改（wiggling）设计

        在深入研究交通灯控制器的初始运行之前，首先要讨论FPV设计的第一阶段：wiggling过程。

1、wiggling过程

        wiggling指的是任何FPV过程中调试的第一个阶段：尝试从获得小而简单的波形阶段，发展到在设计上查看有趣的交通。刚开始看到只有一个周期的反例波形或者覆盖波形，是正常的。

        由于大多数FPV引擎本质上是寻找满足用户条件的最短可能波形，当满足以下任何条件时，它们自然会找到非常短的波形：

• 定义的复位序列无法复位某些状态元素，因此可能会在任意配置中出现；
• 定义了不正确的时钟或时钟门控，设计元素根本不会复位，因此可以在任意配置中出现；
• 应在输入上放置的一些假设尚未定义（没有给输入加约束），导致某些输入以不符合当前设计的任意配置

        在状态元素或信号的值未被RTL定义、约束或明确确定的任何情况，形式引擎都会选择非常快达到覆盖点或违反断言的值；用仿真验证的话，同样的验证结果可能要上千个时钟周期在才找到。这实际上是FPV的一个关键优势：工具能够切中要害，并找到尽快到达所需值的方法。

        看到这些简短的波形时，验证人员要了解它们真正到达覆盖点或违反断言的原因；考虑上面提到的潜在根本原因：复位、时钟或缺少假设。

       前面提到的配置方法，实际上已经错过了一些必要的假设或配置参数，因此在生成有趣的FPV波形之前，应该要在所有设计上进行多次wiggling.

       在看到有用的行为之前，典型的有趣RTL单元上需要发生10-20次wiggles（调试短波形的迭代）。由于交通灯控制器的简单性，在本章的讨论中会看到更少的迭代

2、wiggling阶段1：第一个短波形

        在FPV的早期阶段，覆盖点比断言更重要：确保能够观察到预期的流和行为，并看到符合规格书的波形。

        通过在模型上创建一组合理的覆盖点来开始任何FPV工作，代表典型和有趣的活动。

        在这个阶段犯的一个常见错误是：首先试图证明这些断言；其次考虑覆盖点。由于经过验证的断言不会生成任何波形，因此很难确定我们的FPV环境是否有效地执行了设计；另一方面，观察覆盖波形将直接显示我们的模型的基本流是否如预期的那样发生。

       在第一次FPV运行时，专注于覆盖点state1的实例，该覆盖点显示每个状态机和状态都能到达每个状态；还将关注FSM实例"0"，因为四个FSM都是对称的。第一次运行结果如下（表5.2）。

         看这个结果，可以很快发现有些事情不太正确。首先，在一个循环中覆盖所有盖子；如上所述，这可能是在早期wiggling阶段不正确的复位约束或缺失假设导致的。其次，在复杂性阶段，创建了一个假设，以防止紧急信号到达，因此预计的GREEN_emergency状态根本无法覆盖。要对此进行调试，首先查看最有问题的覆盖点的波形，即GREEN_EMERGENCY的波形，如下图5.6所示

         使用工具选项来显示波形中的复位周期，这通常是调试1周期FPV结果的最佳方式；许多FPV工具在默认情况下隐藏复位周期。

        当处理FPV工具的极短波形时，确保打开工具选项以显示复位周期。

        在图5.6的波形中，在复位过程中，状态是不确定的（X），因此它可以在之后的第一个周期中得到任何有效的值。在最开始的设计代码（RTL）中，确实没有复位主状态触发器：

always @(posedge clk) begin
cur_state <= next_state;
end

        只需要添加相应的复位信号来复位FSM状态的逻辑：

always @(posedge clk or posedge rst) begin
if (rst) begin
cur_state <= RED;
end else begin
cur_state <= next_state;
end
end

        现在可以让FPV工具再次运行初始检查。

3、调试另一个短波形

        在上述修复之后，将模型重新加载到FPV工具中，并再次尝试验证初始覆盖点。这次得到如下结果（表5.3）。

         现在四个状态中的三个状态根本无法覆盖，虽然预计GREEN_EMERGENCY状态将被发现。

        由于该工具已经证明无法达到这些覆盖点，要获得波形来查看，最好的方法是查看能够覆盖的一个相关覆盖点（如果没有可用的覆盖点，则创建一个简单的覆盖点），并查看与覆盖点相关的信号的行为。RED状态可以覆盖，因此先查看该情况生成的波形，如图5.7所示。

         上图先示了状态被复位为红色，周期1上的红色状态是预期的；由于其他状态没有被覆盖，这表明该信号可能永远停留在这个状态。可以创建一个更有趣的覆盖点，显示在接下来的几个周期中保持红色，并尝试通过使用FPV工具的调试功能来跟踪后续周期中持续红色值的驱动因素，来找出发生这种情况的原因。

        调试不可到达的（unreachable）覆盖点时，可以使用或创建一个可到达的简单覆盖点，然后逐渐增加其复杂性，以便更深入地了解设计的行为。

        上述示例，看到五个周期的红色状态应该就足够了：

test_cover: cover property ((cur_state == RED)[*5]);

        为这个新的覆盖点生成trace之后，使用FPV工具的调试功能添加cur_state信号的驱动程序，如图5.8所示。

         到达状态机的yield_in信号对于实现从RED状态的转换至关重要。只有当下一个状态之前是绿色的，通过在其转换回红色的同时，设置其让行信号以让出其对交通的所有权时，其中一个才能转换为绿色状态。

        现在发现了问题的根源：对于四个状态机中的任何一个要转换为绿色，另一个必须首先为绿色，然后设置其yiled信号。但目前的设计在开始时将所有灯复位为红色，因此没有灯会变成绿色。所有需要修改复位条件，使其中一个灯复位为绿色：

parameter t_state RESET_STATE[3:0] = {GREEN,RED,RED,RED};
always @(posedge clk or posedge rst) begin
if (rst) begin
cur_state <= RESET_STATE[index];
end else begin
cur_state <= next_state;
end
end

更改后，重新运行FPV工具，并获得更合理的覆盖点结果(表5.4）:

        此时未覆盖的GREEN_EMERGENCY状态是可以接受的，因为使用了一个assumption关闭了紧急状态（这是一个约束）。选择黄色时，可以在图5.9中看到期望中的该系统的流类型。

         现在可以看到每个方向的预期流量依次到达绿色状态，这是一个典型视图，说明了这个系统应该如何运行。已经基本上覆盖了cover_wave属性，匹配了规格书中给出的波形，而没有真正尝试。我们还应该继续完整运行，检查所有覆盖点，包括cover_wave和每个流量状态机1、2和3的状态覆盖。

五、探索更多有趣的行为

         前面已经过了FPV的第一阶段，现在要检查和实验设计的各种行为，并了解它在各种条件下的行为。在最初的 design exercise计划中仍然有一些尚未验证的断言，因此要确保检查这些断言。形式设计探索的一部分能力是：可以调整设计和环境行为的各种可能性。

        尝试创建新的断言和覆盖点，不一定与 design exercise计划中的内容相匹配，因为在形式设计探索过程中会出现新的想法和问题。

1、回答一些新问题

        在观察图5.9中显示绿灯依次切换到每个FSM的覆盖波形后，可能会想到：

• 确定周期会重复吗？也许我们犯了一些微妙的错误，在每种颜色出现一次后，就会让我们陷入困境。
• 相反，这些转变总是那么快就会发生吗，或者一个灯有可能长时间停留在一个状态？

        为了回答这些问题，可以在状态机中创建一些原始计划中没有的覆盖点：

cover_interesting1: cover property ((cur_state == GREEN) ##1
(cur_state != GREEN) ##[1:$] (cur_state == GREEN));
cover_interesting2: cover property ((cur_state == RED)[*20]);

        当运行该工具时，可以得到在这两种情况下合理的覆盖波形，如图5.10和5.11所示

 

         由于这些行为似乎是合理的，我们还应该抽查设计中的一些其他活动：对各种其他信号的预期值有想法，例如cars_waiting、yield_out等，最好确保它们也按照预期行事。将cars_waiting信号添加到cover_interesting1波形后，实际上发现了一些意想不到的东西，如图5.12所示。

         汽车等待信号自行下降，显示没有汽车等待，即使灯仍然是红色。在一个U形转弯是合法的状态，由于交通灯控制器设计得很差，汽车不等绿灯就掉头是常见的情况。但更可能的是，期待汽车继续等待，直到绿灯亮起。这种奇怪的行为似乎不会发现的任何bug，但我们仍然希望查看和测试现实的示例。因此在状态机设计中增加了一个假设：

no_vanishing_cars: assume property ((cars_waiting && (cur_state ==
RED)) |=> cars_waiting);

        有了这个新的假设，现在看到了更为合理的波形，汽车只有在看到绿灯后才会从方向的等待队列中消失，如图5.13所示

        在设计的早期阶段，这种探索对于激励对进一步设计决策的讨论，并提供反馈帮助指导对规范的进一步细化非常重要。我们应该继续添加信号并检查波形，直到对想要的基本功能和流程有信心。

        在这个简单的设计中，让假设我们已经回答了所有的基本问题，然后继续检查断言的证明。

2、证明断言

         使用FPV工具作为一种即时性测试台生成器（testbench generator），让其找到可以手动检查的特定波形。

        FPV的最大功能是证明断言的能力：这可以为我们提供形式上的信心，即在任何可能的仿真中都不会出现不良行为。在上述示例中，只定义了少量断言，试图证明它们的结果如下（同样，由于存在多个对称状态机，最初只是显示状态机"0"的结果）（表5.5）

        

         前两个是pass，不能违反多个活跃方向交通的基本安全条件，不能进入BOGUS状态。紧急状态的vacuous pass（假pass）表明我们不能违背它，它的先决条件（先行算子）永远无法满足。这样定义这个属性：

emergency1: assert property (emergency |->
##2 (light == L_GREEN));

        这是一个触发的暗示，说明如果emergency信号为高，那么必须在两个周期内变为绿灯。但在前面的配置中，为了简化设计探索，永远不会得到高emergency信号：

fv_overconstrain_emergency: assume property (global_emergency == 0);

        失败的属性liveness1。这是一个属性表明等待的汽车最终会得到绿灯：

liveness1: assert property (
((cur_state == RED) && cars_waiting) |->
s_eventually(cur_state == GREEN));

        由于该property fail，这意味着在某些条件下，当汽车在等待时，灯可能会永远变红，这当然不是交通灯控制器的理想功能。为了理解发生这种情况的原因，可以检查FPV工具生成的反例波形，如图5.14所示

        一个2周期波形可以作为反例出现在这里似乎很奇怪：因为这是一个活性属性，使用s_eventually运算符指定无限条件。这是一个无限的例子：当liveness property fail 时，FPV工具生成由两部分组成的波形：前缀（prefix）和循环（loop）。

        前缀是一个有限的波形，在上述例子中只有一个周期，在反例中出现一次。 loop 由周期2上的不同阴影表示，是一系列事件，可以理解为重复无限长的时间。所以这个波形表示，在周期1的事件发生之后，周期2的事件可以在无限长的时间内重复发生，导致s_eventually 条件永远无法满足。在这种情况下，当汽车在周期1中到达红灯时，该灯可以在周期2和之后的每个周期中保持红色。

        要想了解为什么周期2中的loop可能发生，看看红色状态的fanin，弄清楚为什么它可能永远存在。在FPV工具中添加了几个级别的fanin后，可以追踪根本原因，如图5.15中的新波形所示

        这引出了一个有趣的见解。请记住，我们有一个轮询（round-robin）协议，如果满足两个条件，每个方向都会在下一个时钟周期发出绿灯：

• 没有汽车从当前方向驶来；
• 有一个来自下一个灯的FSM的请求，因为汽车在那个方向等待。

        在这个波形中，可以看到，灯"0"处的不良驾驶员被卡住了，因为灯"1"从未发出绿光，这是因为灯"2"从未发出绿光。。。因为灯"2"从未请求绿灯！"2"号灯处的汽车等待信号始终为"0"，表明没有汽车到达那里，因此该方向从未要求绿灯。因此，灯"3"永久地保持在绿色上，看不到任何释放它的理由。

        如果上述两个条件中的任何一个在无限时间内保持为"0"，则轮询协议将有效地无限终止。这是一个有用的见解：实际上，在中心协议中发现了一个根本性的缺陷：一种恶意光阻止其他光变绿的方法。需要根据项目需求来决定这是否需要进行重大的重新设计，或者是否忽略了一些对设计环境真实的假设。

       在现实生活中，总是会有汽车从各个方向驶来，而且也总能保证交通畅通。因此只需要添加一些FPV假设，而不是重新设计控制器。正如之前提到的那样，在FPV中花费的绝大多数时间都是为了理解该工具产生的corner-case波形，并决定是否需要收紧假设，还是有真正的设计缺陷。

        继续“wiggle”，在检查反例波形后添加更多假设，是FPV过程的预期部分。只有少数反例波形会导致实际错误，但更多的波形会导致对设计需求的新见解。

         为了解决上述问题，需要每个方向最终cars_waiting = 1，所以它会请求光线；并且还需要保证每个方向最终都会cars_waiting = 0，所以它会释放光线。因此可以将这些假设添加到模型的每个方向：

traffic_gap1: assume property (cars_waiting |=> s_eventually
(!cars_waiting));
traffic_gap2: assume property (!cars_waiting |=> s_eventually
(cars_waiting));

        一旦添加了这些假设并重新运行了证明，property就全部通过了。对于更复杂的设计，我们期望在达到这个阶段之前进行多次迭代。复杂的输入组合不会导致违反我们前面所描述的的基本安全规则或导致交通系统死锁。但是最开始为简化问题而遗留的问题：忽视紧急（emergency）情况。

六、消除简化，探索更多行为

        当计划对交通灯控制器进行验证时，添加了一个过约束，即假设emergency信号为0：

fv_overconstrain_emergency: assume property (global_emergency == 0);

        在这种限制下工作非常有用：能够探索和验证基本的交通灯协议和设计，而不必担心紧急情况的复杂性。但现在已经完成了基本的验证，是时候检查模型在更复杂的条件下的行为了。

        在删除这个约束之后，对所有断言和覆盖点重新运行FPV工具，以获得任何问题点的初步想法。当覆盖点被移除时，仍然可以达到，现在可以涵盖GREEN_EMERGENCY状态（表5.6）。

         一些 cover traces 的长度有所下降，因为可能的行为范围被扩大了。检查每个覆盖点的波形，并确保看到的是一些真实的流量和值。

        现在允许任意发生的基于紧急情况的大范围行为，因此很可能会发现一些新的极端情况，可能会违反其中之一。检查top级和交通FSM "0"的断言结果，发现情况确实如此（表5.7）

         基本安全属性safety1的失败是最大的担忧，这是确保多个方向的交通不会同时变黄或变绿的属性。如果违反了这一点，那么设计就存在一个重大问题。查看该属性的fail 波形可以让我们了解一些情况（图5.16）。

        紧急协议有两个根本缺陷。首先，从灯[3]和灯[2]的值中看到，如果一个灯是绿色的，而紧急信号到达另一个方向，则另一方向将发出绿灯，而第一个方向仍然是黄色的，从而导致潜在的碰撞。需要确保紧急转换到绿色的时间延迟一个周期，才能变成黄灯。此外，可以看到多个紧急信号可以同时到达，导致每个方向同时变绿！没有办法证明禁止这样做是一种环境假设，因为紧急车辆可以随时到来；当出现这种情况时，需要修改设计以进行仲裁。

        重新添加简化假设fvoverconstrainemergency会更安全，可以首先在一个更简单的环境中验证这些主要更改没有破坏非紧急状态。在确定没有什么东西被破坏之后，回到这种无约束的环境更有意义。

1、面临复杂度问题

        遇到复杂性问题，一些断言可能很难产生可接受的结果。例如，试图证明我们的一个断言（表5.8）时，可能会看到这个结果：

 

          property safety1，验证引擎无法完全阻止其成功或失败，并且在仅将其验证到五个极限时超时。这意味着，这仅适用于5个周期（bounds）或更短的潜在执行，而不是很好的结果。

        有几种简单的技术可用于降低设计复杂性：可以添加黑盒（blackbos)或切点(cut-points)，隐藏一些逻辑以进行验证；也可以尝试使用过约束将设计限制为特定模式或数据类型。将在后面的章节中看到，有许多更强势的技术可用。

        在design exercise模式下运行时，通常不希望花费大量时间处理复杂度。如果大多数property都遇到了超时和 low bounds（undetermined问题，太复杂了证明不出来）问题，那么需要寻找潜在的降低复杂性的机会，或者可能在复杂性分段计划中添加更多中间步骤。

        如果能够证明或探索大部分的断言和覆盖点，应该把那些有复杂度问题的放在一边，后续章节会做出介绍。