uwes

hi, just create an own uvm_report_server, override summarize() and hook it into th system. you may also hook into the final_phase() to produce last second messages.... /uwe

hi, why not to make a new sequence which does >"Seq1" --- <some delay> - "Seq2"----- <some_delay> - "Seq3"................................. as an alternative you may use the sequence library to create a "random" kind of sequence. /uwe

hi, a sequencer stops automatically if there are no items in the queue (no uvm_do* active). so there is no need to explicitly stop it. btw: your body is serial (there is no fork in the code you wrote) body() { repeat(2) begin uvm_do_on ( spi_seq, spi_sequencer) uvm_do_on ( cpu_seq, cpu_sequencer) end } /uwe

hi, the main point is that a sequence is expanded directly in zero time while an item goes through arbitration and that only if it is being pulled from the driver. /uwe

hi, i think the doc is correct: it sets the regmodel property of the subblock to the matching subblk of the register model. (your code would set the regmodel of the subblock to the same as the parent block) /uwe

hi, here is something i used to build reset aware components using some base classes with the current phasing. please note that there are some assumptions used, it requires latest UVM code from the UVM_1_1_BUGFIX branch, it also handles some issues/bugs/quirks in the current UVM,starts activities in the post_reset phase etc... - anyway here is the code: // assumptions: // reset jump to pre_reset // ALL jumps backward are considered similar to a reset virtual class reset_aware_component#(type C=uvm_component) extends C; local process driver_p; local uvm_phase last_ended_phase; // derived types should implement reset_phase and block phase progress upon reset // should assign reset signals // need to update driver_p virtual task span_phases(uvm_phase phase); endtask virtual function void phase_ended(uvm_phase phase); uvm_phase next_phase = phase.get_jump_target(); super.phase_ended(phase); // 1. kill the driver_p // 2. call cleanup_upon_phase_jump if(next_phase != null) begin `uvm_info("RESET", "BACKWARD JUMP - kill spawned-thread & cleanup via hook",UVM_MEDIUM) if(driver_p) driver_p.kill(); cleanup_upon_phase_jump(); // put "reg_model" property on a reset_aware_component will clean semaphore of regs begin uvm_reg_block b; uvm_reg r[$]; if(uvm_config_db#(uvm_reg_block)::get(this,"","reg_model",) begin `uvm_info("RESET",$sformatf("found reset aware register block %s, resetting handshakes",b.get_full_name()),UVM_NONE) b.get_registers(r); foreach(r[idx]) fork automatic uvm_reg i=r[idx]; begin $display("unlocking ",i.get_full_name()); i.XatomicX(0); end join_none end end end endfunction virtual function void phase_started(uvm_phase phase); super.phase_started(phase); if(phase.get_name() == "post_reset") begin fork begin driver_p = process::self(); span_phases(phase); end join_none end endfunction virtual function void cleanup_upon_phase_jump(); endfunction function new(input string name, input uvm_component parent); super.new(name,parent); endfunction endclass virtual class any_reset_watcher extends uvm_component; function new(input string name, input uvm_component parent); super.new(name,parent); endfunction pure virtual task wait_to_start_of_reset(); pure virtual task wait_to_end_of_reset(); virtual task reset_phase(uvm_phase phase); super.reset_phase(phase); `uvm_info(get_type_name(),"reset active, driving reset values ...",UVM_MEDIUM) phase.raise_objection(this); wait_to_end_of_reset(); `uvm_info(get_type_name(),"reset ended, could progress now ",UVM_MEDIUM) phase.drop_objection(this); endtask virtual task run_phase(uvm_phase phase); super.phase_started(phase); `uvm_warning("RESET-WATCHER", {"STARTING ",phase.get_full_name()}) // NOTE assumption is to go through an initial RESET // as also all phases progress through RESET forever begin wait_to_start_of_reset(); begin uvm_domain my_domain = get_domain(); uvm_phase p = my_domain.find_by_name("pre_reset"); my_domain.jump_all(p); end `uvm_warning("JUMP", "DOMAIN JUMP ANNOUNCED") end endtask endclass so the component sensitive to reset could be like this class amba_domain_reset_watcher extends any_reset_watcher; `uvm_component_utils(amba_domain_reset_watcher) virtual amba_bus_if.monitor_mp xi; function new(input string name, input uvm_component parent); super.new(name,parent); endfunction virtual function void connect_phase(uvm_phase phase); virtual amba_bus_if vif; super.connect_phase(phase); begin if(!uvm_config_db#(virtual amba_bus_if)::get(this,"","xi",vif)) `uvm_error("NOVIF","no vif found"); xi=vif; end endfunction virtual task wait_to_start_of_reset(); @(negedge xi.hresetn); endtask virtual task wait_to_end_of_reset(); @(posedge xi.hresetn); endtask endclass a driver could be like this: class amba_master_driver extends reset_aware_component#(uvm_driver#(amba_master_burst_c)); virtual task span_phases(uvm_phase phase); amba_master_burst_c this_item; forever begin `uvm_info("AHB","fetching next burst",UVM_HIGH) seq_item_port.get_next_item(this_item); have_handshake=1; this_item.set_initiator(this); //response.set_id_info(this_item); drive_burst(this_item); seq_item_port.item_done(); have_handshake=0; end endtask // NOTE manual cleanup of sequencer-driver handshake virtual function void cleanup_upon_phase_jump(); super.cleanup_upon_phase_jump(); if(have_handshake) seq_item_port.item_done(); have_handshake=0; endfunction virtual task reset_phase(uvm_phase phase); super.reset_phase(phase); xi.hbusreq <= 0; xi.htrans <= IDLE; endtask // rest of code endclass an agent could look like this (to stop the sequences upon a jump): class amba_master_agent extends reset_aware_component#(uvm_agent); virtual function void cleanup_upon_phase_jump(); if(is_active==1) sequencer.stop_sequences(); endfunction // rest of code endclass a monitor could look like this: class amba_master_monitor extends reset_aware_component; virtual task span_phases(uvm_phase phase); amba_master_burst_c the_burst; amba_master_transfer_c the_beat; int unsigned beats_to_go; bit the_burst_has_ended; forever begin // granted @(xi.monitor_cb iff xi.monitor_cb.hready && xi.monitor_cb.hgrant); fork begin // end of addr phase @(xi.monitor_cb iff xi.monitor_cb.hready); monitor_addr_phase(the_burst,beats_to_go,$time); // checkif the burst has ended if(the_burst.burst_kind!=INCR) the_burst_has_ended = (beats_to_go==0); else the_burst_has_ended = 0; if(xi.monitor_cb.htrans inside {SEQ,NONSEQ}) monitor_data_phase(the_burst,the_burst.direction,the_burst.data[the_burst.data.size()-1],the_burst_has_ended); else @(xi.monitor_cb iff xi.monitor_cb.hready); end join_none end endtask // monitor // rest of code endclass

