dave_59

You would need to have A extended from a common base class so that m_a could be assigned with any specialization of A. As you have written it A m_a; // is the same as A #() m_a; // which is the same as A #(10) m_a; It would be better to write virtual class A_base; pure virtual methods... endclass class A #(int j) extends A_base; endclass A_base m_a;and your build method would be the same.You should be careful about what you choose to parametrize in a class. Take a look at the DVCon paper I reference at the bottom of my blog article on parameters. BTW, writing class A #(int j) without a default assignment means that you are required to have A #(something) when you reference it. Then A obj_h; would be illegal

If you are paying for 3rd party SVA checkers, then you should request that they provide UVM-aware code so that you can catch the errors. - you are the customer. If your only interest is caching overall test pass/fail, then your simulator may already have this capability. Questa records a TESTSTATUS based on the most severe message produced by your simulation run in the UCDB (Unified Coverage Database) file.

You should look at calling std::randomize(pk_num,pkt_size) with {} on just the variables you want to randomize. The do not even need to be rand variables. Another suggestion would be to put the variables and constraints you want to randomize separately into a separate class. This is what's know in OOP as the "separation of concerns" principle.

You should contact Mentor support directly and have them show you how you can clean up the WLF messages and explain how to set the OpenOnBreak variable.

I assume you are talking about the GUI. When you set the Onfinish to something other than exit, it places a breakpoint on the $finish and echos one line to tell you that it has stop at the $finish. There is an OpenOnBreak setting that you can turn off so that it doesn't open up to the line in the source code where the simulator stopped.

Getting started with the UVM; Using the Register Modeling package http://go.mentor.com/getting-started-with-UVM-registers

Technically, most UVM scoreboards are already a concurrent assertion. It's just a matter of which SystemVerilog syntax is used to model it. The concurrent assertions section of SystemVerilog is designed to merge formal tools with dynamic simulation, and that requires some level of underlying synthesis technology. So until SystemVerilog synthesis technology comes into the 21st century and starts synthesizing classes, you are not going to see concurrent assertions in classes.

There is a Questa specific package that layers on top of the UVM package adding the messages generated by `uvm_error to the wave and messages pane. You'll also be able to clink on the message and have it take you the the source. Until the next major release of Questa comes out, you have to ask Mentor Support directly for this package. There is also a -displaymsgmode switch that logs all Questa $display output, but it will always points you to the same line of code in the uvm_report_server that does the actual display.

Yes, I see what you mean. There should be some level of guaranteed atomic granularity. BTW, you could write class C as class C; local static mailbox #(C) mb = new; function new(); void'(mb.try_put(this)); endfunction function int count; return mb.num(); endfunction endclass

If one write() is doing a reset, and another write() is doing a compare at the same time, you have a race that needs to be dealt with independent of the preemptive nature of Verilog. SystemVerilog already has a mutex feature, it's called a semaphore, so there is no need to use DPI. However, you are not allowed to use blocking statements in a function. Instead of have multiple analysis ports use the same write implementation, people usually write into separate fifos and have another process waiting on data to appear in the fifos.

You are not supposed to be able to use a real at all in a constraint.

It depends. What states are you trying to protect? The write() method calls are automatic - their local variables are independently placed on the stack. If they all write to a shared fifo, then the transactions will be serialized. If these write() method calls are all concurrent, and need compare results with each other, then you have races that need to be dealt with.

There should be no issues running code in parallel as long as write/read access to shared variables is properly managed. That is handled by using semaphores and mailboxes, which is what is used when you write to an analysis fifo. Analysis fifos are unbounded, and a write will never block. This is one way you can serialize the transactions. BTW, no practical simulator of Verilog/SystemVerilog/VHDL implements a process using multitasking, cooperative or preemptive on a single core (multi-core is another topic for another day). There are just too many threads to manage it that way. Code generators take your source code and splice them together into common streams. So what you think is a context switch is just the result of the way the code has been spliced together. You won't see this too much in testbench code, but certainly in the always/initial blocks throughout the design. Also, process control statements like wait and fork that may not actually need to block sometimes create an opportunity for the scheduler to make a "switch" to another thread in the interest of fairness.

Take a look at this code package x; class y; string m_name; function new(string name); m_name = name; endfunction task run(); $display("%s.y.run", m_name); fork begin $display("%s upper fork", m_name); end begin $display("%s lower fork", m_name); end join_any endtask endclass endpackage module top(); import x::*; y y1 = new("y1"); y y2 = new("y2"); initial begin : initial1 $display("%m first initial"); y1.run(); end initial begin : initial2 $display("%m second initial"); y2.run(); end endmodule[FONT="] [/FONT] The ordering of the code within each initial thread is deterministic, but I think you will find differences amongst simulators on how the two threads are interwoven. Even though the fork statement doesn't block, some simulators use certain statements as an opportunity to do a context switch between threads. Continuous assignment statements are another typical place where optimizations make it look like the current thread is preempted to evaluate the function on the RHS of a continuous assignment.

Since SV only supports randomization of integral types, you will have to randomize a quotient and then convert it to real.

You can't compile the individual features of the UVM separately, but you can certainly use things like the reporting mechanisms, resources, command line parser separately. Other features may be harder to use by themselves. There should be almost no overhead in using only certain features of a pre-compiled package.

See http://verificationacademy.com/uvm-ovm/Sequences/Virtual and http://www.mentor.com/products/fv/events/sequence-layering

The project name is called "VIP". That is the name of the committee overseeing what was later named the UVM. I beleive you need to be a committee member to add to the database.

task body; my_seq_base seq_array[$]; seq_array.push_front(my_seq_0::type_id::create("seq_0"); seq_array.push_front(my_seq_1::type_id::create("seq_1"); seq_array.push_front(my_seq_2::type_id::create("seq_2"); seq_array.push_front(my_seq_3::type_id::create("seq_3"); // Shuffle the array contents into a random order: seq_array.shuffle(); // Execute all the array items in turn foreach(seq_array[i]) begin if(!seq_array[i].randomize()) begin `uvm_error("body", "randomization failed for req") end seq_array[i].start(m_sequencer); end endtask: body More example can be found herehttp://verificationacademy.com/uvm-ovm/Sequences/Generation

