targetInfo return values

3 posts / 0 new
Last post
EJing
Offline
Last seen: 1 week 1 day ago
Joined: 12/05/2016 - 9:47pm
targetInfo return values

Hello,

I am not clear on exactly what the different fields mean in targetInfo.   Specifically, what are the meaning and units of profileTime and profilePercent? 

 

>> SYS.agc.targetInfo

ans =

heapSize: [3x1 double]

heapName: {3x1 cell}

mangledName: 'agc'

objectAddr: []

objectID: []

profileTime: 5.0664

profilePercent: 0.0739

isSIMD: 0

MIPS: 0.0038

EJing
Offline
Last seen: 1 week 1 day ago
Joined: 12/05/2016 - 9:47pm

Also, for profiling, how many times and how often should I be reading SYS.agc.targetInfo to a running average of the last few secs of profiling data?

Please advise.

PaulB
Offline
Last seen: 2 days 14 hours ago
Joined: 10/04/2016 - 11:43pm

All profiling is based on a profiling clock which is part of the BSP.  The speed of the profiling clock is implementation dependent.  Some DSPs and MCUs have cycle accurate profiling.  Often Linux systems using a 10 MHz profiling clock.  You can see how fast your profiling clock runs on the Server.  Do Target->Show Info.  Find the "Profile clock rate" entry.

Name: Native
AWECore Version: 8.B.0.0
Processor type: Native
CPU clock rate: 2.904 GHz
Profile clock rate: 10 MHz      <<< This  is the info
Sample rate: 48000 Hz
Basic block size: 16 samples
Communication buffer size: 4105 words
Is floating point: Yes
Is FLASH supported: No
Size of 'int': 4
Cores: 2
Heap padding
Core ID: 0 [0:0]

The .profileTime entry is how many profile clock ticks on average does it take for the AGC module to execute.  The modules have built in smoothing of the profiling information.  It uses a first order smoother and averages over roughly 500 blocks.  That is, the module should execute at least 500 times for this information to stabilize.

The .profilePercent field represents what total fraction of time is used by the AGC module.  This is a fraction of the time available between calls to the pump function.

All this information is correct if your design is running at a single clock divider.  If you are using multiple threads, then the information for the low priority threads will be off since the low priority modules will be pre-empted by higher priority modules.