Quantcast
Channel: UVM Forums RSS Feed
Viewing all 756 articles
Browse latest View live

UVM Phase issue

$
0
0

Hi UVM Experts,

 

I am facing some issue with UVM phase. I have registered one sequence to pre_configure phase of one sequencer which is doing some chip configuration.

In my base test pre_configure phaseI am waiting for that configuration to get over usng hierarchy of RTL path signal. RTL takes some time after configuration gets over to toggle the indication of chip ready which i am waiting in base test pre_configure phase. I observe that sequence gets over but immediately test also gets finished even i raised the objection from base test pre_configure phase.

 

Would you please point me if it is exptected? I think till all raised objections are not lower simulation will not be over. and I want my test to wait once sequence is over and RTL toggles ready signal.

 

Thanks in advance for your time.

 

Thanks,

Akshay

 


UVM and SystemVerilog Papers at DVClub Sept 9

$
0
0

The DVClub meeting September 9 is 100% dedicated to you all reading this forum -- UVM and SystemVerilog.  We'll have four topics in this fast-moving event:

 

  • Update from the Accellera UVM Working Group
  • UVM Register Modelling: Advanced Topics
  • SystemVerilog Scheduling Semantics
  • Advanced Scoreboarding Techniques Using UVM

You can register for the event here:  http://dvclubsept2013.eventbrite.com/#!

 

On behalf of the other presenters, we are looking forward to seeing or hearing you there!

 

=Adam Sherer, UVM WG Secretary

 

VCS: uvm config db with array of interface

$
0
0

Hi,

 

Is there limitations when using uvm_config_db with interface array:

 

Here is an example where I get compilation error:

 

module tb_top();

   import uvm_pkg::*;


   /* DUT interfaces */
   test_if #(.MY_PARAM(4)) my_if   [3] (); // array of interfaces

 

   // Clocks and resets

   [...]

   // design under verification
   [...]

   initial begin
     string inst_name;


      for (int i = 0; i < 3; i++) begin
         $sformat(inst_name, "*.source[%0d].*",i);
         uvm_config_db#(virtual test_if#(.MY_PARAM(4)))::set(uvm_root::get(), inst_name, "vif", my_if[i]); // This line gives compilation error !!!
      end

      run_test();
      $finish;
  end

endmodule

 

Compilation error:

 

Identifier 'my_if' has not been declared yet. If this error is  not expected, please check if you have set `default_nettype to none.

 

 

Is that a simulator issue or is that not supported at all?

Thank you

 

Florian

 

 

parsing using system verilog

$
0
0

Hi,

I have an IP with built in tests, written in pyhton.

I want to parse those tests and use them in higher level (uvm testbench). Eventually each test will be a uvm sequence.

For that I need a system verilog parser.

Is there a reference that I can use for this purpose?

example for lines in existing test:

 

WriteBlock SLAVE 0x0000ffff

Data 8

a5a5a5a5 ffffffff 

 

Thanks

 

 

Connect interface to dut

$
0
0

Hi,

 

I have issues connecting my interface to my dut when using the cadence compilator (vcs does not give any warning here): See the source code below. I get the following warning:

 

ncelab: *W,ICDPAVW (<my_file>): Illegal combination of driver and procedural assignment to variable my_data detected (output clockvar found in clocking block at line <n> in file <my_file>).
           .out_data  (my_if.my_data)

 

Any idea what is wrong her?

Thank you

 

Here's the source code:

interface my_if (input bit clk);

  logic reset;
  logic data;

   clocking master_cb @ (posedge clk);
      output                data;
   endclocking // cb

   clocking slave_cb @ (posedge clk);
      input                data;
   endclocking // cb

   clocking passive_cb @ (posedge clk);
      input                data;
   endclocking // cb

endinterface : my_if

module tb_top;

   logic clk;
   logic reset;

   /* Dut interfaces */
   my_if my_if(clk);
  
   /* Clocks and reset gen*/
   <...>


   assign my_if.reset = reset;

   dut
     my_dut(
                 .clk      (my_if.clk),
                 .arst     (my_if.reset),
                 .out_data (my_if.data)
     );

   initial begin : ib_main
      <...>

   end

endmodule

 

Auto-generate doc script, UVM to HTML

$
0
0

Hi,

I have a question regarding Auto-generate doc script, UVM to HTML:

We're in a process of defining UVM coding guidelines in our group.

We would like to guide engineers to write code and comments in a way that a script can run to auto-generate HTML doc from comments (to document classes, functions, variables, macros, etc).

We've noticed that UVM class reference doc was auto-generated from comments in UVM library files.

does this script (that generate HTML) is part of UVM library ?

can we run it on our own code to generate HTML ? if yes, then how ?

Is it releated to $UVM_HOME/docs/html/javascript/ (main.js, searchdata.js) ?

What are the coding guidelines to support this script ?

 

it seems the script search for comments in such format:

// CLASS: uvm_sequencer #(REQ,RSP)

// Variable: seq_item_export

// Function: new

// Function: stop_sequences

// Title: Report Macros

// MACRO: `uvm_info

