systemverilogconstraintlayering.rar_constraint_random_system

共1个文件

pdf：1个

版权申诉

104 浏览量 2022-09-23 18:45:18 上传评论收藏 301KB RAR 举报

《SystemVerilog约束分层：通过可重用随机化策略类》 SystemVerilog是一种强大的硬件描述语言，它引入了约束随机化技术，使得验证工作更加高效和自动化。本资料集中探讨的核心主题是“约束分层”以及如何利用可重用的随机化策略类来实现这一目标。约束分层是SystemVerilog中的一个重要概念，它允许我们将复杂的随机化规则分解为逻辑上独立的层次。这样做的好处是可以提高代码的可读性和可维护性，同时还能促进复用和模块化设计。在系统级验证中，当面对大量的随机化变量和复杂的约束关系时，约束分层变得尤为重要。我们要理解SystemVerilog中的约束。约束是用于指定变量取值范围和相互关系的规则，它们可以确保随机生成的测试向量符合设计的需求。例如，我们可以设定某些信号之间的时序约束，或者限制某些变量的取值范围以满足特定条件。接下来，随机化策略类（Randomization Policy Classes）是实现约束分层的关键工具。这些类定义了一组随机化行为，可以作为模块或函数的一部分被实例化和应用。通过封装随机化逻辑，策略类能够独立于实际的随机化过程，从而实现复用。它们可以包含基本的随机化操作，如选择、优先级排序，甚至更复杂的条件和循环逻辑。在实践中，我们可以创建多个策略类，每个类专注于一个特定的验证层面或约束集。然后，根据验证场景的不同，我们可以通过组合这些策略类来构建不同的约束层次。例如，我们可以有一个基础策略类处理基本的数据类型约束，另一个处理时序约束，还有一个处理特定功能的约束。文件“system verilog constraint layering.pdf”可能详细阐述了如何定义和使用这些策略类，包括如何定义类结构，如何在类中声明和应用约束，以及如何在测试平台上实例化和组合这些策略。此外，文件可能还包含了实例和示例代码，帮助读者更好地理解和掌握这一技术。 SystemVerilog的约束分层和可重用随机化策略类是提高验证效率和代码质量的有效手段。通过理解和熟练运用这些技术，开发者可以编写出更灵活、可扩展的验证环境，从而更有效地验证复杂的系统级设计。

资源详情

资源评论

资源推荐

收起资源包目录

system verilog constraint layering.rar （1个子文件）

system verilog constraint layering.pdf 337KB

SystemVerilog Constraint Layering via

Reusable Randomization Policy Classes

John Dickol

Samsung Austin R&D Center

Austin, TX

j.dickol@samsung.com

Abstract- SystemVerilog provides several mechanisms for layering constraints in an object. Constraints may be

added via inheritance in a derived class. Inline constraints (i.e. randomize with {…} or `uvm_do_with) permit specifying

additional constraints when randomizing an object. Unfortunately, SystemVerilog does not provide a good way to save

these inline constraints for reuse in subsequent “randomize with” calls.

This paper describes a technique for packaging constraints into reusable “randomization policy” objects and using

one or more of them to augment the constraints used while randomizing another object. Examples will be shown for both

native SystemVerilog classes and UVM sequence items.

INTRODUCTION

SystemVerilog[1] classes and random constraints provide a powerful mechanism for creating verification

stimulus. The language provides several mechanisms for layering constraints in a class object. Constraints may be

added via inheritance in a derived class. Inline constraints (i.e. randomize with {…} or `uvm_do_with) permit

specifying additional constraints when randomizing an object. Unfortunately, SystemVerilog does not provide a

good way to save these inline constraints for reuse in subsequent “randomize with” calls.

This paper defines a way to encapsulate constraints into reusable “policy” classes and defines a methodology to

use arbitrary combinations of these policies when randomizing another object. These policies may either be

compiled into the other object or specified prior to randomization. Different test scenarios can use different

combinations of policies as needed. This technique is applicable to native SystemVerilog or to a verification

methodology such as UVM[2].

CONSTRAINT LAYERING SCENARIOS

Consider stimulus generation for a multi-processor memory system. Several types of constraints are typically

needed for generating interesting transaction addresses:

 Limit addresses to the address ranges in the system memory map. These ranges may be dynamically

generated at runtime and may change during the simulation.

 Avoid addresses in any reserved regions (e.g. “magic” addresses used for testbench control)

 Constrain addresses to cause evictions from the data cache. This requires keeping track of what

addresses are currently in the cache and generating addresses which are not already in the cache.

In theory it’s possible to include these types of constraints into a transaction base class with appropriate control

knobs or add them as needed through inheritance. In practice, however, it is difficult to predict exactly what

constraint capabilities a test writer will want to use. So, the test writer will add constraints in a new class derived

from the base transaction. Different combinations of test constraints will require different derived classes.