Help us help you by telling us what versions of Questa and UVM are you using? Also, is line 6 `uvm_field_int(ADDR_BUS,UVM_ALL_ON) Some times I see these kinds of errors when the version of the package you are using does not match the version of the +incdir library.

Take a look at the link again and see the important note for Windows users. I didn't notice that you were using Windows.

Looks like you did not provide the required DPI libraries for the UVM. Please see http://go.mentor.com/uvm1-0-questa

KumarSunilB, The OVM developers policy was to make sure that the source code was strictly written in SystemVerilog without requiring any C code. The UVM developers changed that policy and now contains certain functionality that can not be implemented in pure SystemVerilog source code (command line switches and hierarchical references via string pathnames). The UVM also has functions for string matching regular expressions that would be very inefficient to implement in SystemVerilog and are readily available in existing C libraries. UVM 1.1 can be run on Questa 6.6e or greater. The current version of Questa is 10.0c and contains a precompiled version of UVM 1.1. Dave

Dudi, If the API required to talk to the interface from the driver/monitor needs parametrization, like is the data bus 32-or 64 bits, there's no getting around the fact that both the driver and interface need to be fed the same parameters. However, if the communication between the driver and interface is independent of those parameters, there is a more elegant solution. Don't use virtual interfaces and stick with abstract classes. There are a number of papers describing this method starting with one I co-authored with Jonathon Bromley at DVCon 2008: "Abstract BFMs Outshine Virtual Interfaces for Advanced SystemVerilog Testbenches" Also Dvcon 2010: 6.1Coverage Driven Verification of an Unmodified DUT within an OVM Testbench And DVCon 2011: 1.4First Reports from the UVM Trenches: User-friendly, Versatile and Malleable, or Just the Emperor's New Methodology?

You many want to read these papers from DVCon DVCon 2011 12.2 Simple & Rapid Design Verification Using SystemVerilog Testbench on Intel’s Next-Generation Microprocessor Thomas R. Alsop, Wayne Clift, Luke Hood, Jeff Gray - Intel Corp. DVCon 2009 1.1 Model-based Instruction Stream Generation for Processor Verification Van Le, Hans van der Schoot, Michael Warner - Mentor Graphics Corp.