dave_59

You should not be using this in your code; the sequencer base class takes care of arbitration between concurrent sequences. You would only use this if you need to create an arbitration mechanism that does not rely on the sequencer.

This goes back all the way back to Mentor's AVM, before any official standard. "Components" are essentially long-lasting objects that get constructed at the beginning of the test. There are relatively few of them compared to "transaction" classes. There is considerable overhead in creating a report_object because each object has to maintain a database of report setting or knobs that would be too expensive for the magnitude of transaction that get created. You can always use the context of the sequencer (m_sequencer), or create an independent report object if you need to control the reporting of sequences separately.

But you can refer to package parameters directly without importing them, or you can import the package as part of the module declaration.

It would help to explain why you need Verilog 95 style ports. There is a way of using parameterized classes which are themselves passed as parameter types to a module. But most HDL synthesis tools do not accept classes even though they may be perfectly synthesizable in some cases.

It looks like you didn't compile the DPI portion of the UVM library, or don't know how to use the pre-compiled versions of the UVM library. (I don't know if Modelsim has pre-compiled libraries; Questa does for sure)

UVM-AMS is an Accellera Working Group that has not yet published anything open to the public to read. You are welcome to apply to join the group at the link.

This is a warning from one particular tool, not the UVM code. srandom(seed) is a SystemVerilog language feature and there is no restriction on value of the seed

Hi Mark, Looking at this library, It seems that Mantis 3220 has been backed out since UVM 1.2 uvm_report_server.svh:792 $swrite(time_str, "%0t", $time); should be $swrite(time_str, "%0t", $realtime); -Dave

Although languages like Python have become immensely popular because they are easy to learn, enabling rapid prototyping, and have accumulated vast libraries for many different applications, they have yet to earn their place in Industry practice because of their relatively poor performance. Verification teams constantly struggle keeping their already slow nightly regression runs nightly; having it turn into days or weeks is not acceptable. I do know a number of design teams have successfully developed testbench models in <your_favorite_language_here>. Those are fragmented examples and as the other David says, it would be stretching resources to support all of them. We are still wasting resources from the mistake of having to support both Verilog and VHDL HDLs back in the 1990s. Is it possible optimizing Python overtakes the performance of C/C++ in the years to come? Maybe. But unlikely in the next decade.

It is not possible to have a class object with both a member variable from B and member variable from C simultaneously; it is one or the other. So you can never randomize an object with both member variables. Perhaps you can show some example code of what you are thinking.

Of course @(func(signal)) is going to cost more in performance than just plain @(signal).

This does not work, This is exactly the problem described in the original post.

I think defparam is partly to blame here. Before introducing the inline parameter override syntax using #(param1,...) in Verilog-2001, it was very difficult to predict when a parameter had received its final elaborated value relative the the module referencing it. Adding generate constructs makes that process even harder when you start allowing hierarchical references to parameters outside you instance, before the instance hierarchy has been fully elaborated. So the "no hierarchical names" rule is a broad hammer. In your particular example, you can get around this rule by using typedef instead of parameter references. SystemVerilog allows referencing a type from an interface port because there is a strict relationship between the interface instance and the port it is connected to. interface bus #(N = 8) (); typedef logic [N-1:0] adr_t; logic [N-1:0] adr; endinterface module m #(M = 8) (bus intf0, input [M-1:0] adr_pure1 ); typedef intf0.adr_t adr_t; // bring interface type into local scope if (M != $bits(adr_t)) $error("unequal parameters"); endmodule module top; bus b(); m m1(b,'0); // no error m #(10) m2(b,'0); // error endmodule

This is a open issue with the LRM. https://accellera.mantishub.io/view.php?id=7190

It's not legal to dynamically select an instance of a module or interface. Elaboration flattens out all hierarchy. Arrays of instances are not true arrays like a variable. Each element could have different characteristices because of defparam, bind, and port connections. The BNF does not allow the syntax.

Hi Linc, Section 4.4 Stratified event scheduler of the 1800-2017 LRM defines a time slot as A time slot is clearly a single point of time encompassing all the regions (active, inactive, nba,...) and the iteration of all the region without advancing time. A time step has a looser definition, and there is already a request to use it more consistently in the LRM. There are many uses of time step that really should be time slot. IMHO, a time step should be used to refer to a particular point in time, or the advancement from one particular time to the next nonexempt time slot.

See the link to My DVCon paper.

Hi Linc, Your code works correctly on three other EDAPlayground simulators.

@ljepson74, All you have to do is import uvm_pkg::uvm_enum_wrapper; and you've got this handy little class to use, you don't even need to have a class based testbench.

The UVM field macros do not handle OOP very well, and is one of the many reason we do not recommend using them. It would be much simpler and more efficient to use the streaming operator exactly as you wrote it in a do_pack method.

The link answers the question on how to apply a distribution to any set of constraints. The dist construct only works with explicit values.

https://verificationacademy.com/forums/systemverilog/distributed-weightage-constraint#reply-46525

You always incur overhead for automation. Performance rapidly deteriorates as you introduce dependencies with other random variables. For example, suppose you need 8 unique values between 10 and 20. You are going be calling $urandom_range many extra times throwing away values that don't meet the constraints. And it becomes very difficult to know when there are no solutions, and you end up in infinite loops looking for solutions that are very hard to find or don't exist. This is what a constraint solver does for you. Since constraints are tied to the class inheritance system, they provide another key benefit: you can add to or override them easily. It's very difficult to override constraints embedded within procedural code (this includes using in-line constraints).

Where did you read 0 is not a valid seed?

Give your error message a unique ID. Use set_report_severity_id_override to change the severity of that ID from UVM_ERROR to UVM_INFO. Then call get_id_count at the end of your test to make sure it's non-zero.