hi, there is a pending mantis http://eda.org/svdb/view.php?id=3741. this highlights an issue that one cannot set the default sequence from via a string (and therefore from the cmdline) together with the new phase hooks. to make it clear: - "set_config_string(<inst>,”default_sequence”,<seq>)" is not deprecated at all. neither set_config_string nor the string way. - what is deprecated is to setting the default_sequence WITHOUT specifiying the phase (that means the path without the ".xyz_phase" postfix) - setting the default sequence via the type or seq-instance has benefits (type safety, param types) but in some areas the string is legit, valid and the best way to go. /uwe

hi, >Is there a recommended IUS version and UVM version for this basic usage? We use IUS 10.20* and I believe UVM 1.1 (BTW, is there a get_uvm_version API as in VMM?) i would always recommend "latest" IUS which comes with latest released UVM and contains fixes to already known issues. there is no "get_uvm_version" althrough there are some defines in src/macros/uvm_version_defines.svh if required. there are examples in the examples directory of uvm. >My simple use model is to allow reset, config-dut, then run and finally check/cleanup - as said everything is fine APART from a right reset support. that is currently a hot topic how that should be modelled. i need to check if my reset_aware_component and reset_watcher classes are upto date to post. /uwe

hi, >wat is the significance of p_sequencer and m_sequencer? ANY class member prefixed with "m_" is considered a UVM private field/function/task and should be considered as implementation detail and is therefore subject to change without notice. /uwe

hi, 1. if you raise/drop in pre/post body you dont need another raise/drop in the body itself 2. a single standing objection is good enough to stop the phasing from progression 3. you only need raise/drop on the _phase methods if you are not using method #1 4. you should NOT use uvm_test_done as objection to object to, use rather the starting_phase of the sequence in pre_body/post_body regarding #2 - the get_next_item doesnt call the body() method - the uvm_do,uvm_send macros/function basically put a sequence item into the queue and wait until it is completed with a handshake. - at get_next_item() the item is pulled out of the queue (and randomized), then it is delivered to the driver (the body method is blocked in the uvm_do call) - if the queue is empty get_next_item blocks - you must always complete the handshake (get_next_item -> item_done) otherwise you will get an error - you must not call body() yourself - this task is invoked by the sequencer - the uvm_do/uvm_send simply stall the body task until the lower level has completed /uwe

hi, i think that code portion is a fallback (a field is X but the status is kep at UVM_IS_OK). what should be done is to set the status in the reg_adapter::bus2reg() appropriatly to UVM_HAS_X.

hi, depends what you want to do with the phases? - you want the fully thing with domains, phases, phase jumps forward/backward, user defined phases mixed with other things such as sequences then probably it will be a bumpy ride. - you only want to subdivide you stimulus into slices then you are probably ok (althrough you could also use virtual sequences for this) basically you need to answer the questions: - when should an activity start - when should it end - can the activity be ended (killed) - can the activity stop a phase from progression - what happens upon exceptions such as reset regards 7uwe

