uwes

hi, if you do not know your starting_phase you do not know which phase ending you should be objecting to. keep in mind there is a set of active phases at any point of time (for instance run, post_reset but it could be more). so basically ONLY when someone calls your object and provides a pointer you know the correct phase. especially when time moves forward you have no real chance to identify your phase. due to the phasing graph there is nothing like get_current_phase().raise_objection(); on the other side starting_phase is only required if that sequence wants to object a phase ending - so typically only root sequences need it. /uwe

hi, btw: the code shown does NOT do what you think. in SV randomization and object allocation are separate (in contrast to specman/e). that means if you randomize an object such as when using uvm_do* sub objects are not automatically allocated by randomize. it is upto the user to allocate objects (as part of the constructor). now because allocation is user defined constraints on references/object handles itself are meaningless in SV. they can either be satisfied because the USER made the the references to be the same OR they make the randomization fail when the user doesnt handle the refs properly. you may use some other methods to pass in handles: 1. implement pre_randomize() or post_randomize() in the sequence to assign cfg 2. implement pre_body(), pre_do() or similar to retrieve references 3. use the config_db to pass references around 4. use explicit code in the body sequencer=get_sequencer(); sequencer.cfg ....; 5. split uvm_do into uvm_create, assign variables, then use uvm_rsend|uvm_send (make cfg a non-rand!) 6... regards /uwe

hi, >One thing that could help writing basic testbenches and also get started with uvm without having to jump directly into phase progress, objections and so, is to have uvm_test come with a different phase progress policy, >i.e it could come pre-configured for progress on return in all task phases. This is also dangerous because then the semantic of a sequence would depend where it is running. when running as phase sequence it would need to object to prevent killing, as "run" sequence it would not need to raise objections. if users now retarget a sequence from "run" to the phase their sequence would stop instantly .... i think the more exceptions we make, the more special cases we invent the harder it gets. there should be no semantic differences in facilities which could lead to confusion. i do think that objections/barriers or what else does the same job are the right thing to use in this case. i think it is reasonable to factor out the raise/drop into an uvm_objecting_sequence so users can use that one instead of the base version and they get everything the way you want. That way, it wouldn't need to raise anything to stay alive, and could still drop phase_done at any time to become killable if needed.

hi, >task run_phase(uvm_phase phase); >phase.progress_ok_for(this); // optional second parameter bit yes=1 >forever whatever(); >end this doesnt work because it ties a phase to an object. BUT what you really want is to tie a thread to a phase ending (sure you can call "phase.progress_ok_..(threadID)"). >- no need to understand nor use objections. >- regular phase bodies requires no encapsulation. again, any default we choose is probably wrong for some people. IF UVM would raise/drop the objections by default - THEN the question is for the others - "why the hell do i need to drop?, how many?, why do i need to drop before i eventually raise again?". i think it would be bad design to spread raise/drop between library/user code. all of that should be in one place. >- backgrounders allows abortive termination explicitly. just to be explicit: ANY phase can be aborted even with objections raised. this happens during a "jump". you cannot object a "jump" - you can only object the normal ending of a phase.

hi, there should be a "SEQLIB/EXEC" message emitted with UVM_FULL verbosity before the sequence is started

hi, here is a mantis item to track this request: http://eda.org/svdb/view.php?id=3887

hi, with UVM_FULL verbosity you should be getting quite some infos: UVM_INFO /home/uwes/src/uvm/distrib/src/seq/uvm_sequence_library.svh(688) @ 0: uvm_test_top.sequencer@@simple_seq_lib_RST [sEQLIB/START] Starting sequence library simple_seq_lib_RST in reset phase: 10 iterations in mode UVM_SEQ_LIB_RAND UVM_INFO /home/uwes/src/uvm/distrib/src/seq/uvm_sequence_library.svh(754) @ 10: uvm_test_top.sequencer@@simple_seq_lib_RST [sEQLIB/END] Ending sequence library in phase reset UVM_INFO /home/uwes/src/uvm/distrib/src/seq/uvm_sequence_library.svh(688) @ 10: uvm_test_top.sequencer@@simple_seq_lib_CFG [sEQLIB/START] Starting sequence library simple_seq_lib_CFG in configure phase: 10 iterations in mode UVM_SEQ_LIB_RANDC UVM_INFO /home/uwes/src/uvm/distrib/src/seq/uvm_sequence_library.svh(754) @ 20: uvm_test_top.sequencer@@simple_seq_lib_CFG [sEQLIB/END] Ending sequence library in phase configure you may also switch on transaction recording and see the sequences/hierarchy in the waveform /uwe

