uwes

hi, just guessing that the set_config*(logical_path,field,value) does not apply to the logical path of your scoreboard. you somehow also indicate that because you say that the set_config works on driver+monitor. try one of following: - set_config_int("*","initial_id",20'hffff0) - set_config_int(<path.to.scoreboard>.get_full_name(),"initial_id",20'hffff0) - set_config_int("*.scoreboard","initial_id",20'hffff0) regards /uwe

SIGSEGV is a compiler or simulator internal error. you should contact your simulator vendor to resolve it. a SIGSEGV is nothing you can achieve with pure SV.

its much better to use the type based factory api instead of the string based one (you get compile time checking for instance) sometype somefield; somefield = sometype::type_id::create("somelogicalname");

hi, it is pretty hard to give you a meaningful answer just by seeing this error msg. but i'm just guessing - - check your arguments to your port/export/imp ports especially ordering, number and what they are types/param types/instance names - check the other messages potentially pointing to the offending line in the source code - check that the imp is correctly declared+instantiated class X extends uvm_component; uvm_blocking_put_imp #(TLMTYPE, X) in=new("name",this); task put (TLMTYPE p); ... endtask endclass

hi, sequencers are controlled by their downstream drivers. so you have to have a "whatever driver" which is pulling sequence items from the sequence. you can use something like the attached standalone sequencer // test: irun -uvmhome ~/src/uvm/distrib ies-tests/test42.sv ~/src/uvm/distrib/src/dpi/uvm_dpi.cc module test42; import uvm_pkg::*; `include "uvm_macros.svh" class a_tr extends uvm_sequence_item; `uvm_object_utils(a_tr) function new(string name = "a_tr"); super.new(name); endfunction : new endclass class uvm_nodriver_sequencer#(type A=uvm_sequence_item,type B=A) extends uvm_push_sequencer#(A,; class dummy_push_driver extends uvm_push_driver#(A,; `uvm_component_utils(dummy_push_driver) function new (string name = "dummy_push_driver", uvm_component parent = null); super.new(name, parent); endfunction : new virtual task put(A item); endtask endclass local dummy_push_driver _driver= new("dummy_push_driver",this); `uvm_sequencer_param_utils(uvm_nodriver_sequencer#(A,) virtual function void connect(); super.connect(); req_port.connect(_driver.req_export); endfunction function new (string name = "uvm_nodriver_sequencer", uvm_component parent = null); super.new(name, parent); `uvm_update_sequence_lib_and_item(A) endfunction : new virtual function void build(); super.build(); _driver.build(); endfunction function void start_of_simulation(); print(); endfunction endclass class a_seq extends uvm_sequence#(a_tr); `uvm_sequence_utils(a_seq, uvm_nodriver_sequencer#(a_tr)) function new(string name = "a_seq"); super.new(name); endfunction : new virtual task body(); `uvm_info("test42","here we go",UVM_NONE) `uvm_do(req) `uvm_info("test42","here we go",UVM_NONE) endtask endclass uvm_nodriver_sequencer#(a_tr) my_sqr = new("sequencer",null); initial begin set_config_string("*", "default_sequence", "a_seq"); run_test(); end endmodule

hi, actually there has been a param macro for sequnces in ovm (the comments still show this). however this macro has been removed as there are some conceptual problems around param-sequnces+factory. the *utils* macro does the factory registration among other things. the root problem is that the string based api of the factory cannot handle param types. param types can only be used with the type based api (::type_id::create....). some of the builtin sequences assume the string based api and so the param sequences do not work for them. so as long as you only use the type-based-factory api you are fine and you can use the existing field macros if you really require string based factory requests you can wrap the param sequence into an unparam container. class a_seq #(int P=5) extends uvm_sequence; `uvm_sequence_utils(a_seq#(P), a_sqr) function new(string name = "a_sqr"); super.new(name); endfunction : new virtual task body(); // somebody endtask endclass class b_seq extends uvm_sequence; `uvm_sequence_utils(b_seq, a_sqr) function new(string name = "b_sqr"); super.new(name); endfunction : new virtual task body(); // you will see a warning about a type being defined twice // because a_seq#(5) and a_seq#(10) have their static init performed (and register with the factory a_seq#(10) foo; // now get a param seq from the factory foo=a_seq#(10)::type_id::create("seq"); endtask endclass // nothing but a un-param wrapper class c_seq extends a_seq#(20); `uvm_sequence_utils(c_seq, a_sqr) function new(string name = "c_sqr"); super.new(name); endfunction : new endclass btw if you print the factory contents you will see that the a_seq got registered in the factory with the "a_seq#(P)" string - the literal first argument to the utils macro.

.... in addition to the search time - the OVM (and later the UVM) versions under ..../tools/ will be actively bugfixed - if you use "-uvm" it will enable a couple of improvements in handling UVM such as (tcl command support, library precompile, simvision addons/filters etc) regards /uwe

hi, to explain this is a long story :-) anyway... if your testbench methodology relies upon random stimulus it also has to rely on "random stability". this means that calls to randomize/srandom/random will yield the same stream of data as long as possible. SV itself does a bad job in preserving the random stability so its likely that changing your tb infrastructure in a minimal sense can change the overall behaviour. you can imagine that this is a killer for any application (think of adding a monitor to your testbench does change the whole scenario). so uvm+ovm in its core have an algorithm which assigns a seed to any uvm_object computed from a type+logical path+a counter. by doing that each object delivers the same stream of random vales as long possible - adding/removing topology should not have any influence anymore. so by default you should stick to the use_uvm_seeding which enables this builtin random stability.

