c4brian 5 Report post Posted November 13, 2015 This is mostly likely some hang-up between my architecture, and my tool (RivieraPro), but my profiler results basically have 84.55% CPU used by "other-code" with no details as to what that means, and the remaining percent distributed to my top testbench files (and all their children). Anyone run into anything like this in RP, or another tool? Something is eating my simulation alive the longer it runs... Quote Share this post Link to post Share on other sites
apfitch 205 Report post Posted November 14, 2015 One possibility is that you don't have access specified (+acc - not sure in Riviera Pro) which is why it can't report on the "other" code. In Questa you can add -classdebug to get better visibility into classes. Another hackier option is just to hit break a number of times and see where the break occurs. There's a good chance it'll stop in the code that's eating the simulation resources. regards Alan Quote Share this post Link to post Share on other sites
kirloy 0 Report post Posted November 16, 2015 Some issues with "other code" was fixed in newest Riviera 2015.10. Please try it. Quote Share this post Link to post Share on other sites
c4brian 5 Report post Posted November 16, 2015 Alan, Ive got +access+r specified. I'll try your break technique. Just ran with the new RP, and 85% of my CPU cycles are still dumped into "other code", in the hierarchy tab. All my testbench classes are simply listed as a list of packages, and none of them have any cycles associated with them. I'm not sure how it should be displayed, but I thought perhaps it might have a hierarchical display like test - env - children - etc. could someone give me some kind of ballpark metric, like for a single component testbench, the HDL might eat up say, 50% of your CPU, and the testbench another 50%, or is it 90/10.. etc? According to my report, my DUT is only pulling around 2% of the CPU. Quote Share this post Link to post Share on other sites
kirloy 0 Report post Posted November 18, 2015 For design using UVM from separate library -profiler_all must be used for asim command instead -profiler. -profiler collects data only for working library code. Other code in this case represents code from libraries other than work - in this case from UVM. When you use -profiler_all then code from all libraries used in simulation is profiled. If UVM needs to be profiled this is also good idea to use debug version of UVM (compile UVM with -dbg switch and use library created this way) Quote Share this post Link to post Share on other sites