Debugging FPGA-based video systems: Part 1 - Embedded.com

# Debugging FPGA-based video systems: Part 1

Editor’s Note: In this two part 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 video streams in real time. Part 1: Timing analysis and debugging.

In this series of articles we will discuss some strategies for debugging a video system built in an FPGA. The examples use Altera’s video debugging tools and methodology, although the concepts can be applied generally.

Before moving on to the video-specific parts of debugging it is worth checking that the design has synthesized correctly and has passed a number of basic sanity checks.

Timing Analysis
Hardware designs that run from a clock need to meet a number of timing constraints. The two most basic of these exist to prevent errors if a signal changes while it is being sampled by a register: The input to a register must be stable for a time before the clock edge on which it is sampled e referred to as the setup time (Figure 21.1 ).

Figure 21.1. Setup and hold times

Most signals originate from registers in the same clock domain, the outputs of which change just after the clock edge (i.e. there is a delay going through the register). There are also delays while the signals pass through combinational logic, and further delays if the signals need to be routed across the chip to their destination. The sum of these delays is known as the propagation delay. The mathematical relationship between the delays is expressed by the following two equations which must be satisfied for all paths within the chip:

propagation delay þ setup time < ¼ clock period
propagation delay > ¼ hold time

Where < ¼ is the mathematical less than or equal symbol, and > ¼ is greater than or equal There are more complex timing issues when signals cross from one clock domain to another but these are usually handled by specially designed library components.

A hardware design where these equations are satisfied for all signals on the chip is said to meet timing. A design which does not meet timing will usually fail in subtle and unexpected ways so further debugging is not usually productive.

Check that the Design Meets Timing
During synthesis the layout tool will place the logic within the chip and then run a timing analysis to check that the design meets the setup and hold requirements of the chip that will implement it. If these requirements are not met, the tool will adjust the layout and run the timing analysis again, continuing until timing analysis passes.

For the timing analysis stage the designer must provide scripts to tell the tool what timing behavior is required. These scripts are written by the hardware designer and shipped with the library component (if you write your own hardware with multiple clock domains then you will need to provide these scripts). If these scripts are incorrect, or if the clock speeds set in the scripts are lower than the actual speed of the clock, then the design can fail even if it meets timing.

A timing failure in one part of the circuit can cause problems elsewhere in the design, because if one part of the design fails to meet timing then the tool will stop rearranging the design throughout the chip. It will report the errors that have caused it to stop processing, but may suppress errors for other areas of the design which have not been completely processed. Thus a timing failure in one part of the chip is said to hide failures elsewhere in the design.

The propagation delay varies with several factors: The temperature of the silicon within the chip: recent chips run fastest at room temperature and slowest at the top and bottom ends of their temperature range. Manufacturing variations can change the propagation delay between one batch of chips and the next.

Manufacturers partly deal with this by measuring the speed of chips after production and assigning a higher speed grade (and price) to those with lower propagation delays but there is still a small variation within each speed grade.

Small changes in the supply voltage: tolerances within the power supply components allow for difference between the supply voltages from one board to another. The timing analysis tool will usually check the timing multiple times with different timing modes e for example it will check both the maximum and minimum propagation delays for the temperature and manufacturing variation.

All timing models for a design must pass before it can be used in a production system is used when timing passes only at lower temperatures: a liberal application of freezer spray to the chip can make a design work for a minute or two e often long enough to indicate that timing is the cause of failures.Fix Your Design if it Does Not Meet Timing
Here we will bereferring back to the two basic timing equations earlier. In most chipsthe propagation delay is significantly larger than the hold time, so thefirst equation is the harder to satisfy. This equation can always besatisfied by decreasing the clock frequency (increasing the clockperiod) but this is usually unsatisfactory, especially for video designswhere a minimum clock frequency is required to process all the pixelsin a frame.

Another method is to buy a chip at a faster speedgrade. Unfortunately this has cost implications or is not possiblebecause previously shipped products need to be upgraded. Other methodsof making a design meet timing include:

