SystemVerilog does not have destructors like C++, so it will automatically handle garbage collection and memory management for you, to a degree.  I have a problem in which I would like to track a collection of objects, each with a unique ID.  I defined a static queue to manage the list of IDs.  A new ID is created and checked for uniqueness in the constructor.  The problem is what is a good way to remove the ID from the queue when the object is destroyed, no longer needed.  I could fudge it with something like requiring the client to make some sort of method call that "deallocates" the object before it goes away, but that seems kludgy to require the client to manage that.

Any ideas?

TIA

Hello Everyone,

I am trying to control a sub virtual sequencer's non-virtual sub sequencers using a top level virtual sequencer.
It looks like this diagram.

<start of diagram>

                       .------------------------------------------------------.
                       | my_test                                              
                       | .--------------------------------------------------. |
                       | | sequences                                        | |
                       | '--------------------------------------------------' |
                       | .--------------------------------------------------. |
                       | | my_env                                           | |
                       | '--------------------------------------------------' |
                       '/----------------------------------------------------\'
                       /                                                      \
                      /                                                        \
                     /                                                          \
                    /                                                            \
                   /                                                              \
                  /                                                                \
                 /                                                                  \
                /                                                                    \
               /                                                                      \
              /                                                                        \
             /                                                                          \
            /                                                                            \
           /                                                                              \
          /                                                                                \
         /                                                                                  \
        /                                                                                    \
       /                                                                                      \
      /                                                                                        \
     /                                                                                          \
    /                                                                                            \
   /                                                                                              \
  /                                                                                                \
 /                                                                                                  \
.----------------------------------------------------------------------------------------------------.
| my_env                                                                                             |
|                                     .------------------------.                                     |
|                                     | my_virtual_sequencer   |                                     |
|                                     '------------------------'                                     |
| .-----------------------------------. .----------------------------. .---------------------------. |
| | sub_virtual_agent                 | | sub_agent_a                | | sub_agent_b               | |
| | .-------------------------------. | | .------------------------. | | .-----------------------. | |
| | | sub_virtual_sequencer         | | | | sub_sequencer_a        | | | | sub_sequencer_b       | | |
| | '-------------------------------' | | '------------------------' | | '-----------------------' | |
| |       .-------------------------. | | .------------------------. | | .-----------------------. | |
| |       | sub_agent_3             | | | | driver_a               | | | | driver_b              | | |
| |     .-------------------------. | | | '------------------------' | | '-----------------------' | |
| |     | sub_agent_2             | | | | .------------------------. | | .-----------------------. | |
| | .---------------------------. | | | | | monitor_a              | | | | monitor_b             | | |
| | | sub_agent_1               | | | | | '------------------------' | | '-----------------------' | |
| | | .-----------------------. | | | | '----------------------------' '---------------------------' |
| | | | sub_sequencer_1       | | | | |                                                              |
| | | '-----------------------' | | | |                                                              |
| | | .-----------------------. | | | |                                                              |
| | | | driver_1              | | | | |                                                              |
| | | '-----------------------' | | | |                                                              |
| | | .-----------------------. | | | |                                                              |
| | | | monitor_1             | | |-' |                                                              |
| | | '-----------------------' |-'   |                                                              |
| | '---------------------------'     |                                                              |
| '-----------------------------------'                                                              |
'----------------------------------------------------------------------------------------------------'

<end of diagram>

I am trying to apply section 4.8 Virtual Sequences of uvm users guide.
But I think I am missing on something.

I have a top level virtual sequence that has the top level virtual sequencer as its p_sequencer. I have this in the macro:

`uvm_declare_p_sequencer(my_virtual_sequencer)

And then I have this in the task body() to access the sub sequencer of the sub virtual sequencer:

`uvm_do_on(sub_sequence_1, p_sequencer.i_sub_virtual_sequencer.i_sub_sequencer_1);

sub_sequence_1 is a physical sequence.
Is this correct under the UVM standard?
If not, how do I properly control i_sub_sequencer_1?

This is how I access it in the test build_phase:

uvm_config_db #(uvm_object_wrapper)::set(this, "i_my_env,i_my_virtual_sequencer.main_phase","default_sequence",my_virtual_sequence::type_id::get());

Any help/inputs to this is much appreciated.

Thanks,
Martin

Hello, i am new in UVM and Sv, i wanted to knw the UVM do_copy function in detail

1.the need of $cast(rhs,rhs_)

2.need to call super.do_copy.

