uwes

hi, the ::set operation sets the default sequence (the one which is automatically started) for a particular phase. so basically you "configure" during build_phase() that a particular sequence should automatically run in the "run_phase()". btw the build_phase() is not a run_time phase and would therefore not execute any sequences.

hi, ovm did support a dual "include" and "import" use model. uvm only supports the "import" use model and therefore the code has been restructured to reflect that. as part of that change there is now a single file which has to be compiled to get the "uvm_pkg". (btw: saying that also means that the "ovm" style of including ovm header files in required places will not work. you should remove all `include "ovm_*" from your code and replace it with "import uvm_pkg::*;" and optional "include uvm_macros.svh") /uwe

hi, the last tarball contains errata, fixes and similar things. btw there is a release-notes listing all resolved mantis items (this is the full list not the delta against 1.0) /uwe

hi, the -2005 semantics of program blocks were badly broken. the semantic had to be fixed for the -2009 ieee1800 standard release. unfortunately the specified -2005 and -2009 do differ in some cases potentially leading to simulation mismatches depending upon which language revision you choose. as a result of the -2005 program blocks issue it was the safe route in the past to encapsulate the whole environment in module-endmodule. these environments continue to perform with the same semantic in -2005 and -2009 and should not cause nasty surprises. also to note is that all the 3 vendors support the module semantic while the -2009 semantic may not be yet supported completely by all three. so again so far this was the safe route - once full support for -2009 is present you may use it. /uwe

hi, the project code itself is maintained as project on sourceforge for collaboration. looking at http://www.accellera.org/home you'll see that the standard itself got approved (http://www.accellera.org/activities/vip/UVM_Class_Reference_Manual_1.0.pdf). The release of the final tarball will happen in the next few days and users can download then from accellera.org, uvmworld.org or sourceforge.net. /uwe

hi, i would not use the function add_v_if you wrote. this function has bad side effects and the order of actual if's within the my_v_ifs depends on the calling order of your add_v_if function. and this calling order is undetermined (when called from different processes/initial/...)

hi, when downloading that tarball keep in mind that this is not the FINAL approved UVM_1.0 tar ball. while it has all source code the documentation needs to be updated (i think it still has the 10EA docs).

hi, ieee1800-2009 ch. 4.7 has the exact same statements: At any time while evaluating a procedural statement, the simulator may suspend execution and place the partially completed event as a pending event in the event region. The effect of this is to allow the interleaving of process execution, although the order of interleaved execution is nondeterministic and not under control of the user i'm not sure what you mean with "that it does not apply"? the whole point is that there is no "guarantee" that line+1 is executed after line in a sequential context even if the simulators most of the time stick to it.

hi, going from OVM to UVM should be not a big deal. saying that obviously means that this is true the closer you stayed to the OVM main functionality and didnt use internals/obsolete/private extensions to the core. there is a script to help you in that conversion which is part of the UVM release. it should take existing OVM code and get you to running UVM code (or pretty close). so far migrations i've seen took from 30sec upto 1day max.

hi, i think the main problem behind your question is: whats wrong with an array of interfaces? and why cant i access them via an index expression? basically the point is that an interface is an "static" entity similar to a module. when iterating over it it would be hard to ensure that the type (the structure of it) of each of the elements of that array are the same and the access to members is valid. (each of the if instances could be structural different based upon parameters, generates, if, etc). one way to handle it is to assign the if array to a virtual-if array. the virtual-if array can be used the normal way (because each element has a fixed structure). the attached code shows the non-working and the virtual interface way interface test55i; bit a; endinterface `define NUM 4 module test55; virtual test55i my_v_ifs[`NUM]; generate genvar l; for(l=0;l<`NUM;l++) begin: gen_l test55i myif(); initial my_v_ifs[l] = myif; end endgenerate `ifdef BAD_IF_ARRAY // this doesnt work because the cnt in gen_l[cnt] has to be a elab time CONSTANT // you could reference gen_l[2].myif.a // but not something like gen_l[<some non constant>].myif.a initial begin int cnt; for(cnt=0;cnt<`NUM;cnt++) gen_l[cnt].myif.a <= 1; end `endif `ifdef VIF_ARRAY function void set(virtual test55i some[`NUM]); foreach(some[idx]) some[idx].a <= '1; endfunction initial begin #1 set(my_v_ifs); end `endif endmodule

hi, the baseline scenario for objections (voting/consensus) is a barrier with N participating objects. apart from the "uvm_test_done" barrier with a result of "ending a simulation" you could have barriers to progress your test scenario from one phase (lets say config) to a new phase (lets say data-traffic), or you could use a custom objection to have traffic send as long as necessary - once all agree a particular device doesnt need to send traffic anymore you switch it off via all_objections_dropped regards /uwe

hi, >Is it correct to assume that SystemVerilog processes are scheduled cooperatively, i.e a conforming simulator excludes preemption and there is never more than one active process, even on a multi core system, and the active process runs until it executes an explicit blocking statement? this is incorrect. the VLOG2001LRM (which is used as base for SV) states in section 5.4.1 & 5.4.2 5.4.2 Nondeterminism ... 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. ... >One should think that SV semaphores was introduced to solve the same problems, but if there is never more than one active process in SV, then what service does a semaphore offer that a >plain int does not? even when not stated in the SV-LRM the semaphore needs some 'atomic' operation. if this would be not the case a semaphore could not check the lock and acquire the key without the possibility that another process is doing that exactly at the same time. with #1 (above) an vlog/sv-int solution would be hard to accomplish. /uwe

hi, regarding your questions: #1 raise& drop should be in pre+post body because those functions are ONLY called when the sequence is "started" (aka a root sequence). a subsequence doesnt call pre/post body and therefore doesnt work change the objection count. so as a rule of thumb you would have as much objections as you would have active root sequences. (reactive) sequences such as for slaves and background functionality do not need objections. #2 if your sequences are non-blocking you got some options: - first you could wait for the responses to appear after the final sequences have been send - second you could use a drain time to let your simulation complete after all objections have been dropped - you could also have the scoreboard, the monitor or driver raising objections to prevent your simulation to stop too early #3 driver+monitor could have objections too, i see no issue in that some "component" says "please do not stop now" #4 this is more work to add raise+drop to every sequence body it is simpler to do something like: virtual class uvm_active_sequence #(type A,type B=A) extends uvm_sequence#(A,; // ctor function pre_body(); uvm_test_done.raise_objection(...); endfunction functionpost_body(); uvm_test_done.drop_objection(); endfunction endclass and derive your active sequences (the onces with raise+drop) from uvm_active_sequence and the rest from uvm_sequence /uwe

hi, if you want to get started you can do so TODAY. what you get are the 99% developer sources (there might be some smaller implementation changes/bugfixes/tests pending). the current pdf's (user guide+ref manual) have not been added to the repo because they are being reviewed currently but you can generate the full API reference directly from the sources if needed. so feel free to get version "0.99" either via git clone git://uvm.git.sourceforge.net/gitroot/uvm/uvm or by using this link http://uvm.git.sourceforge.net/git/gitweb.cgi?p=uvm/uvm;a=snapshot;h=master;sf=tgz regards /uwe

hi, for own code you could do something like the code below. i think it would be better to have the set/get variants instead of the direct access. /uwe : program test50; import uvm_pkg::*; class my_queue#(type T=int) extends uvm_queue#(T); typedef T this_type[$]; function new(string name=""); super.new(name); endfunction function this_type get_view(); return queue; endfunction function void set_view(ref this_type r); this.queue = r; endfunction endclass initial begin int a[$]; static my_queue#(int) mq = new(); a.push_back(4); mq.set_view(a); a.push_back(5); assert (mq.size() == 1); mq.push_back(5); assert (mq.size() == 2); end endprogram

hi, the full UVM solution could be: 1. create a pin-wiggler verification component (makes the reset, potentially via a sequence...) 2. the two agents can use the new phases in UVM (block their reset_phase() until the reset is de-asserted), the normal behaviour would run in the phases following the reset_phase()... i think there are more solutions depending upon your actual project/size/scope regards /uwe

hi, the severity counts are per report_server. as every uvm_component is an uvm_report_object with (potentially) an own report_server it is upto the user to say from scope/sever the counts should be retrieved. this is the reason that you have get_report_server and get_severity_count separated. /uwe

uvm_component::build() takes care of that, so given your super.build() ends up calling the uvm_components build everything should be fine.

hi, the points you raise are outside of the scope of the UVM standard. The standard provides a defined set of sv base classes to model registers, memories, register fields, memory maps. they can be used in a testbench to simplify scenario creation or raise the abstraction level for easier checking/debug. saying that means also that the standard will NOT contain translation rules/references of other inputs formats such as ipxact files or generators to converts them into specialized SV classes. however there are commercial providers (duolog for instance) of tools which can generate from a single source all data and documentation you are asking for AND also generate the specialized sv code for your register to integrate with the register package of UVM. /uwe

choosing the simulator root seed is simulator specific and has nothing todo with methodology. however your commandline suggests that you do choose the seed outside of the simulator call. normally i would use "-seed random" which picks a seed value automatically so you can use the very same command to create different scenarios. ONLY in case of a failing simulation i take the seed value and supply it to "recreate" that particular failing scenario "-seed <somefailingseed>". it doesnt make sense to: - choose a particular seed. its impossible to know the scenario created by a seed in advance. (it only makes sense to recreate a scenario using a known seed IF the context has not changed) - to store/save seeds in order to create particular scenarios AND change the TB/design. The seed might not recreate the same scenario when parts of TB/ENV change. UVM tries to preserve the scenario as long as possible but there is no indication that a scenario is changing. normally you should create a cover point for the required scenario and monitor this as metric of completion. - carry seeds from one simulator to another. a particular seed generates different scenarios on each simulator (due to different constraint solvers etc) regards /uwe

hi, seems this Makefile is broken. the correct compile should be similarthe following command: gcc -shared -fPIC -DQUESTA -I $MTI_HOME/include -m32 src/dpi/uvm_dpi.cc -I $UVM_HOME/src/dpi -o libuvm_questa.so /uwe

if i remember right, the standards document is currently under review by the accellera member companies (btw the standard IS the documentation, the library is a reference implementation). this review has a 30days period which sort of makes the next decision point 2nd half of jan2011. from there on there are a couple of steps to release it which makes the mentioned feb16 a reasonable date. if you are keen to start and use it simply get a copy from the sourceforge revision control. however keep in mind that there might be minor changes to api's and some new functionality still needs to be verified. on the upside you know the standard before it is a standard. /uwe

hi, UVM10 as accellera standard is SV only. there are no plans to include other languages or interfaces to other languages from this point of view in 1.0. however interoperability is considered important and might be a focus in a newer release of the standard. Also cadence as supplier of SC/e/SV has obviously an interest to support the main languages under one methodology roof to allow seamless integration of models despite of the language they are written in. The released UVM10ML is an extension of UVM10 and allows interoperability of SV/SC/e. Have a look at this solution which is avail here in the downloads/contribution area. http://www.uvmworld.org/contributions-details.php?id=98&keywords=UVM_ML

hi, here we go you built the scoreboard component and LATER you try to apply the set_config().

well, if the first variant doesnt work (the most generic kind) the issue might be somewhere else. - logical name different than "scoreboard", (or the fieldname) - set-config after component has been built - not using the automation (not using super.* in the appropriate hooks) - maybe other issues