1.理清验证环境
16路输入,16路输出的路由器。
验证组件:
完整的测试平台应该包含以下验证组件
lab1的基础验证结构:
底色为灰色的为Top文件,在顶层文件中应该有例化测试文件,DUT文件,和接口文件;从该图中可以看到Test文件中包含对设计DUT的复位任务。复位端reset_n低电平有效
通过接口interface将program中的reset激励连接到DUT的复位端。也就是说在top中接口实例要与router实例的端口对应连接。
一、接口文件
- 所有的接口都是没有方向的
- 所有的方向在时钟块里说明,时钟块clocking可以模拟硬件的输入(input)采样和输出(output)驱动。 之后的所有数据驱动都需要用到clocking
- skew定义是模拟硬件的建立保持时间,对input的采样时在时钟上升沿的前1ns,在采样后的1ns对output进行驱动。
- modport TB(clocking cb,output reset _n)连接测试程序,后续测试文件中的验证组件驱动需要通过插口TB完成。
问题:
- 为什么reset_n复位从x跳转到0,而不是1?
四值逻辑初始值是x
- 为什么restet_n发生在0时刻,而frame_n和valid_n的翻转发生在51ns处,而且reset_n过2ns后再次翻转为1也发生在51ns处?按照代码来理解reset_n跳为1应该在frame_n和valid_n的翻转后的2ns?
test在top中例化后,rtr_io.reset_n仿真一开始程序就运行了(接口没有敏感事件),所以rtr_io.reset_n在0时刻复位。
rtr_io.cb.frame_n;rtr_io.cb.valid_n时钟块的output要在时钟上升沿触发后的1ns(51ns)才可以驱动为1,因此在51ns翻转。rtr_io.cb.reset_n是时钟块内的input在时钟上升沿的前1ns(49ns)采样,而program里定义rtr_io.cb.reset_n延迟2ns后赋值,也就是51ns时翻转为1。
- 为什么仿真在1450ns结束?(module与program的区别)
模块含有代码和变量,可以在其他模块中例化。程序块不能有任何的层级例如:模块的实例,接口或者其他程序。仿真会在程序块结束时自动结束。