uwes

have a look at uvm_enum_wrapper in uvm12+. you could simply do the following (untested) class myenumwrapper#(type T) extends uvm_enum_wrapper#(T); static function bit is_inside(string x); return map.exists(x); endfunction endclass // and later myenumwrapper#(my_enum)::is_inside("alpha") /uwe

sounds as if the file ahb_bridge.sv is corrupt.

hi, could it be that this is a UVM earlier than UVM-IEEE? if thats the case then you probably hit a known issue. /uwe

uvm-1.0p1 is pre-historic and uvm-1.1-rc* is just slightly younger. please run with a recent uvm version such as uvm-1.2 or uvm-ieee

hi, you are using uvm1.2 with the uvm11 version of the cadence extensions. please choose one of the following 1. use the cadence distributed version in your install 'irun -uvmhome CDNS-1.2 ....' (no need for any other uvm compile/flags ...) 2. you point to the right extensions 'irun -uvmhome ...yourpath... -uvmexthome <cdnsinstall>/tools/methodology/UVM/CDNS-1.2 ....' i also see that you are using a very old version of ius and it is suggested to use a more recent one. /uwe

hi, there are two questions you ask: 1. why is auto_predict=off the default?: normally auto_predict==off is the more versatile mode of operation. it works through a monitor when the real transaction is seen on the bus, it works in passive mode, it works with back-to-back transfers etc. 2. does setting auto-predict after the write help?: simply no. for auto predict to work the driver-sequencer handshake has to wait till the real end of transaction on the bus and it has to be switched on before the read/write operation.

hi, the technical part of the error is that you missed to include the system functions into your command invication (something like -loadvpi, -svlib or similar). nevertheless i would recommend the file a support ticket to have this resolved. /uwe

hello, again - its hard to suggest something if you cannot clarify what you mean with 'kill'. this could a everything from - killing via 'kill -9' on the os level (or via signals to the simulator) - $stop,$finish and friends - via calls to uvm api methods - through phase operations/jumps - through a message causing the simulation to end - through a 'coded' natural end - through an end of event (by "killing" the clock) - through an end caused by external code .... /uwe

hi to answer the question we need to know 'how' your test is 'killed'. what mechanism is used to terminate? /uwe

a rand var which divides by 7 and 17 can be divided by 7*17 (since both are prime). so the constraint should be as simple as x % (7*17) == 0 //uwe

unless you wrap the string/int/bit in a class instance this will not work.

uvm gives you the ability (via vpi) to write using ```uvm_hdl_deposit(string path, value)```

i think this is yet another issue in the register model related to https://accellera.mantishub.io/view.php?id=5446

sv should be supported too in hal. typically hal is more focused on rtl code. /uwe

there are a few points to add here 1. since this a specific request for a particular tool please raise a request with your vendor 2. fork/disable etc are subject process control and are very close to grey area's of the vlog spec and/or races - so you might see differences in behviour 3. a much better solution than to disable the block are one of the two following: a) recode the for loop to a while loop >for (int k=0; k<64; k++) int k=0; int flag=1; while(k<64 && flag) do k++; .... // set flag to break done or B) wrap the for loop in a task and then terminate the task with a "return" upon the condition instead of a break /uwe

hi, this comes from uvm_report_info/warning which for the uvm_object bar should refer to uvm_pkg::uvm_report_* functions. due to the nested class these refer to foo::uvm_report_* which is illegal. the underlying problem is that the function call uvm_report_* in the macros has been designed to either reference uvm_pkg::uvm_report_* or the functions directly visible in the current type "local"::uvm_report_*. a workaround is to add new uvm_report_* functions into bar forwarding the call to uvm_pkg::uvm_report_* /uwe

hi a few answers Is it possible to factory overwrite a param. nope. params are elab time constants. you cannot change them later. factory usage requires that the override is a subtype of the override base type. #analysis ports with multiple instances can be done either using A) the decl macros, B) the uvm_subscriber or C) by folding all transactions into a meta transaction+channel id # you can factory override tlm classes given you register them plus you use create() to instantiate them. (ps: i havent checked what functions are virtual so that you can benefit from it) # param classes with different parameterisation needs to be factored so that there is a common *_base class which can be used as array element type. you may then set each array element to a derived class instance (which might have addon different parameters). even that will most likely not solve your problem since the base class doesnt see the actual param value. /uwe

hi the difference is that with version one you create an object named "mem_tr" in the context of get_full_name() while with the second one you create an object named (long name with alot of dots) {get_full_name(), ".mem_tr"} in the uvm_root: context. Here it depends for which instances you set the factory override. for various reasons it is not a good habit to have object names involving dots or other non a-Z0-9_ characters. just think of print out of a.b.c.e.f and you allow "." in names then it could be "a" . "a.c.d.e.f" or "a.b" . "c.e.f" or any weird combination. with that you should avoid any get_full_name() in the name argument of the ctor. for the particular SDI warning the name should have no "." since this is considered a hierarchical delimiter (which for you isnt true).

uvm11 had problems in this area. uvm12 should be better in some areas but still https://accellera.mantishub.io/view.php?id=4871

hi the mentioned problem is part of https://accellera.mantishub.io/view.php?id=5446 the fix is quite long and affects a couple of uvm functions. /uwe

hi, normally there is nothing bad with the fact to access a local member from a virtual function/task. functionality should be exposed via functions/tasks and never via member fields. in that sense opening the access to the local implementation detail g_request_id would be the wrong solution. the right course of action would be to encapsulate the static member g_request_id into an atomic accessor like in java AtomicInteger::incrementAndGet() and expose that in the base class instead. in this particular situation you can probably use an own id generator instead.... /uwe

hi, ... this nasty timescale problem.... you got a few options 1. scale like dave suggests 2. force all timescales to be the same in your system 3. uvm could have implemented a workaround used in the tlm2 area (uvm_tlm_time) and use this data type to represent time instead of the broken,bad sv native "time" datatype. all uvm api would use this uvm_time data type ( 4. the solution i would prefer however is that the sv -1800 committee goes and provides a real "time" datatype which scales properly when switching timescale regions... (or even better get rid of timescale at all)

hi, i assume you are using uvm library coming with the cadence install. if so then there has been a leftover debug statement in the uvm_link* file in the uvm1.2 install. that issue got resolved in one of the hotfixes .... regards /uwe

hi, the fix will be in the next version of uvm. this will be most likely the version matching the upcoming uvm-ieee release. /uwe