SV中的module,interface,program,checker,都提供declaration空间,内部定义都local当前的那个scope,相互之间的building block不影响,不识别. package也可以提供一个declaration的空间,可以被其他的building block共享,Package declaration可以被import到其他的building block中,或者package中. (package中不能再包含module,interface,prog

SV搭建testbench的关键概念:CRT(constraint random test),测试集的随机化. 由于对象class由数据和操作组成,所以对数据的随机化一般放在一个class内.(对环境或环境的配置也可以反映在配置参数的随机化上) 一个constraint包括两部分:rand/randc变量声明,constraint约束块.其中randc会在重复之前,周期性取值,constraint约束块中的变量至少有一个rand/randc 变量,constraint约束块必须在{}内,用:来表

SV中线程之间的通信可以让验证组件之间更好的传递transaction. SV对verilog建模方式的扩展:1) fork.....join 必须等到块内的所有线程都执行结束后,才能继续执行块后的语句.(所以使用的很少) 2) fork.....join_none 先执行块后的线程,而后再执行块内的线程.不会产生块后的线程必须等块内线程的情形. 3) fork.....join_any 只要块内的线程有一个执行结束,就执行块之后的线程. 需要说明一下,begin.....end之间的顺序操作,

Interface:SV中新定义的接口方式,用来简化接口连接,使用时注意在module或program之外定义interface,然后通过'include来添加进工程. interface  arb_if(input bit clk);              //clk信号,一般单独拿出来 logic [1:0]grant, request;       //只定义信号类型.类型在不同的modport中分别定义. logic rst; clocking cb @(posedge clk); 

SV中class的properties和methods默认都是public的,但是可以声明为local和protected. 一个properties声明为local类型的,则只在该class中的methods可以调用该变量.即使subclass也不可以调用. local interger i; 一个properties或者methods声明为protected,与local类似,但是在subclass中可见. extern protected virtual automatic task_na

Verilog-1995中规定的数据类型有:变量(reg), 线网(wire), 32位有符号数(integer), 64位无符号数(time), 浮点数(real). SV扩展了reg类型为logic,除了reg类型的功能外,可以用在连续赋值,门单元和模块所驱动.但是不能用在双向总线建模,不能有多点驱动. 其他数据类型:无符号双状态  bit, 有符号双状态32位   int, 有符号双状态8位     byte,                            //可以用内置函数  $

OOP:Object-Oriented Programming,有两点个人认为适合验证环境的搭建:1)Property(变量)和Method(function/task)的封装,其实是BFM模型更方便的应 用.2)继承(Inheritance)与合成(Composition)非常适合一个架构的搭建. 在SV中,类可以定义在program, module, package中,但是一般一个类或几个相关的类会单独写在一个文件中.最终在program中调用.而且在SV中,所有成员 默认都是public类

SV采用CRT的激励形式,而判断验证进度的标准也就是覆盖率(coverage). 覆盖率的两种指定形式:显式的,直接通过SV来指定出的,如SVA,covergroup. 隐式的,在验证过程中,随"register move"就可以由simulator得到的,如代码覆盖率等. 覆盖率类型:代码覆盖率---由仿真器直接提供,只能表示设计的冗余度,与spec关系不大.(toggle/expression/block) 功能覆盖率---与spec比较来发现,design是否行为正确,需要按ve

UVM中的类包括:基类(base)------------uvm_void/uvm_object/uvm_transaction/uvm_root/uvm_phase/uvm_port_base 报告(reporting)--------uvm_report_object/uvm_report_handler/uvm_report_server/uvm_report_catcher Factory---------uvm_*_register/uvm_factory 配置(config)----

randomize中的变量只支持2-state的values,不支持4-states. randc类型的变量不能被约束在solve------before的语句中. constraint可以被定义在class外: class  C: rand int x: constraint protol:    //隐式的 extern constraint protol2:    //显式的 endclass constraint C::protol { x inside {-4, 5, 7}; } co

SV中的class通过new来创建实例,new函数可以传递多个参数: packet P1:  P1 = new:创建一个P1的对象: P2 = P1:P2也指向同一个对象: P2 = new P1:P2是P1的shadow copy,指针直接被copy. 对于参数化的class的new函数调用:new函数可以通过类操作符::来调用 class E#(type T = int) extends C: T x: function new(T x_init) super.new(); x=x_init