hi, i forgot to mention: if you run IUS with irun using UVM is simply "irun -uvm ...rest..of..files..and.options". the UVM version inside `ncroot`/tools/uvm should be already enabled for transaction viewing etc regards /uwe

hi, this package has not been posted to uvm world. normally (this was the case with ovm) cadence did supply this as part of the embedded ovm distribution. no addon work was necessary to transactions in simvision. the easiest way to get the package is to contact cadence support or your local ae. regards /uwe

hi, there is a replacement of OVM_UVM_Rename.pl with ovm2uvm.pl in the more recent uvm codebase. this script will handle some API changes of the ovm to uvm migration in addition to the o-to-u changes the original script did. the current version as of today can be downloaded from the git repo here http://uvm.git.sourceforge.net/git/gitweb.cgi?p=uvm/uvm;a=blob_plain;f=distrib/bin/ovm2uvm.pl;hb=788f159 regards /uwe

hi desperado, >As an engineer, I am pretty curious on what's happen even behind the screen and so does was my question on this forum. Can you elaborate to my questions plz. as i said this is implementation/tool specific and every tool does have an own (correct) implementation. also the terms "stack"/"heap" memory are not clear in the context - i mean there is a stack for the machine code you are executing and there is a (user) stack of your sv program - this might be somewhere else (for instance in the heap memory). but again this depends on your simulator and code architecture. so there is not concrete answer to your question. btw: functions and tasks are normally code or data sections (as they do not change during runtime, creating another object doesnt double the code streams). so its neither on the stack nor in the memory pool. i dont think "recursive" or "re-entrant" does make a change here. regards /uwe

hi, the IEEE1800-2009 ch 6.21 "scope and lifetime" has some information about this topic. however the standard doesnt talk about heap/stack because this distinction is secondary. the storage elements have to follow a clear "lifetime" semantic. depending upon their lifetime objects can be allocated on the stack or on the heap. for instance you could even allocate objects on the stack but you would need to move them to the heap if the reference to the object is used outside of the stackframe. is there a particular reason for your question? why do you care? i mean as long as the semantic is preserved any implementation is correct. regards /uwe

hi worma, you can build something along the lines of uvm_random_sequence. basically you can 1. create a sequence (uvm_constraint_seq having a member "string valid_seqs[]" ) 2. add the valid_seqs member 3. translate all valid_seq strings into their seq_kind using get_seq_kind() (you should now have a list of valid sequence idx) 4. pick an element from that list 5. exec that sequence (do_sequence_kind(idx)) from your user-seq you can now say 'ovm_do_with(subseq,{valid_seqs=["my1_seq","my_two_seq"}) regards /uwe

hi, the best way to make your voice heard is to join the VIPTSC working group http://www.accellera.org/activities/vip and also file bugs reports or change requests in the mantis database http://www.eda.org/svdb/main_page.php. The mantis items will be reviewed on a regular basis by the commitee an then approved/rejected/etc for inclusion. regards /uwe

hi, the register model for UVM is intented to be included in UVM-1.0. there is no released/approved version of this yet - only the UVM developer repository contains a "work-in-progress" version. regards /uwe

