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

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

    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
  5. uvm_event with uvm1.2

    unless you wrap the string/int/bit in a class instance this will not work.
  6. uvm gives you the ability (via vpi) to write using ```uvm_hdl_deposit(string path, value)```
  7. i think this is yet another issue in the register model related to https://accellera.mantishub.io/view.php?id=5446
  8. >Is the 1800.2 not just based uvm-1.2? 1800.2 is based upon uvm12 but there is not a 100% overlap >If a newer version of UVM lib come out, is it compatible with UVM-1.2? there will be no uvm1.2(a,b,c) aka a newer version matching the uvm12 reference manual. the new version accellera builds will match 1800.2 and eventually support some api from uvm12 due to backward compatibility concerns. if your env works with uvm12+UVM_NO_DEPRECATED then it should be small step to 1800.2 /uwe
  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. Problem about Setting UVM severity

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