Signed field in RAL model

$
0
0

 Hello All,

 

I have some queries regarding RAL model :

 

(1.) How to declare any particular Register's filed as "signed" in RAL model?

(2.) By default all the register fields in RAL model are "unsigned" or "signed"?

 

If possible please guide me for the same.

 

Thanks,

Bonny G. Vora

Of begin_event, end_event, transaction recording, and pipelined interfaces

$
0
0

What is the proper use of begin_tr() and end_tr() and their associated events?  There are these very nice descriptions for begin_event and end_event.

 

  // Variable: begin_event
  //
  // A <uvm_event> that is triggered when this transaction's actual execution on the
  // bus begins, typically as a result of a driver calling <uvm_component::begin_tr>.

  // Processes that wait on this event will block until the transaction has
  // begun.
  //
  // For more information, see the general discussion for <uvm_transaction>.
  // See <uvm_event> for details on the event API.
  //
  uvm_event begin_event;

 

  // Variable: end_event
  //
  // A <uvm_event> that is triggered when this transaction's actual execution on
  // the bus ends, typically as a result of a driver calling <uvm_component::end_tr>.

  // Processes that wait on this event will block until the transaction has
  // ended.
  //
  // For more information, see the general discussion for <uvm_transaction>.
  // See <uvm_event> for details on the event API.
  //
  //| virtual task my_sequence::body();
  //|  ...
  //|  start_item(item);    \
  //|  item.randomize();     } `uvm_do(item)
  //|  finish_item(item);   /
  //|  // return from finish item does not always mean item is completed
  //|  item.end_event.wait_on();
  //|  ...
  //
  uvm_event end_event; 


Great! That is exactly what I want and would expect.  Then begin_tr has even more verbiage that reinforces that:


  // Function: begin_tr
  //
  // This function indicates that the transaction has been started and is not
  // the child of another transaction. Generally, a consumer component begins
  // execution of a transactions it receives.
  //
  // Typically a <uvm_driver> would call <uvm_component::begin_tr>, which
  // calls this method, before actual execution of a sequence item transaction.
  // Sequence items received by a driver are always a child of a parent sequence.
  // In this case, begin_tr obtains the parent handle and delegates to <begin_child_tr>.
  //
  // See <accept_tr> for more information on how the
  // begin-time might differ from when the transaction item was received.
  //
  // This function performs the following actions:
  //  blah blah good details here ...
  extern function integer begin_tr (time begin_time=0);

 

begin_child_tr() and end_tr() have similar verbiage.  Notice the lines I've highlighted.  Now let's go look at the sequence side of things.  According the the UVM user's guide, the basic execution flow of a transaction in a sequence is as follows (this is also what the uvm_do macro implements):

  1. Call start_item() to create the item via the factory. 
  2. Optionally call pre_do() or some other functionality.
  3. Optionally randomize item.
d) Optionally call mid_do() or some other functionality, if desired.
  4. Call finish_item().
  5. Optionally call post_do() or some other functionality.
  6. Optionally call get_response(). 

