Jump to content
Sign in to follow this  
Vithal

UVM_REG: Simulation performance is badly affected by uvm_reg env

Recommended Posts

I am trying to use uvm reg in SOC to load initial programming of clocks & other csr programming by backdoor loading, it reduced the simulator time but the wall clock time is increased much compared to the frontdoor programming. Removed uvm reg factory registration for all the regs, removed all the fields, replace create with new  and only kept hdl_paths & memory map related assignments, now the wall clk time is reduced by 50% but still backdoor sim wall clk time is more than the fron door.

tried assigning null to the ral_env once the backdoor programming is done still no change.

 

Any one has faced this problem? any solution to over come this?

 

following is the tests sim data:

with frotdoor --> took 3msec --> 1hr30mins

with backdoor(+with all the above optimisation) --> took 2msec --> 3hrs

(sim till the backdoor completion took only 14mins, but rest of the sim perf is badly affected)

 

My basic question is , once my backdoor is done, i am assigning null to the ral_env, is the ral_env obj not going into auto garbagecollection and not freeing the memory?

 

We have total 850 registers in my ral_env, all the regs doesn't have any fields also.

 

Adavance thanks for your input/suggestion.

 

Thanks,

Vithal

Share this post


Link to post
Share on other sites

I'd be careful when comparing frontdoor with backdoor, seeing as how frontdoor accesses will take simulation cycles to complete (backdoor is done in 0 time). That extra time that needs to be simulated will also affect the total job length. The frontdoor also has the extra overhead of triggering your bus UVC(s) and the sequencers/drivers/etc. will also slow down your simulation.

 

A fair comparison in terms of simulation length would be with "RAL and frontdoor" against "no RAL and native bus sequences" that do exactly the same thing. It's probably going to run faster without the RAL, but "how much faster?" is the question. Also keep in mind that by not having the RAL you'll lose productivity (no checks => implement your own) and maintanability (you'll pass register addresses around). I'd think this is a trade-off I wouldn't want to make.

Share this post


Link to post
Share on other sites

hi,

 

did you check the runtime and memory profile to identify some slowdown candidates? 

 

>(sim till the backdoor completion took only 14mins, but rest of the sim perf is badly affected)

this sounds as if the backdoor usage has disabled general simulation optimizations. since the backdoor requires vpi/hdl access you simulator might provide option to finetune performance.  

 

please provide more details to understand if this is a simulator specific issue or a general uvm issue.

 

regards

/uwe

Share this post


Link to post
Share on other sites

Hi, Sorry for the late reply. 

tried vcs mem/time profiling but not able to analyse it correctly as the report is a summary at the end of the sim, instead of which sim time it took more mem.

I tried with MTI also and seeing the same perf issue, so it is not tool issue, it is UVM issue(collecting the garbage/cleaning the unreferenced object not cleaned)

following is my test data:

Front door: test took 1.8ms sim time and 1hr 6mins wall clock time.

 

backdoor sim:

0 -- 114usec --> backdoor init configuration done -->took  ~10mins  --> after this deleted the regblock(reg_env has associative array of reg blocks objects till this time & deleted at this time)

114 usec -- 660usec --> test complete. (basically init configuration was taking 1.2ms in front door) --> took 2hrs wall clock time 

 

>>this sounds as if the backdoor usage has disabled general simulation optimizations. since the backdoor requires vpi/hdl access you simulator might provide option to finetune performance. 

yes I guess this is the issue, how to disable this sim access once my backdoor is done?

 

Thanks a lot for your reply & support,

Regards,
Vithal

 

Share this post


Link to post
Share on other sites

Optimizations like that are done at elaboration time, so you can't say you want to enable them later during the simulation. The simulator simply does't track the values of some intermediary signals to make the simulation faster. You'll have to search in the manual how to turn on access only for for the signals you need for the backdoor. I think the switch is +acc in Questa. No idea about VCS.

Share this post


Link to post
Share on other sites

hi,

 

is this a testbench you can share? i'd like to see the cpu profile for the simulation. that should indicate what your simulation is doing all the time. this can be a UVM issue or a simple coding problem or a tool issue. 

 

/uwe

Share this post


Link to post
Share on other sites

hi,

Thanks for you suggestions/time & sorry for the late reply.

After doing the profiling, figured out the there is a configuration issue with & without backdoor simulations.

In frontdoor simulation we are enabling few clks but where as in bkdoor sim we are enabling all theSOC clocks.

After correcting this we see SOC sim time improvements in back door sims.

Thanks a lot for the support.

Regards,
Vithal

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

×
×
  • Create New...