hi sean, this is a typical sv problem with 1800-2005. the resolution of variables within constraints is inner scope first then outer scope. this means that if a member is found within the object to generate this field is referenced. this means that "abc" is actually the same as "this.abc" which is equivalent to "callee.abc". so using "this." doesnt make sense. in total you got three solutions: #1 you rename the field #2 you can use ieee1800-2009 syntax if that is supported using the "local::" retval = inner.randomize() with { local::value == value;}; #3 you may use the class scope operator retval = inner.randomize() with { outer_c::value == value;}; for your example it would mean: #1 `uvm_do_with ( callee, { abc == abc_temp} ) #2 `uvm_do_with ( callee, { abc == local::abc} ) #3 `uvm_do_with ( callee, { abc == caller::abc} ) PS: actually the 1800-2009 LRM 18.7 states: >Names qualified by "this" or "super" shall bind to the class of the object handle used in the call to the randomize() with method. this means that retval = inner.randomize() with { this.value == value;} retval = inner.randomize() with { super.value == value;} should work in as you expected earlier. so it is a semantic difference between the -2005 and -2009 LRM what you will will see as the result. regards /uwe

hi, the embedded documentation shows the following usage model: //----------------------------------------------------------------------------- // MACRO: `uvm_set_super_type // // Defines the super type of T to be ST. This allows for derived class // objects to inherit typewide callbacks that are registered with the base // class. // // The registration will typically occur in the component that executes the // given type of callback. For instance: // //| virtual class mycb extend uvm_callback; //| virtual function void doit(); //| endclass //| //| class my_comp extends uvm_component; //| `uvm_register_cb(my_comp,mycb) //| ... //| task run; //| ... //| `uvm_do_callbacks(my_comp, mycb, doit()) //| endtask //| endclass //| //| class my_derived_comp extends my_comp; //| `uvm_set_super_type(my_derived_comp,my_comp) //| ... //| task run; //| ... //| `uvm_do_callbacks(my_comp, mycb, doit()) //| endtask //| endclass //----------------------------------------------------------------------------- a more in depth example can be found here: tests/09callbacks/20inherit/test.sv regards /uwe

hi worma, in UVM can have two styles to describe scenarios. the first style (a declarative style) would be similar to what you have shown in your code section. actually it is a set of constraints on an array of transactions. this set of transaction is usually randomized once and then send item-by-item. the second style in uvm is a sequence style which allows you step-wise generation. to illustrate that have a look at the pseudo-code examples below declarative style: class uvm1_seq extends uvm_sequence; // rest of uvm required decls rand transactions t[5]; constraint legal { // your constraints on transaction here } virtual task body(); foreach(transactions[idx]) // now send the transaction or generate sequence items using the transactions // for instance `uvm_do_with(op,{type==transaction[idx].type} endtask or with the second style: class uvmm2_seq extends uvm_sequence; // rest of required decls rand int unsigned scenario_length; rand int addr; rand int length virtual task body(); repeat (scenario_length) begin `uvm_do_with(op,{type inside {my_transaction::MEM_WR_32,my_transaction::MEM_WR_64}; length==uvmm2_seq::length;...}) // now you can look at op to see what has been sent ( or you can peek into the "transaction store" of the last send transactions last_type=op.type; `uvm_do_with(op,{last_type==M32 -> type==R32; length==uvmm2_seq::length;...}) ` end

