• Content count

  • Joined

  • Last visited

About uwes

  • Rank

Contact Methods

  • Website URL
  • Skype

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

346 profile views
  1. 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
  2. sv should be supported too in hal. typically hal is more focused on rtl code. /uwe
  3. 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
  4. 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
  5. 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
  6. 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).
  7. uvm11 had problems in this area. uvm12 should be better in some areas but still https://accellera.mantishub.io/view.php?id=4871
  8. 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
  9. https://accellera.mantishub.io/view.php?id=5636
  10. 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
  11. 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)
  12. 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
  13. 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
  14. hi, actually the 'bad' guy here is the line uvm_resource_db#(uvm_reg_block)::set("uvm_reg::*", get_full_name(), this); it simply doesnt make sense that every block stores itself in the config-db as part of the uvm library. see https://accellera.mantishub.com/view.php?id=5040
  15. hi, why dont you just use grab/lock from the frontdoor sequence on the sequencer running your parallel sequences ? obviously each thread should run an own instance of the frontdoor sequence in order that each instance can perform the necessary access sequence in an atomic fashion. essentially the lock/grab scheme allows you to block other sequences from executing items while your sequence is in an atomic/critical section. /uwe