In this series:

As discussed in the previous blog posts in this series, Xilinx System Generator provides many advantages when prototyping and designing highly demanding signal processing applications that target field-programmable gate arrays (FPGAs). Its high-level environment means that designers do not require in-depth FPGA expertise and can concentrate on their algorithms instead. This is definitely one of the main reasons why System Generator is adopted by so many researchers and MATLAB users.

While System Generator hides as much as possible FPGA complexities, with all their considerations and constraints, designers must still be aware of some FPGA aspects. An obvious one is that FPGAs do not have an infinite number of resources. When designers encounter this issue, they usually quickly realize that some optimizations to reduce logic usage must be done or that they require a larger FPGA.

Another issue often faced by users (including the most experienced ones) is timing errors. Timing issues are part the normal workday for a digital circuit designer. For people with a limited knowledge of digital circuits, however, they might appear as a big and mysterious challenge and the solutions for resolving them may not be obvious.

This blog post is intended to help people better understand timing issues. Subsequent posts will provide tips and tricks for avoiding or fixing such errors when designing with System Generator.

How do I know if I have timing issues?

Whether you build your FPGA model directly from System Generator or you integrate your model into a larger project and then build it, if you see a message from the synthesis tool similar to “design did not meet timing requirements”, then you have timing issues. Depending on the build options, a bitstream file might still be available but it could demonstrate indeterminate behaviour. This bitstream should not be used except if you know exactly what you are doing.

Within System Generator and MATLAB, designers can validate that their model works; that is, it produces the expected results at the correct time. The synthesis tool validates that your design can perform the required work within the specified clock period.

FPGA timing constraints

Before fighting against timing issues, designers must have an idea of what they are.

Most digital circuits nowadays are synchronous. This means that the logic is encapsulated between registers. The transitions to all input registers must be stable before the next rising edge of the clock so that the behaviour of the entire circuit can be predicted.

Figure 1 shows a simple synchronous design. The clock is common to all registers and its maximum achievable frequency depends (among other things) on the logic between the registers and the targeted FPGA family/technology. It usually varies from tens to hundreds of megahertz. External interfaces with dedicated hardware might be faster.

Figure 1: A synchronous digital circuit

Figure 1: A synchronous digital circuit

The same principle applies to all System Generator models. All memory elements (registers, shift registers, memory blocks, FIFOs, delays, etc) should be seen as registers and all logic blocks without inherent delay represent logic. In the same manner, Xilinx System Generator blocks that have delays can be broken down into memory elements and pure logic blocks.

The timing constraints of such digital circuits are derived from the fact that all signals must be stable before the next rising edge of the clock. In the example of Figure 1, on the clock’s rising edge, if A, B or C changes, the result D must be stable before the next rising edge. The timing constraints are derived from the following factors:

·         Propagation delay – Sometimes called data path delay, the propagation delay is the time required to travel from one register to the next. It is the sum of the logic and wiring (routing) delays.

·         Clock path skew – Caused when the clock follows different paths and thus has different arrival times when reaching each register. Most FPGAs have dedicated paths to distribute the clock and minimize the skew.

·         Clock uncertainty (jitter) – Clock periods differ slightly because of jitter.

·         Setup and hold time – Intervals before and after the clock where the data must be held stable.

Figure 2 shows the different elements constituting the timing constraints. Most of the time, propagation delay is the main factor. The synthesis tool (or more precisely, the place-and-route step) minimizes the routing delay by packing interconnected logic together as locally as possible. Therefore, the logic delay is generally the main factor. Since the logic is directly derived from the implemented algorithm and designer choices, it means that we can fix most of the timing issues directly from System Generator!

Figure 2: Delays

  Figure 2: Delays

Numerical example

In Figure 3, we add some sample delay numbers to our previous example. If we ignore the negligible parameters, the longest propagation path (the critical path) must be smaller than the clock period. This path corresponds to the one highlighted in red. It gives a delay of 20 ns (2ns + 7ns + 1ns + 9ns + 1ns). The maximum clock frequency is therefore about 50 MHz (1/20ns). If the specified clock frequency is higher than that, the synthesis tool will raise timing errors for the path failing the constraints.

Figure 3: Delays           

Figure 3: Delays

Conclusion

If we simplify the timing constraint equation, we can state that timing errors roughly occur when the propagation delay is higher than the required clock period. This means that we are trying to do too much within one clock period. We can work on the System Generator model to reduce the amount of work performed every clock cycle. In the next blog posts in this series, we’ll provide some tips and tricks to fix these­ ­­issues.