uwes

hi, i do not understand what your problem is - please explain. typically you convert the bit-wiggle on the dut output to transactions in a monitor. this monitor then broadcasts/delivers these transactions to all listeners via tlm_analysis_ports. the connection is made via .connect() calls between ports/exports/imps. the scoreboard itself provides at least two logical inputs (input+output of dut) and maps the two together. /uwe

correct a phase can start when ALL predecessors have completed (through dropping their objection). until the successor starts all predecessors continue to run (even with their objection gone to zero). dropping the objection just means "from my point of view, i could continue with the next phase". so the "easy way" you are asking for is the builtin way. - you should be using the runtime phases to start behaviour via the default_sequences hook only - its ok to do things via run and the runtime phases. but you have to be aware that there are some constraints. for instance if you really want to jump phases (backward) then only the runtime phases can be affected. you cant jump the run_phase. if you do jumps then threads in run and the other phases are separate. - the driver should drive independently of the phase (and potentially all the time if the protocol requires it).

hi, you should have a monitor looking at the output of your DUT and providing these transactions to the scoreboard. the scoreboard can then check if the transactions are correct. >Is there any workaround for the same?? for what problem specifically? /uwe

hi, hard to guess without seeing the full error message including line/column info (and seeing if this is a compile/runtime error). another strange thing is the the $system just to print something - hope you want to do more than that right?? /uwe

hi, cadence usually recommends to use the field macros in order to benefit from a short and concise description which for most users ends up in a faster development. the macros implement for you in a generic way common functionality you typically shouldnt really care about. The performance hit by using the macros heavily depends upon your application and should be weighted against the time to develop and keep pack/copy/compare/print upto date. keep in mind that this is not really an all or nothing decision - you can start with macros and then start optimizing if required. BTW1: the macros+implementation has been optimized in 2011 and some bottlenecks have been eliminated. BTW2: there is a simple rule in UVM: as a user you CALL "(pack|print|copy|compare|...)" and if you got own functionality you need then you implement this in "do_(pack|print|copy|...)". have a look into the UVM user guide and its examples for examples. regards /uwe

hi, i dont think there is an issue here . the only thing the msg is indicating is that someone inside your test is trying to read the config db property "recording_detail' but apparently this property has not been set on your top level test. the attached testcase produces the same msg: // irun -uvm +UVM_TESTNAME=test1 test143.sv +UVM_CONFIG_DB_TRACE module test143; import uvm_pkg::*; `include "uvm_macros.svh" class test1 extends uvm_test; `uvm_component_utils(test1) function new(string name, uvm_component parent); super.new(name, parent); endfunction function void start_of_simulation_phase(uvm_phase phase); bit foo; super.start_of_simulation_phase(phase); void'(uvm_config_db#(uvm_bitstream_t)::get(this,"","recording_detail",foo)); endfunction endclass initial run_test(); endmodule

hi arno, you are right that ius requires to add the libuvmpli for the old 3step mode for uvm11a onwards. you do not require it for irun or irun in 3 step mode. the reason is that uvm11a contains some temporary code which is implemented in this library. regards /uwe