SV中的structured procedure: 1)intial procedure,keyword只有initial:最开始被调用一次: 2)always procedure,keyword包括always,always_comb,always_latch,always_ff: 整个仿真时间一直被调用: 3)final procedure,keyword 只有final:最后被调用一次: 4)Task: 5)function: 其他的procedure contexts,包括:covera

Verilog与C之间进行程序交互,PLI(Programming Language Interface)经过了TF,ACC,VPI等模式. 使用PLI可以生成延时计算器,来连接和同步多个仿真器,并可以通过波形显示等调试工具. 通过PLI方式连接一个简单的C程序,需要编写很多代码,并理解多仿真阶段的同步,调用段,实例指针等概念. PLI方式给仿真带来了额外的负担,为了保护Verilog的数据结构,仿真器需要不断的在Verilog和C之间复制数据. SystemVerilog引入了DPI(Dire

1)首先定义纯虚类Sv_object,主要实现下边两个function: 定义local static 变量nextobjectID; 虚方法 virtual function void copy(St_object that, CloneType clone_type = DEEP);在基类中复制都可以通过super.copy来迭代copy. 2)在Sv_object的基础上,实现对mailbox和event的封装.产生两个基类Sv_mailbox_wrapper与Sv_event_wrapp

我们可以在uvm中实现HDL的后门访问,具体包括的function有uvm_hdl_check_path,uvm_hdl_deposit, uvm_hdl_force,uvm_hdl_release,uvm_hdl_read, task 有uvm_hdl_force_time. 这么做与直接用SV中force, release 有什么区别,有什么好处?这么做的话函数的输入是字符串而不是HDL(hardware description language, 硬件描述语言 )的层次结构.有了字符串就可

一.SV中非堵塞事件 module test; event ev1, ev2; //belong to logic function part always@(ev1) $display("ev1 triggered at %0ts", $time); initial wait(ev2.triggered) $display("ev2 triggered at %0ts", $time); //belong to stimulus initial begin -&g

一份代码,在写完之后,一定要再经过一次或多次整理和打磨,才能算完成的:一份代码,一定要把其有效代码行,精简.锤炼到最少.最短.最有效,才能算完成的.   下面这些问题和回答是忘记是在哪里看到的了,参考夏晶的文章,和我自己的验证经验,做了补充,作为日后学习的参考. Q:验证的目的? A:这也是发现Bug,发现所有的Bug,或者证明没有Bug(转自夏晶的帖子),无论任何验证语言.任何验证环境.任何验证方法学.任何Feature List,都是为了达成这一目的而使用的方法,或者所手段.这是夏晶给出来的

一.前言 近期疫情严重,身为社畜的我只能在家中继续钻研技术了.之前写过一篇关于搭建FIFO验证平台的博文,利用SV的OOP特性对FIFO进行初步验证,但有很多不足之处,比如结构不够规范.验证组件类不独立于DUT等问题.此次尝试验证更复杂的IP,并利用SV的更多高级特性来搭建层次化验证平台. 二.APB_I2C IP概述 实践出真知,于是在opencores网站上下载了个APB_I2C的IP核,便着手展开验证工作.第一步是理清楚这个IP的整体功能.引脚作用以及顶层结构.整体功能从模块名称便可得知是

1.测试平台的构建 发生器(generator):创建事务并且将它们传给下一级 驱动器(drive):与设计进行会话 监视器(monitor):捕获设计返回的事务 计分板(scoreboard):将捕获的结果跟预期的结果进行对比 测试平台应该分成若干个块(block),然后定义它们相互之间如何通信. 2.OOP(Object-Oriented Program) 类(class).对象(object).句柄(object).属性(property).方法(method).原型(prototype)

本期将讲解UVM环境构成和启动方式.主要参考资料为 http://bbs.eetop.cn/thread-320165-1-1.html http://rockeric.com/ 环境构成 进行仿真验证的基本流程是 例化DUT 产生并发送激励 检测响应 检查响应是否正确 在验证环境中,产生并发送激励将会交给两个不同的类完成,即uvm_driver和uvm_sequence,检测响应通过uvm_monitor完成,而检查响应是否正确通过uvm_scoreboard.除了保证某项功能正确,我们还需要