plz explain in detail. Thank u

Hi all,
I'm trying to access a verilog hierarchy which was generated by a generate block - but I'm having some problems with it. for example:

verilog file: (let's assume it is located at "testbench" hierarchy, and an interface named "some_interface" is already defined)

genvar i;
generate
for (i=0;i<3;i++)
begin : GENERATE_HEADER
some_interface some_interface_inst(clk);
assign some_interface_inst.x=1'b0;
assign some_interface_inst.y=1'b1;

end

endgenerate

systemverilog file:

virtual some_interface some_interface_arr[0:2];

for (int i=0;i<3;i++)
some_interface_arr[i]=testbench.GENERATE_HEADER[i].some_interface_inst;

I believe I can't access a generated verilog hierarchy with a system-verilog for loop (variable i). Am I correct? and if so - is there a way to pass this obstacle?
Thanks in advance,
Eyal.
P.s - What I'm generally trying to do is to get handles to the instantiated interfaces (some_interface) and pass them to system verilog objects in my testbench, using the virtual interface array.

I've read the UVM 1.1 references searching for this answer. In the `uvm_field_array_*macros session there's no `uvm_field_array_real.

Does anyone have the answer?

Observation:

In  uvm_reg::write() set(value) is called immediatly while

uvm_reg::do_predict() is called at the end of the task.

In a case where auto_predict() set and an analysis port sends collected

transactions from the bus monitor to the reference model,

the analysis port write method may return before uvm_reg::do_predict() is called .

This will cause uvm_reg::get() to return the updated value but uvm_reg::get_mirrored_value() to return

the old value.

Hi All,

I have a question regarding the proper placement of the following code for raising an objection in a multi-layered testbench (i.e. virtual sequencer -> virtual sub sequencer -> sub sequencer):
<start snip>
virtual task pre_start();
  if(starting_phase != null)
    starting_phase.raise_objection(get_sequencer());
endtask
<end snip>

I have tested the physical sequences and they work when no virtual sequences are involved.
With that isolated, I introduced the 2 virtual sequences and since the new default_sequence is the top virtual sequence, I placed a raise_objection there.
Here is a summary of my trial runs:
1) Pure physical sequence as default_sequence - raise_objection at physical sequence (works);
2) Top virtual sequnce as default_sequence - raise_objection added to virtual sequence's pre_start (does not work);

What happens to 2) is the top virtual sequence does not end but the sub sequences do not run either.
Please shed some light on why this is happening and possible ways to fix this.

Thanks,
Martin

 

Hi,

I want to use a value which is a constant in my VHDL design file. I want to make my env. generic depending on the value of this constant. How do i import this constant from VHDL to SV

Thanks,

Parag

`uvm_analysis_imp_decl(_rcvd_pkt)  //THIS
class dpx_rr_scoreboard extends uvm_scoreboard;

   `uvm_component_utils(dpx_rr_scoreboard)

   virtual function void write_rcvd_pkt(input some_trans t);  //AND THAT
   endfunction : write_rcvd_pkt                               //AND THAT

endclass : dpx_rr_scoreboard

I poked around in the uvm class library just a bit, but did not figure this out.

Any ideas?  Is this a uvm thing or Cadence thing (trying to enforce that I write sensible code) or just fooling thing on my part?

I am asking Cadence directly as well, but wanted to throw this out to the crowd.

**I am just trying to get a shell of a scoreboard compiling, and don't care that it does nothing yet.  Let's ignore the fact that I don't have uvm_analysis_imp_rcvd_pkt created.

I have this code in a sb :

sb_comparer.sev = UVM_ERROR
if(!expected_item.compare(received_item, sb_comparer)

but even so all the messages are printed:

UVM_INFO @ 8250000: reporter [MISCMP] Miscompare for tx2rx_sb_

I tried to check in uvm_comparer.svh :

function void print_msg (string msg);
    result++;
    if(result <= show_max) begin
       msg = {"Miscompare for ", uvm_object::__m_uvm_status_container.scope.get(), ": ", msg};
       uvm_report_info("MISCMP", msg, UVM_LOW);
    end
    miscompares = { miscompares, uvm_object::__m_uvm_status_container.scope.get(), ": ", msg, "\n" };
  endfunction

I cannot find were uvm_comparer::sev is  taken into account.

What am I missing ? (or is this a BUG in UVM)

In addition to the `uvm_info / `uvm_fatal / uvm_error, etc. macros, there are "context" versions: `uvm_info_context / `uvm_fatal_context, etc. The documentation is not exceptionally useful for the latter.

Why would one use the "context" versions of the macros?

Regards - Cliff Cummings

I am trying to create a driver with two stage pipeline using the example given on uvm_transaction entry of uvm on-line reference as shown below.

task do_item();
forever begin
mbus_item req;
lock.get();
seq_item_port.get(req); // Completes the sequencer-driver handshake
accept_tr(req);
// request bus, wait for grant, etc.
begin_tr(req);
// execute address phase
// allows next transaction to begin address phase
lock.put();
// execute data phase
// (may trigger custom "data_phase" event here)
end_tr(req);
end
endtask: do_item

when I compiled my version using irun, it complained about

ncvlog: *E,ILLHIN (driver.sv,233|13): illegal location for a hierarchical name (in a package).

Could anyone please tell me what is the right way to lock the sequencer in the driver.

thanks, 

Hi all,

I've created a uvm sv file (it is actually a register block), which has the following format:

class X extends uvm_reg_block;

rand reg1 x1[255];

rand reg2 x2[255];

rand reg3 x3[255];

// and so on - thousands of registers (reg1,reg2,reg3 are rand classes).

constraint reg1_0_const {...};

constraint reg2_0_const {...};

constraint reg2_1_const {...};

constraint reg3_0_const {...};

constraint reg3_1_const {...};

Hi all,

I experiencing some strange things in the reg_driver which is shipped as part of the UVM 1.1d release.

Below the code snippet taken from the examples/simple/registers/common/reg_agent.sv:

class reg_driver #(type DO=int) extends uvm_component;
   ...
   task run_phase(uvm_phase phase);
      reg_monitor mon;
      $cast(mon, m_parent.get_child("mon"));

      forever begin
         reg_rw rw;
         seqr_port.peek(rw); // aka 'get_next_rw'
         DO::rw(rw);
         mon.ap.write(rw);
         seqr_port.get(rw); // aka 'item_done'
      end
   endtask
   
endclass 

In here, the driver communicates via the sequencer using the peek/get method (in this example there is no explicit response give, so no put method) The call in between the peek and get is DO::rw, where DO is a parameter which points to the dut in these examples. In this dut, the value of transaction/sequence_item rw will be changed.

And now the interesting thing: When we peek a value first and after this we get the value, I would expect we get the *same* result. I basically assume the sequence item is stored in a tlm_fifo and we first peek the value without clearing it, and with the get it and will be flushed from the fifo (aka item_done). However, in these examples, the 'get' results in a different value as the initial peek!

It gets even more funny as this (unwanted?) updated value is also returned back to the sequencer, which will call the bus2reg method to process the (unwanted?) updated value.

Instead I would expect the usage of a put or put_response method to report back any updated value. But when updating the reg_driver to provide a response (and adding the provides_responses = 1 to the adapter component) some examples, like the register aliasing example, seems to break.

I would appreciate any input to clarify if this changed transaction item between the peek and get is really intendend, and if not, whether the exampels can be updated accordingly.

Thanks,
Martin

Hi all

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". 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

Marcel

what arguments  are passed to +uvm_set_severity 

in order to cancel all `uvm_info for all components ?

Hi,

I'm running v.13.10.001 of ncsim.

It doesn't look like it supports uvm command line argument uvm_set_config_int like:

ncsim <flags> work.my_tb +UVM_TESTNAME=tb_m00308_default_test +uvm_set_config_int=*,<my_variable1>,<my_value>

Is that correct?

One aspect that was not covered in the UVM Basics series posted by Cadence in May 2012 was the register layer (aka UVM_REG). In this new video series we are giving an overview of the concepts, components and applications of the UVM register layer.

The new video series is broken up into twelve clips:

1. Introduction
2. Testbench Integration
3. Adapter
4. Predictor & Auto Predict
5. Register Model & Generation
6. IP-XACT
7. Register Model Classes
8. Register API & Sequences
9. Access Policies
10. Frontdoor & Backdoor
11. Predefined Sequences
12. Demonstration

You are now registered for success!  (sorry, bad pun.  )

=Adam Sherilog, Cadence

Not sure do you have similar problem? I have a problem in handling the reset value in RAL.

f the reset value of a field in the register is don't care, what can I do for it?

Now my plan is extend a new access type. For this kind of registers, the read value in reset test is not checked.

Do you guys think it is a feasible way? Thanks.