dave_59

For what you want to do, it would be so much easier not to use the uvm_sequence_library and simply put the sequences into an array, and choose an array kind that suits how you want to index it. For example uvm_object_wrapper seq_lib[type_e]; // associative array indexed by an enum type_e To register a sequence, you do seq_lib[my_label] = my_sequence::get_type(); Now you can use any selection mechanism for the index, then call the factory's seq_lib[selected].create_object() to create the sequence you have selected.

In Verilog, functions/tasks do not need to be defined before they are called. Only data types and variables need to be defined before use.

This is really a workaround for the fact that earlier versions of SystemVerilog did not support non-blocking assignments to class variables. When you have many different processes simultaneously writing and reading the same variable, you need a way to prevent races between the indeterminate ordering between the reads and the writes. In the case of the UVM sequencer, you want all the sequences to have a chance to write their requests to the sequencer before arbitration kicks in to select a sequence. Without some kind of blocking mechanism, its possible that a single sequence can "hog" the sequencer, not giving the other sequences a change to put in their requests. In the past, this was done by adding #0 delays, a highly discouraged practice. A #0 simply means go to the end of the queue of things currently executing. A single #0 is sometime unavoidable, but once you start adding more #0's you are simply postponing race conditions for later in the queue. The UVM originally tried to solve this by adding a repeat (some_large_enough_number) #0; hoping that that number was larger than anyone else would have used. The NBA region solves this by creating a separate queue of updates to execute after all the activity at the current time has settled out. If the sequences had used NBAs to write their requests, this wait functionality would not be needed. And the comment about if the UVM library was `included in a program block instead of a package is false in so many ways Scheduling semantics of program blocks has nothing to do with where the code is declared, only where the process is initiated when calling run_test(). You certainly are allowed to have nonblocking assignments in a program block. You certainly do need this functionality because you can have the same races within a program block between reads and writes as you can within a module.

Yes, Dynamic arrays are transferred as "Open Arrays". See this post for an example. C pointers can be transferred through the DPI and stored in SystemVerilog using the chandle data type. However you cannot reference what the pointer is pointing to in SystemVerilog, you have to transfer the pointer back to C to reference.

The 7.eleven() was just a simple example to make that point that just because the BNF allows a particular syntax is not enough to make legal. The problem with chaining is that "." (dot) is not an operator like it is in C/C++. Section 23.7 Member selects and hierarchical names in the 1800-2012 LRM defines the rules for interpreting the names in between the dots, and function calls are not part of that. Unfortunately, what may seem an unambiguous case to one person may become ambiguous when another aspect of the language is thrown in that they were unaware of. The LRM committee tends to keep these features out of the standard until a reasonable consensus can be had. Ultimately, the LRM is considered a guideline rather than a standard for many due to economic pressures from users and vendors alike.

Chaining of method calls is not legal in the LRM. See http://www.eda.org/svdb/view.php?id=2735

You did remember that field automation macros never do a uvm_config_db::get() for you? Most people don't realize this, and many other problems including their performance are why we do not recommend using them. Please see this link. But even if it did to the get(), only the set()s that came before it would have an effect. So at the end of elaboration, you need to get the handle to your ga_cfg and set cfg.montitor_enable = UVM_ACTIVE;

Are you asking about defaults for regular Verilog ports of modules and interfaces, or interface ports of modules and interfaces? SystemVerilog allows default connections for ports that are not interface ports. interface itf(input logic clk, logic reset=0); wire signal; endinterface // itf module top; bit clk; itf i1(clk,); // only clk port connected endmodule Ports that are interfaces cannot be left unconnected. module DUT(itf i); always @(i.signal) ... endmodule i.signal would not exist unless it was connected to an actual interface instance of itf.