hi, a few things: 1. you use the new phasing (_phase) BUT then you should object the end of the phase and not uvm_test_done. 2. your objection raise/drop should be in pre/post body only. you dont need the one in the body() 3. it is unclear how you set the default_sequence? as there are a couple of ways (and http://eda.org/svdb/view.php?id=3741) in the meantime you can increase verbosity, trace the phasing, trace the objections etc to see how your env is behaving.

hi, the UVM_TESTNAME is used very early when the root component starts to construct the hierarchy. UVM cant check if you did choose the right test it can only check if you supplied a testname which is available. /uwe

hi, in general it is a good idea to utilize the config_db BUT one needs to be prepared for a few things especially when mixing set/get_config and config_db#()::set/get 1. config_db is strongly typed - the set/get_config_int are loosely typed and mapped to uvm_bitstream_t. 2. the config_db can store any type structs/arrays/... (obviously only when supported by the simulator) so that means: - set/get_config_string and uvm_config_db#(string)::set/get are exchangable - for class types its simpler to use the config_db (but you need to make sure you are using the SAME type during set and get) - for arrays/assocs, structs etc its simpler to use the config_db - the *_int are usually handled easier with the get/set config. the reason for this is that an automatic mapping to uvm_bitstream_t is performed and therefore you dont need to know the exact type. for instance with the config_db you would need to say uvm-config_db#(bit[3:0])::set BUT then you always need the "bit[3:0]" to access the store - you cant simply say here is a int="5". please note that the strong typing has some implications on the capabilities you can use for auto configuration with the field macros. /uwe

hi, you need a few prerequisites: 1. use a uvm version shipped with IUS 2. enable transaction recording (via cmdline, sv-set_config_int or tcl) 3. (do not use 10.20s70,10.20s71 which are broken with respect to transaction recording) #1+#2 is for instance accomplished with irun -uvmhome `ncroot`/tools/uvm-1.1 +uvm_set_config_int="*",recording_detail,1 .... then you need to build the static hierarchy (run till start_of_simulation) or simply run some time. then pick your sequence fiber and put it into the waveform.

hi, i added http://eda.org/svdb/view.php?id=3739 for this and will add the fix to the 1.1a queue

ok, then add a mantis item with your use case so the tsc can look at that. /uwe

hi, type definitions are scoped. in that sense your examples declares the types bus_if#(16).vif_t and bus_if#(32).vif_t

hi, >What is the proper way to specify objection inside a sequence ? the typical way would be: virtual task pre_body; if (starting_phase != null) starting_phase.raise_objection(this, "Starting seq"); endtask: pre_body virtual task post_body; if (starting_phase != null) starting_phase.drop_objection(this, "stoping seq"); endtask but finally its upto the user to specify the time ranges which are protected from phase progression. >Do I need to add objection code in both regular sequences and virtual sequences ? you always need to raise an objection if you want the phasing system to wait until your behaviour is finished.this is the same for all like sequences, virtual sequences, initial blocks, running tasks, etc... >your code: - method1 will not really work with the new phasing (because its not objecting the end of a phase) - method2/post_body >if ((get_parent_sequence() == null) && (starting_phase != null)) it seems strange that you have a different expression in the drop which might lead to a different drop number than raise and therefore errors out. /uwe

hi, in general you only need a single/last objection per phase to stop the phasing system from progressing. so you dont need every sequence to object - only the usually (single) root sequence objects the phase progression. this at least is the standard case - you could have your sequences also more "phase aware" such as - starting a sequence in one phase BUT objecting the end of another phase - waking up a sequence at sometime BUT wanting all traffic to complete in the current phase there are more cases but here you have to be explicit in coding which phase end you want to object and uvm doesnt provide a framework for that yet. you have to communicate/derive your starting/ending phase via standard mechanisms (uvm_config_db, event_pool, tlm_ports).. /uwe

hi, the printout is "as expected". well, uvm currently relies upon the %p format to print the contents which not all simulators support fully. so for ius this means you do get an "?" printed. the the workaround would be to implement print policy classes but this seems quite some effort for what will be later a %p. /uwe

hi, i does work the way you started. most likely you just missed a paramterization somewhere. please post the definition of bss_uvc_frmbuf_env. did you register your param class using the *param* version of the macros? /uwe

hi, there are two things to know with sequence libraries: 1. yes, they came in late and not really tested so the decision was not to make it part of the standard in 1.0 (the standard is the refence manual!) 2. for the 1.1 release the viptsc didnt have enough feedback/testing to move it from beta into the standard. anyway, we do use sequence libraries and also recommend them to our customers. we havent seen major issues with that (only minor and reported+fixed) so i think they should be relatively safe to use. /uwe

hi, there is no "formal" thing for that. all mantis items are discussed in the weekly tsc call - and this is the place to raise your voice.