Hello,

On 15 March 2017 at 16:06, Muhammad Abdul WAHAB <muhammadabdul.wahab@centralesupelec.fr> wrote:

Hello,

I have a couple of questions regarding CoreSight components.

How can I evaluate the bandwidth of CS components ?

What bandwidth are you interested in? The throughput of the trace infrastructure will depend on the system design, activated trace buffers and trace sinks, trace bus width, and other factors. Trace generation rate is dependent on the code being executed .If the generation rate at the currently traced cores exceeds the rate that the system van sink the trace data then the

trace generation will stall until bandwidth becomes available. This stalling will not affect the operation of the cores - trace will be lost but the core will continue to execute at full speed.

For self hosted trace, then if the trace sink is using system memory then this can have an effect on other programs / components using that memory in the normal way. Additionally for self hosted trace there is overhead in enabling and disabling the trace.

How to evaluate energy overhead introduced by activating CS components ?

Are you currently designing a SoC or are you using an existing device?

If you are in the design stage then I recommend contacting ARM support who may be able to help with energy estimates for these components - hardware emulation should also help in this case.

For existing devices it rather depends if your SoC has any self power monitoring capability. If so then using this with trace powered and running or not should give you an answer. Otherwise you may need to contact the device manufacturer.

What would be the best metrics to evaluate CS components or similar debug components ?

That would really depend on the purpose of your evaluation - what are you trying to discover? Are you using them with an external debugger / on a bare metal system or self hosted on a linux based board?

Besides, I tried evaluating CS components overhead and I did not really see any change in execution time overhead. I understand that this is because the PTM is non-intrusive debug component and that it has a copy of cpu instructions and it operates in parallel. Am I right about this ?

You are correct - the operation of the PTM will not slow down the associated core. It is coupled directly to the core and monitors certain signals which allow waypoint trace to be generated. Waypoints are flow control changes that cannot be directly inferred from the opcodes being executed. The trace decoder will then take the waypoint trace packets and the memory image of the opcodes executed to decode the program flow over time. So not every instruction is traced as an output packet

I recommend reading the PTF architecture manual for further explanation of program flow (PTM) trace.
[http://infocenter.arm.com/help/topic/com.arm.doc.ihi0035b/index.html}

Thank you very much for your help and time.
Best Regards,
M.Abdul WAHAB
_______________________________________________
CoreSight mailing list
CoreSight@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/coresight

Best Regards

Mike Leach

Principal Engineer, ARM Ltd.

Blackburn Design Centre. UK