i.MX8QXP debug trace options

[EAlepins]

Hi,

i.MX8QXP (ARM Cortex-A35) has debug trace feature. However, I am a bit confused about:

1) The information tracing provides. Do you have a list? There is at least:

• profiling (functions duration and number of calls)
• object code coverage
• But is there other information as well? For example cache misses/hits; PMU data; other interconnect's traffic information; etc.?

2) I think there are no external ETM pins to the SoC. Hence, I understood there were 2 means to output trace data:

• on-chip: store data to DDR (can it be stored elsewhere?)
• off-chip: stream data outside of SoC. I saw on the Internet PCIe bus used for that. But does the i.MX 8X is limited to using that bus or any other would work?

3) Does trace data pass by the central SoC interconnect (DRAM Block + Big Node) or is has a dedicated internal bus? If through the SoC interconnect, then I can't see how ETM tracing can be non-intrusive. There will be application performance degradation when tracing is enabled. Am I right? Do you have examples showing the percentage of interference obtained?

4) PCIe intrusivity: same question, but for off-chip tracing through PCIe. Trace data traffic going through PCIe will collide with applicative's PCIe data. Do you have examples showing interference? Or an applicative PCIe occupation threshold (X% PCIe bandwidth) below which adding PCIe trace has no significant impact?

Thanks,

Étienne

[igorpadykov]

Hi Étienne

I asked internally and got below :

------------------------

For Linux BSP, we support OProfile, which can be found from Linux BSP reference document:

Chapter 2.6 OProfile.

And in Linux BSP, we can use followed command to track the DDR loading:

     perf stat -I 1000 -a -e ddr0/read-cycles/,ddr0/write-cycles/,ddr0/cycles/

We don't have tools to track PCIE.

------------------------

Best regards
igor

[igorpadykov]

For Linux BSP, we support OProfile, which can be found from Linux BSP reference document:

Chapter 2.6 OProfile.

And in Linux BSP, we can use followed command to track the DDR loading:

     perf stat -I 1000 -a -e ddr0/read-cycles/,ddr0/write-cycles/,ddr0/cycles/

We don't have tools to track PCIE.

[EAlepins]

Hi,

Thanks for your answer. However, we will not be using Linux. And when I was mentioning PCIe, I was not talking about sniffing the PCIe traffic but rather use the PCIe bus as a mean to export the tracing information generated inside the i.MX 8X SoC.

My question is not related to tools provided by NXP, but rather to understand the tracing capabilities at HW level of the SoC itself. Can you help on my initial questions?

Thanks,

Étienne

[Aubineau_FAE]

Hi,

You can get in touch with Lauterbach, they have solutions to perform ETM -> ETR -> PCIe -> external PowerTrace on i.MX8.

Regards,

Vincent

[igorpadykov]

------------------------

For the ARM core debug trace, I think the customer can check ARM Technical Reference Manual, the hardware interface is the JTAG interface. 

I haven't seen special trace functions on iMX8X soc.

 ------------------------

Best regards
igor

[igorpadykov]

For the ARM core debug trace, I think the customer can check ARM Technical Reference Manual, the hardware interface is the JTAG interface. 

I haven't seen special trace functions on iMX8X soc.

 ------------------------

[igorpadykov]

For the ARM core debug trace, I think the customer can check ARM Technical Reference Manual, the hardware interface is the JTAG interface. 

I haven't seen special trace functions on iMX8X soc.

[EAlepins]

Hi,

i.MX 8X trace functionality is described in Reference Manual (IMX8DQXPRM) §Chapter 6 "Debug Architecture" and §6.2.1 ETR and §6.2.2 ETM. So there is trace support in i.MX 8X.

What I am not able to find is the interference that ETM will cause in the i.MX 8X SoC:

- Are the trace information sent on the same interconnect as used by the rest of the SoC? (Cortex-A35, etc.) (i.e. on DB Ram and Big Node)

- Does NXP has experience or projects that showed how much PCIe interference the trace was causing? For example, using PCIe Gen 2,for a full SW running on 4 Cortex-A35 cores, how much % of the PCIe bandwidth is occupied by trace data? Or any other data you have giving me an idea of the order of magnitude of the performance drop caused by the trace.

Thanks,

Étienne