0% found this document useful (0 votes)
290 views

Systemverilog Constraint Layering Via Reusable Randomization Policy Classes Poster

SystemVerilog constraints can be reused across multiple objects using reusable randomization policy classes. The policy classes contain the constraints and can be mixed and matched as needed. This provides a flexible way to add different types of constraints when randomizing objects. The paper provides examples of using policy classes to constrain address ranges for a transaction object in SystemVerilog and for a UVM sequence item and sub-sequence.

Uploaded by

Marko Nedic
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
290 views

Systemverilog Constraint Layering Via Reusable Randomization Policy Classes Poster

SystemVerilog constraints can be reused across multiple objects using reusable randomization policy classes. The policy classes contain the constraints and can be mixed and matched as needed. This provides a flexible way to add different types of constraints when randomizing objects. The paper provides examples of using policy classes to constrain address ranges for a transaction object in SystemVerilog and for a UVM sequence item and sub-sequence.

Uploaded by

Marko Nedic
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 1

SystemVerilog Constraint Layering via

Reusable Randomization Policy Classes


John Dickol, Samsung Austin R&D Center, [email protected]

Problem: How to reuse Solution: Put constraints in Examples More details in the paper Conclusions
The two examples below illustrate the concept See the paper for more applications of this idea: Randomization policy classes provide a flexible
random constraints? “Policy Classes” for a simple address transaction. Two policies • policy_list classes encapsulate a list of and efficient way to add different types of
SystemVerilog constraints may be added to an Putting the constraints in a standalone class
constrain the generated addresses to lie within policies. Lists may be nested to any number constraints into an object being randomized.
object via inheritance or with inline constraints allows them to be defined once then added into
permitted regions and outside prohibited of levels. This technique can be used with native
specified when the object is randomized (e.g. other objects as needed. Policies can be mixed
regions. • Policies with persistent state information SystemVerilog or can be applied to UVM.
obj.randomize with {…} ) But the SV and matched in any combination.
e.g. keep track of recently used addresses
language doesn’t define a way to easily reuse
and use them in constraints for subsequent
constraints in multiple objects.
randomizations.

SV Example UVM Example UVM Sequence


Policy Base Class
This example uses policy This example adapts the SV example
class my_seq extends uvm_sequence #(addr_txn);
1 Policy classes contain
class policy_base#(type ITEM=uvm_object);
classes to add additional to UVM. A sequence adds the same
ITEM item; reusable constraints ...
reusable constraints to a policy classes to the same address my_subsequence sub_seq;
transaction object. virtual function void set_item(ITEM item); transaction which has been converted policy_list#(addr_txn) default_pcy = new;
this.item = item; to a UVM sequence item. policy_list#(addr_txn) special_pcy = new
endfunction
endclass task body;
default_pcy.add(permit);
1 policy_list combines multiple
policies into a single policy
default_pcy.add(prohibit);
Policy Classes
class addr_permit_policy extends policy_base#(addr_txn); 2 “item” refers to object
being randomized special_pcy.add(default_pcy);
special_pcy.add(special);
// Transaction addr range must fit within permitted ranges
constraint c_addr_permit { 2 Sequence sets default policy
for sequence item “req” // `uvm_do(req);
`uvm_create(req);
item.addr inside {['h00000000 : 'h0000FFFF - item.size]} ||
item.addr inside {['h10000000 : 'h1FFFFFFF - item.size]} ; req.policy = {default_pcy};
} `uvm_rand_send(req);
endclass
3 “item” constraints apply
to top-level object 3 Sequence puts special
policy into config_db … uvm_config_db#(policy_list#(addr_txn))::set(
null, {get_full_name, ".sub_seq.*”},
class addr_prohibit_policy extends policy_base#(addr_txn); "default_policy", special_pcy);

// Transaction addr range must avoid prohibited ranges


constraint c_addr_permit {
4 … using sub_seq
fullname + wildcard …
`uvm_do(sub_seq);

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


}
endclass
5 … for use by sub_seq
or any of its children UVM Transaction Class
class addr_txn extends uvm_sequence_item;

Transaction Class
4 Queue of policies for
this transaction
rand bit [31:0]
rand int
addr;
size;
class addr_txn;
rand bit [31:0] addr; rand policy_base#(addr_txn) policy[$];
rand int size;

rand policy_base#(addr_txn) policy[$];


6 If policy has not already
been set … constraint c_size { size inside {1,2,4};

function void pre_randomize;


constraint c_size { size inside {1,2,4};} super.pre_randomize();

function void pre_randomize;


foreach(policy[i]) 7 … try to get policy from
UVM config_db
if(policy.size ==0) begin
policy_list#(addr_txn) default_pcy;
policy[i].set_item(this);
8 Policies are randomized
at same time as txn endfunction
endclass
if(uvm_config_db#(policy_list#(addr_txn))::get(null,
get_full_name,
"default_policy",

Test Fragment 5 Add policies to txn 8 Use item’s full path to


query config_db begin
default_pcy) )

policy queue policy = { default_pcy };


...
7 …sets “item” in each end else begin
addr_permit_policy permit = new; `uvm_error(get_type_name(), "could not get policy from config_db");
policy to point to this txn addr_prohibit_policy prohibit = new; end
addr_txn txn = new;
9 If successful, set policy
for this sequence item
end
txn.policy = {permit, prohibit}; foreach(policy[i]) policy[i].set_item(this);
endfunction
6 Randomizing txn… txn.randomize;
...
endclass

You might also like