uwes

hi, first this smells like a tool issue as UVM doesnt do the randomization itself. two things however are suspicious to me 1. you randomize the own object "this". while this is legal its strange to me (i usually randomize the object and then perform operation with it) 2. you only generate "i". you should probably use "std::randomize(i)" instead of the class randomize

so this finally boils down to a simulator issue and not to an UVM issue. as `__FILE__ and `__LINE__ are being defined by the compiler the compiler should take care of the correct string encoding on that platform.

#2 means completely use parameters (the SV language "parameters") in all required places and pass the parameters into all required instances. parameters are elab time constants - everything passing through uvm_config_db is a runtime thing so that will not work. but why is this an issue? interface test82i #(int S=3); endinterface module test82; class monitor#(int S=5); virtual test82i#(S) myif; endclass class agent#(int S=10); monitor#(S) mon; endclass agent#(20) i = new(); endmodule

what about http://www.uvmworld.org/forums/showthread.php?157-TLM-PORT-IMPORT-and-EXPORT

hi, the SV LRM has the requirement of assignment compatible types and the restrictions based upon the parameters. however you still got a couple of options: 1. create your uvc supporting the max with of your busses. make the real width a configuration field (not a parameter) and adjust the bus values at runtime by using masks 2. completely parameterize your uvc (passing down all parameters from the top through the env to monitors/agents/drivers etc.). this usually works ok if you have a limited+fixed set of parameters and/or sub components 3. refactor your uvc so that most of it is not parameterized and replace the instances of the generic base classes with derived parameterized classes at runtime. (basically real vlog parameters have to be at least elab time constants, you cant base them at a runtime decision)

hi, this looks strange and i havent seen this issue in recent ius versions. also 10.20s11+ are known to run fine with uvm10 so i think its best to either supply more information or a testcase /uwe

hi, simply signup on the accellera website and you get access to the xls. 7uwe

hi, In general, we recommend that the uvm versions shipped with IUS / IES be used, as they are ensured to run optimally. > 1) Can I get this to work and if so how ? To use uvm-ml with uvm-1.0p1 you need to wait for the next uvm-ml release from Cadence, that will incorporate necessary changes in phasing (uvm-1.0 significantly changed phasing compared to uvm-1.0ea, as explained correctly by Bart in the prev. reply). IUS10.2s70 (target for end of June) will include UVM-ML support. We are working to provide a release of uvm10ml as a tar file earlier. if you are interested please contact your local cadence AEwho can get you access once released. > 2) When will Cadence release an IUS version that ships with uvm-1.0p1 ? > If it already does, which version is this ? the most recent IUS 10.20s40 release has uvm-1.0p1 in it. while the default is still UVM10EA you can enable UVM10 by adding "-uvmhome `ncroot`/tools/uvm-1.0" to the uvm commandline. as a side note: you can use any accellera version with IUS10.20s11+, just point '-uvmhome' to the directory and add uvm_dpi.cc file to the cmdline. you will not have all debug features enabled with the accellera version but yet you can develop+run.

for accellera members here, http://www.accellera.org/apps/org/workgroup/vip/download.php/4089/schedule-uvm-1.1.xlsx uvm1.1 is about to be closed and release by mid/end may

UVM10 is part of the March update release (10.20s40 sometimes also 10.20s17) - you dont need to wait till june

UVC's as of today run with UVM10EA. UVM10EA is also the default when using '-uvm' which irun. if you want uvm10 you should add "-uvmhome `ncroot`/tool/uvm-1.0" to your cmdline

to run uvm-1.0p1 with an open source version you need to add "$uvmhome/src/dpi/uvm_dpi.cc" to the commandline. please note that for the ius 10.20s40+(=10.20s17) you dont need the *.cc on the commandline if you use the embedded uvm release. /uwe

hi, m_* members (fields+methods) are considered internal UVM fields and should never be used. they are implementation details, can change at any time and without any notification. i think the technical reason is that SV does not have 'friends' like c++ has. p_* are normal members and can be used.

hi, sure, you could create an report catcher catching the "HBFAIL" fatal error and print the objection table using <objection>.display_objections()

the issue is that in sv a backslash is a special character. the windows filename "c:\foo\some\name" is just "c:" + "\f" + "oo" + "\s" + "ome" +"\n" + "ame". which results only for "\n" in a line break the other escape like sequences are ignored (are just "f" "s"). module test78; initial $display("c:\foo\some\name"); endmodule ncsim> run c:foosome ame ncsim: *W,RNQUIE: Simulation is complete. btw: java for instance checks and allows only some characters to be prefixed by "\"

hi, you need a c-compiler to use DPI (even on windows you can get gcc) and link the result into the simulator.

hi, i think thats not as intented. it seems that the offset of the root uvm_reg_map does not get honoured when computing the full physical address. if you instantiate your register block into a top register block (with offset 'h8000) with which is having an (aribitary(=ignored)) offset

hi, uvm config db requires compatible types. the value arg of set/get needs to be assignment compatible to the type parameter of uvm_config_db! in your example the type is "virtual ubus_if_parameter" which is the same as "virtual ubus_if_parameter#(32)" BUT the instance vif_para is a ""virtual ubus_if_parameter#(64)" which is not asssignment compatible with the #32 variant. its one of the strange sv problems that all types get specialized (and there is nothing like a generic type anymore). in sv assignment compatible means that ALL parameters have to be equivalent! /uwe

yes, there is a fix for mantis3481

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

hi, there are no newer "released" versions of UVM. BUT the bugfix branch of UVM (UVM_10X_DEV) has quite some fixes for some of the problems found. I was suggesting to try the bugfix branch or if that is not an option you may try the patch: http://uvm.git.sourceforge.net/git/gitweb.cgi?p=uvm/uvm;a=commitdiff;h=0aa7e3f11ebbac2d5ef50ad39eb55b0ee46bdf55 /uwe

hi, i think the official way is to derive a new uvm_report_server amd reimplement compose_message(). then make an instance of the new server and call uvm_report_server::set_server(new-instance) /uwe

hi, this could be a variant of mantis3414 http://eda.org/svdb/view.php?id=3414. can you try to rerun with a newer version of UVM? /uwe

hi, if you use set_config_int, get_config_int or the automatic apply_config_setting (same applies to other numeric types such as _enum) your set() should be uvm_config_db#(uvm_bitstream_t)::set(). note the type "uvm_bitstream_t" instead of your enum.

hi, adding to janick's comments. its not that this style breaks encapsulation its also prevents a proper configuration override. so you should make a local field "test" and make an appropriate set_config or ::set from test/env/agent or similar. (keep in mind that there could be more than a single set-config)