uwes

what commandline do you use? the simplest path to uvm is to use irun as follows: "irun -uvm <your-vlog-testfile>" (no dpi compile needed, one step invocation, ...) /uwe

hi, only sequences which you want to run entirely (they start AND end) should be protected using raise+drop. all others (slaves,background, reactive(interrupt)) should not raise objections. if you start a sequence as background you should make sure that it uses raise+drop and it has a chance to end (no forever) or you dont raise+drop and you can use forever (and they dont need to finish).

hi, >For further understanding of the way UVM works (as I'm a new adopter) why can't you drop the objection in the body of the sequence? Is this just a convention or it it not possible. you can at any time raise and drop an objection. basically raise+drop should encapsulate behaviour which should not be interrupted (through end of test or end of phase). so its perfectly legal to raise at any time (if you did not before the phase/test could have ended before) and its legal to drop at any time (but you have to be aware that with the drop the test/phase ends without the rest of your functionality running >I ask as I have set up a base sequence that does the raising and dropping of objection, the sequence that has the forever loop just extends this and only has a body. you put the raise+drop in the base sequence so you dont have to write that piece of code in a derived class. raise+drop should only be done for self-active sequences (and not for slaves, nor reactive sequences, nor background sequences) >I can see your code idea will still work, but for further understanding of UVM I wondered why I could just not drop the objection in the extended sequence body task. if you would drop in the body() you could not use your sequence as subsequence anymore (because it drops the objection in the subseq and therefore eventually ends the phase/test). you typically want raise+drop on the outermost level of code which should should complete entirely.

hi, it depends what you mean with "synchronize". - the monitor should work without the driver being present (in passive mode you just observe) - the driver and the monitor should always observe the very same interface - so all the driver can do is to utilize events from the monitor (since driver and monitor look at the same wires they should generate the same events - this is therefore a small shortcut) depending upon your infrastructure you can use a semaphore, an objection + all_dropped/wait_for*, or you could eventually use a normal fork/join. you could also instantiate 4 single threaded drivers which ensures to have at max 4 items running. or you fork 4 independent get_next_item+drive threads... /uwe

this sounds like as if you are having a base class handle pointing to a derived class. so even if the handle references a derived class object you can only access base class properties. in order to access the properties of the derived class you have to $cast the object to the derived type. btw it would be good if you show more of your code and the full error message if you want more help than guessing. /uwe

hi, if you do instantiate your sequence manually then starting_sequence is unset(=null). if you use the show pre_body with the guard (starting_phase!=null) then raise_objection() it will not work since no objection is raised. typically i use the config-db with default_sequence and starting_phase. /uwe

hi, why not just "objection-instance.clear()" /uwe

//------------------------------------------------------------------------------ // Copyright 2007-2011 Cadence Design Systems, Inc. // All Rights Reserved Worldwide // // Licensed under the Apache License, Version 2.0 (the // "License"); you may not use this file except in // compliance with the License. You may obtain a copy of // the License at // // http://www.apache.org/licenses/LICENSE-2.0 // // Unless required by applicable law or agreed to in // writing, software distributed under the License is // distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR // CONDITIONS OF ANY KIND, either express or implied. See // the License for the specific language governing // permissions and limitations under the License. //------------------------------------------------------------------------------ // author: uwes@cadence.com // run using: irun -uvm test252.sv module test252; import uvm_pkg::*; `include "uvm_macros.svh" class demote extends uvm_report_catcher; function void cdns_tcl_global_stop_request (); uvm_domain common; uvm_phase e; common = uvm_domain::get_common_domain(); e = common.find_by_name("extract"); uvm_domain::jump_all(e); endfunction function new(); super.new("demote"); endfunction virtual function action_e catch(); if (get_severity() == UVM_FATAL) cdns_tcl_global_stop_request(); return THROW; endfunction endclass class test extends uvm_test; `uvm_component_utils(test) function new(input string name, input uvm_component parent=null); super.new(name,parent); endfunction // new virtual function void report(); $display("still alive"); endfunction // report virtual task run_phase(uvm_phase phase); super.run_phase(phase); uvm_top.set_report_severity_action_hier(UVM_FATAL,UVM_DISPLAY|UVM_COUNT); `uvm_info("FOO","BLA",UVM_NONE) `uvm_warning("aWARNING","SUCH") `uvm_error("anERROR","ERROR") `uvm_fatal("aFATAL","a fatal") #20; endtask endclass initial begin demote d; d = new(); uvm_report_cb::add(null, d); run_test("test"); end endmodule

hi, the issue with this is that you have to implement the cb for all components which should do extract,report,etc manually. an alternative would be to do the FATAL without UVM_EXIT and cause a phase jump of all phases/domains to common:extract instead. /uwe

hi, the simple >task apb_test_1::dbg_eot(uvm_phase phase); >forever begin : fe >#100; >phase.phase_done.display_objections(); >end : fe >endtask : dbg_eot doesnt really help since "phase" might not be the active phase anymore. i did use the following solution which gives you all pending objections in all domains/phases (despite of the phase we are in) and the set of phases. /uwe 692 uvm_domain domains[string]; 693 uvm_phase phases[$]; 694 uvm_domain::get_domains(domains); 695 foreach (domains) begin 696 domains.m_get_transitive_children(phases); 697 phases=phases.find(item) with (item.get_phase_type()==UVM_PHASE_NODE && item.get_domain()==domains); 698 phases=cdns_array_utils#(uvm_phase)::unique_(phases); 699 700 foreach(phases[j]) begin 701 uvm_objection o; 702 o = phases[j].get_objection(); 703 if(!(doFilter==1 && o.get_objection_total()==0)) begin 704 $display($sformatf("objections to uvm_objection \"%s\"",o.get_full_name())); 705 o.display_objections(, 1); 706 end 707 end 708 end 709 end

basically you got the following: - running OVM/UVM in co-existence mode (no no dependencies, no direct interaction): this should work out of the box (but thats not what you want) - running OVM/UVM jointly: requires several things incl. phase synchronization - NOT really recommended - convert all OVM to UVM using the script - typically the fastest route - use a facade around uvm exposing it as ovm. kind of typedef uvm_void ovm_void; typedef uvm_root ovm_root; typedef uvm_factory ovm_factory; typedef uvm_object ovm_object; typedef uvm_transaction ovm_transaction; typedef uvm_component ovm_component; ... this CAN work but might get problematic if you are using or utilizing OVM specials. so yes there are some way to do that but as jade says typically its best and fastest to migrate. in addition to the other ways this path is known and quite some documentation exists. /uwe

i assume the tool is saying that this is not supported in the 10.20 release, right? you should try a more recent release such as 11.*,12.1,12.20,... as a side note you can view the type and/or instance based coverage using "iccr" or "imc" without the need of the direct coverage api/options. /uwe

please file a request with cadence support so this gets addressed

conceptually sequencers work all the time. they take data from all running sequences on demand and provide it to the driver (+arbitration,+randomization,...). what you want is to redirect your traffic to either seqr2 or seqr3 (and not switch on/off sequencers). you can do something like: if(signal) `uvm_do_on(sequencer2,....) else `uvm_do_on(sequencer3,...)

not sure what you mean with "control the scheduling of 2 seqeuncers"? do you want to control which path the data should go?, which is invoked in the simulation cycle first? ... from an high level perspective it sounds you want a virtual sequence and tell which sequencer should execute it, right?

did you try to stop the sequence using sequence.kill() before you kill the thread with "disable fork" ?

the error is because you indicated to send an item, you got granted but failed to deliver the item without a delay. typical issues are: - a delay between grant and delivery of an item (this can only happen if you utilize the "fine grained" sequence control. for instance between start_item+finish_item) - your process asking for the grant has been terminated. as a result the terminated process cannot deliver the item anymore. this could be due to a process::kill,suspend; disable fork, the end of a phase (terminating the process),... /uwe

you can have the local/protected modifier for new. i think this was not in the original ieee1800-2005 lrm but its in the -2009 release. as far as i know all of questa,vcs,ius support this.

hi, one issue here between the lines is that the execution order of static initializers is NOT defined in the LRM as far as i know. so it would be unclear what the result would be class singleton; int a=3; // 3 for sure int c=a+1; // could be 1 or 4 endclass another issue with the singleton code the way its written is that the singleton is unconditionally allocated and not just on demand. typically the singletons look like module top; class singleton; static local singleton me; local function new (); endfunction static function singleton get(); if(me==null) me=new(); return me; endfunction endclass: singleton initial singleton::get(); initial singleton::get(); endmodule: top

this sounds like http://eda.org/svdb/view.php?id=4322. you may want to check if the mantis_4322 branch resolves that

can your sequencer handle b_seq#(12) sequences? it sounds to me as if you did not fully supply the parameter in all the places. my assumption would be that you have somewhere an assignment of a b_seq#(0) to a b_seq#(12). i would check for places where b_seq is used without parameter.

did you miss the `uvm_object_param_utils(b_seq#(address)) ? not sure since essential parts of the code are missing and the error msg is incomplete

hi, you dont need to compile the dpi code yourself when using "irun -uvmhome ...". irun is taking care of that for you. if you really want that for whatever reason just add the uvm_dpi.cc file to the commandline. if you dont want irun doing all handling for you you can try something like: irun -uvmhome $UVMHOME -uvmnoautocompile $UVMHOME/src/uvm_pkg.sv $UVMHOME/src/dpi/uvm_dpi.cc test.sv /uwe

hi, some other/more options: 1. add a random_delay to your low level transaction and have the driver make the gap before/after a transaction. (your reg model doesnt see the gap) 2. create an extension container holding a random_delay field. pass the container during read/write/update/etc in the extension arg. translate in the adapter to a low level gap (either as part of the low level transaction (see#1) or cause a GAP-transaction on the low level sequencer/driver, or invoke a custom gap() member in the driver....) 3. have the adapter inserting random gaps before/after transactions 4. have a parallel sequence running the low level driver just doing gap-transactions. this will randomly mix the gap (transactions) with all other traffic. 5. throttle the low level driver by only getting a real transaction after a certain gap (basically have the low level driver doing+injecting the gaps) 6. i guess there are more options the path depends what you need in terms of controllability, reuse and simplicity. regards /uwe

yes, its kind of a chicken-and-egg problem. with the macros we do decisions very early to improve performance. this however may conflict with the late changes to the message properties. /uwe