Debugging FPGA-based video systems: Part 2

Andrew Draper, Altera Corp.

June 02, 2013

Andrew Draper, Altera Corp.June 02, 2013

Editor’s Note: In Part 2 of this series from Digital Video Processing For Engineers, Andrew Draper describes some of the strategies for debugging an FPGA-based video system to be sure it reliably delivers the necessary video streams in real time. Part 2: Clocked and flow controlled video streams.

Most digital video protocols send video frames between boards using a clock and a series of synchronization signals. This is simple to explain but it is an inefficient way to communicate within a device, as all processing modules need to be ready to process data on every clock within the frame, but will be idle during the synchronization intervals.

Using a flow-controlled interface is more flexible because it simplifies processing blocks and allows them to spread the data processing over the whole frame time. Flow-controlled interfaces provide a way to control the flow of data in both directions e the source can indicate on which cycles there is data present and can backpressure when it is not ready to accept data.

In the Avalon ST flow-controlled interface the valid signal indicates that the source has data and the ready signal indicates that the sink is able to accept it (i.e. is not backpressuring the source).

If you are building a system from library components, most problems will occur when converting from clocked-video streams to flow-controlled video streams, and vice versa.

Debugging Tools
Several debugging tools are available: the most basic tools of which are an oscilloscope, logic analyser or (within an FPGA) an embedded logic analyser (such as Altera’s SignalTap tool). These tools provide a high-resolution view of the data being transferred on a number of signals.

If you have data integrity issues between boards, then low-level debugging tools such as these can be used to diagnose the problem. Unfortunately, once the signals between boards or within devices are clean, these tools typically provide too much data to diagnose the types of problems that appear at higher levels.

Higher-level debug tools provide a way to trace the data passing through the system and display it as video packets. The amount of data in a video system is more than can easily be transferred, so it must be compressed to allow it to be transferred to the debug host and analysed.

The highest level of compression can be achieved by ignoring most of the pixel values and only transferring control packets and statistics about the data flow for example, a count of the number of clock cycles where data was transferred, was not available to transfer from the source or was back-pressured by the sink.

The Altera trace system (Figure 21.3) is instantiated when you are building a video design within the QSYS environment. Two parts are needed: a trace monitor component for each interface to be traced and a trace system component which transfers trace data packets to the host.

Click on image to enlarge.

Figure 21.3. Trace monitors and the trace system

A video trace monitor component needs to be inserted into each video stream you want to monitor. This component is nonintrusive e it has no effect on the video data going through the stream. The video trace monitor component reads the signals being transmitted and sends summaries to the trace system.

You will need to parameterize the video trace monitor to match the type of data being sent and to match the trace system data-width. The trace system component takes the reports from the trace monitors and buffers them before sending the results to the host over JTAG or USB, where they are reconstructed for the user.

You will also need to parameterize this component to select the type of connection to the host, the number ofmonitors, the buffer size, etc. The SystemConsole host application decodes and displays the received packets to show the data as it passes through the system (Figure 21.4). Each video packet is displayed as one line in the display. Follwing in the rest of this article are descriptions of some common video errors and how to recognize them in the trace output.

Click on image to enlarge.

Figure 21.4: Example of decoded trace output

Debug tools are also available which allow the debug host to access memory mapped slaves within the target. The Altera JTAG Avalon Master and USB Debug Master components are explicitly designed to do this: if you do not have such a component available then most processor debuggers can be used in a similar way.

Converting from Clocked to Flow-controlled Video Streams
In a functioning system the input to the flow-controlled domain will send data as it becomes available. The system needs to transfer, on average, one line’s worth of pixels in each line scan time. The transfer of data will normally be controlled by “valid”, with “ready” asserted occasionally to select the cycles on which data is accepted.

The number of cycles on which “valid” is asserted depends on the ratio between the screen resolution and the clock rate in the flow-controlled domain. If the clock is just sufficient for the highest resolution then “valid” will be asserted on most cycles within the main part of the frame. At lower resolutions “valid” will only be asserted on a proportion of the cycles.

The “ready” signal to the clocked video input should not be the main source of flow control on the frame, so it is typically deasserted only for short periods to synchronise with the sink. One common problem is that if “ready” is de-asserted for too long then the memory buffer in the video input block can overflow.

Attaching a streaming video monitor to the output of the video input block can help detect overflow situations e if the video input block is backpressured (by de-asserting “ready”) for too long then it will abandon the backpressured frame and send a short packet.

This can be seen on the trace. The trace also reports the number of not-ready cycles within each packet and the time interval between packets. This can be used to check that the interface is being mostly flow-controlled by “valid” rather than “ready”.

If the clocked video-input block has a control port then the debug master can be used to check the overflow sticky-bit in the status register. This bit will be set if there has been an overflowsince it was last checked - note that if you have software monitoring and clearing this bit then reading it from the debugger will not be reliable.

< Previous
Page 1 of 2
Next >

Loading comments...