1. inserting buffer registers to reduce the length of combinational paths;
2. changing the layout to place critical registers closer to each other; and
3. reducing the fan out of signals (which can increase switching speed and make the layout simpler).

Ifthe timing tool reports hold-time violations that reducing the clockspeed will not fix, design changes are required. Refer to FPGA Design: Best Practices for Team based design (Simpson) ISBNe13: 978-1441963383.

Ifyou are using library components to create your design then thecomponent designer will have already considered these issues and mayhave included parameters which help their component meet timing (usuallyin exchange for an increase in size or latency). Many libraries includecomponents called pipeline bridges (or similar names) which can be usedto easily insert buffer registers into all the signals of a bus withoutaffecting its behavior.

The SystemConsole Debugger
Aswe will use SystemConsole as an example of a tool running on a debughost we will now provide a basic introduction. Debug tools usually referto the system being debugged as the target e the system which you useto debug the target is the debug host.

The host will beconnected to the target via one or more debug cables (nowadays these arenormally JTAG, USB or Ethernet though debugging over other media ispossible). To enable debugging, the system designer places debug agentswithin the target system (Figure 21.2 ). These agents aresometimes packaged within other components e for example, most processorcomponents now contain a debug module e or they can be explicitlyinstantiated by the system designer.

Figure 21.2: Deubg agent for clock sense indication

Thosedebug agents that use a JTAG interface to communicate with the host areautomatically connected to the JTAG pins on the device by the Quartussoftware. In the current Altera software, debug agents using othercables (USB and Ethernet) must be explicitly connected to the pins onthe device.

Check That Clocks and Resets are Working
Incorrectlyfunctioning clocks or resets are a common cause of design failures,which should be ruled out early in the debug process e even experiencedengineers have wasted hours of time debugging apparently failed systemswhere the clock has been disabled or the wire supplying the clock signalfrom a test device to the board has been knocked off.

Othercauses of clock failures include Phase locked loops which are unable tolock because their input signal has too much jitter or is outside theacceptable range of input frequencies. Reset signals can also becomestuck e either holding part of the design in reset permanently or neverresetting it.

If a design is not reset then it does not start ina consistent state, and may get into a state that its designer did notintend. Sometimes a design will get out of these unusual states andsometimes it will become stuck. FPGA designs with reset faults sometimeswork because the configuration logic within the FPGA sets mostregisters to their defined reset state at the end of configuration.

Mostdebug tools, for example the Altera SystemConsole tool, provide ways tocheck that clocks are running and resets are behaving correctly. InSystemConsole the explorer window shows a green clock badge on nodesthat have a running clock and a red clock badge (with associatedtooltip) on nodes which can sense the clock but do not detect itrunning.

It also provides the jtag_debug service to givescripted access to the clock sensing hardware. The TCL (Tool CommandLanguage) code below shows an example of its use:

set jd [lindex [get_service_paths jtag_debug] 0]
open_service jtag_debug \$jd
puts “Clock running: [jtag_debug_sense_clock \$jd]”
puts “Reset status: [jtag_debug_sample_reset \$jd]”

This article is from a chapter in Digital Video Processing For Engineers , by Michael Parker and Suhel Dhanani and is used with thepermission of the publisher Newnes (Copyright 2013), an imprint ofElsevier Ltd.

Next week: Part 2,  “Clocked and Flow Controlled Video Streams”

Andrew Draper is a principal design engineer at Altera Corp. and is based in Chesham,Buckinghamshire, United Kingdom. He received his engineering trainingat Cambridge University and Godalming College before going on to work atPhilips Consumer Electronics and Madge Networks.

## 1 thought on “Debugging FPGA-based video systems: Part 1”

1. David.Walker says:

Well, off to a flying start! At least half the article is not about the title subject! It is poorly written (or copied) “All timing models for a design must pass before it can be used in a production system is used when timing passes only at lower temperat