dave_59

An interface class is not the same as a plain interface. The interface keyword in front of a class type definition is special modifier, like the virtual keyword that defines a special type of class. The BNF shows you the syntax that is possible to express, but not all of it is necessarily legal. Any syntax that is not expressible is illegal. If you scan through this series of BNF items, you will observe that there is no way to assign an interface/module/program to a type parameter. If you go through the list of data_type items, there is nothing that allows an interface_identifier unless it is preceded by the virtual keyword.

The BNF does not allow it An interface is not a data_type (A.2.2.1 Net and variable types). A virtual interface is a data type, but not the interface itself.

You really have to understand the random stability issue when you write any SystemVerilog code, this includes the people writing the UVM BCL. And UVM has its own seeding mechanism that is on top of the SystemVerilog mechansim, which makes it even mmore complicated. The person that wrote get_some_number() has to provide assurance to the person writing code that calls get_some_number() that it will or will not disturb the RNG. Perhaps we need a methodology similar to Manual object Clone on write (MoCow); leave it up to the routine that disturbs the RNG to decide if they need to preserve it. Note that there has to be a careful balance between random stability and random diversity. If for some absurd reason you do need to call $urandom inside get_some_number, then preserving the RNG won't work because you could have multiple `uvm_info calls and you would want each $urandom call to produce a different random number.

Did you declare the variables as rand? Can't really help wiithout seeing some code.

Yes. I mean the problem is more widespread than just uvm_mem. Anywhere there is the possibility of addressing a memory needs the ability to change the index range.

This was supposed to be fixed in UVM 1.1b. Maybe they missed some other places. http://www.eda.org/svdb/view.php?id=3966

There certainly is a way around it. Don't use `uvm_do_* and instead do start_item(req); req. tx_err_bytes.rand_mode(0); req. tx_err_bytes = {4,5,7}; req.randomize() with { tx_data_byte[0]=='h00; tx_data_byte[1]=='h11; tx_data_byte[2]=='h00; tx_data_byte[3]=='h99; tx_data_byte[4]=='h55; ///----------------- tx_no_of_bytes_to_send ==20; } finish_item(req);

It's not a LRM gray area. People are just lazy when specifying a global disable.

http://www.doulos.com/downloads/events/DVCon_08_abstractBFM_final.pdf http://events.dvcon.org/2012/proceedings/papers/01P_3.pdf http://events.dvcon.org/2015/proceedings/papers/04P_19.pdf

Another option that is gaining in popularity is to avoid using virtual interfaces and instead use abstract classes. Then you can selectively couple the interface parameters you want with the class parameters you want.

The iff clause is an edge qualifier. It means wait for the edge to happen if and only if both the edge happens AND the expression is true. @(event iff (expression)); is equivalent to do @event; while (!expression) This becomes very handy when using clocking blocks. Once you start using clocking blocks, you want to make sure all your code that references the clocking block signals are synchronized with the clocking block event and no other events controls or wait statements. This eliminates all chances of race conditions that might add or miss a clocking block cycle.

http://go.mentor.com/programblocks

