uwes

no, nothing is planned in this area. the core question is why does the simulator emit different info when you terminate with different exit codes... this doesnt sound like a good practice /uwe

hi, i fully agree with chris. we (cadence) do recommend to use the macros and have the verification engineer's brain focus on the "business logic" rather than on the creation of boiler plate code. It's important to note that macros and manual implementation do not contradict each other - one can start with the macros since they will lead to a fast creation of the env ... and if (and only if) the implementation isnt fast enough one could switch to a manual implementation of the particular slowdown problem. why do we have the macros in UVM? Just because they provide lots of code which cant be wrapped away in a different way in SV - think other languages dont have macros at all. So IF the underlying language would provide a path to capture the functionality hidden behind the macros today without using a preprocessor then i would rip out the macros due to the downsides they have. so essentially its a tradeoff today: implementation speed+maintenance cost vs runtime speed+macro-handling-downsides >Why spend 10-20 minutes creating these in addition this is not a one time shot. the manual implementation needs to be maintained ... and another side: the assumption that macros are slow because they literally expand into lots of generic code isnt necessarily true. the macro's expand into code because sv doesnt have another way to express this and yet they can serve as starting point for an optimization :-) /uwe

hi, there is no nice path or setting to accomplish this with the current uvm library. what you could do is to override the system function $finish via pli and supply an own version of $finish. /uwe

hi, the uvm doc is generated via natural docs. the developer repo contains an install+setup in order to generate the uvm doc . downside of natural docs is that only the special comments are extracted - what you miss to document is not part of the generated doc. intelligentdv (doxygen like documentation) or DVT both directly extract more information and are also extracting non documented functions or inheritance relations. >can we run it on our own code to generate HTML ? if yes, then how ? clone the devel repo, look at uvm_ref/nd/gen_nd also look at the config/setup files in uvm_ref/nd/Proj /uwe

hi, this sounds strange to me. i just rechecked 13.10 and its working as expected. btw have you set +UVM_VERBOSITY to NONE ? if you do then the UVM_CONFIG_DB_TRACE messages are NOT emitted since they are printed with UVM_LOW verbosity. /uwe

hi, as far as i remember there is an issue with messages from uvm_root and reporting adjustments via the cmdline. that might affect the RNTST message. btw: the first arg is "uvm_test_top" when the test is created via the factory. its the logical name of the top test (which is of type hammer_base_test). /uwe

hi, im sure ius supports that. what are your symptoms and have you escaped the "*" in order to avoid shell expansion? /uwe

hi, i thought this would remove all info messages +uvm_set_action=uvm_test_top,_ALL_,UVM_INFO,UVM_NO_ACTION btw +uvm_set_severity would change INFO to WARNING/ERROR/FATAL and therefore still emit it - just with a different severity /uwe

hi, the *_context variant of the macros can be used when you want the message to appear as if emitted by another object. a common use model would be if all your components use a common helper class which emits a message then typically you want instead of your common helper class appearing in the message the parent component to be printed. the _context macros are just `define uvm_*_context(ID, MSG, CNTXT) \ begin \ if (CNTXT.uvm_report_enabled(...)) \ CNTXT.uvm_report_* (...); \ end

Sounds like Mantis 4160 /uwe

hi, if you do have an QDA of reals in a class instance then you can implement the do_record() function and record your reals from this place. /uwe

hi, the sv lrm requires to have these things declared in sv itself. there can be no explicit or implicit dependencies to definitions outside of the sv lrm world (well apart from dpi). if your simulator vendor supports the use of symbols from outside of the sv domain like vhdl then its a private extension, with a private semantic and with private functionality. a much better route in my mind is (A) translate the vhdl constant package/file to a sv constant package/file via a translator/generator or ( describe the constants in a language independent format and generate VHDL and SV from this common source. both paths are simple, vendor independent, lrm compatible regards /uwe

hi, especially as a new user you should be using the uvm_field macros which implement lots of boilerplate code for you. then you dont need the do_* functions at all then. you really only need the do_* functions for special customized/super optimized code. i assume you refer to: //| class mytype extends uvm_object; //| ... //| int f1; //| function void do_copy (uvm_object rhs); //| mytype rhs_; //| super.do_copy(rhs); //| $cast(rhs_,rhs); //| field_1 = rhs_.field_1; //| endfunction the super.do_copy() is required to perform do_copy on base class fields and the cast is required to access the actual fields of the class (and not just those of the uvm_object base class) /uwe

hi, how do you create your item? ::create*()? new()? inside the uvm_do's ? /uwe

hi, there are more ways to find this issue: 1. when enabled (verbosity) you should see a message like this UVM_INFO /grid/avs/install/incisiv/10.2/latest/tools/uvm-1.1/uvm_lib/uvm_sv/sv/seq/uvm_sequencer_base.svh(1468) @ 0 ns: uvm_test_top.m_env.m_iab_test_sequencer [NODEFSEQ] The "default_sequence" has not been set. Since this sequencer has a runtime phase schedule, the uvm_random_sequence is not being started for the run phase. 2. via config db trace you would see that the lookup for a "default_sequence" failed. you would also see the exact lookup parameters. 3. when you invoke uvm_component::check_config_usage() you would see some uvm_config_db settings have not been used. /uwe

hi, this is a typical configuration/setup when one virtual sequence drives multiple lower level entities in parallel. there might be slight variations depending upon the exact properties of your environment. One thing you should be looking at is the translation/ending model of the upper/N*lower conversion. does one upper item translate into N same sized lower items? do the lower items complete at the same time? if its not guaranteed that they end at the same time then is there q requirement that driverX operates in back-to-back mode (no gaps between lower items on a line)? /uwe

hi, i think the check is correct. uvm_reg_block's kind of behave like uvm_components. both cannot have same named entities at a particular level of the hierarchy because they form a tree. they can only use the same name in different branches of the tree. when a uvm_reg_block is configured one of the args is the parent. if you instantiate a reg_block you are not just instantiating it in that scope you are also building a "global" hierarchy of uvm_reg_blocks. therefore the name of the reg_block has to be unique among all of the parents children. ^/uwe

hi, there are multiple ways to do that. the easiest is to use a virtual sequence (one without a driver) which drives the sequences on Lower1,Lower2,Lower3 and have the subsequences started in a fork/join. class UpperVseq ... someSeq Lower1; someSeq Lower2; someSeq Lower3; task body(); fork `uvm_do_on(Lower1sqr,Lower1) `uvm_do_on(Lower2sqr,Lower2) `uvm_do_on(Lower3sqr,Lower3) join endtask

