SV通识部分二
2020-11-10 13:44:56 0 举报AI智能生成
大家赞赞吧
作者其他创作
大纲/内容
SV通识部分二
测试平台
包括：验证结构中的各个组件、组件之间的连接关系、测试平台的配置和控制
系统上包括： 编译仿真流程、结果分析报告和覆盖率检查等
狭义上要关注： 结构和组件部分，可以产生设计需要的输入，也会在此基础上进行设计功能的检查
组件间相互独立，验证组件与设计间需要连接，验证组件间需要通信，验证幻境需要时钟和复位信号驱动
硬件设计描述
（硬件描述文档左侧） MCDF，将uplink多个通道数据经过内部的FIFO最终以data packet形式发出
结构
包含 Slave channel 、Arbiter、Registers、Formatter
接口时序
系统信号端口
clk（0）、rstn（0）
通道从端接口
CHx_DATA(31:0) CHx_VALID(0) CHx_READY(0)
当前拍，且单个数据接受
整形器接口
FMT_CHID(1:0) FMT_LENGTH(4:0) FMT_REQ(0)发送请求 FMT_GRANT(0)被允许发送的接受标示 FMT_DATA(31:0) FMT_START(0) FMT_END(0)
reg和grant至少差一拍（且对于整个数据包能否接受，先检查缓存是否足够）数据连续发送，start和grant也差一拍，start和end和数据同时发送和结束，总时长为length
data必须连续发送
控制寄存器接口
CMD(1:0)读写命令、CMD_ADDR(7:0)、CMD_DATA_IN(31:0) CMD_DATA_OUT(31:0)
data_in跟CMD写命令同时发生，data_out比读命令晚一拍
MCDF寄存器描述
地址0x00通道0控制寄存器32bits读写寄存器
bit（0）
通道使能，1开，0关，复位值1
（2：1）
优先级：0最高，3最低，复位值3
（5：3）
数据包长度：0对应长度4，1对应长度8，2对应长度16，3对应长度32，4-7均暂时对应长度32，复位值0
（31：6）
保留位：无法写入，复位值0
0x04
0x08同上
0x10通道0状态寄存器32bit只读寄存器（表示硬件内部状态）
bit（7：0）
uplink data从端FIFO的可写余量，同FIFO的数据余量保持同步变化，复位值为FIFO的深度数
（31：8）
保留位：复位值0
0x14
0x18同上
上行和下行数据的接口协议不同
MCDF也有寄存器的读写接口，可以支持更多控制功能
激励发生器stimulator
也被称为driver，BFM，behavioral，generator发生器
模拟与DUT相邻设计的接口协议（也应该有clk和rstn的输入确保和dut的接口一侧是同步关系），只需要关注如何模拟接口信号，使其能够以真实的接口协议来发送激励给DUT（边界信号）
不该违反协议，但不拘束于真实的硬件行为
比真实硬件行为更丰富的激励，会使得模块级验证更加充分
较精细的stimulator还可以有其他的配置接口用来控制接口的数据生成
也可以有存储接口数据生成历史的功能
分为：initiator和responder，MCDF中，与channel slave和registers接口的属于initiator，主动发起接口数据传输。与formatter接口连接的属于responder，对接口的数据发送请求做出响应，而它本身不会主动发送数据。
stimulator实现要考虑的因素
channel initiator
确保channel 从端接口协议上有握手信号，需要遵照接口时序，确保chx_ready为低时，保证chx_data和chx_valid保持不变
相邻数据之间没有数据包的限制，所以相邻数据之间的关系较弱，也应该考虑数据之间是否有空闲周期，以及整体数据的传输速率设定
由于每一个数据从端都有对应的FIFO缓存数据，所以也要考虑如何让FIFO的状态可遍历。例如，典型的FIFO状态可以分为enpty，full，以及中间状态。要使得FIFO可以触发这些状态，我们就应该控制channel initiator的传输速率。
register initiator
接口上cmd默认状态应为idle，但是cmd_addr、cmd_data_in并未指出默认值应该为何值，所以可以考虑给出随机数值测试DUT的接口协议稳定性
在寄存器读写传输上，可以考虑连续的写/读或者读写交叉的方式测试寄存器模块的读写功能
对于读写寄存器的所有比特位测试都应该覆盖
对于只读状态寄存器需要测试是否为不可写入的设定，同时需要测试读出的数值是否为真实的硬件状态
formatter responder
先侧重formatter的接口协议是否充分遍历
需要详细理解协议的要求，除了按照协议给出fmt_grant的响应，也需要检查协议的时序
fmt_grant的置高，代表formatter的从端有足够的存储空间，可以容纳formatter要传输的长度为fmt_length的数据包。为了模拟真实场景，可以考虑让fmt_grant采取立即拉高或者延时拉高的行为，测试formatter接口的响应时序。
监视器
概述
monitor主要用来观察DUT的边界或者内部信号，并且经过打包整理传送给其他验证平台的组件，例如check
观察DUT边界信号 ： 对于系统信号如clk，可以监测其频率变化；对于总线信号，可以监测总线的传输类型和数据内容，以及检查总线时序是否符合协议
观察DUT内部信号： 从灰盒验证的手段来看，往往需要探视DUT内部信号，用来知道stimulator的激励发送，或者完成覆盖率收集，或者完成内部功能的检查。
组件结构方案
全局性
分布式（较好）
独立性，复用性，可维护性，封装性好与全局性
内部信号监测建议
若无特殊需要，应采取灰盒验证策略（非白盒验证）
观察的内部信号应尽量少，且是表示状态的信号（不建议采集中间变量信号：信号时序、逻辑甚至留存性都不稳定，对验证环境的收敛是有害的）
可以通过接口信息计算的，尽量少去监测内部信号，因为这种方式有悖于假定设计有缺陷的验证思想。观测到的内部信号在被环境采纳之前也有必要确认他们的逻辑正确性（可通过动态检查或者断言触发的方式来实现）
比较器
check是最需要时间投入的验证组件
肩负着模拟设计行为和功能检查的任务
功能
缓存从各个monitor收集到的数据
将DUT输入接口侧的数据汇集给内置的reference model，reference model扮演了模拟硬件功能的角色，也是需要较多精力维护的部分，因为验证者需要在熟悉硬件功能的情况下实现该模型，而又不应参考真实硬件的逻辑
通过数据比较的方法，检查实际收集到的DUT输出端接口数据是否同reference model产生的期望数据一致
对于设计内部的关键功能模块，也有相对应的线程进行独立的检查
在检查的过程中，可以将检查成功的信息统一纳入到检查报告中，便于仿真后的追溯，若检查失败也可以采取暂停仿真同时报告错误信息的方式，进行在线调试
实现方式
online check
仿真时收集数据和在线比较，并且实时报告
offline check
仿真收集到的数据记录在文件中，仿真结束后通过脚本或者其他手段进行数据比较
将checker添加到验证环境中，需要分析DUT的边界激励，理解数据输入，并且按照硬件功能来预测输出的数据内容，该预测（prediction）过程发生在reference model中，有时也称为predictor。
reference model也会内置一些缓存，分别存放从DUT输入端观察到的数据，以及经过功能转换的数据，同时checker也有其他缓存来存放从输出端采集到的数据
组件结构
reference model 、 formatter FIFO（output data buffer） 、 data checker
channel checker
arbiter checker
register checker
formatter checker
checker、monitor、stimulator与MCDF内部各个模块都有着一一对应的关系。
分散搁置
各自检查对应模块的功能
checker之间通信需要特殊连接
报告信息较难统一
对于各个checker的使能控制因其分散变得复杂
集群搁置（较好）
checker各自相邻，可以共享monitor的输入，减少复杂的连接关系
可以按照统一的报告形式，写入到记录文件中
集中管理各个checker，例如在前期使能各个模块的checker，在后期可以将其作为黑盒验证，只使能data checker
结构实现建议
对于复杂的系统验证，我们倾向于集中管理stimulator和checker，因为他们两者都需要主动给出激励或判断结果，也需要较多的协调处理
monitor则相对更独立，因为它只是作为监测方，将其兢兢业业观察到的数据一字不落的交给checker即可，至于checker怎么使用，monitor并不需要关心。
因此，monitor和checker是一一对应，我们通常将他们进一步封装在 agent 单元组件中，而checker则最终集群搁置在中心化的位置
验证结构
情景模拟
模拟实际工作，抛出一系列问题，加以思考
课程给出的建议按照工程项目观点，是合理的
项目背景
项目耗时
channel slave（slave interface+FIFO） 需要 7 个工作日
arbiter 需要 10 个工作日
formatter 需要 5 个工作日
registers 需要 4 个工作日
MCDF integration（模块集成）需要 2 个工作日
designer安排（取最长设计者用时间安排）
肖
channel slave 7 天 + MCDF integration 2 天 = 9 天
吕
arbiter 10 天 = 10 天
高
formatter 5 天 + registers 4 天 = 9 天
verifier安排（按照验证设计3：2人力安排）
channel slave 11 个工作日
arbiter 15 个工作日
formatter 8 个工作日
registers 6 个工作日
MCDF integration 各个模块在子系统完成后集成验证，暂时定 30 个工作日
职业：硕士
0 条评论
回复 删除
下一页