hi, >In the beginning, it was the expensive, complicated and broken drop propagation. Also, keeping track of the objection count is a manual procedure, i.e the user has to make sure that raise and drop calls are balanced. It seems the only reasonable way to do this >without corrupting the objection count goes something like this: i dont think objection are really hard to use here. you simply raise your objection and you drop it from some other place. really the ONLY rule is they have to be balanced and this is the case in most code. raise/drop simply encapsulate regions where you want to make sure noone ends without you agreeing to it. raising 3 and dropping 5 is a bad design to me. >But then it seems the raise and drop calls aren't actually needed, but have to be there because it has been decided that phases are to be terminated by default. raise and drops encapsulate the regions where you would like to have NO phase progression. btw phases end their threads may stop or not, they may be terminated or not. >Had phases been allowed to run to completion, then the phase done objection would not be needed. Or have I missed something obvious? if phases would run till completion, how would you then describe - behaviour spawning multiple phases? - how would you make the decision when to progress? - when all threads are done? how would you handle spawned background threads - what does happen to the spawned threads (are they killed? do they continue? (how do i specify that i agree with my threads ending without having ending them myself) the decision made during the design of uvm was to decouple the task/thread termination from the phase progression. only this separation enabled all the different use models and not just a particular one. saying that means that there are use models which would NOT require objections/phases etc but they are not the generic use models. /uwe

hi, 1. there is a "spellchecker" capability. the RSRCNF message is like this one: UVM_WARNING test.sv(48) @ 0: uvm_test_top.dad.child2 [RSRCNF] resource flag in scope uvm_test_top.dad.child2 not found uvm_test_top.dad.child2: flag = 0 mde not located did you mean mode? 2. in order to get the unused resources you may use the following: uvm_component:: // Function: check_config_usage // // Check all configuration settings in a components configuration table // to determine if the setting has been used, overridden or not used. // When ~recurse~ is 1 (default), configuration for this and all child // components are recursively checked. This function is automatically // called in the check phase, but can be manually called at any time. // // To get all configuration information prior to the run phase, do something // like this in your top object: //| function void start_of_simulation_phase(uvm_phase phase); //| check_config_usage(); //| endfunction here is a testcase: http://uvm.git.sourceforge.net/git/gitweb.cgi?p=uvm/uvm;a=blob_plain;f=tests/10resources/01simple/test.sv;hb=refs/heads/UVM_1_1_BUGFIX

hi, as adam said: if you stick to the run_phase and object to the end of run_phase instead of test_done objection everything works like before. the new phases provide you a !standardized! grid where you can hook your functionality in. this is especially useful if you integrate code/stimulus from different vendors/sites/origin. with fine granular phases comes that you need a mechanism to determine when its time to move on to the next phase (think you can have traffic crossing phase boundaries, sometimes you want all traffic to complete in a phase, sometimes you dont care about phase boundaries). the objections (sometimes also known as concensus) ARE a simple distributed mechanism to make that "can-i-move-forward" decision. trouble or issues should only occur in a few scenarios right now: - jumps - incorrect use of objections - phases terminating too early, sequences/phases not starting, phases never ending (Including simulation timeout) - bad assumptions on thread persistance over phase boundaries i agree that some behavior of the library is not obvious and may lead to unexpected behaviour. right now the phasing committee tries to work out the route going forward to address the problems. >I guess the frustration is in part due to my problems with objections, I always felt it was something wrong with them, and now when they have invaded the phasing, I suddenly had 47 of them when I already had more than enough with the uvm_test_done_objection alone. Oh well. can you explain what is so hard with objections? typically you dont have to talk to 47? usually you only see them in only in a base sequence making sure the sequence is completed within a phase. /uwe

hi, please note that even if you are not aware to use the new phasing its present and executing. it executes the old style run_phase as well as the other 12 fine granular runtime phases. in addition to that there are advanced concepts such as domains/schedules which are from uvm_phase derived objects. objections are being used for distributed control of phase progression so every phase does have a end_of_* objection. >Can anyone explain the rationale behind this, i.e what problem the new phasing is solving, perhaps with a simple example demonstrating how and why the new phasing is an improvement over ovm phasing. for the initial point of view not much has changed apart that you now have 12 fine granular runtime phases running in addition to the old ovm run_phase. however the phasing has been made extensible (can have own phases, schedules, domains) and there is the capability to jump forward/backward from/to phases. this has lots of implications and the phasing commitee is working to establish a methodology/recommendation howto use the phasing safely to accomplish things like reset-during-runtime. >Can anyone explain the rationale behind this, i.e what problem the new phasing is solving, the main problem phasing is addressing is "coordination of distributed components/stimulus; providing a known "grid" from the tb" regards /uwe

