SOPC第七.ppt

7.4.1 总线功能模型 第0层 提供被测器件和模型之间的基本接口。这一层提供两种语言和各自的仿真器之间的接口，也提供了模块间的管脚连接。同时可以监控被测器件的管脚信号。 第1层 为模型提供第一级命令，主要是读写命令，同时也提供总线功能模型的配置命令。 7.4.1 总线功能模型 第2层 提供将第1层的命令组合使用的功能，这样就可以产生更加复杂的操作。 第3层 模型的最高层，允许产生更复杂的测试。这一层的命令更大程度上与模型和应用程序有关。 7.4.1 总线功能模型 以上4个层次为验证工程师提供了不同抽象层次的测试生成方法： 第0层可以用来测试特定的错误，如奇偶校验 第1层可以验证被测模型的基本功能 第2层可以建立更为复杂的测试 第3层可以产生直接随机测试 7.4.1 总线功能模型 标准服务： 顺序控制、消息处理、日志处理 顺序控制服务就是要对一个任务中并发的多个命令进行管理。 消息处理服务可以由用户指定在仿真过程中应该显示什么类型的信息。 日志服务提供了一种记录所有已执行过的指令的标准机制 7.4.2 总线监控器 总线监控器的三个基本功能： 协议检查：总线监控器将报告所监控的所有违反总线协议或接口规范的操作。 覆盖率报告：监控器跟踪左右发生的操作类型并且在仿真结束时产生对应的报告 事务处理日志：监控器提供所监控总线或者接口的操作记录。 7.4.3 设备模型 除了总线功能模型和总线监控器，建立与被测设计接口的设备模型也非常有用。一个典型的模型就是存储器模型。 如果被测试模块是SDRAM控制器，那么在测试平台中建立不同SDRAM的功能模型将有助于验证测试。 物理层接口的设备模型也非常有用。在USB的例子中，USB模块与几个不同的物理层有接口，拥有一个准确的物理层接口功能模型对于验证USB模块是必不可少的 7.4.4 验证模块的用途 模块验证的验证模块代价很高，但是对于一个完备的验证而言，基于模块的验证和建立一个可重用的验证平台是必不可少的 这些验证模块既可以用在芯片级验证也可以应用在模块级验证中。 7.5 达到100%覆盖率 7.5.1功能覆盖率和代码覆盖率 功能覆盖率和代码覆盖率的高低与否都是说明当前设计被全面验证测试的标准。 HVL可以用来衡量模块功能是否被测试完全 代码覆盖率就是测量RTL代码哪一部分被测试过，哪一部分没有。 7.5.2 硬件建模 IP设计团队使用硬件建模作为仿真的补充手段。对于在子模块验证阶段没有达到百分百覆盖率的IP，硬件建模在IP核验证阶段就更加重要。 对于许多IP核来说，很有必要将IP核和对应的电路板进行硬件建模。并且在真实环境中进行测试验证。 硬件建模最大的好处就是可以在硬件模型上运行真正的应用程序。 7.5.3 试生产 即使经过全面验证和硬件建模，设计也难免包含细微的错误。这主要是由于有一些情况在仿真时没有考虑到，或者在硬件建模时没有对某些配置进行对应的建模。因此虽然基本上已经对IP核进行了全面验证，但是这些IP核还没有在真正的片上系统中进行过应用。所有对于新的IP核应该有一段试生产期。典型的做法是在真正发售这些新的IP核之前，在限定（1到4位）用户群内使用并保证其正确性。这样做可以避免以后因为产品的设计错误而要承担的风险 7.5.4 特性检查 特性检查：对设计的某些规范使用特定的格式或语言进行描述，然后使用形式化技术来证明当前的设计满足这些规范。 状态机的特性检查： 状态机不能进入一个不能够退出的状态 两个状态机不能进入死锁状态 子模块的特性检查： 对于空FIFO不能进行读操作 对于满FIFO不能进行写操作 7.5.4 特性检查 对于模块的接口进行的特性检查： 定义一个合法操作的集合 对这些操作对应的数据进行约束 7.5.5 代码覆盖分析 测试覆盖的种类： 语句覆盖率 分支覆盖率 条件覆盖率 路径覆盖率 触发覆盖率 翻转覆盖率 语句覆盖：统计每一条执行过的语句执行的次数 7.5.5 代码覆盖分析 分支覆盖：分析if-then-else或者case语句的每一个分支是否都被执行过。 条件覆盖：分析分支中每一个条件是否都曾经触发过分支，并且统计每一个条件触发的次数 例7.1 条件覆盖检查分支条件： if (a = ‘1’ or b = “0”) then c = ‘1’; else c=‘0’;