However, start_item() has this bit of code in it. 


    `ifndef UVM_DISABLE_AUTO_ITEM_RECORDING
      void'(sequencer.begin_child_tr(item, m_tr_handle, item.get_root_sequence_name()));
    `endif

 

Which in turn calls uvm_component::begin_tr().  *Screeeeeeeching halt sound*  Whaaat?  The function description for begin_tr() just said it is "typically called by a driver".  But, it turns out that begin_tr() is in fact typically called by the sequence executing the transaction (indirectly via the sequencer).  Well, it turns out that this is documented, but the documentation has a bit of a multiple personality disorder.  Here's a snip from the uvm_transaction class documentation:


//------------------------------------------------------------------------------
//
// CLASS: uvm_transaction
//
// ... blah blah blah ...
//
// The intended use of this API is via a <uvm_driver> to call <uvm_component::accept_tr>,
// <uvm_component::begin_tr>, and <uvm_component::end_tr>
during the course of
// sequence item execution. These methods in the component base class will
// call into the corresponding methods in this class to set the corresponding
// timestamps (accept_time, begin_time, and end_tr), trigger the
// corresponding event (<begin_event> and <end_event>, and, if enabled,
// record the transaction contents to a vendor-specific transaction database.

 

I like how the intended use model (as previously stated) was reiterated here.  Which is then followed by this single line, which finally gets around to stating how this thing actually works.


// Note that start_item/finish_item (or `uvm_do* macro) executed from a
// <uvm_sequence #(REQ,RSP)> will automatically trigger
// the begin_event and end_events via calls to begin_tr and end_tr.

 

Oh, so the default configuration of the UVM library is to not implement the intended methodology, and instead encourage bad behavior.  That's nice.  Now let's follow that up with this line trying to reiterate the intended use model again.


// While convenient, it is generally the responsibility of drivers to mark a
// transaction's progress during execution. 

 

Ok. got it. My drivers should trigger these events, not the sequences.  This has been repeatedly stated at least 4 times up to this point!  Surely it must be as simple as calling begin_tr/end_tr at the appropriate times in my driver and the start_item/finish_item methods will adapt accordingly, no? 


// To allow the driver to control
// sequence item timestamps, events, and recording, you must add
// +define+UVM_DISABLE_AUTO_ITEM_RECORDING when compiling the UVM package.

 

Oh, of course!.  Now that we've been repeatedly told what the intended use model is, we finally discover that to actually use it, we must set an obscurely named flag that seems to refer only to automatic transaction recording.  Gosh, why didn't I think of that first?


// Alternatively, users may use the transaction's event pool, <events>,
// to define custom events for the driver to trigger and the sequences to wait on. Any
// in-between events such as marking the begining of the address and data
// phases of transaction execution could be implemented via the
// <events> pool.

 

Alternatively? It seems to me, that given that it's the default configuration of the library, it is the primary method to do so. And it also happens to be the only method I've seen demonstrated in every EDA vendor and service provider training I've seen on the subject. It goes on to talk about exactly why you should implement things in the intended way.


// In pipelined protocols, the driver may release a sequence (return from
// finish_item() or it's `uvm_do macro) before the item has been completed.
// If the driver uses the begin_tr/end_tr API in uvm_component, the sequence can
// wait on the item's <end_event> to block until the item was fully executed,
// as in the following example.
//
//| task uvm_execute(item, ...);
//|     // can use the `uvm_do macros as well
//|     start_item(item);
//|     item.randomize();
//|     finish_item(item);
//|     item.end_event.wait_on();
//|     // get_response(rsp, item.get_transaction_id()); //if needed
//| endtask
//|
//

 

Yep.  That is indeed the problem I want to solve. If only UVM would get out of it's own way.  It looks like someone was tasked with adding automated transaction recording to UVM and they decided to hi-jack the begin_event and end_event in order to do so.  Except they discovered a lot of VIP (most VIP?) didn't bother to make the appropriate calls to begin_tr and end_tr.  So they said, "Why don't I make the calls for them!", and here we are.  Unfortunately it breaks using begin_event and end_event for anything except automatic transaction recording.

 

