Simulation Result Show


PASS with no warnings:

PASS with warnings:


A trap of SystemVerilog inline constraint

In Constraint Random Verification(CRV), we may write the inline constraint with below format:


In most cases,  this works. After be randomized, the value of item.var1 is _something_. But have you ever thought about the result of below codes:


You will find that the  both item.var1 is not set to 10, but a random value. Why? This is because the ‘scope’. For inline constraint, it first looks up the var1 in item scope, thus it finds var1. The inline constraint equals to:


That means assign the value to itself. So the result is a random value.

To achieve our goal, there are two ways.

First is rename the local variable name from var1 to _var1.

The second is add “local::” contributor before the local variable var1. Shown as below.



Then the item.var1 will be set to 10 after randomization.

A summary: The priority of the scope in inline constraint is



2016年9月,我去面新的工作,面试官问了我一个问题:如果在不同的component的同一个phase中对uvm_config_db#(int)的某个key set不同的值,那么最终哪个值会生效?当时只是肤浅的回答:后设置的生效。然后面试官引导了一下,问,那在build_phase中呢?回答是最顶层的设置生效。虽然答案是对的,但是我想并没有达展现是面试官想要的。




SV DPI Scope

SV的DPI(Directed Program Interface)提供了SV与其他语言(C/C++)通信的桥梁。本文不会讲解DPI的基础知识,只针对Scope这一概念进行解释,因为这是在DPI编程中常遇到的,也是比较难debug的问题。

对于SV呼叫C,不会存在Scope不对找不到对应的C function的问题。但是C呼叫SV,则会碰到这种问题。VCS仿真器会给出如下Log

Error-[DPI-DXFNF] DPI export function not found

The DPI export function/task ‘sv_task’ called from a user/external  C/C++/DPI-C code originated from import DPI function ‘c_main’ at file ‘'(line 3) is not defined or visible.

Please check the called DPI export function/task is defined in the mentioned which invokes that DPI export function/task is made with ‘context’. Another work-around is using svGetScopeFromName/svSetScope to explicitly set the scope to the module which contains the definition of the DPI export function/task.

Continue reading “SV DPI Scope”

Open Verdi with existed simv

Verdi is a very useful tool in ASIC/SoC verification. We use it to check waveform and debug issues. Usually we use

to open the Verdi GUI. In this way, Verdi will compile the Design and Testbench with the files specified in dut.f and tb.f which may spend much time.

Verdi provides another way to avoid this. First you needs to add “-kdb” option when analyze your design&testbench files, re-compile and build the design&testbench, then you get the “./simv” which is an executable binary file. Now you can use below command to open verdi without re-compiling DUT/TB: Continue reading “Open Verdi with existed simv”

Dynamic constraint using decorator design pattern

During the process of functional verification, we may encounter the problems of narrowing down the constraint to verify some corner cases times again. Usually we will need a children class and write down the constraint in it. If there are lots of corner cases, then we have to maintain lots of children classes. It’s painful and boring work.

And in another case,  we have a class tree with 1 parent class and 4 children classes. If we want to add new constraint to the parent class in some test cases, in traditional way, that means another 4 grandchildren classes with the same constraint block. Continue reading “Dynamic constraint using decorator design pattern”