Hello,
I have a couple of questions regarding CoreSight components.
How can I evaluate the bandwidth of CS components ? How to evaluate
energy overhead introduced by activating CS components ? What would be
the best metrics to evaluate CS components or similar debug components ?
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 ?
Thank you very much for your help and time.
Best Regards,
M.Abdul WAHAB
Hi all,
I want to use STM to debug a platform based on cortex a7 under linux and windows.
I want to decode all the packet generated by this component within ETB buffer ,then desplay them in a readebal file.
Could you help please?
Best regards,
Karim.
Hi Mathieu,
Le 15/03/2017 à 18:00, Mathieu Poirier a écrit :
> What do you mean by "bandwidth"? Please give us a little more details.
I am using PTM component to trace a program on Linux. I recover the
trace on FPGA using TPIU. I was wondering what types of program will
generate so much trace that the PTM's internal FIFO will overflow and I
won't be able to get the trace for my program. To evaluate this, I
thought about benchmarking CoreSight with MiBench programs but I did not
see any overflow (by having a look at decoded trace and having a look at
I-Sync packet).
> That won't be easy as it is HW dependent. Energy probes that tap
> directly into the CPU cores would be best but again, the probe points
> need to be present in HW. That's only one part of the equation - the
> debug power domain also has to be measured.
I don't have any measurement tools. I was thinking more about a
simulator or something that would allow me to do it from Zynq SoC. I
think I might be able to get more details on this one from Xilinx as I
am using Xilinx Zynq SoC.
> Again, you will have to give me a little more details on what you need to do.
The idea is to find suitable metrics to evaluate debug components.
Depending on the type of trace source and trace sink, there will be
differences. My trace source will be PTM and I was thinking about first
using ETB as trace sink to evaluate the maximum trace bandwidth. Then,
do the same evaluation with TPIU. I was wondering what will be the
suitable metrics to evaluate CS components efficiency. Is it enough to
benchmark the CS Debug components with MiBench Benchmark and evaluate
execution time overhead.
> I hope this helps
Of course, it helped. Thank you so much for your quick reply.
Best Regards,
M.Abdul WAHAB
The first patch is a minor typo to allow printing the trace info.
The second patch enables translation of perf.data files into last branch events
that are then processed by the autoFDO tool to extract a coverage file.
Sebastian Pop (2):
perf tools: fix printing of auxtrace_info
perf tools: new inject capabilitity for CoreSight traces
tools/perf/Documentation/cs-etm.txt | 38 +++++++++
tools/perf/util/cs-etm.c | 163 ++++++++++++++++++++++++++++++++++--
2 files changed, 196 insertions(+), 5 deletions(-)
create mode 100644 tools/perf/Documentation/cs-etm.txt
--
2.6.3
