dave_59
Members-
Posts
403 -
Joined
-
Last visited
-
Days Won
21
Content Type
Profiles
Forums
Downloads
Events
Everything posted by dave_59
-
Erling, I like your solution. What you have just described is essentially making MyDrv an abstract class without explicitly using the keyword "virtual" in front of the class declaration. In both cases you have to extend MyDrv to get a working driver implementation. Adding "virtual" to the class means that the compiler could check that it was never constructed directly, but then you would not be able to register it with the UVM factory. The other thing it does is keep all the signal and timing related references inside the interface or module where the class is declared. This eliminates all the indirect references that normally would be through a virtual interface reference. Dave
-
Because it is a more elegant solution. This is a standard OO programming patern and it means you don't have to have an RTL interface around if you don't need it.
-
Although you didn't mention it, I assume that your problem is because both driver and monitor class are referencing the same virtual interface. Unless the compiler has some very sophisticated dead code analysis, it not going to know that that your driver is not going to be used - especially if the driver is registered with the factory. I'll use this as another plug to get people to think about using abstract classes instead of virtual interfaces to connect to the DUT. See the following papers http://www.dvcon.org/2010/proceedings/papers/06_1.pdf http://www.dvcon.org/2011/proceedings/papers/01_4.pdf http://ovmworld.org/forums/showthread.php?100-OVM-wrapper-for-Verilog-Bfms&p=350#post350 Dave Rich
-
clone() means construct followed by a call to copy(). clone() is virtual so that you can construct the same object type as the one you started with. clone() calls copy() to perform a deep copy of the object type you just created. The copy() method by itself just copies class member values from one object to another. Normally, the copy() method only copies the class members for the current class type, then it calls super.copy() to copy the class members of the base class.
-
der57. I agree with you 100% See http://go.mentor.com/a-time-for-change .
-
The text you quoted in 13.3.2 seems to be leftover from Verilog-2001, which introduced automatic tasks, but not automatic variables in general. That section should be deleted and what is stated in section 6.21 Scope and lifetime should apply instead: In your example, the task foo is the enclosing scope that includes a fork-join block. The compiler will extend the life of taskArg to inclide the like of the nested fork/join block. It can do that because it can statically (i.e. at compile time) determine the dependencies. It can't do that across a task call. Dave http://www.eda.org/svdb/view.php?id=3548
-
QuestaSim 10.0a slow performance with UVM 1.0
dave_59 replied to icarus035's topic in UVM Simulator Specific Issues
First, you should be using the pre-compiled UVM package released with Questa 10.0a. See http://go.mentor.com/uvm1-0-questa Yes, there was a compiler performance bug with the UVM 1.0 in Questa 10.0a and 6.6d. It has been fixed in Questa 10.0b (soon to be released), Questa 6.6e (already released), as well as the next release of the UVM. -
Erling, The UVM EA kit was an early adopter release -- a work in progress, not for production use. The body() method in ovm_random_sequence correctly turned turned the pick_sequence constraint off in ovm_sequence_base. Then, uvm_sequence_base added the c_randomized constraint, but uvm_random_sequence forgot to turn it off as well. This section of the UVM (the sequence built-in's) had no examples/tests to catch this error, and is now deprecated, so I guess you are left with one of my suggested workarounds, or modify the source yourself.
-
Erling, See the LRM section 18.11 In-line random variable control. When you call randomize(i), all rand variables in MySeq (including the is_randomized bit in uvm_sequence_base) become state variables except for i. All constraints remain enforced, so the c_randomized constraint is not able to set the is_randomized bit to 1. Not knowing what you are really trying to do, there are a number of things you could do: is_randomized = 1; before calling randomize(i) c_randomized.constraint_mode(0); before calling randomize(i) call randomize(i,is_randomized) call std::randomize(i) with {your_constraints};
-
How to depress the path for UVM REPORTING?
dave_59 replied to aprice's topic in UVM (Pre-IEEE) Methodology and BCL Forum
Another option, depending on how much you need to selectively control the report options, is to use the report handlers from higher level components in the lower levels: class my_agent extends uvm_agent; function void build_phase(uvm_phase phase); my_driver_h = my_driver::type_id::create(...); my_driver_h.set_report_handler(get_report_handler); ... endfunctionIf you do this, you will no longer be able to selectively modify the reporting options for all messages in your driver. You still have the ability to controll messages by IDs.The other option is to create separate logging objects that are disconnected from the hierarchy: class my_driver extends umv_driver; uvm_report_object log = new("some_shorter_name"); function void some_function(); `uvm_info_context("myid","my message here", UVM_LOW, log); end -
Questasim 6.6d Does not Compile Codec Example
dave_59 replied to jkolisnyk's topic in UVM Simulator Specific Issues
There is a Questa 6.6e release that might fix your problem. Questa 10.0a is the latest release and was the first release to incorporate the released UVM-1.0p1 directly. You should look at this article and try to run the example with the pre-compiled UVM package Otherwise contact Mentor support directly. -
Is there way to mask a message type in UVM
dave_59 replied to ninad_99's topic in UVM SystemVerilog Discussions
This is not a language question. See +uvm_set_action in the reference manual +uvm_set_action=uvm_test_top.*,_ALL_,UVM_WARNING,UVM_NO_ACTION There is no way to get a list of message types that have been masked other than querying the severity-id pairs individually. I would not recommend this approach as you would now be using the report handler as a configuration mechanism. Instead, use the configuration mechanism to drive the report settings. -
Because the UVM was deigned by committee and committees love to have more than one way of doing anything (Sorry, could not resist) I think the idea was that at some later point, the UVM might include more than just a UVM package. Technically, the UVM macros are not part of the UVM package, but are needed to compile the package anyways. Dave
-
Issues with Questa 10.0beta2
dave_59 replied to R_C1363912821's topic in UVM Simulator Specific Issues
RC, you are using a beta release that is not supported. Please download the latest version: 10.0a. -
Trouble running Questasim 10.0a with simple UVM example
dave_59 replied to cliffc's topic in UVM Simulator Specific Issues
If you are using a release prior to 10.0a, then you must follow the directions Building the UVM DPI Shared Object Yourself setting $UVM_HOME to the location where you downloaded the Accelera kit. Questa 10.0a was the first release that included the Accellera kit. Dave -
About the config class usage
dave_59 replied to hugemx830202's topic in UVM (Pre-IEEE) Methodology and BCL Forum
Mike, This is exactly what we recommended in the OVM. Use only config objects, not ints or strings. Use uvm_object as the base for your config class; components have much more overhead associated with them. You should not call xx.build() directly because the scheduler inside the UVM kernel will do that for you at the appropriate time. Dave Rich -
help on UVM_READONLY
dave_59 replied to chenyong's topic in UVM (Pre-IEEE) Methodology and BCL Forum
The `uvm_field_**** macros are the field automation macros, where **** are a certain subset of data types. They are supposed to save you some amount of code writing by performing certain operations for you, get_config being one of them, along with printing, copying, pack, and unpack. I normally do not recommend using them because I like seeing the code, and there can be a lot of overhead in the code the macro invokes. See Parameterized Classes, Static Members and the Factory Macros. By the way, the paper I reference just won "Best Paper" as this year's DVCon. Dave -
help on UVM_READONLY
dave_59 replied to chenyong's topic in UVM (Pre-IEEE) Methodology and BCL Forum
The UVM_READONLY setting only applies to operations performed by the field automation macros. Anything you do manually is not affected by the field macro settings. BTW, since this is inside an uvm_component, get_config_int would have been implicitly called if you had not used UVM_READONLY. Dave -
UVM_DEPRECATED message
dave_59 replied to uvm_rookie's topic in UVM (Pre-IEEE) Methodology and BCL Forum
4th option, just seq.start(seqr); in your test. -
Trouble running Questasim 10.0a with simple UVM example
dave_59 replied to cliffc's topic in UVM Simulator Specific Issues
Please see http://go.mentor.com/uvm1-0-questa for instructions for running Questa 10.0a with the UVM.