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