Zynq UltraScale+ MPSoC - is event tracing supported

[efraim]

Hello,

I am trying to trace events on mmult_add SDSoC linux sample on the ZCU102 board.

I have the JTAG and the ethernet configured and the application runs as expected. I can also run debugging sessions with no problem. Running tracing sessions however only returns about 2ms of the invocation and only does so once - traces don't ever return anything anymore, until I restart the board.

I've found the following in the release notes of the SDSoC development environment: https://www.xilinx.com/html_docs/xilinx2017_2/sdaccel_doc/topics/development-environment/ref-sdesoc-dev-environment-features.html :

OpenCL™ compilation flows supported for Zynq UltraScale+ MPSoC ZCU102 and Zynq zc702, zc706, and zed platforms.
   Build, software profiling, and debugging flows only (no emulation, performance estimation, or event tracing in this release).

Does that mean that event tracing is not supported in the SDSoC environment too? Or is my setup broken somehow? I've tried doing tracing in both Windows and Linux versions of 2017.2 SDSoC.

[skalicky · Accepted solution]

Hi efraim,

I think you're looking at the wrong information. UG1027 is the Information guide for SDSoC. The latest 2017.2 one is here:

https://www.xilinx.com/support/documentation/sw_manuals/xilinx2017_2/ug1027-sdsoc-user-guide.pdf

Page 86 explains that:

Programming and bitstream - The trace functionality is a "one-shot" type of analysis. The timer used for timestamping events is not started until the first event occurs and runs forever afterwards. If you run your software application once after programming the bitstream, the timer will be in an unknown state after your program is finished running. Running your software for a second time will result in incorrect timestamps for events. Be sure to program the bitstream first, followed by downloading your software application, each and every time you run your application to take advantage of the trace feature. Your application will run correctly a second time, but the trace data will not be correct. For Linux, you will need to reboot because the bitstream is loaded during boot time by U-Boot.

Buffering up traces - In the SDSoC environment, traces are buffered up and read out in real- time as the application executes (although at a slower speed than they are created on the device), but are displayed after the application finishes in a post-processing fashion. This relies on having enough buffer space to store traces until they can be read out by the host PC. By default, there is enough buffer space for 1024 traces. After the buffer fills up, subsequent traces that are produced are dropped and lost. An error condition is set when the buffer overflows. Any traces created after the buffer overflows are not collected, and traces just prior to the overflow might be displayed incorrectly.

Sam

[efraim]

Hello skalicky,

Yes, indeed this appears to be the case, however unlike the description in the document:

After an overflow occurs, an error file is created in the <build_config>/_sds/trace directory
with the name in the following format: archive_DAY_MON_DD_HH_MM_SS_-GMT_YEAR_ERROR.
You must reprogram the device (reboot Linux, etc.) prior to running the application and
collecting trace data again.

the error file is not created.

Thank you for the help.

By the way, is there a way to adjust the trace buffer size in the design?

[skalicky]

Hi efraim,

UG1027 (2017.2 version) is here:
https://www.xilinx.com/support/documentation/sw_manuals/xilinx2017_2/ug1027-sdsoc-user-guide.pdf

on page 110 it says:

-trace-buffer depth

The -trace-buffer option specifies the trace buffer depth, which must be at least 16 and a power of 2. If this option is not specified, the default value of 1024 is used.

Sam