uwes

hi, im not convinced that the bind of classes into the dut is a good way - big setup or not. i rather feel that the proposed structure is the outcome of some of the shortcomings/unexpected behavior of (virtual) interfaces interfaces. /uwe

hi, i would use the same standard infrastructure for a couple of reasons - things never stay simple - you may already have a transaction: delay-between-request-response, react-or-not, - you want a standard approach to control your components - you may want standard transaction recording - you may want standard sequence like behaviour (controllable from higher layers) - the only thing i would save if the agent is never,never, never used in passive mode is the monitor

hi, you would use a derived class ("extending") if you intent to add functionality or additional members to this sequencer type. you can use a typedef to create a shorter name for the sequencer type.

hi, yet another reason NOT to mix static and dynamic hierarchy althrough technically you can create unique paths using % or unique prefix paths. to me its much simpler just to instantiate my required classes complete separate from the DUT infrastructure and ONLY supply the interface for my agents/monitor/s via the virtual interface. /uwe

hi, #1 a component can have any number of PORTS (initiator) #2 a (standard) component can only have one IMPLEMENTATION (the _imp) #3 you can use special macros to create other/parallel IMPLEMENTATION port types to allow multiple imp ports directly within a component #4 you can encapsulate an IMP into a uvm_subscriber an instantiate that into the component. that way the port impl are not within one scope. #5 a uvm agent can have any number of sequencers. /uwe

hi, a few things to it: - you cannot start() a transaction (only a sequence, a transaction requires a .start_item()+finish_item()) - there is a check that sequences have to be in a CREATED,STOPPED,FINISHED state in order to start them. not sure if there can be a race which bypasses the fatal, or if the fatal is demoted. anyway, attempting to start the same sequence instance or transaction on multiple sequencers at the same time probably most likely leads to bad behaviour. -

hi, although it may not be written explicitly uvm_reg's terminology and modelling closely follows ipxact1.5. so i dont expect this class to be removed as long as ipxact(1.5) is taken as structural "origin" /uwe

an "an unexpected situation encountered" is an internal tool error. you should contact cadence support along with your tools version/setup/testcase. there is nothing wrong you did. /uwe

virtual interfaces are the primary method to reach out from a class context into the static module area. using OOMR (out of module refs) have downsides and break encapsulation and i typically avoid them. also to note is that there is a semantic difference whether you instantiate something in an interface/module context (this is what you suggest as far as i understand) or in a program block context (thats what the SV lrm suggests to separate TB/DUT). >Real interfaces can handle all these cases nicely, while virtual interfaces can not dont understand this. a virtual interface is a reference to a real interface instance. as a side note: there is also the concept of an interface db. you could for instance 1. create a module wrapper for an interface type (a module with an instance of an interface) 2. bind an instance of #1 to some place in the dut hierarchy 3. statically register inside the module wrapper a reference (a virtual interface) with a name in a db 4. then your tb you simply ask the db for a logical if and the db would return the virtual if instance associated with that logical name basically this allows you to separate dut-if from tb via a logical if name. /uwe

hi, if you use a uvm_event you always need to expose that event. if you do use a analysis_port you can hide it through multiple levels via *_exports(=proxies). i think its better to use a 1. instantiate an uvm_blocking_peek_imp#() in the monitor 2. implement the montor::peek task() 3. from the sequence peek into that .addr_ph_port.peek(util_transfer); see the ubus for an example (in the slave) /uwe

hi, this is the result of using the old style 'uvm_sequence_utils' macro. see for instance http://www.uvmworld.org/contributions-details.php?id=107&keywords=Appnote:_Migrating_from_OVM_to_UVM-1.0 for more details /uwe

hi, >1)Will all these components be elaborated under the same uvm_root? i think you mix some things: 1. the scope there the component is created (and who has references to it) 2. the notion of the logical path 3. uvm_root - for uvm_root documentation: // Implicit top-level - The ~uvm_top~ serves as an implicit top-level component. // Any component whose parent is specified as NULL becomes a child of ~uvm_top~. // Thus, all UVM components in simulation are descendants of ~uvm_top~. so where you instantiate your component (scope) doesnt matter. what matters are the name argument and the parent reference. this means for Q1:yes, Q1bii: all components are phased by the same/single uvm_root phase controller. how they are phased depends upon their domain/schedule association and custom/phase transitions. BTW: as you typically connect your tb with the DUT via virtual interfaces there is no need to instantiate your tb(or components) inside the dut. /uwe

hi, run_test never returns (it ends with a timeout).the #1us + drop are never executed. you could write it as initial run:test("env"); initial #1us uvm_pkg::uvm_test_done.drop_objection(uvm_pkg::uvm _top); /uwe

hi, why not simply: // raise somewhere uvm_pkg::uvm_test_done.raise_objection(uvm_pkg::uvm_top); // drop somewhere uvm_pkg::uvm_test_done.drop_objection(uvm_pkg::uvm_top);

hi, the 1us in the example do not need to be there (its just an example to reach consensus after 1us). > I can't predict how long the simulation is needed thats when you need objections > It doesn't work very well what does that mean? what behaviour do you see? for me this looks good. /uwe

hi, >It still doesn't make sense to me that the uvm_heartbeat is not something that can be derived from and replaced with the factory. one of the topic for upcoming uvm releases is to make the uvm library itself more factory aware so that you can override objects used within the library /uwe

