Duplicate or multiple OVM banners

When executing vsim on a design containing OVM, two or more OVM banners appear on the screen and/or in the transcript file.

# ------------------------------------------------- 
# OVM-2.1.1 
# (C) 2007-2009 Mentor Graphics Corporation 
# (C) 2007-2009 Cadence Design Systems, Inc. 
# ------------------------------------------------- 
# ------------------------------------------------- 
# OVM-2.1.1 
# (C) 2007-2009 Mentor Graphics Corporation 
# (C) 2007-2009 Cadence Design Systems, Inc. 
# -------------------------------------------------

The message is printed in method ovm_report_handler::report_header() in src/base/ovm_report_handler.svh

This is called only from OVM code in method ovm_report_object::report_header() in ovm_report_object.svh

This too is called only from OVM code in ovm_root::new() in ovm_root.svh

Solution:

All possible causes of multiple printout of this message and suggestions for resolution: 

1. User code has instantiated ovm_root multiple times via multiple calls to ovm_root::new().  This should not be done and will need to be corrected. 

2. User code has extended ovm_root and changed its behavior. This also should be not be done and will need to be corrected.

3. User code calls ovm_report_handler::report_header() directly via an ovm_report_handler object handle.

4. User code calls ovm_report_object::report_header() directly via an ovm_report_object handle or subclass method override calling super.report_header(). 

5. One additional and very likely possibility is that there are multiple ovm_pkg universes compiled separately and integrated at runtime. This can happen in a simulation scripting case, which compiles separate units (e.g. VIPs or testbench bits) each of which correctly does an import ovmpkg::*. Those units are then integrated in to a toplevel testbench by `include instead of by import my_subunit1::*; import my_vip2::* etc 

Don't use `include for this case. Use only `import. Otherwise the outcome is that each package, while called ovm_pkg, is actually a different package namespace with a different ovm_root etc.

Virtual Signal Spy...Debugging Made easy

If you are using Questasim, your waveform debugging will be easy if start using Virtual Signal Option. With the help of this option New Signals can be created by applying the expressions on the Existing signals. You can also delay the signals by certain amount when comparing input with output which will be general case many times.

Few examples include:

Create a virtual signal that is the same as /top/signalA except it is delayed by 10 ps. 

  virtual signal -delay {10 ps} {/top/signalA} myDelayedSignalA

Create a three-bit signal, chip.address_mode, as an alias to the specified bits. 

  virtual signal { chip.instruction[23:21] } address_mode

Create a two-bit signal (with an enumerated type) based on the results of the subexpressions. For example, if aold equals anew, then the first bit is true (1). Alternatively, if bold does not equal bnew, the second bit is false (0). Each subexpression is evaluated independently.

  virtual signal {(aold == anew) & (bold == bnew)} myequalityvector

Create signal newbus that is a concatenation of bus1 (bit-reversed) and bus2[7:4] (bit- reversed). Assuming bus1 has indices running 7 downto 0, the result will be newbus[11:0] with the upper 8 bits being bus1[0:7] and the lower 4 bits being bus2[4:7]. 

  virtual signal {(concat_reverse)(bus1 & bus2[7:4])} newbus

I personally felt this option saves lot of time and effort during debugging.

Hope the same for you too...