To build a "proper" agent, I'm supposed to call begin_tr and end_tr in my driver.  This means I have to use +define+UVM_DISABLE_AUTO_ITEM_RECORDING, and lose that feature.  On top of that, other VIP is not going to implement the calls to begin_tr and end_tr, because they are going to assume the sequence does it for them.  So if you were using those events with other VIP, your tests are now broke until that other VIP is updated.

 

Taking this VIP the other way doesn't work either.  Calling begin_tr/end_tr from your driver and using it in a testbench that doesn't have the +define will cause double triggering of the events.  Maybe that won't mess anything up, but it certainly could.

 

So I ask these questions:

▪   Do you have a pipelined interface in your design?

▪   Are you interested in when your transactions start and end?

▪   Do you utilize begin_event and end_event?

▪   If not, what do you do instead?

▪   Would you utilize begin_event and end_event if they worked properly?

▪   If the default behavior of the library was changed to not automatically trigger these events, would it break your existing tests?

▪   Does anyone use the automatic transaction recording?

 

I think this really needs to be fixed. It simply means creating a couple of events specifically for automatic transaction recording to use, rather than hijacking the begin/end events.  If the automatic recording could take advantage of the developer manually triggering the begin/end events for greater accuracy, that would be great.  But not doing so, would be no worse than we have now.


uvm_do_with constrain problem with sequence

$
0
0

class my_transaction extends uvm_sequence_item;

....

int a;

int b;

int c;

....

endclass

 

 

 

class my_sequence extends uvm_sequence#(..)

....

my_transaction tx;

...

`uvm_do_with(tx,{tx.a==1;tx.b==1;tx.c==1;})

....

endclass

 

 

 

 

 

class my_complex sequence extends uvm_sequence#(...)

 

my_sequence seq;

..

..

`uvm_do_with(seq,{seq.a==0;seq.b==0;seq.c==0;})   // This Doesn't work........How can I change value of a,b,c in this situation?

UVM_FATAL invokes $finish(1)

$
0
0

To circumvent UVM calling on $finish directly when completing normally, one would override "finish_on_completion" to 0 before calling "run_test()". What I do is:

 

   uvm_top.finish_on_completion = 0;

   run_test();

   $finish(2);

 

The last statement tells the tool to publish useful simulation statistics such as total run time, memory used, etc. This information is very useful in monitoring large batches of simulations for many purposes, among which is farm optimisation and debugging bad code consuming lots of memory.

 

However, when UVM_FATAL is invoked, effectively a $finish(1) is called - and the above-mentioned information is thrown away. Is there a way to overcome this and get UVM to call $finish(2) or at least allows this to be customised? Probably via a uvm_config_db::set()  and uvm_config_db::get() ? Or perhaps I am not aware of something that already allows this?

 

A work-around would be avoid using UVM_FATAL and use UVM_ERROR with a following $finish(2) - but this is clumsy and widespread change is required.

 

Thanks

What ever you do, don't use ...

$
0
0

I just saw a presentation on UVM tips and it recommended to NOT use the uvm_field macros. Several companies have come out and said that these generate large, cumbersome methods that are hard to debug, and that you should write the methods yourself. IMHO, this seems like bad advice. Having written these methods for VMM, I find it error prone and a waste of time. Why spend 10-20 minutes creating these when the macros do it automatically? Once you waste an hour debugging the copy method when you leave out one variable, you stick with the macros. And how slow are these automatic methods? They never show up on the simulation profiler.

 

This reminds me of when I used to change the oil on my car, and then left a rag on the engine that caught fire and cost me $200 to replace the O2 sensor, and could have ended up much worse. How much was I saving?

 

It is your time that is the most valuable thing. Use the macros to save coding time and debug time. Spend your time on something creative like understanding Flits!

Multiple CPU interfaces can access the same register model

$
0
0

Hi,

 

