uwes

hi, polymorphism is a general concept. see http://en.wikipedia.org/wiki/Polymorphism_(computer_science). the testbenches we write are essentially software. in that sense all methods to improve creation/speed/maintenance/stability/reuse of software should be in the focus for tb developers too. the concept of polymorphism is one way to improve. /uwe

hi, the error message clearly indicates what is wrong: ncsim: *W,RNDOCS: These constraints contribute to the set of conflicting constraints: assert(jb_seq.randomize() with { jb_seq.num_jelly_bean_flavors == 1;}); (./jelly_bean_ex.sv,483) constraint num_jelly_bean_flavors_con { num_jelly_bean_flavors == 10; } (./jelly_bean_ex.sv,182) num_jelly_bean_flavours cant be one and ten at the same time. /uwe

hi, do yourself a favor and upgrade to a recent version of ius such as 12.20,13.10,13.20. ius9.2 is out of maintenance for 3years and i do not remember the qualified uvm versions there. in addition using the latest uvm11d will also prevent quite some error seen in earlier versions. /uwe

at the first glance this code isnt useless. if obj isnt part of m_t_inst.m_pool (and obj is of a class type) then the pool returns "null" as indication that no object with key "obj" did exist in the pool. if missing its added to the pool. on the second thought the whole code is an iterator over the m_pool key set - so there is an entry for each key. but yet the entry could be "null" through a m_pool.add(key,null) ... i'm not sure if this is scenario is valid ...

hi, I assume that m_sub_seq is a child of m_top_seq. if so the constructor of m_top_seq should allocate .m_sub_seq as well (or allocate it in pre_randomize()). this is because sv doesnt allocate objects during randomization in contrast to sn/e. /uwe

please contact cadence support to resolve this issue. there are many factors which could play here (ius version, commands, use model) /uwe

hi, 1. set the “selection_mode = UVM_SEQ_LIB_USER; “ of the sequence library 2. implement “virtual function int unsigned select_sequence(int unsigned max);” and return the index of the chosen sequence inside “sequences” without having kind you could do something begin int item; uvm_object_wrapper w[$] = {AS::get_type(),BS::get_type(),CS::get_type()}; void'(std::randomize(item) with {item dist {0:=20,1:=20,2:=20};}); // now just find the index of w[item] in sequences[$] and return it, or ... end /uwe

hi, although there has been no objection against the end of post_shutdown_phase the phase continues to run past ready_to_end. this is because ALL predecessors of the next phase need to be in the phase ready to end state. since both run_phase and post_shutdown_phase have a joint next phase all tasks in run_phase and post_showdown_phase will be terminated at the same time. for your example it means that its guaranteed that the last of the runtime phases (post_showdown_phase) will not end before run_phase has ended (100ns) "ready to end" just means we "could" end if all agree. if we do not agree the tasks continue to run "phase_ended" means we really ended this phase and we continue to the next phase /uwe

hi, uvm_resource_db is a layer under uvm_config_db. uvm_config_db provides a simpler and clearer api compatible with the traditional set_config_xyz() methods. for normal purposes uvm_config_db is the best route. /uwe

hi, >class pma_base_sequence #(parameter LANES = 4) extends uvm_sequence; >`uvm_declare_p_sequencer(sequencer #(LANES)) i think it should be: class pma_base_sequence #(parameter LANES = 4) extends uvm_sequence#(transaction #(LANES)); /uwe

hi, there are various options to - learn and track heap memory (tcl: heap -help or via gui) - understand profiling information (source, memory,randomization) to find "hotspots" (irun -helpsubject profile) - get the traditional total time, memory, consumption for each of the processing steps (irun -status) - understand algorithm complexity via code coverage or algorithm quality via functional coverage The issue i see with the same-tool benchmarking and "make a recommendation" out of that is that - this is heavily tool version dependent - i would assume that weak spots in performance are addressed by the tool and internal optimizations asap - code rewrites on the source level to optimize speed might limit optimization options for the tool in the future - commonly accepted "good" code should run fast on all simulators - "fast" code doesnt necessarily mean "good" code. - code quality metrics (such as in sw) is getting more and more important - the "run-fast" vs "create/debug/maintain" trade-off needs to be considered /uwe

