Jump to content
Sign in to follow this  
thanhvanchi

issues about Construction a verification environment for specific modules

Recommended Posts

Hello everyone!

I'm trying to build a generlc verification environment for specific modules of mine, that essentially only differ (besides their actual implementation) by the number of inputs/outputs of a certain interface standard and the data_size of each of these interfaces.

This leads to the point, that I like to have an environment, where I can set the number of interfaces and for each of these interfaces the data_size.

Unfortunately this simple setup of non-dynamic pre-compile settings is getting me in a lot of trouble.

(1) Sequence_Item

class input_item #(int unsigned data_size) extends uvm_sequence_item;
    `uvm_object_param_utils(input_item)
    
    rand logic[data_size-1:0] data;
   .......

The first question that comes to mind writing this code is the following:

Is it possible to factory overwrite a param. class with another specilisation of that same class (e.g. define a driver with input_item<32> and then factory overwrite it with input_item<42>)?

Otherwise a item_base class would be necessary that than would be extended by this class.

(2) Analysis Ports

class env extends uvm_env;
 ....

    // need N = number of interfaces analysis ports between each monitor and scoreboard
    uvm_analysis_port #(input_item#(17)) ap_1;
    uvm_analysis_port #(input_item#(12)) ap_2;
    .....
    uvm_analysis_port #(input_item#(42)) ap_N;
....

Due to the different input_items all ports are of a different type. Therefore it is not possible to create an array of N=number_of_interfaces, which leads to this not being possible to implement. Furthermore the analysis_port/export classes cannot be overwritten through the means of the factory.
 
(3) Virtual Sequence

class top_vseq_base extends uvm_sequence #(uvm_sequence_item);

`uvm_object_utils(top_vseq_base)
 
      uvm_sequencer #(input_item#(17)) seq_1;
      uvm_sequencer #(input_item#(12)) seq_2;
      ...
      uvm_sequencer #(input_item#(42)) seq_N;

In the virtual sequence I essentially run into two problems:

1. The first one is the same problem as in (2) of not being able to create an array of different types or having a pre-processor for-loop 

2. The other one is the fact, that I'm not able to get access to the number N . Even if they were all of the same type and I would declare a dynamic array, there is no build_phase and no way to get informations through either the config_db or "p_sequencer.variable" in internet. I could put a member variable into the virtual sequencer, but I'm not sure if it is a good idea/possible to create a dynamic array in the body method.

General Solutions so far:

I only see two solutions here ...

1. Defining a gigantic input_item with data_size of 256/512 and then cut it everywhere. But unfortunately I will be in need of an array of completely different items in the next version of this environment anyhow. The reason for that is, that I would like to group a bunch of M different interfaces into one environment, all of them running a different item. Therefore the analysis_ports would all run a different item.

2. Just building a code generator, in which the user sets all parameters, creating the necessary environment for the given DUT.
 
If you have any input, I would be glad to hear it.

Thanks!

Share this post


Link to post
Share on other sites

hi

 

a few answers

 

Is it possible to factory overwrite a param.

nope. params are elab time constants. you cannot change them later. factory usage requires that the override is a subtype of the override base type.

 

#analysis ports with multiple instances can be done either using A) the decl macros, B) the uvm_subscriber or C) by folding all transactions into a meta transaction+channel id

# you can factory override tlm classes given you register them plus you use create() to instantiate them. (ps: i havent checked what functions are virtual so that you can benefit from it)

 

# param classes with different parameterisation needs to be factored so that there is a common *_base class which can be used as array element type. you may then set each array element to a derived class instance (which might have addon different parameters). even that will most likely not solve your problem since the base class doesnt see the actual param value.

 

/uwe

 

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×