hi sean, uvmrgm is known to run on all three major ieee1800 simulators without any code changes. the only non-sv thing is that the backdoor access requires DPI (and VHPI in case VHDL is in the picture) (you have to include the dpi/*.c file which implements uvm_rgm_[set_hdl/release_hdl/get_hdl/backdoor_wait]). if you do not require backdoor access you can simply turn it off by "-define UVM_RGM_NO_BACKDOOR_DPI". the header files required to compile the c file should be part of your simulator. >2. Porting VMM to UVM and make it executable with irun: any advice? well porting the vmm library to uvm does not really make sense to me. if you really want to keep your legacy code you might want to consider the uvm-vmm interoperability library. porting the non-uvm variant of ral to ius is a non-trivial task as it also requires to fix the contents of the ral library in case its incompliant sv code or IUS does not support yet. 3. the roadmap... the plan of record right now is the following: 1. requirement collection/clarification has been completed 2. voting has completed on the requirements on "what has a high prio to be in uvm-10", "what is optional for uvm1.0" 3. right now - register package vendors prepare a presentation/workshop of their package to the user community (see http://www.accellera.org/apps/org/workgroup/vip/event.php?event_id=2814) - user/companies might review all proposed solutions to see if they meet their requirements 4. mid of sept2010 there will be an acellera face2face meeting where all proposals will be presented in depth with a followup voting on which package should be the starting point. right now it is upto the accellera members to investigate if the proposed packages meets their requirements in terms of features, use models and scalability. regards /uwe

hi, there is no direct API in UVM for doing this. however you can use alternate facilities to address your primary concern. as far as i understand your primary concern is that you want to be "notified" if there is no progress with your simulation. to do that with UVM you might want to look at heartbeat feature of the objection subset. The heartbeat feature requires to send a notification to the heartbeat object within a defined time window. if the trigger is missing a simulation stop is being generated. so to some extend its not showing the progress - its rather a safeguard to prevent the simualtion from stalling. attached is an example of that (this example is part of the uvm developer source kit, see uvm-10ea/tests/02objections/91heartbeat/*) regards /uwe module test; import uvm_pkg::*; `include "uvm_macros.svh" class my_catcher extends uvm_report_catcher; int id_cnt; int client_cnt[uvm_report_object]; uvm_component c; virtual function action_e catch(); if(get_id()!="HBFAIL") return THROW; $display("MSG: %s", get_message()); id_cnt++; if(!client_cnt.exists(get_client())) client_cnt[get_client()] = 0; client_cnt[get_client()]++; return CAUGHT; endfunction endclass uvm_objection myobj = new("myobj"); class mycomp extends uvm_component; time del; function new(string name, uvm_component parent); super.new(name,parent); endfunction task run; repeat(10) #del myobj.raise_objection(this); endtask endclass class myagent extends uvm_component; mycomp mc1, mc2; function new(string name, uvm_component parent); super.new(name,parent); mc1 = new("mc1", this); mc2 = new("mc2", this); mc1.del = 45; mc2.del = 55; endfunction endclass class myenv extends uvm_component; uvm_heartbeat hb; myagent agent; function new(string name, uvm_component parent); super.new(name,parent); agent = new("agent", this); hb = new("myhb", this, myobj); hb.add(agent.mc1); hb.add(agent.mc2); endfunction task run; uvm_event e = new("e"); hb.start(e); fork repeat(11) #60 e.trigger(); #550 hb.remove(agent.mc1); join uvm_top.stop_request(); endtask endclass class test extends uvm_test; myenv env; my_catcher mc; `uvm_component_utils(test) function new(string name, uvm_component parent); super.new(name,parent); env = new("env", this); mc = new; uvm_report_cb::add(null,mc); endfunction function void report; uvm_report_object r; if(mc.id_cnt != 2) begin $display("** UVM TEST FAILED **"); return; end if(mc.client_cnt.num() != 1) begin $display("** UVM TEST FAILED **"); return; end r = env; if(mc.client_cnt[r] != 2) begin $display("** UVM TEST FAILED **"); return; end if($time != 660) begin $display("** UVM TEST FAILED **"); return; end $display("** UVM TEST PASSED **"); endfunction endclass initial run_test(); endmodule

hello, general phasing and custom phases have been a big point on the agenda in the last accellera face2face. there the companies agreed on the requirements and are now starting with the implementation and the implementation spec. here is some info about the new predefined phases http://www.accellera.org/apps/org/workgroup/vip/download.php/3304/latest/predefined_phases_reqs_working.xls and here are the captured requirements for phasing model: http://www.accellera.org/apps/org/workgroup/vip/download.php/3215/latest/phasing_reqs_working.xlsx regards /uwe

hi adi, picture uvc and bus uvc should be independent. the connection between the two is made via sequence layering (see the uvm reference guide on layering) - only this small piece of code should know howto "translate" a picture into bus transactions. >Am I wrong? dont think so. the attached is some code. it is creating a "special" bus sequence which pulls a picture from the higher layer sequence, translates it and sends the resulting bus transfers via the bus) class uvm_layered_sequence #(type SEQR=uvm_sequencer, type UREQ=uvm_sequence_item, type URSP=UREQ, type LREQ=uvm_sequence_item, type LRSP=LREQ) extends uvm_sequence #(LREQ,LRSP); protected SEQR upper_sequencer; function new(string name="uvm_layered_sequencer"); super.new(name); endfunction task pre_body(); uvm_object temp; uvm_sequencer_base s = get_sequencer(); if(!s.get_config_object("upper_layer_sequencer",temp,0)) uvm_report_fatal("LAYER", "no upper layer sequence pointer", UVM_FATAL); if(!$cast(upper_sequencer,temp) || (temp==null)) uvm_report_fatal("LAYER", $psprintf("incompatible upper layer sequencer or null is=%s",temp),UVM_FATAL); endtask endclass class uvc2touvc1_seq extends uvm_layered_sequence #(picture_sequencer,picture_trans,picture_trans,bus_trans); `uvm_sequence_utils(uvc2touvc1_seq,bus_sequencer) LREQ this_trans; // Constructor function new(string name="uvc2touvc1_seq"); super.new(name); endfunction // Sequence body virtual task body(); UREQ t; forever begin upper_sequencer.get_next_item(t); uvm_report_info("LAYER", "conversion of upper to lower (picture to bus_trans)", UVM_INFO); // FIXME translate picture into bus transfers //`uvm_do(this_trans) upper_sequencer.item_done(); end endtask endclass : uvc2touvc1_seq

hello adi, still it is not clear to me what you mean with "the data is already in the memory"? do you mean in a memory (like a memory instance in your design/tb) or you have it accessible in your class/tb)? is the tb driving it actively into the dut? or is the dut grabbing the data? normally i would generate&randomize the picture data in the picture_seqeunce_item class and then drive it into the dut. in this scenario no external memory is involved and the picture properties as well as the contents can be randomized in the sequnce via constraints. let me add some more clarifications: - i would separate the abstract picture handling from the dut/bus transaction handling. this would create sort of a picture_sequence_item class together with a picture sequencer (well thats actually just a 3line declaration). then i would create an uvc with driver,monitor, seqeunce_item and sequencer for the bus(or the communication protocol with the DUT). this uvc should be able to handle the complete IO of the dut but only in the sense of send or receive "something" it should not know anything about the picture. - a sequencer is sort of an "abstract" component and ONLY provides the feature of "producing" a stream of sequence_items. the items, their sequence and their properties are ONLY made by the sequence the sequencer is executing. i havent seen cases which requires addon behaviour being declared in a sequencer. - a driver takes an abstract sequence item (or transaction) and converts it into lower level transactions (= normally bit-wiggling). this is the place where one has to "interpret" the transaction and perform the appropriate actions on the lower abstraction level. - very often its best to separate abstraction level. here its best (or i would recommend) to separate "picture" and "bus". therefore i would have the following pieces: picture uvc: class picture_sequence_item extends uvm_sequence_item; class picture_sequencer extends uvm_sequencer#(picture_sequence_item); // there is no need for a driver+monitor as we do not map this into lower level transactions bus uvc: class bus_seqeunce_item extends uvm_sequence_item; class bus_seqeuncer extends uvm_sequencer#(bus_seqeunce_item ); // this probably has address,data, class bus_monitor extends uvm_component; class bus_driver extends uvm_driver#(bus_seqeunce_item ); the bus_driver implements get_next_item and always gets an bus_seqeunce_item. i think most of your questions relate to the fact that it is not clear (at least to me) what you mean with your "memory where the picture is stored". i would be great if you could clarify this (or make a small picture of it) btw: under normal conditions the pattern between sequencer-driver is fixed ("the-get-next-item-loop") as well as the pattern sequnce-item and sequncer. regards /uwe ps: feel free to contact me via private email under uwes@cadence.com

hi aapafi, from reading your post some areas are not completely clear to me, such as: - how does data get into memory? via a bus or via dual port memory or simply via (simulation) backdoor? - how does you dut send back the result of its operation? anyway i just make a few assumptions here and it should be simple to midify some of the requirements once you stick to "standard" structure. i would do the following: 1. create a picture class deriving from uvm_sequence_item holding the picture data as well as the high level properties YUV etc. make it child of uvm_sequence_item allows you to generate specific sequences of pictures easily. sequences of pictures are produced by the picture_sequencer. 2. create a bus driver (or backdoor memory) driver (a "full" uvc with io transaction, driver, sequencer, ...). this uvc should be able to drive transactions on either the bus or the backdoor or directly to the memory depending on your infrastructure. 3. layer #1 over #2, which allows you to store your picture in the memory using the custom driver of #2 (lets assume the dut stores the picture in some other memory area). the verification env would consist of a virtual sequncer which would run the following sequence. 1. randomize some picture properties (format/size/etc) 2. program the dut via bus uvc#2 3. write picture into memory using picture sequencer+bus uvc 4. start computation 5. wait for end of computation 6. read the dut results via the bus driver 7. compare the dut results with the expected results. (well this is just a short/initial suggestion, more details/constraints from your side may change the approach). if you got question about howto structure verification environments with system veriflog and uvm you may want to check out the uvm reference flow http://www.uvmworld.org/uvm-reference-flow.php which has several verification components and approaches captured into in documentation and code. regards /uwe