Jump to content


  • Content count

  • Joined

  • Last visited

  • Days Won


uwes last won the day on December 1 2017

uwes had the most liked content!

About uwes

  • Rank

Contact Methods

  • Website URL
  • Skype

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

1,092 profile views
  1. 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.
  2. 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
  3. 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
  4. hi to answer the question we need to know 'how' your test is 'killed'. what mechanism is used to terminate? /uwe
  5. uwes


    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
  6. uwes

    uvm_event with uvm1.2

    unless you wrap the string/int/bit in a class instance this will not work.
  7. uvm gives you the ability (via vpi) to write using ```uvm_hdl_deposit(string path, value)```
  8. i think this is yet another issue in the register model related to https://accellera.mantishub.io/view.php?id=5446
  9. Version 1.0.0


    hi, this archive contains the code for a framework to build indirect registers in a flexible fashion. More insight are shown at dvcon2017-us /uwe
  10. sv should be supported too in hal. typically hal is more focused on rtl code. /uwe
  11. 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
  12. 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
  13. 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
  14. 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).
  15. uvm11 had problems in this area. uvm12 should be better in some areas but still https://accellera.mantishub.io/view.php?id=4871