hi arno, let me answer some of the points you raise >in my view the preferred way to use UVM is to download the release and compile it oneself : .sv and pli code. This way a user can play with it. first of all its your choice if you go with the version coming with ius or if you use the native accellera version. i'll give you later some reasoning to prefer the ius version and i also accept if one wants the pure accellera version - really your choice. in the example i gave (i should have been pointing out that this is only an invocation example). all the example points out is that to use ius with uvm all you have to do is "irun -uvmhome <your-uvm-distrib-location> <eventually +UVM_TESTNAME=xyz> ....". when using the uvm versions coming with ius uvmhome should point to `ncroot`/tools/uvm-1.1. all what is needed to compile ANY uvm distrib is the appropriate setting of -uvmhome - no compile of .cc code, no library compile, no addon incdir settings required - you only point to your distrib and i think that makes using any uvm version quite simple to use. >A while back one of the goals was to keep OVM SystemVerilog only. But all the pli calls introduced have prevented this. Too bad. there are a number of things in OVM/UVM which cannot be accomplished with native SV ( or only with big effort). some things to name: - regexps - hdl backdoors in registers >I think that the recommendation should be to use the release and compile it oneself : i sort of disagree that it makes sense to force anyone having them compiling c-code and the library - what IUS/irun provides is a direct frontend to develop uvm testbenches with the need to figure out compile/pli >That's what I do anyway, since I support several simulators and may need to play with the code of the release. fair enough, the uvm accellera code run (tested!) on all simulators (vcs,questa,ius). >I would like to see the makefiles supplied in the release examples, which are simulator specific, include the compilation of all the .sv and pli code of the current release only, and ONLY of the current release. It shouldn't rely on anything from the tools install directory. all examples are independent and are using the uvm release out of the distribution. for ius for instance you see -uvmhome ../../../src (or similar) which is pointing to the uvm code of the current tree. this doesnt use any UVM out of the install (and actually this would nt work if the version do not exactly match). if you do something different let me know. again: for ius all you need for compile,elab+run is "irun -uvmhome <your-uvm-dist-directory> ...." >Especially for Cadence where the compil/elab/run can be done with irun or in 3 steps with ncvlog/ncelab/ncsim. the UVM development uses exclusively irun as its frontend. we aim to provide to our users the fastest and safest route to run their simulation and this is the reason to use irun with its extensions for uvm. if you do require an old 3step approach using ncvlog/ncelab/ncsim we do have proper docs to show you what needs to be done in this case (you can also cheat and replace ncvlog with "irun -compile", ncelab with "irun -elaborate", .... and still use the irun extensions for uvm :-)). BTW: i just forgot to give you some reasoning WHY to prefer the version delivered with IUS over the native accellera version 1. the ius-version has been enhanced with support for - direct transaction recording into simvision - extensions in the simulator interface which allow you to perform uvm specific actions in the tcl commandline - multi language support to enable direct communication with sc and e - some more goodies (if you look in the install you will find them :-) (please note that all of these extensions do not change an API, you can still compile your testbench against the acellera-uvm or the cadence uvm without issues) 2. cadence provides bugfixes to uvm releases already in new simulator releases and this even before accellera cuts a new release. (well you obviously could checkout the mantis branch a fetch+overlay the fix yourself but i think its important that once an issue is known its fixed and distributed asap) hope this clarifies regards /uwe

hi, you could use a uvm_event to do that: 1. make an instance of the uvm_event somewhere , store it in the config-db under a known key 2. make the CONFIG sequence trigger the event (pull it from the config db via the known key and trigger it once you pass your now-we-can-have-reset point) 3. in the reset block also retrieve the event and simply wait upon the trigger (if you dont want to change your reset-block-sequences you may want to create a wrapper sequence waiting upon the event and then starting the real sequences. at the same time if you are able to identify the now-we-can-have-reset point in the monitor there would also be no need to change the config sequences.) regards /uwe

hi, the main way to run uvm+cadence tools should be "irun -uvmhome `ncroot`/tools/uvm ....". i assume the issue you bring up is because of two things: 1. a recent change which now requires -uvm or -uvmhome to be present (and not just +UVM_TESTNAME) for irun 2. you are running in 3step mode (ncvlog,ncelab,ncsim) which requires that you are handling all uvm specific switches such as the -loadpli manually (ps: obviously you can use it together with you own uvm version: irun -uvmhome <your-uvm-distribution-dir> ....) /uwe

hi, the accellera distribution should run on all simulators the same way given you do some steps upfront (compile dpi if required). the uvm release inside the vendor install typically contains additional goodies (messaging improvements, transaction recording, simulator interface improvements, eventually multi language capabilities etc.) /uwe

hi, why dont you implement your own uvm-comparer and pass it in when you compare()?

hi, you should call compare() and add own functionality in do_compare(). as a rule of thumb call XXX and add own functionality in do_XXXX /uwe

hi, IUS prints "MyOtherComp" - as far as i see thats the correct value /mfg

hi, can you supply a testcase or state your memory configuration?

hi, >If the sequencer and sequences need to be there, then where do we need to implement the mechanism which sends the sequences to the sequencer. it is not mandatory the reactive agents use sequences. its just good practice to use the same infrastructure. >Does the mechanism to be part of the agent. typically yes. >For eg. ahb slave which is having memory inside it and its job is to update the memory whenever write happens and drive the read data in case of reads. So if this ahb slave needs to have sequencer and sequence then the mechanism where (does it needs to be >part of agent or sub environment) it updates the memory or reads from the memory and sends the sequence to the sequencer. have a look at the ubus slave infrastructure and the slave_memory_seq. it should be simple to adapt the concept the ahb /uwe

hi, >When uvm1.2 will be released? (already saw a this tag in the SoruceForge) - uvm1.2 will be next year (~dvcon). what you saw is the start of the development branch >Will there be uvm 2.0? what kind of features will be containned? it has not yet been decided what version follows uvm1.2 (1.3 or 2.0). also requirements collection for post 1.2 has not started yet (the tsc is about to close requirements for 1.2) /uwe