Assuming my DUT has 2 external CPU interfaces that can access to the same Register Model.

How should I implement it in my UVM environment ?

 

I guess I need 2 adapters and 2 predictors. Do I need to set 2 maps ? one per sequencer ?

Is it possible to set 2 different sequencers to the same map ? or we have to set 2 maps and set_sequencer to each one of them ?

 

Thanks, Ofir

Scoreboarding the Register Model

$
0
0

I am attempting to implement the UVM register model in my testbenches. Are there reference implementations that connect to a scoreboard? Our methodology uses C++ reference models with fields identical to the registers in the DUT. I would like to receive an event from the register model with an access type, register name or address and data to pass to DPI functions for comparison. Are there any interfaces for this built in to the model already?

 

Thanks.

Controlling verbosity while using component override

$
0
0

Hi,

 

My question is about controlling the verbosity for one agent when I am using override for it. Let me give more details here. I have base env and base agent class. My environment extends this classes and creates env and agent. I have base test also. From top module  I override the env class. In my test which is extended from base_test If i have to control verbosity for one agent I can write set_report_verbosity methods. But now this case gives me compilation error. As my env is overriden run time but when I have to sent the verbosity for perticular agent I have to give hierarchy path.

 

In my base test I have handle of base env as env. my component base_env is overridden with x_env. x_env is having x_agent. I want to control the verbosity for x_agent for debug purpose. in my start of simulation phase if I write like "env.x_agent" it gives error which is very obivious. Is there any sollution how can i control the vebosity of agent in this case?

 

 

Thanks,

Akshay

Register "abc_rm.mem" value read from DUT (0x0000000000000002) does not match mirrored value (0x000000000000000X)

$
0
0

Can any one please explain what this would mean  .

I can write on the this register perfectly . 

The only problem is reading . 

I am performing uvm_reg_single_bit_bash_seq on this register . 


connect uvm_analysis_export (SV) and tlm_aanalysis_port (SC) with UVMC

$
0
0

Hi,

 

I am trying to connect uvm_analysis_export (SV) and tlm_aanalysis_port (SC) using UVMC like the following:

 

    uvm_analysis_export #(obs_xact#(WL,DEP)) sc_export;
 

    uvmc_tlm#(obs_xact#(WL,DEP))::connect(sc_export,"fft_ap");

 

but I got the follow error message:

 

  Incompatible complex type usage in task or function call.
  The following expression is incompatible with the formal parameter of the
  function. The type of the actual is 'class
  uvm_pkg::uvm_analysis_export#(class test_pkg::obs_xact#(12,512))', while the
  type of the formal is 'class uvm_pkg::uvm_port_base#(class
  uvm_pkg::uvm_tlm_if#(class test_pkg::obs_xact#(12,512),enum
  uvm_pkg::uvm_tlm_phase_e))'. Expression: this.sc_export
  Source info:
  uvmc_tlm#(test_pkg::obs_xact#(12,512),uvm_pkg::uvm_tlm_phase_e,uvmc_pkg::uvmc_default_converter#(uvm_pkg::uvm_object))::connect(this.sc_export,
  "fft_ap", null ...
 

Isn't uvm_analysis_export is extended from uvm_port_base#(uvm_tlm_if#())?

 

Thanks

Sam
 

Problem in viewing waveform

$
0
0

Hi All,

I am using Cadence ncsim.
I have an (UVM Verification Component)UVC which is not connected to any DUT for now. It is a simple UVC which just generates few address,Data and READ or WRITE requests.
In my Module top I am generating the clock .
When I run without GUI, I can print out the the requests which is been generated.  Simulation completes at 560NS+50

But I have problem viewing the waveform. Values are only at 560 NS time stamp. Even clock is high only at this time stamp and its blank or says no value available before 560NS.

Could anyone help me with this. I dont know what is wrong exactly.

Thanks,
Leela

how to (best) delay the start of built-in UVM register test stimulus