hi, im not aware of an issue in that area. the message basically says that you are trying to register a string type name for a class in the factory but a class with the same name has already registered that typename. here are some points you may want to check: 1. you will see this warning - if you declare a class with the same name in different scopes (same class name in different packages, different modules/classes ) - if you include the file with the class decl multiple times - if you use a param class and not use the _param_ version of the macros 2. you might cross check with the examples in the examples directory

hi, the uvmreg register model uses "bit" to store values. i think that is correct because as an abstract model it only deals with zeros+ones. in case you want to detect 'X,'Z you can do so by looking at the return code of the operation and check via UVM_HAS_X if the conversion of the bus operation to the register value involved 'X. if you want that check in general simply add it to your bus2reg adapter conversion function. /uwe

hi, the magic of this is that the set_config is a static function (your are calling it upon the type and not upon an instance). so with that you say sometype::function() which calls function without having an instance. so this code is a static function which in its body allocates a dynamic object using new. /uwe

hi, you might want to look at: - uvm_sequencer::set_arbitration() - uvm_sequence::set_priority() if you want to arbitrate between sequences. to "override" the arbitration you can use grab/lock (ungrab/unlock)

hi, UVM uses the SV native DPI to implement regexp and hdl access (via $pli). UVM doesnt expose a new interface for DPI its simply SV code therefore you use the normal DPI. /uwe

hi, maybe its too simple :-) uvm_do* does items and sequences ... /uwe class simple_seq_do extends uvm_sequence #(simple_item); function new(string name="simple_seq_do"); super.new(name); endfunction `uvm_object_utils(simple_seq_do) virtual task body(); `uvm_info(get_name(), $sformatf("In body() of %s", get_name()),1000) `uvm_do(req) endtask endclass : simple_seq_do class simple_seq_sub_seqs extends uvm_sequence #(simple_item); function new(string name="simple_seq_sub_seqs"); super.new(name); endfunction `uvm_object_utils(simple_seq_sub_seqs) simple_seq_do seq_do; virtual task body(); `uvm_info(get_name(), $sformatf("In body() of %s", get_name()),1000) #100; `uvm_do(seq_do) endtask endclass : simple_seq_sub_seqs EDIT: uvm_sequence_utils are deprecated - changed to uvm_object_utils

hi, all messaging is done through the context. this is either the component you are in OR via the global context which routes the msg to uvm_root. this means you simply have to pick a component and use uvm_report_enabled(). for a sequence you can use the get_sequencer() for a transaction you could choose anything applicable.if you dont know your real context you may use uvm_root. /uwe

hi, class env extends uvm_component; `uvm_component_utils(env) is correct. this is a typo. /uwe

hi, for instance: `uvm_info("KIND",$sformatf("object is %s", tx.sprint()), UVM_DEBUG); as alternative if more code is required (with some downsides): if (uvm_report_enabled(UVM_HIGH)) begin // end

hi, why not simply call uvm_report_fatal("SOMETHINGISWRONG","....."); you may also have a look at the uvm_heartbeat facility. this is connected to an objection and expects a raise|drop within a window. if no raise|drops occur in a window the heartbeat stops the run with a HBFAIL fatal msg. /uwe

hi, i think so far we only talked about howto accomplish things from the technical side - what I didnt hear so far is the use case or use model. depending upon this there might be other solutions other than fork/join, serialization etc. /uwe

hi, you can access the read-only repository using git. git checkout git://uvm.git.sourceforge.net/gitroot/uvm/uvm git checkout –t origin/UVM_1_1_BUGFIX any mantis_* and Mantis_* branches are fixes of the appropriate mantis issues. UVM_1_1_BUGFIX is the latest code leading to the next uvm version. /uwe

hi, uvm uses the same convention. m_* just tells you NOT to use it. the reason to have it public accessible is because sv doesnt have friend classes, doesnt allow get_sequencer().somefunction() and uvm_sequencer f=get_sequencer(); f.somefunction() ... is looooonnnnnngggggg p_* is always used as shortcut for parent_*, same arguments apply for the get_parent().xxxx() doesnt work. /uwe

hi, returning an exit code is a facility of the simulator (not UVM). it also depends what simulator commands are executed (usually tcl).