You need to write your script as a script: vsim -voptargs=+acc -assertdebug -sv_seed random -coverage -onfinish stop -c my_top -l ./sim_log/my_test$Sv_Seed.log +UVM_TESTNAME=my_test +UVM_VERBOSITY=UVM_LOW add wave -r /* run -all coverage save -onexit ./coverage_database/my_test$Sv_Seed.ucdb; There is no need to echo the seed - it does that for you automatically. You should use +acc instead of -novopt

SystemVerilog packages are designed to be independent units with no dependencies except for other imported packages. This forces an explicit package compilation order, and also means that packages cannot hierarchically reference anything outside the package that has not been imported from another package. This means your testbench in the package needs some clearly defined boundary to access the top module. You may want to see my DVCon paper: The Missing kink:Testbench to Dut connection

The best method is not to use the macros at all. Learn the basics without the use of the macros. See http://verificationhorizons.verificationacademy.com/volume-7_issue-2/articles/stream/are-ovm-and-uvm-macros-evil-a-cost-benefit-analysis_vh-v7-i2.pdf

Chitlesh, The original purpose of the UVM was to standardize a way of coding your testbench in standard SystemVerilog so that it could be re-used and integrated with code developed by other people, projects and external VIP. Instead of creating your own mechanisms for configuring, executing, reporting, etc., and having to document, provide training and support, the UVM gives you all that in another standard. Much like in the software world, the UVM provides standard coding patterns like the factory and wrapper classes using established practices. Over the years, the UVM has grown in complexity with many new features that each by themselves are extremely useful. However, taken as a whole, these features give the user too many choices to implement the same thing. Also, many of these features are not necessary in typical verification environments; it becomes very difficult for people thinking about adopting the UVM to know the minimum subset of what they need to know to get started. So what is needed is another "standard" layer of best practices that go on top of the UVM. The UVM Guidelines on the Verification Academy are an attempt to provide that extra layer of filtering to make UVM more re-usable like it was originally intended to do. I don't necessarily agree with everything decision that the Guidelines make for you, but I don't have the time or think it is important enough to argue every case. Nor do I think the guidelines will fit everyone's particular testbench environment. But having a set of guidelines is a good practice to have as your starting position, and exceptions need to be justified. In the particular case of the run_phase, most people seem to think that is sufficient for the average testbench and that proper use of sequences can provide the all the functionality of phasing. To say that the reset_phase would be removed in a future release was a bit too strong. But I think what they meant is the current way that it exists now many not continue to exist in future releases. I haven't followed all the UVM 1.2 phasing discussions, but I don't think they made nearly as much progress as they hoped they would have. But even if all the phasing issues were addressed in UVM 1.2, I would probably still recommend the use of sequences as that is a much more important and simpler concept to grasp.

ljepson74, The reason for this is more than just visual consistency, but for better interoperability with debugging aids. Unlike the static Verilog module hierarchical world, there is no authoritative ownership of objects for the tool to construct a hierarchical pathname. In other words, there is no permanent relationship between the object being created, and the object creating it. The Verilog elaboration process builds a pathname for you for you. When you call new as part of a dynamic procedural thread, you just get a handle to an object that you can store, or you can pass it around to another object. In fact, when you call the factory's create, you are delegating creation to another object; a proxy for that object. For objects derived from uvm_component and uvm_sequence, the UVM has a mechanism to assemble a string pathname for you that is used in reporting. When you debug, it is much easier to navigate through your environment when the pathnames match the actual class variable names that you would use to reference a class variable.

Because it makes no sense. In Verilog/SystemVerilog, functions cannot block and take 0 time. An objection to ending a phase means extending the time of that phase. If you extend the time in the "build_phase", there is nothing you could add to it.

This because you need to understand the macro `uvm_oject_utils() See parameterized-classes-static-members-and-the-factory-macros, then look at the Reference for uvm_object_registry.

This is a general issue with all tasks in the UVM that are not class methods. I have filed 0005216: tasks declared outside of class methods need to have an automatic lifetime

Nizam, You were not really clear on which C interface you were using, DPI or VPI. For DPI, one thing that is clear in the LRM: you cannot call an DPI exported SV routine from a thread that was not created by calling a DPI imported C routine. But in any case, there are issues beyond the thread-safe issues that Uwe mentioned. There needs to be a global synchronized concept of time in an SV simulation. SystemVerilog has no built-in mechanism to understand calls that could be from another point in simulated time. All this is not to say your application cannot use pthreads - it's just that the interaction between the SV kernel and C must be performed within a single thread. Dave

Sorry it took so long to respond. I was on vacation. Please see go.mentor.com/programblocks

Uwe, I agree that the specification does not guarantee an inst_id that is incremental starting at 0, but the API does say "The instance counter is used to form a unique numeric instance identifier." so that implies a unique inst_id across all constructed objects derived from uvm_object that cannot be reused.

I don't understand how any of the reasoning in post #4 can be correct. First of all, the object is in use until the next object gets created. As long as a class variable holds a handle to a class object, that object must exist. Second, when you construct an object, all class members get initialized with default values. That is independent of any simulator implementation; the user should not be aware of any reused objects. Third, there is only one static variable m_inst_count for all classes derived from uvm_object. So how could the id not be unique until you construct the 232th object?

You problem with the qverilog command is with the -R switch. To pass multiple arguments to the simulator, you need to include them in quotes, or whatever your shell requires to form a single argument. In either case, you should not be compiling the UVM source or DPI yourself.