uwes

i believe you have to register (simply try to submit a mantis and you'll see). if you need to signup to file a mantis simply send an email to Alsop, Thomas R [thomas.r.alsop@intel.com] /uwe

http://eda.org/svdb/view.php?id=4092

hi mark, i think there are some things to consider: 1. if the classes are real base classes, then they should be abstract/virtual. (so they are not registered with the factory then) 2. if you dont register the fields via the macros you can still implement the do_(copy,print,...) in order that derived classes handle the fields as if they were normal uvm_field_xxx* 3. if you dont register the fields you also loose auto config thus needing manual extraction of values from the config_db /uwe

hi, i think the point is that the text file is not really intended to be viewed. its rather a vaguely "defined" exchange format so that other tools may display stream information. in that context the RADIX is simply a marker of your preferred way to print a uvm_field so (basically a hint how you want to have it displayed). i'm going to file a mantis to clean this up. /uwe

hi, a simple "workaround" would be to derive a new uvm_recorder and implement set_attribute with that change and override the uvm_default_recorder. i mean i dont really see that as "issue".

hi, we have just validated your test and have to confirm that there is an issue. I'll get you an update ASAP. /uwe

hi, technically you can extend uvm_root (because there is no "final" in the language) BUT you cant make uvm use your derived class without edits.if you could explain your use case we hopefully can identify other paths to accomplish the functionality without interacting with the critical core classes. /uwe

hi, switching on objection trace should tell you which object has been raising/dropping the objections (+UVM_OBJECTION_TRACE). eventually you have two parallel sequences running) /uwe

i'm not dave - but anyway :-)

hi, obviously you cant access base_sequence_item::addr because its not a member of that class. even when you can assign a derived class handle to a base class handle you can only access properties of the baseclass via the baseclass handle. there are a couple of approaches: 1. $cast the temp_item to an enh_sequence_item (then you can access the enh_sequence_item properties) 2. add a virtual function to base_sequence get_addr() and implement this in all derived classes. then in do_op() call get_addr() to retrieve the addr 3. guess there are more ... /uwe

hi, there are two sides of the medal: a technical one and a non-technical one technical one: REG and RGM attempt to solve the same kind of thing (register abstraction). there is quite some overlap but there are also non-overlapping features. if you do require them depends upon your application/verification approach etc non-technical one: while REG is the standard included register model and RGM comes as contribution one has to factor in things like: legacy environments, internal knowledge and generators (like the one you mention exists in your company), is this a new environment or inherited, is it a recode-to-reg, is the question to convert an existing rgm-env, what do you gain? so from what i hear it doesnt sound like a "no-brainer" in NEITHER direction. it sounds that this is not a new verification env and your company flow utilizes custom rgm scripts which probably! makes the rgm route an easier route for you. if you can address some of the questions above then the guidance would be easier. /uwe

hi, uvm_queue is a parameterized class. you never know what kind of type is actually used so you cannot write a generic comparison function (and as there are no type bounds in sv one cannot guarantee that the parameter is at least an uvm_object and use do_compare for the items) /uwe

hi, im not sure if the "const" is protecting you from modifying the object. the LRM says --- An instance of a class (an object handle) can also be declared with the const keyword. const class_name object = new(5,3); In other words, the object acts like a variable that cannot be written. The arguments to the new method shall be constant expressions (see 11.2.1). The members of the object can be written (except for those members that are declared const). ----- /uwe

hi, you should be using a more recent version such as 10.20s100+ or 11.10+. ius82 does not support uvm. /uwe

hi, which version of ius are you using? in general you should not have to modify any UVM files to get it running. btw: the easiest path to run with ius+uvm is "irun -uvmhome <youruvmhomedirectory> ... <your-verilogfiles>". this takes care of all uvm-compile and addon switches. regards /uwe

hi, the decision to deprecate set_config_* was a decision to focus on one API(uvm_config_db) instead of two (uvm_config_db and set_config_*). while set_config_* is deprecated it was explicitly noted that this deprecation does not mean set_config_* will disappear. (btw the set_config_* deprecation means deprecating the global and uvm_component local functions and has nothing todo with the cmdline interface +uvm_set_config_*) /uwe