$
0
0
I've run into the following issue using the built-in UVM register tests.
The built-in UVM register tests (seem to) start R/W-ing immediately after top-level reset is released.  
This was fine, initially.  See attached image "Capture".
 
We now have some delay between the release of top-level reset and the actual reset going to the register block.  This is resulting in a read occurring before reset to the rtl regblock is released, and causes the test to hang.  See attached image "Capture2".
 
Without modifying the built-in register tests/sequences, how would anyone suggest that we cleanly delay the stimulus?    Perhaps I just need to make the stimulus aware of the different reset when the model/stimulus is generated, or simple add some delay to a phase before the R/W-ing starts.  (The former sounds right.  If that's the solution, I'll need to figure out how we're generating the model/stimulus.)
 
I've just started hunting around for the built-in UVM register test sequences and will return to it tomorrow, but will anyone tip me off as to what names I should be searching for?
 
thanks
 
 
This has been useful, https://verificationacademy.com/cookbook/registers/builtinsequences, but it seems I need to do some more reading and hunting before I grasp how the built-in register stimulus is created and used.
 

Attached Thumbnails

  • Capture2.PNG
  • Capture.PNG

How inputs are driven in UVM ?

$
0
0

Hello,

I'm newbie to UVM. I'm trying to develop a 2:1 Mux using UVM standard classs libraries.

I've a question that how the inputs are generated using Sequences and driven at driver side to interface ?

 

-Thanks

Disable UVM_INFO printout by verbosity

$
0
0

Hello,

I have a library with the sequence which exploits `uvm_info to print messages. It uses UVM_MEDIUM verbosity and AXI4STREAM_SLAVE id. I would like to disable those messages, however I can't change code of the library. For this reason, I have tried to call  m_sequencer.set_report_severity_id_verbosity(UVM_INFO, "AXI4STREAM_SLAVE", UVM_HIGH). Please notice, the function is called for sequencer on which the sequence is spawned. The report configuration of the sequencer:

 

 

# report handler state dump
#
#
# +-----------------+
# |   Verbosities   |
# +-----------------+
#
# max verbosity level =         200
# *** verbosities by id
#
# *** verbosities by id and severity
# UVM_INFO:AXI4STREAM_SLAVE --> UVM_HIGH
#
# +-------------+
# |   actions   |
# +-------------+
#
# *** actions by severity
# UVM_INFO = DISPLAY
# UVM_WARNING = DISPLAY
# UVM_ERROR = DISPLAY COUNT
# UVM_FATAL = DISPLAY EXIT
#
# *** actions by id
#
# *** actions by id and severity
#
# +-------------+
# |    files    |
# +-------------+
#
# default file handle =           0
#
# *** files by severity
# UVM_INFO =           0
# UVM_WARNING =           0
# UVM_ERROR =           0
# UVM_FATAL =           0
#
# *** files by id
#
# *** files by id and severity
# report server state

 

 

The problem is that the message is still displayed. I debugged the issue and noticed that the problem is in uvm_sequence_item.svh (I use UVM-1.1d). In the uvm_report_enabled function, there is a part:

if (m_client.get_report_verbosity_level(severity, id) < verbosity ||
        m_client.get_report_action(severity,id) == uvm_action'(UVM_NO_ACTION))
      return 0;
    else
      return 1;

As one can see, even if the message will be rejected by get_report_verbosity_level, it will get the default action from get_report_action and be printed at the end. According to my understanding, it's not a behaviour described in the documentation (uvm_report_object):

If the verbosity level of a report is greater than the configured maximum verbosity level of its report object, it is ignored.  If a report passes the verbosity filter in effect, the report’s action is determined.

The decision whether the message is printed is based on the assigned action, not verbosity. Moreover, I don't see sense of verbosity usage in this case. I would be grateful, if somebody could clarify my concerns.

 

Of course, another workaround is to call: m_sequencer.set_report_severity_id_action(UVM_INFO, "AXI4STREAM_SLAVE", UVM_NO_ACTION) however, I don't understand, why I couldn't get the same behaviour modifying verbosity.

Viewing all 756 articles
Browse latest View live