Although there are no current plans to remove the 12 runtime phases, the committee has in the past considered making backward incompatible changes. (http://forums.accellera.org/topic/926-runtime-synchronization-survey-question-6-of-6/) . Given the amount of time the committee has spend in the last two years trying to resolve a large number of open issues, and the fact that there a number of reasonable alternatives to the UVM phasing, I recommend staying away from it. UVM 1.2 is now pushed back to beginning of 2014 Precompiling the UVM is not necessary unless you are running lots (100s) of small tests, or you have network filesystem issues. It's just provided as a convenience for people just getting started with the UVM. In tools that support separate compilation, you can compile the UVM package into different work libraries and select the appropriate work library when you compile your test.

You can put commands into your scripts that would provide more information than what $finish(2) provides. Questa provides a Tcl command simstats, and you can also use OS commands like time to get similar info.

Hi Chris, To use macros or not is likely to invoke a language war along the lines of OOP vs AOP' strong vs weak typing, code indenting, and variable naming rules. There are good arguments for both sides, and I think it is important to understand both sides, and that there are extremes where one way clearly outshines the other. When I first looked at the code that was being proposed fro the OVM, there were the macros `vf, `vt, `f, `t, `ef, and `et. There were there because someone didn't like typing the extra characters for a virtual function (and I'll leave it to the reader what the other macros stood for). To me, use of those macros was clearly wrong. They obscure the code for the uninitiated reader, and you must understand the underlying keywords anyways. Plus, there are many IDE/template generators that will fill that out for you. You must remember that the majority of engineers writing UVM code today are new to it as well as new to SystemVerilog. And there is also a large number that go months without writing any code and have a tough time getting back into it. The `uvm_do macros are a mixed bag. Yes they do save you some typing, but you need to understand what is behind them to be able to choose the correct 1 out of the 16 variations of that macro anyways. Maybe one or two variations of the `uvm_do macro will save you some time, but you will loose that productivity trying to look them up in the reference manual to remember what the the others do. And the time you would save typing the 5 basic statements to send a sequence_item is inconsequential compared to the amount of other code you need to write in the sequence. The performance of `uvm_field macros have greatly improved since the OVM, but they are still not acceptable in my book. Most testbenches will easily make up the 10-20 extra minutes to enter the code over their lifetime. And there are IDE/template generators to cut the code creation time down as well. When used improperly, the field macros are as difficult to debug as not using them, just different kinds of bugs. And I can't tell you how many people forget that only certain kinds of fields, and only when used in an uvm_component do the auto-configuration. P.S. I hope your emergency room factoid was not from a recent trip to one - I know you've had more than your fair share of trips there.

kansagaratushar, This is one of the reasons I don't recommend using the with clause of randomize(); it goes against OOP programming practices. It would be much easier in the long run to extend my_transaction to add or override the constraints you want, and then use the factory select the transaction you want. See https://verificationacademy.com/cookbook/sequences/overrides for examples of how to use the sequence with the factory.

The LRM considers the clocking block output declaration as the assignment to the signal data. The statement cb.data <= value is not a direct assignment to data. Checking this at run-time rather than statically would be a severe performance penalty for all assignments. A modport would not help. You either need to change data to a wire, or conditionally compile/generate the clocking block. Chris Spear is a Synopsys employee and mainly has access to VCS. From my experience with other joint customers, VCS is not performing any assignment checks regardless of whether the clocking block is driven or not.

Questa will also generate an error because the code is illegal as the error message reports. The DUT connection makes a continuous assignment to data, and the clocking block output is consider a procedural assignment to data. Declare data as a wire instead. See http://go.mentor.com/wire-vs-reg for an explanation of why you can;t mix procedural and continuous assignments to the same signal.

I never evaluated performance, but I've got to believe DPI is quicker. And BTW, I've only personally done both with PERL, not python.

You will have to download the UVM kit from the Accellera site and compile it yourself. I don't recall if the student version supports DPI, so you may need to compile it with +define+UVM_NO_DPI

That's not completely correct. The Starter/Student editions will support classes. but not calls to class.randomize(), covergroups, or assertions. So you could create some basic UVM structures.

That is exactly what the "ID" is supposed to be used for. You should prefix all of your ID's with MY_ or whatever.

The best way: your favorite awk/sed/perl script. No really, why do you want to do this? Adding any kind of report catcher will just slow the system down.

If you can call a python function from C (which you can) then you can use the SystemVerilog DPI to call C which would call python, If you simply want to call a python script, you can use the $system("command") task, but all interaction with python and SystemVerilog would have to be through file I/O.

How about showing the exact error message. Also what version of the UVM are you using and are you sure the macro file you are including is from the same version of the package you are importing.

I think you have the streaming operator on the wrong side of the assignment. You want a limited part of bit_vector to fill bit_array, not all of bit_vector (which is 32K bits) to fill a limited part of bit_array. bit_array = {<<{bit_vector with [0+:packer.count()]}};

It serves no purpose other than legacy from OVM, and in the OVM it served as legacy from the URM/eRM. This class is the top of the class inheritance hierarchy. SystemVerilog has no need for a class that serves as a base of all classes, but Specman e did have this concept. Somebody though they would need to have a common root base class, so they added it to the library, but it turns out it is not needed in the UVM.

Try putting the dist_normal in a function used by a constraint. class A; int seed = $urandom; int tmp; rand int ii; rand int mean; constraint c{ii == normal(mean);} function int normal(int mean); return $dist_normal(seed, mean,10); endfunction constraint mn {mean inside {[200:400]};} endclass : A A a = new; initial repeat(10) begin int tmp; a.randomize(); tmp = a.seed; $display("%p %d",a, $dist_normal(tmp,a.mean, 10)); end endmodule : top Dave Rich Mentor Graphics

The answer is the same as what I posted here: https://forum.verificationacademy.com/forum/verification-methodology-discussion-forum/uvm-forum/30592-zero-delay-loop-verilog-design#comment-30597