hi, why does it not have a sequencer? why does it not use sequences? reactive agents can use the same sequencer/sequence infrastructure and can can be therefore controlled the same way as pro-active agents. eventually the only differences typically are: - reactive sequences typically do not use objections (because the test /pro active agents control the end of test) - reactive sequences are typically infinite (because they have to respond at any time) /uwe

hi, the reason that there is not get_current_phase() is very simple. there is simply NO single current phase. at any time there is a SET of active phases (during simulation time it would be "run" + one of the 12 runtime phases + any user defined phases). the only way to know a "current" phase is to hook into the notification from the phasing system (phase_started, phase_ended and the xxxx_phase tasks). this however is only safe until "time" is spend (because the phaser could proceed to the successor phases (could be a set!), or jump, ...)

objections are a generic way to reach the consensus. obviously there are features in objections which not everyone needs in every testbench such as hierarchical propagation. and yes in some cases you dont need them at all (if you only got one active component/sequence) nevertheless they provide a common functionality applicable to almost all designs (incl. raise/drop ordering, debug,...). speaking about "overhead" if you are concerned about that then you should first relate your simulator speed improvement vs the time needed to build a custom solution. there are more sections in uvm which are simple to utilize and cut your code down BUT come at the expense of a runtime penalty (field macros, uvm config db, string operations in config db, messaging,... raise/drop times should be negligible (even in its current form) compared to the rest of the tb. if this is different for you some design criterias would need to be re-evaluated but this requires your input/testcases/examples.

typically this doesnt go together. if its reactive the device never knows how much traffic is comming. therefore it should be able to answer at any time for an infinite number of requests. your device sounds like a DMA style device. you set it up for N transfers, then the device is supposed to perform N transfers, right? you could for instance in the programming sequence raise N objections and with every DUT transfer you see you drop one. /uwe

- how do you achieve consensus WHEN to stop your simulation? you need some mechanism to prevent the termination in the "critical sections". no matter how you call the thing its in general doing what objections do as well - running infinite stimulus and have an internal coverage progress watcher is imho not a good strategy. typically i try to run a set of shorter tests instead of a indefinite long one. easier to debug upon a failure, easier to run in parallel, its easier to reuse finite sequences,.... - see point#2 if you have infinite stimulus - thats ok even with objections as long as there are windows in the traffic which allow the simulation to end.

hi, i dont think there is a direct way with your constraints inside uvm. the options are: 1. you can edit your checker: simply throw the uvm error in the else error Setup_label: assert property (code_update_setup_check_prop) else uvm_report_error("SVA","some error"); 2. if you cant modify you can still use the simulator capability, query the assertion state and push the info into uvm.

hi, raise and drop of objection should encapsulate sections of behaviour/code/sequences were YOU(=the sequence) object normal phase progression. that doesnt mean that with the drop you move on to the next phase.it is upto the testwriter/sequence writer to define/determine when phase progression is NOT wanted repeated raise/drop etc is a common scenario. ONLY if there is consensus (by having NO objection to the phase end) the phaser moves to the next phase.some consequences of that are: 1. primary stimulus (when raising objections) needs to be finite 2 if the primary stimulus is NOT finite its upto the developer/user to ensure that raise/drop at least has a chance to reach the all_objections_dropped state (for instance variable gaps, big enough gaps between component behaviour) 3. only primary (and "self" active stimulus) should raise/drop objections - reactive elements should NOT 4. other components (reactive/monitoring) may also raise/drop objections to extend runtime (sort of a drain time but NOT time based). a typical example would be a scoreboard objecting the end of the run-phase when there are transactions pending

hi, the bottom line issue is that only phase aware objects can clearly identify the "current" phase exactly. other objects can only be told what the exact current phase is (there is a set of concurrent active phases, eg. run + pre_configure (+ eventually user defined phases)). you cannot query the phasing and determine to which phase you belong to. the "default_sequence" capability in the sequencer uses the phase info provided to set the current_phase for started root sequences. i see the following way to address your issue: 1. you know in which phase you start/end your sequences: then you can get the phase object and object the phase termination (and drop once finished) uvm_domain uvm= uvm_domain::get_uvm_domain(); uvm_phase p =uvm.find(uvm_shutdown_phase::get()); p.raise_objection(...); 2.your sequences do NOT span multiple phases and you dont know the starting phase: the wrap it in a meta sequence which in in its body forks all your sequences. when the meta sequence is started via the default sequence hook then starting_phase is set and you can propagate it to your child sequences 3. your sequences span multiple phases: start your sequences in the phase_started hook - then you know the current phase. simply propagate it to your sequences. /uwe