Troubleshooting Runtime Errors

Programs compiled usingsdscc/sds++can be debugged using the standard debuggers supplied with the SDSoC™ environment or Xilinx® SDK. Typical runtime errors are incorrect results, premature program exits, and program “hangs.” The first two kinds of errors are familiar to C/C++ programmers, and can be debugged by stepping through the code using a debugger.

A program hang is a runtime error caused by specifying an incorrect amount of data to be transferred across a streaming connection created using#pragma SDS data access_pattern(A:SEQUENTIAL), by specifying a streaming interface in a synthesizeable function within Vivado HLS, or by a C-callable hardware function in a pre-built library that has streaming hardware interfaces. A program hangs when the consumer of a stream is waiting for more data from the producer but the producer has stopped sending data.

#pragma SDS data access_pattern(in_a:SEQENTIAL, out_b:SEQUENTIAL) void f1(int in_a[20], int out_b[20]); // declaration void f1(int in_a[20], int out_b[20]) { // definition int i; for (i=0; i < 19; i++) { out_b[i] = in_a[i]; } }

Notice that the loop reads thein_astream 19 times but the size ofin_a[]is 20, so the caller off1would wait forever (or hang) if it waited forf1to consume all the data that was streamed to it. Similarly, the caller would wait forever if it waited forf1to send 20 int values becausef1sends only 19. Program errors that lead to such “hangs” can be detected by using system emulation to review whether the data signals are static (review the associated protocol signalsTLAST,ap_ready,ap_done,TREADY, etc.) or by instrumenting the code to flag streaming access errors such as non-sequential access or incorrect access counts within a function and running in software. Streaming access issues are typically flagged asimproper streaming accesswarnings in the log file, and it is left to the user to determine if these are actual errors. Running your application on the SDSoC emulator is a good way to gain visibility of data transfers with a debugger. You will be able to see where in software the system is hanging (often within acf_wait()call), and can then inspect associated data transfers in the simulation waveform view, which gives you access to signals on the hardware blocks associated with the data transfer.