Using inline constraints (randomize with{} or `uvm_do_with) is feasible for relatively simple constraints (e.g.

number of transactions, simple distributions, etc.), but can be cumbersome for the more complex constraint types

listed above. These typically require elaborate iterative (foreach) constraints or require updating history information

in the post_randomize method.

REVIEW OF EXISTING CONSTRAINT LAYERING TECHNIQUES

To demonstrate the existing and proposed constraint techniques, let’s start by defining a simple transaction

(addr_txn) consisting of an address and a size (number of bytes). From that base class we derive a read/write

transaction (rw_txn):

class addr_txn;

rand bit [31:0] addr;

rand int size;

constraint c_size { size inside {1,2,4}; }

endclass

typedef enum {READ, WRITE} rw_t;

class rw_txn extends addr_txn;

rand rw_t op;

endclass

Figure 1. Address transaction base class and derived read/write transaction

We can constrain the address by adding constraints in a derived class (rw_constrained_txn):

class rw_constrained_txn extends rw_txn;

constraint c_addr_valid {

// Transaction addr range must fit within certain ranges

addr inside {['h00000000 : 'h0000FFFF - size]} ||

addr inside {['h10000000 : 'h1FFFFFFF - size]} ;

// transaction must avoid "magic" testbench control addresses

!(addr inside {['h13000000 : 'h130FFFFF - size]}) ;

// Don't write to first 4K bytes. Reads OK.

if(op==WRITE) {

!(addr inside {['h00000000 : 'h00000FFF - size]}) ;

}

endclass

Figure 2. Read/write transaction with address constraints in derived class

Or, we can specify inline constraints when randomizing the base object:

rw_txn t = new;

...

t.randomize with {

// Transaction addr range must fit within certain ranges

addr inside {['h00000000 : 'h0000FFFF - size]} ||

addr inside {['h10000000 : 'h1FFFFFFF - size]} ;

// transaction must avoid "magic" testbench control addresses

!(addr inside {['h13000000 : 'h130FFFFF - size]}) ;

// Don't write to first 4K bytes. Reads OK.

if(op==WRITE) {

!addr inside {['h00000000 : 'h00000FFF - size]} ;

}

};

Figure 3. Randomizing read/write transaction using inline constraints

Although both of these techniques are usable, as more types or combinations of constraints are desired, it will be

cumbersome to manage the many derived classes or sets of inline constraints. It would help if there were a way to

package constraints into reusable building blocks.

HIERARCHICAL CONSTRAINT CONTAINERS

SystemVerilog provides a mechanism for hierarchical constraints. The language reference [1] defines “global

constraints” but a better term for this might be “hierarchical constraint classes”. A class may declare an object

member (i.e. class instance) as “rand”. When the top-level object is randomized, the lower level objects are also

randomized. All rand variables and constraints in the top- and lower-level objects are solved simultaneously.

We can apply this idea to our problem by moving sets of constraints into separate classes and declaring rand class

handles for those constraint classes in the base transaction. Now, when the top-level transaction is randomized, the

sub-class instances are randomized at the same time. We have problem however: The constraint classes have their

own “addr” and “size” members which will be independently randomized. We need a way to ensure that these all

have the same value. One way to solve this is adding additional “equality constraints” at the top level to ensure the

addr and size members in each class have the same value. This works, but requires the top-level constraints to

know which lower-level rand variables are in use. We will subsequently show a better way to solve this.

class addr_permit;

rand bit [31:0] addr;

rand int size;

constraint c_addr_permit {

addr inside {['h00000000 : 'h0000FFFF - size]} ||

addr inside {['h10000000 : 'h1FFFFFFF - size]} ;

}

endclass

class addr_prohibit;

rand bit [31:0] addr;

rand int size;

constraint c_addr_prohibit {

!(addr inside {['h13000000 : 'h130FFFFF - size]}) ;

}

endclass

class rw_constrained_txn extends rw_txn;

rand addr_permit permit = new;

rand addr_prohibit prohibit = new;

// Ensure all addr & size are equal

constraint c_all {

this.addr == permit.addr;

this.addr == prohibit.addr;

this.size == permit.size;

this.size == prohibit.size;

}

endclass

Figure 4. Read/Write transaction with address constraints in separate container classes

We can more easily support multiple constraint classes in the top level by deriving all policies from a common

base class and using a queue to contain any number of constraint classes. Using a foreach constraint to constrain the

addr and size members will add the equality constraints for any number constraint containers.

class addr_constraint_base;

rand bit [31:0] addr;

rand int size;

endclass

class addr_permit extends addr_constraint_base;

constraint c_addr_permit {

addr inside {['h00000000 : 'h0000FFFF - size]} ||

addr inside {['h10000000 : 'h1FFFFFFF - size]} ;

}

endclass

class addr_prohibit extends addr_constraint_base;

constraint c_addr_prohibit {

!(addr inside {['h13000000 : 'h130FFFFF - size]});

}

endclass

class rw_constrained_txn extends rw_txn;

rand addr_constraint_base cnst[$];

function new;

addr_permit permit = new;

addr_prohibit prohibit = new;

cnst = {permit, prohibit};

endfunction

constraint c_all {

foreach(cnst[i]) {

this.addr == cnst[i].addr;

this.size == cnst[i].size;

}

endclass

Figure 5. Read/Write transaction using a queue of constraint container classes

It can be a maintenance chore to keep the top-level equality constraints in sync with the constraint objects. For

example, if we want to add a new constraint using rw_txn’s “op” member (READ or WRITE), we need to update

the top-level constraints to support this new member. If a constraint class doesn’t constrain one of the top-level

members, it still needs to declare it for the top-level equality constraints to be valid.

ELIMINATING TOP-LEVEL EQUALITY CONSTRAINTS

If the top-down equality constraints are problematic, perhaps can we use bottoms-up constraints instead? If the

constraint objects had a way to directly refer to members of the containing class instance, we would not need to

maintain the top-level equality constraints. SystemVerilog supports “upwards name referencing” which tries to

resolve variable names by scanning upwards through the module hierarchy (see [1] section 23.8). This is close to

what we want, except we want to scan upwards through the class instance hierarchy which is not supported.

What we can do, however, is declare an object handle in each constraint class which will contain a reference to

the top-level object being randomized. If we write our constraints using this handle, we have access to all of the top-

level objects members with requiring any top-level equality constraints. Figure 6 shows an example of this

technique. The constraint base class (addr_constraint_base) contains a variable “item” of the same type as the top-

level object (addr_txn). The constraints in each constraint class refer to the top level members by using the item

handle (item.addr, item.size, etc.)

One step remains for this technique to work: we need to set the “item” variable to point to the top-level object

before randomizing. This is conveniently done in the pre_randomize method of the top-level object.

class addr_constraint_base;

addr_txn item;

endclass

class addr_permit extends addr_constraint_base;

constraint c_addr_permit {

// Transaction addr range must fit within certain ranges

item.addr inside {['h00000000 : 'h0000FFFF - item.size]} ||

item.addr inside {['h10000000 : 'h1FFFFFFF - item.size]} ;

}

endclass

class addr_prohibit extends addr_constraint_base;

constraint c_addr_prohibit {

!(item.addr inside {['h13000000 : 'h130FFFFF - item.size]}) ;

}

endclass

class rw_constrained_txn extends rw_txn;

rand addr_constraint_base cnst[$];

function new;

addr_permit permit = new;

addr_prohibit prohibit = new;

cnst = {permit, prohibit};

endfunction

function void pre_randomize;

// Set item variable in each constraint class to point to top-level object being randomized

foreach(cnst[i]) cnst[i].item = this;

endfunction

endclass

Figure 6. Constraint class using item handle instead of top-level equality constraints

评论收藏

内容反馈

版权申诉

钱亚锋

粉丝: 123

system verilog constraint layering.rar_constraint_random_system

评论0

最新资源

system verilog constraint layering.rar_constraint_random_system

评论0

system verilog

Verilog and system verilog

verilog-format的配置文件

systemverilog

dct.rar_DCT vhdl_dct_dct_verilog_dctofjpeg.rar_verilog dct

fpu.rar_VHDL FPU_fpu_fpu verilog_fpu.rar_双精度

H[mm.264.rar_Verilog h264_h.264 verilog_h264 verilog_h264 pdf_h

H.264_verilog.rar_.264 verilog_Verilog 压缩_verilog h.264_压缩 veril

ADC_Sample.rar_ADC verilog_ADC VHDL_ADC_Sample.rar_adc verilog_

DUC.rar_System Generator D_duc.rar_system generator_数字上变频_软件DU

SRC.rar_If..._src verilog

LPM_RAM.rar_RAM VERILOG_lpm_lpm_ram_verilog 调用LPM_verilog的ram模块

H.264_verilog.rar_264_264 VERILOG_H.264_h.264编码 verilog_h.264编码v

System_Verilog_Tutorial.rar_Able_paper

div_clk.rar_clk div3_clk_div01000010_clkdiv verilog_sim.do_veril

Divider_Verilog_ISE.rar_ise分频

DPCM.rar_DPCM_DPCM编码_verilog DPCM_verilog编码器_解码Verilog

AMBA_VIP.rar_1484vip.com_AMBA vip_verilog IP_verilog核_vip

crc_verilog_xilinx.zip_CRCGEN.PL_Verilog crc_crc verilog_crc32_c

SPI_verilog_vhdl.rar_hdlc_hdlc verilog_hdlc verilog_verilog SP

my_2.5.2.rar_VCS DPI_VC_hdrs.c_ncverilog_peacepr1_uvm实例

pri_encoder_using_if.rar_If..._pri

Verilog-HDL.rar_hdl_verilog hdl

THDB_ADA_v.1.4.2_SystemCD.rar_THDB-A_THDB-ADA_THDB_ADA资料_Verilog

Verilog-AMS.rar_AMS verilog_Verilog-AMS_verilog_verilog ams仿真_vh

led_test_cn.rar_XLINX edk_edk_edk led_led_test_cn.rar_xilinx edk

LED_RUN.rar_led_run.v_run_红色飓风

最新资源