dave_59

You don't need to use generate block to do what you want: for(int i=0 ;i< NUM; i++) fork int j=i; // each process needs a separate copy of 'i' forever begin e[i].wait_on(); seq[i].start(agents[i].sequencer); e[i].reset(); end join_none wait fork; // waits forever

You should understand that `uvm_do_with(req, {req.number_of_samples == number_of_samples;})" generates req.randomize() with {req.number_of_samples == number_of_samples;}); SystemVerilog first searches the object being randomized for all operands inclosed by the with constraint, which in this case is req. So you effectively get req.req.number_of_samples == req.number_of_samples since there is no req.req.number_of_samples, randomize() then searches the local scope, the scope containing the randomize statement. req.number_of_samples == req.number_of_samples, which is a no-op constraint. What you probably want to do is write req.randomize() with {number_of_samples == local::number_of_samples;}); The local prefix says you want to only search the local scope, not the object being randomized.

Sorry, cut & paste error from your message. The method is set_report_severity_id_action_hier

You should use a virtual sequence that generates the number of data items to send/receive and have that sequence control the sequences running on the two agents. If that won't work for you, you'll need to provide a lot more details about the relationship between the two agents.

The problem is that top.set_report_severity_id_override() only sets the override for one component, the uvm_top. All classes not extended from uvm_report_object (effectively all classes not extended from uvm_component), refer to the uvm_top for their report settings. You need to use component_h.set_report_severity_id_override() or top.set_report_severity_id_override_hier() to set the override for top and all of it's children. The children have to been already constructed at the time of the override. I don't remember if they ever implemented this, but I recall a feature being discussed that certain report settings of the parent are copied over to the children as they were constructed. You might search reference manual for that.

The fact that uvm_top is a const variable means that they do not want you to modify it. Unless the UVM documents that you should extend a class, you should not be extending any UVM classes.

What you have shown should not result in a tool error. You should always be able to assign an extended object instance to a base class variable without a cast. Can you show us a little more code and the actual error message you are getting.

A big problem with modports and virtual interfaces is that some simulators have failed to implement all the required checks (only read modport input variables, etc.), removing much of their value to the user. It may be that the LRM failed to clearly explain their intent. Clocking blocks also suffered from poor specification in the LRM and were only recently cleared up in the 1800-2009 LRM. I do find the useful for interacting with wires inside interface. Although designed to remove race conditions, they can introduce other race conditions especially if you mix the clocking block event with other events in the same interface. I just wrote a paper mentioning this issue at last week's DVCon.

Typically, your driver interacts with your item using virtual methods of the sequence item. For example, the pack and unpack methods will know what do do with the extra fields. The driver just sees a stream of bits or bytes. We we would need to know more about what these additional members do to suggest further.

Are you sure simulation ends at time 2? It ended at time 10 for me after the main phase ends at time 2. Also, I see you found a solution to your once through problem. You should avoid the use of static variables. You just need to make done a class member.

The code actually limits the count to < 20, so that is 19 iterations. It takes 2 time units each to drop the objection to end main_phase, so that is 2*19 = 38. The 10 time unit delay to drop the objection to end the run_phase is in parallel to the main_phase.

I see you found the package as I was typing my last message. I would make sure the release of uvm_rgm that you are using matches the release of the UVM that you have. Again, I strongly recommend using uvm_reg.

You may need to download the UVM_RGM package from the user contribution section of UVMWorld and add that to your compilation scripts. The UVM_RGM package is not part of the officially released UVM package, it is a user contribution from Cadence. The standard UVM package contains uvm_reg, that was officially released with UVM 1.1. If you are just looking for examples to learn the UVM that already work with Questa, I suggest looking here.

It would help if you could show the exact format of the file. You say you want to read a hexadecimal formatted file line by line, yet you are reading entire file as a string. Why not use $fgets to read the file a line at a time, and then use $sscanf to convert each line. You can do this just before the `uvm_do

There is a difference between adopting from scratch and migrating. Adopting UVM_REG is the no-brainer. If you want to migrate to UVM_REG from UVM_RGM, it would be easy if you are already generating the register descriptions from a source like IP-XACT or an Excel spreadsheet. Then there is most likely a way to generate either register description format. There is no tool that I am aware of the will convert the SystemVerilog source.

UVM_RGM is not part of the Accellera standard, it is a user contribution from Cadence which is based on their user contribution from the OVM, which had no Register Abstraction package. UVM 1.1 has a Register Abstraction as part of the Accellera standard called UVM_REG. There is already multiple vendors that support generators producing UVM_REG descriptions.

If uvm_delay was defined as `define uvm_delay(time) #(time*1ns) Then a timeout of 100ms would be set_timeout(100ms/1ns) It would not matter what the current timescale was as long it was at most 1ns. Also, if people started using the SystemVerilog timeunit construct, there would be no problems with time scales and compilation order.

The value passed to set_timeout will use the timescale of whatever the UVM package was compiled with -it does not matter what your testcase was compiled with, unless you used a time literal somewhere the calculation of the timeout value. It would have helped if `uvm_delay multiplied its time argument by an agreed upon time unit literal. This is another case (like with random stability) that once both the developers and users of the UVM understand the semantics of how time is managed in SystemVerilog, you can plan accordingly.

The comparator classes in the UVM came from examples in the AVM, they were never truly intended to be part of the core BCL, just coding templates. They have not kept up with all the features of the OVM/UVM.

Even if you don't know all the instance names you can use a wildcard to match the instances in b_agent

You need to distinguish between e the language, and specman the simulator application that compiles e source code. As an application developed by InSpec, later renamed to Verisity, and finally acquired by Cadence, specman links with other simulators using the standard PLI mechanism. Any tool that supports the PLI mechanism can support the use of specman, which Questa does. Mentor's Questa does not support the e language without the Specman application provided by Cadence to compile and execute the e code. If you are familiar with SystemC, you will also see many familiar things from that library, like the TLM communication interfaces and the reporting mechanisms. In fact many of the same developers worked on both. The register package came from the VMM. Looking at this information from an academic point of view is fine, but I wouldn't suggest trying to learn the UVM by repeating how things were done in the environments where each feature came from. Some features don't translate very well in terms of efficiency when coming from other languages.

Chenyong, The UVM is derived from many sources. If you want to learn a language, you learn that language, not any of its predecessors. Unless less you are into academic research, of course. The main advantage SV over e is that it widely supported across many vendors as well as being widely adopted. If you want to know the academic reason SystemVerilog was developed, you have to go back about 25 years ago back when there were many hardware descriptions languages. Users demanded a single language to build libraries of design IP so that they could re-use and exchange their IP and netlists (it also helped when you needed to exchange engineering resources). About 15 years ago, after Verilog had become dominate language for ASIC design, many languages for testbench development started popping up and once again users demanded a single language so they could re-use and exchange verification IP. The result was SystemVerilog and now the UVM.

It depends what you mean by "actually used". More specifically, what it means to ignore them, assuming there are already there. Do you simply mean you don't what their run phases to execute? what about the other phases? At what point do you know that you want to ignore them? If the top-level test knows at the build_phase that they are to be ignored, why build them? You can use the factory to override the component with another whose run_phase it an empty stub.

Here are two resources to start with: A recorded webinar Intro to UVM Registers The UVM Cookbook page Registers/Overview

Pulzar, When mixing phase domains, you should think about when the next phase can begin, not when the current phase ends. The extract phase cannot being until both the shutdown and run phases are done. You typically want the driver to have one active thread getting transactions and transferring it to the interface at a time. The driver won't know from which phase the sequence item was generated in.