hi, while i agree with adiel on the fact that UVM_RGM is a Cadence owned packaged and UVM_REG is part of the UVM standard and RGM is not - i think no one needs to rush and replace RGM and migrate to REG. UVM_RGM is a cadence contribution package which is in use throughout customers and has been used in numerous projects. you may consider switching to UVM_REG when starting a new project, building a whole new model etc. but if UVM_RGM is already present in the original OVM|UVM TB you should think twice if you want to add the effort of switching the models ... /uwe

hi, the uvm_update_sequence_lib_and_item macro is deprecated thats why removing all deprecated code from the lib using +define+UVM_NO_DEPRECATED is causing an compile error. im not entirely sure whether uvm-rgm-latest (2.7.5) (http://www.uvmworld.org/contributions-details.php?id=125&keywords=Cadence_UVM_RGM2.7.2_release) comes without deprecated code - but you might want to try. /uwe

hi, althrough specman/e has been developed by verisity (later bought by cadence) the language has become a standard (ieee1647) years ago. apart from cadence(specman) the other vendors also supply e-support (just talk to them or watch other eda/verification blogs). lets go back to the original question - uvm-sv vs uvm-e. basically UVM (U-"V"erification-"M"ethodology) describes an approach howto verify designs efficiently today. and as it is a methodology is should be language/tools independent. what you get with UVM is a set of building blocks and "best known methods" to tackle the big problem of design verification. UVM has been implemented in SV (via the VIPTSC) and an implementation of the same thoughts are avail for e (called "UVM-e"). having the same structure/terminology/methodology between the e-flavour and UVM-SV flavour allows verification engineers to design/handle/develop/understand verification environments using multiple languages. btw: UVM is based upon RVM/VMM/AVM/eRM/sVM/URM(and its predecessors) and UVM-SV is supported by the three major EDA vendors. looking at the underlying languages e vs SV you will see that they overlap with their features. while SV attempts to be a generic language for all design+verification (inheriting verilog for design) - e focuses on the verification aspect alone. the "generic" vs "specialized" language discussion is a repeated one which you will see in lots of different areas - all time when people promise a generic language which addresses all problems other folks come up with a DSL (domain specific language) which offers much more effiency in a particular field. looking at the current (out of EDA language) landscape you see new languages almost every day. the main diffs between SV and e are SV supports hardware design and e supports Aspect oriented programming on top of the typical object oriented (which both sv+e support). to sum up: - the methodology (UVM) is based upon concepts developed earlier for instance in e(eRM,sVM) or SV(RVM,VMM) - i think people suggest to study the concepts (HOWTO do things) rather then focusing on a language. once you understand WHY you should be doing things like that you can easily map the concepts to either SV or e - "SV" vs " e" is a long discussion which comes down to technical differences (design+verification vs verification only, generic language vs DSL leading to diffs in efficiency) AND "what resources can i access?" (do i have access to e/sv resources?....) regards /uwe

hi, did you import the uvm package somewhere? (import uvm_pkg::* /uwe

hi, in case the examples use internal capabilities it should be considered a bug and will be removed in subsequent releases. /uwe

hi, to be clear: you should be using objections as a distributed mean to perform end-of-test handling. the timeouts are usually only sort of a "grace" period to delay end of simulation or the transition to another phase.

hi, >That makes sense from a logical point of view, but how does that fit into UVM phasing? I.e., since the drive is a component, it also has the configure, run, etc. phases, so how do I make one > thread that runs through all of those phases? I have to put the "get_next_item / drive / item_done" loop into some phase, no? if you want it all time running hook it into the "run" phase.

hi, uvmreg(the register model in uvm) and uvmrgm(the cadence register model) both address the same functional areas. there are overlaps and there are differences between the two. also to note is that the uvmrgm register model has its root in ovmrgm which has been brought forward to uvm. so its not a new model its rather continued support for an existing package for customers. with respect to the technical details it really depends upon your use model and required features if you see a difference or not, or if your required features are already covered with uvmrgm. /uwe

hi, you cannot change the static topology (=creating any components) once you pass start_of_simulation BUT what you can do is to build all components and then dynamically switch them active or passive.you can silence the sequencers/drivers/... /uwe