hi, unless you raise an objection to prevent the phase from ending all your started functionality in pre_reset,pre_configure is terminated instantly. so you have to wrap all functionality which should be atomic / not interrupted or terminated in phase.raise_objection() and phase.drop_objection() /uwe

depending upon your uvm version you have to add libuvmdpi.so ( and eventually libuvmpli.so ) since they contain the precompiled uvm dpi c-code. if you compile this code yourself then you dont have to supply the libraries. /uwe

you can only set one default_sequence per phase. the result of a consecutive uvm_config_db::set is determined by the semantic of the uvm_config_db. but there there is no feature that multiple sets on the same field result in accumulated values. but whats not in the library you can do yourself easily with code like the one below. it takes plus args +SEQNAME and starts these sequences serially... /uwe 97 begin 98 uvm_cmdline_processor cmd = uvm_cmdline_processor::get_inst(); 99 string seqnames[$]; 100 uvm_factory f = uvm_factory::get(); 101 102 103 if (cmd.get_arg_values("+SEQNAME=", seqnames) == 0) begin 104 `uvm_error("TEST/NOSEQS", "No +SEQNAME=...") 105 end 106 foreach (seqnames[i]) begin 107 uvm_sequence_base seq; 108 if (!$cast(seq, f.create_object_by_name(seqnames[i]))) begin 109 `uvm_error("TEST/NOTASEQ", {"Type ", seqnames[i], " is not a sequence type"}) 110 continue; 111 end 112 void'(seq.randomize()); 113 seq.start(sqr); 114 115 end

an alternative is to override the uvm_report_server::report/compose_message/process_report and have them messages from your components formatted or colorized differently. also you could install component local report_handlers for your objects with a derived uvm_report_handler::report() functionality. they could prefix ID, MSG, etc. technically the definition of the uvm_severity cannot be changed other than by changing the uvm source itself (you can also cheat and do the following. it works because uvm_severity is an int and not the enum. this might change in the future. the final thing not shown here is to replace uvm_report_server::compose_message and translate the int back to the literal you want ...) module test282; import uvm_pkg::*; const int MY_SEVERITY=4; initial begin uvm_top.set_report_severity_action_hier(MY_SEVERITY,UVM_DISPLAY|UVM_COUNT); uvm_report(MY_SEVERITY,"ID","MSG",UVM_NONE,`__FILE__,`__LINE__); end endmodule

hi, the lookup name .v_seq.slv_seq[k]evt looks strange. it looks like that the get_full_name() inside the sequence is not really what you assume with "*.v_seq.slv_seq[%0d]" /uwe

unless you are switching off constraints explicitly they should be honoured. /uwe

why not just write a sequence which selects one of these packets? /uwe // short skeleton, you can improve this scheme ... class bla extends uvm_sequence; frame_packet a; short_packet b; illegal_packet c; rand int sel; task body(); case(sel) 0: uvm_do(a); 1: uvm_do(; 2: uvm_do©; endtask endclass