uwes

hi, another solution instead of dpi/vhpi/pli/.... is to use a custom backdoor and simply reference the registers via an out-of-module-reference. /uwe

hi, a typical standalone reference model would most likely be dervied from uvm_component. it should not be part of the monitor. monitors and drivers translate transactions into bit-wiggle (and reverse). /uwe

hi, there are a few things mixed here: - a particular 'imp' port type is always calling a specific function in the supplied container (2nd arg of the imp, usually the enclosing component). this means multiple instances of the same imp are connected to the same function in the enclosing component. - the *decl* marcos simply pre/post fix the port imp type name AND the function which is called in the container. so normally an put_imp would end up in put() but with decl of (_post) it ends up in put_post() instead). - imp-port-type to target function relation is usually N:1 (this also means you cant have instances of an imp of item type A and B at the same time). to get around and have N:M connections you basically got 3 ways 1. separation via the decl macros: (this makes new imp port base types and new target functions which are called) 2. you create a meta-transaction which holds your real transaction(s). in the target you unpack the meta transaction based upon a selector field like an target index,....: (this makes an explicit N:1 connection and you handle the transaction target locally) 3. you create a proxy using the uvm_subscriber(or similar). for a N:M connection you simply instantiate M proxies in your target. each proxy is handling then one endpoint alone. /uwe

hi, the commandline type-override only works using the string based factory access. parameterized classes cannot really be handled using the string based factory access (thats why you have the 'param' macro set).

this is a known issue, captured in the above mentioned database, there is a fix avail but it has not been merged into a release.

for instance: any_driver#(apb_item)::type_id::set_type_override(my_apb_driver#(32,apb_item)::get_type()); with class my_apb_driver #(int L=16,type D=int) extends any_driver#(D); (unchecked) /uwe

http://eda.org/svdb/view.php?id=3544

hi, there are a couple of things to consider here. first: an "virtual interface" is just a reference to a real interface instance in sv. with that you simply ask "how can i connect an system verilog interface to a vhdl DUT" - well that is not a UVM problem. and that is a simple question of what your simulator supports. - you can probably instantiate your vhdl dut in the verilog tb. then you can access the ports of your verilog instance as if they were verilog. this looks like: library ieee; use ieee.std_logic_1164.all; entity test105 is port ( clk: in std_ulogic ); end test105; architecture rtl of test105 is begin end rtl; interface test105if; bit clock=0; endinterface module tb; test105if mif(); test105 my(mif.clock); endmodule - depending on your simulator you may also access signals inside the vhdl via OOMR or via other backdoor mechanisms ($nc_mirror and similar) - using bind (depends upon your simulator) interface test105if; bit clock=0; endinterface interface test105rstif(input rst); endinterface module tb; test105if mif(); test105 myvhdl(mif.clock); endmodule bind test105 test105rstif myrstifinst(rst); library ieee; use ieee.std_logic_1164.all; entity test105 is port ( clk: in std_ulogic ); end test105; architecture rtl of test105 is signal rst : std_ulogic; begin end rtl;

hi, if you do use the new(UVM10+) model (no uvm_"sequence"_* macros) you do NOT associate sequence types with a particular sequencer type anymore. the uvm_declare_p_sequencer is only giving you the type+p_seqeuncer pointer but nothing happens in terms of registration. accessing the p_sequencer.sequences.size() just make me think that you want to pick sequences from the sequencer based on some selection criteria. for that you should look into the uvm_sequence_library capability. with that you can make your selection (what sequence to run) in a seqeunce library. you may associate seqeunces with multiple sequence_libraries (N:M, per type, per instance) and later you simply run your sequence library on a particular sequencer.

hi, another option is to avoid the rand-array-allocation issue at all is to generate the elements on the fly and NOT the full array upfront. if you do have dependencies between the transactions you can add inline constraints using the uvm_do_*_with class of macros and refer to send items.

hi, uvm_reg_block, uvm_reg etc are all base classes and need to be specialized(=derived). a generic uvm_reg would have no fields, a uvm_reg_block would have no embedded regs etc. so from that point of view it doesnt make sense to make an instance of such a uvm_reg_block or uvm_reg therefore they are "virtual". /uwe

hi, depends what you mean with "multiple tests": - running multiple sequences concatinated? this is simple, basically you would do something like: config-seq1; test-seq1; config-seq2; test-seq2;..... - you may select different tests with the same compiled snapshot without reinvoking compilation/elaboration: so you simply change the +UVM_TESTNAME=arg to select your test. - you may use the phasing system to concatinate tests: basically you jump back to a previous phase such as reset/pre_reset/configure or similar once a particular test phase has finished. for that you need to build a test controller which controls the sequence of your tests and controls the phasing. typically this is not a really good use model because if you got something to debug in the n'th test you might be required to run the (n-1) upfront to get the same behaviour. also the phasing system does NOT allow you to go back to a phase state earlier than (including?) start_of_simulation once you passed that stage. this restriction prevents you from rebuilding the component hierarchy. - you can probably use the simulator commands/tcl to reset a simulation and restart it with a new test. this simply allows you to skip simulator invocation time. - you could probably also use a simulator snapshot capability to run a test till a certain point (post long time config), create a snapshot, reseed some components, run a test, reload snapshot and go with a reseed ..., this allows you to run the same test multiple times with different seeds from a custom timepoint. - running multiple tests in parallel: if your tests are "sequences" and are not colliding you can run them in parallel. say, in a subsystem you may excercise component A and component B at the same time (even if you had before only A&B tested standalone) /uwe

