现代SOC设计可能涉及连接数十个IP，在顶层通过MUX进行总线选择，最终连接到芯片外部的引脚，这些IP的连接具有不同的延迟。
从验证的角度看，存在着很多的边界场景，因为不同IP的连接和控制逻辑相互耦合。
如果希望使用Simulation进行完备地验证，通常需要花费巨大的努力，人为地分析清楚这些边界场景进行覆盖。
所以SOC连接验证属于FPV中的一个非常适合的场景，这个MUX逻辑比较简单，大多数的连接规格都很容易转换为直接且明确的断言。
搭建FPV连接验证环境
到目前为止，我们在讨论很多FPV应用场景是都强调了DUT的复杂度问题。FPV连接验证之所以能够用在系统级或者芯片级的原因是我们只关注SOC的连接正确性，而不是所有功能。
另外，在验证SOC连接性的时候，很多和连接正确性无关的逻辑都可以进行黑盒化（blackbox）。
再次强调一点，我们验证的只是连接性，而不是所有的功能规格。
在上图中，我们可以看到所有和连接无关的逻辑模块都被黑盒化，即模块的输出随机。
有一个推荐的FPV SOC 连接验证的策略就是，一开始将所有的子模块都黑盒化，然后执行连接规格断言，然后根据失败的断言将不应该黑盒化的连接规格相关的模块黑盒化去掉（例如一些控制寄存器，MUX逻辑等等）
指明连接性规格
在完成FPV连接性验证环境搭建之后，我们就需要指明我们需要证明的连接性规格，例如：
**• 相互连接的输入输出信号。
• 信号直接的延迟或延迟范围。
• 额外的使能条件。**
为了方便检视或者脚本化这种连接性规格，通常可以使用EXCEL表格描述相应的连接规格要求，如下表所示：
许多FPV EDA工具都定义了这样的表格，可以在本地读取表格生成断言，然后将FPV执行结果反标到表格。
当然了，没有脚本化也没有关系，这种断言写起来也比较简单。
这种 SOC 信号的连接逻辑往往是一组相当简单的 MUX 和触发器，所以像通常很容易被证明，除非中间具有比较深的FIFO或者复杂的控制逻辑。
END
作者：验证哥布林
原文链接：
使用FPV进行SOC连接验证
微信公众号：
推荐阅读
更多IC设计技术干货请关注IC设计技术专栏)