hi, in static contexts you have to use the macro set with the postfix "_context". while the normal macros will invoke <this>.uvm_report_xyz() and therefore require a non static context the _context macros will invoke <context>.uvm_report_xyz(). messages emitted with the _context version can be used in static contexts and provide the same functionality as-if the non-context version would have been invoked in context. (an alternate use model for the _context macro version is to emit a message from a different place than what appears as the messages context. eg. you can print from within the driver BUT the context is showing as if the message was emitted by the agent) /uwe

hi, this is the way it is. type checking for overrides needs to happen at runtime. /uwe

hi, there are a few things playing here 1. run_phase is parallel to all other runtime phases ((pre|post)_)?(reset|configure|main|shutdown)_phase 2. a phase is terminated when all predecessors of the next phase are completed 3. completed mean "they do NOT object phase progression" for your example it means that main_phase is started but since you dont raise an objection its terminated instantly. then post_main_phase is started and so on. since only the run_phase objects progression all runtime phases end in zero time (apart from the last one which needs to wait till the parallel phase run_phase completes). that post_shutdown_phase and run_phase terminate and the joint successor phase extract_phase is started. have a look at +UVM_PHASE_TRACE /uwe

hi, have a look at http://sourceforge.net/p/uvm/code/ci/852d197932c928f526c44779e16c68bcc2854e73/ this should ignore unmodelled fields. let me know if this works for you /uwe

hi, i see the issue. do_check() is prepared a "no-compare" mask but only marks the UVM_NO_CHECK and WO* areas. non-modelled are not marked as "no-compare" since they are no fields. im going to file a mantis /uwe

well, the field macros do not call ::get(), it's the uvm_component's apply-config_settings() method which iterates over the defined fields and pulls the values from the config_db and assigns them to the local fields via set_*_local(). the above scenario should work IF the monitor::build_phase() first retrieves the config object and then invokes super.build_phase() to have auto configuration applied. in that particular case ::set(this, "tb_env0.ga_env0.ga2.monitor", "cfg.monitor_enable", UVM_ACTIVE) should set the field as desired.. /uwe

hi, i just looked briefly at the implementation of do_check() but it looks ok. can you please supply the register definition and the expected/actual value? /uwe

hi, i think the following is simpler (slightly different semantic) foreach(agent[i]) begin uvm_config_db #(ral_block_host_regmodel)::set(agent[i],"", "regmodel", regmodel); end

just leave them out. uvmreg only considers modeled fields. /uwe

hi, that is a simple shell issue. the shell will expand the meta characters such as *,? ... and pass the expanded result to the tool. the backslash simply tells the shell to avoid any expansion. unfortunately what is being expanded is shell dependent. you may work around with the following - prefix with backslash - put the whole argument into quotes ' - put the argument subject to shell expansion into a .f file and -f include the file /uwe

hi, you should be able to use function uvm_reg_map_info uvm_reg_map::get_reg_map_info(uvm_reg rg, bit error=1); to retrieve the properties for a reg/mem in a particular map. once you have the properties you may switch the rights for the particular entity via the uvm_reg_map_info::rights attribute /uwe

hello, #1 >I suppose I could just use another transaction type and ignore the data. yes this is the simple path. you have to provide a transaction type and you have to pass "something". i agree sticking with one path is the better option and TLM is a better path since its an abstract interface without being tied directly to an implementation/language/domain ... #2 TLM (from the sv impl side) allows you use non-uvm_objects as transactions. so you can pass ints, enum, structs as transaction without wrapping them. if the base types are supported by code mediating between SV/SC depends upon your implementation. nevertheless you should be aware that when you use primary types (int,enum,string,structs,...) as transaction objects in uvm-sv you basically have a pass-by-value semantic. if you pass traditionally objects around you have a pass-by-reference semantic.

hi, - there are no plans to remove the 12 runtime phases - release of uvm12 will be towards end of the year - precompiling uvm usually isnt giving you that much (since the heavy part is usually elaboration of the tb). the steps required depend upon your vendor. /uwe

hi, this is a known issue: http://eda.org/svdb/view.php?id=4497 http://eda.org/svdb/view.php?id=4009 http://eda.org/svdb/view.php?id=4305 http://eda.org/svdb/view.php?id=3369 the workaround today is to have another map instance having the same register set added as the original map. /uwe