hi, have a look at http://www.uvmworld.org/contribution_download.php?id=107

hi, what do you mean with "still waiting". the wait_trigger() task should be aborted BUT without cleanup. this probably looks like as if there are still num_waiters waiting. if you do use "disable fork" to break the wait_trigger() you probably have to call cancel() to indicate that you removed one waiter. /uwe

hi, the class reference for uvm is being generated using "natural docs" (http://www.naturaldocs.org/). the whole tool+setup is part of the developer repository. other tools to generate documentation from sv code are DVT (http://dvteclipse.com) or the doxygen based tools from intelligentDV (http://intelligentdv.com/downloads/index.html#doxygentools) /uwe

hi, here is an (incomplete) list: http://agnisys.com/products/ids http://www.duolog.com/products/bitwise-register-management http://www.semifore.com/index.php?option=com_content&view=article&id=1&Itemid=10 /uwe

hi, you cant directly connect a port of "uvm_sequence_item" to a receiving end of expecting "BUSTYPE". (i assume BUSTYPE is NOT uvm_sequence_item) >Is there any way to make the two compatible? there are a few ways: 1. make the port monitor_item_done a port sending BUSTYPE items 2. make the repredictor receiving uvm_sequence_items and $cast the generic items inside the predictor to your BUSTYPE 3. create a proxy component with one tlm in-port of type uvm_sequence_item and one out port of BUSTYPE and simply cast inside the write function to the BUSTYPE and send the $casted element further. you might want to look at http://uvm.git.sourceforge.net/git/gitweb.cgi?p=uvm/uvm;a=tree;f=tests/70regs/40addons/02_simple_seq_bkdr_ftdr;h=e44900ee1ac6d615a8079c3ae3b85ba79b0fb0f0;hb=master the relevant code parts are: class transaction extends uvm_sequence_item; // predictor def and analysis port must have same types uvm_reg_predictor#(transaction) predictor; uvm_analysis_port#(transaction) item_collected_port; // connect uenv.drv.item_collected_port.connect(predictor.bus_in);

hi, the usage of "uvm_test_done" is deprecated. adding "-define UVM_NO_DEPRECATED" hides all deprecated code from compilation. in order to fix that you should 1. move from using the uvm_test_done objection to an end-of-phase objection 2. probably you also have to change the calls to set_drain_time and set_report_verbosity_level to their UVM10 counterparts. /uwe

hi, adding +UVM_PHASE_TRACE leads you to the issue. it shows you that all phases are ended before you starting/continue driving. looking at your code it is obvious that: 1. you object uvm_test_done in your sequence 2. your sequences are started in the "main_phase" as you are starting your sequences in the main-phase you cant utilize the backward compatibility switch on +UVM_USE_OVM_RUN_SEMANTIC and your objection is towards end of test (the old way) and not to the end of phase you are locking the whole system. so what you should do is the following: 1. object "starting_phase" instead of "uvm_test_done" this should get you going. (there are some other smaller things but they do not matter for the issue. regards /uwe

hi, can you share more of what "is not working"?. is it not compiling?, not giving the expected results? not seeing any traffic? /uwe

hi, if your company is an accellera member you can download it here: http://www.accellera.org/apps/org/workgroup/vip/documents.php.

hi, the generator for ipxact to uvmreg is supplied on demand. please contact your local AE/or sales people in order to get access to it. /uwe

i added http://eda.org/svdb/view.php?id=3633 to track this. it seems only the do_on familiy of macros honors the sequencer of the item correctly.

ok, the issue is that even when you initialized the item using `uvm_create_on with a SQR specified the uvm_send() sends the sequence to the local sequencer. if you simply replace uvm_send with an appropriate seq.start(targetsequener,this) your example works (probably) as expected. /uwe --- a/ubus/examples/test_lib.sv +++ b/ubus/examples/test_lib.sv @@ -231,7 +231,7 @@ class test_2m_4s_azhang_vseq extends uvm_sequence; //// `uvm_do_on_with(read_byte_seq0, p_sequencer.seqr1, {read_byte_seq0.transmit_del == 0; }) `uvm_create_on(read_byte_seq0, p_sequencer.seqr1) assert(read_byte_seq0.randomize() with {read_byte_seq0.transmit_del == 0; }) - `uvm_send(read_byte_seq0) + read_byte_seq0.start(p_sequencer.seqr1,this); addr_check = read_byte_seq0.rsp.addr; m_data0_check = read_byte_seq0.rsp.data[0] + 1; // WRITE MODIFIED READ DATA

hi, did you extend `UVM_REG_DATA_WIDTH to 128? otherwise your reg fields can only store upto 64bits by default. /uwe