hi, >Is it recommended/replaced/deprecated? as said before: the Cadence register generator is avail upon request. It is not yet shipped as part of the standard install (that might change with newer versions). At the time of the register discussion the Accellera committee determined that generators are not part of the standard and therefore the path from an alternative description such as ipxact is outside of the UVM work scope. Therefore, the Cadence register generator is recommend for use by Cadence customers and does support both the Accellera standard UVM_REG and legacy Cadence UVM_RGM users. >We are doing IP-XACT and uvm_reg right now that is fine. the generator is handling ipxact-1.4,1.5 regrads /uwe

hi, the phase tasks should be ONLY activated by the phaser (and not by any other object). there has been some discussion in the tsc to have the phase executing the extract,check,report phases upon errors which today simply end the simulation. BTW: you can do that today without hacking the uvm core code: 1. make a report catcher and catch HBFAIL 2. upon a fail print object.display_objections() 3. force a jump in the phaser for all domains to extract() /uwe

hi, couple of things - the original post is quite some old post, slightly mixing old and new style phasing/phase progression. - the uvm_test_done objection is basically the objection to end the run phase. (using the uvm_test_done objection is the ovm/uvm10ea style while objecting the appropriate phase is the current way) - 9200sec usually indicates that the run didnt end with consensus to stop earlier. that means that most likely there is an objection pending. - looking at the uvm example i see task run_phase(uvm_phase phase); phase.raise_objection(this); uvm_top.print_topology(); #1us; phase.drop_objection(this); endtask so a wait of 1usec then a drop and the simulation should stop - and thats what i see: UVM_INFO ../../../src/base/uvm_objection.svh(1120) @ 1000 ns: reporter [TEST_DONE] 'run' phase is ready to proceed to the 'extract' phase BTW: no matter what you do, how you encapsulate it and optimize it with a companion object like erling suggests the main thing is that at least ONE needs to object an end of phase to keep your simulation running. if NO objection is pending the phase progression goes forward and finally ends simulation via extract, report,check

hi, i assume that this is due to the "starting_phase" guard typically shown. if(starting_phase!=null) phase.drop_objection(this); //or raise objection if you do start() a sequence the starting_phase is NULL while when started via the default_sequence it is set. that means if you start() the sequence NO objections are raised/dropped. regards /uwe

hi, >A root sequence is always started from some task phase, and that phase could easily protect the root sequence, and then sequences wouldn't need to know anything about phases, and could therefore have an >invariant that is easier to understand. this is wrong. you can start a root sequence in any context at any time (you can do that from a non-uvm module, you can start a root sequence without knowing (or referencing a phase), virtual sequences actually dont need a context/sequencer to run). >However, a major problem with objections is the atypical case where you want to disable task progress temporarily outside the root sequence. This can't work in a reasonable way with objections. strange, either its a "major issue" OR an "atypical" use case. it cant be both at the same time >phase.lock(this, "for some reason"); frankly, where is this different to "phase.raise_objection(this)" ? >It is even allowed and necessary to peek into the phase to use the objection directly, otherwise it wouldn't be possible to prolong the test, etc. i dont understand what you mean you talk directly to the objection in the phase object you are getting. i mean if you you want the objection api exposed in the phase and hide the inner objection - fine. >My conclusion for now is that uvm does not have proper phase/test end support. This has simply been left as an exercise for the user. i disagree with that statement. - end of test works fine given you do use the provided objection capabilities. so far placing them in the root sequence has been sufficient. extending that model to a per transaction objection interaction is something which has to be evaluated. - phases support: as i wrote earlier the phases itself are ok however what seems very unclear to alot of people is howto interact with the phasing. that needs cleanup. and again if you want to directly influence the directions and wnat to give feedback it would be great to join the viptsc /phasing subcommittee where these questions are discussed on a weekly schedule. regards /uwe

here are the relevant files from the uvm development: http://uvm.git.sourceforge.net/git/gitweb.cgi?p=uvm/uvm;a=tree;f=natural_docs;h=a65b4f15c43bea9c4f438b324c6d3b2eada71545;hb=refs/heads/UVM_1_1_BUGFIX http://uvm.git.sourceforge.net/git/gitweb.cgi?p=uvm/uvm;a=tree;f=uvm_ref;h=1ffd83fcb1bf3383e47065507e880b86493c233a;hb=refs/heads/UVM_1_1_BUGFIX /uwe

this has nothing todo with uvm. it is what the sv-lrm says - simulators "may" do that: " ... At any time while evaluating a behavioral statement, the simulator may suspend execution and place the partially completed event as a pending active event on the event queue. The effect of this is to allow the interleaving of process execution. ... " it basically means that there is no guarantee in a sequential/behavioural code section that (line+1) is executed right after (line). the simulator may at anytime start executing some other code. think of it like a multi-threaded program. while one cpu is working on one block another one may execute a completely different block in parallel(at the same time).

hi, uvm uses naturalDocs. apart from naturaldocs your can doxygen (http://intelligentdv.com/downloads/index.html#doxygentools) or DVT(http://www.dvteclipse.com/ which can do javadoc, naturaldocs etc) /uwe

hi, there are two sides to this: 1. the analysis port exposes a write "function". that in itself is a strong guarantee that a call to write() will return without ANY delay. 2. there is NO guarantee (due to the preemptive nature of verilog) that ONLY code in the call chain of that function is being executed. see http://www.uvmworld.org/forums/showthread.php?128-UVM-and-SystemVerilog-prosess-semantics&highlight=simulator for more details. /uwe