cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
efraim
Observer
Observer
1,292 Views
Registered: ‎08-02-2017

Zynq UltraScale+ MPSoC - is event tracing supported

Jump to solution

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.

0 Kudos
Reply
1 Solution

Accepted Solutions
skalicky
Explorer
Explorer
1,755 Views
Registered: ‎09-19-2017

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

View solution in original post

3 Replies
skalicky
Explorer
Explorer
1,756 Views
Registered: ‎09-19-2017

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

View solution in original post

efraim
Observer
Observer
1,192 Views
Registered: ‎08-02-2017

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?

 

0 Kudos
Reply
skalicky
Explorer
Explorer
1,188 Views
Registered: ‎09-19-2017

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