In this series:

In the previous posts of this series, I explained what timing errors are and how to fix them when they happen in a Xilinx System Generator model. To quickly recap:

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.

With this in mind, most of the time you can meet the timing constraints by cutting the critical paths through the use of additional registers and by properly configuring Xilinx blocks.

But if these simple tricks do not resolve the issues, you might have to look outside the box – meaning that the problem might be external to the System Generator model itself. This blog post identifies some of the most frequent sources of errors and provides some solutions to explore. For example, it can be a bad design relative to the clock, false constraints that fail, or sub-optimized project settings.

Validate the clock

The clock plays a key role in the timing constraint equations. Particular care must be taken with it, specifically with regards to:

·         Clock frequency – The timing constraints are directly derived from the specified clock frequency, so be sure to specify the right one. For example, if you have a clock frequency of 80 MHz, do not round it as if it was 100 MHz. This would result in a much harder to meet timing constraint – 10 ns instead of 12.5 ns!

·         Clock distribution – In a regular design, jitter and clock path skew are negligible. In our previous example, these values were in the sub-nanosecond range while the data path delays were many nanoseconds long

[1]. If this is not the case, it means that there is something wrong with the clock and it’s likely that no dedicated paths are used to distribute the clock. In this case you might want to read more about BUFIO, BUFG, and BUFR, which are specific resources instantiated to use dedicated clock trees.

·         Clock generation – Unless you know exactly what you are doing, clocks should always originate from dedicated clocking resources, like phase-locked loops (PLLs), mixed-mode clock managers (MMCMs), or dedicated clock inputs. No logic should be involved. For example, the usage of a binary counter to reduce clock frequency should be avoided.

Are the timing constraints necessary? Do they make sense?

All registers clocked by the same source are automatically grouped by the synthesis tool and the associated timing constraints are generated. However, some timing constraints are often irrelevant or unnecessary and can be removed. As a designer, you need to identify these paths and instruct the synthesis tool to ignore them.

For instance, resets are a good example of signals having hard-to-meet timing constraints as they are usually connected to a high number of memory elements located throughout the chip (high fan-out). But, if you know that a reset is held for many clock cycles, its associated constraints are generally useless.

Signals that do not need to be valid within one clock cycle or signals that we know are available for many clock cycles before the start of processing are also good examples of unnecessary constrained paths. Their associated timing constraints can be removed or relaxed. To help understanding the point, Figure 1 shows the example described in [1]. The critical path was determined by the red line and was 20 ns. This was based on the facts that A, B and C can change after any rising edge of the clock, and the result D must be stable before the next rising edge.

Figure 1: Critical path of a synchronous digital circuit

Let’s suppose now that A and B are parameters and are fixed before any processing on the C input. During the time A and B are being set, we do not care about the result D. Then, during run time, while A and B are fixed, C continuously changes and therefore the result D too. The intermediate result of the and gate is fixed and therefore not a part of the critical path any more. The new longest path is shown in Figure 2 and is reduced to 13 ns.

This kind of scenario where some parameters are set before the processing starts often happens in real life designs. Removing or relaxing such unnecessary timing constraints solve their associated timing issues and generally helps with other constraints not directly implicated. The synthesis tool can then concentrate on the true challenging paths and has more flexibility to meet their requirements.


Figure 2: Critical path of a synchronous digital circuit when ignoring false paths

Timing constraint syntax and methodology differs greatly if you are using ISE [2] or Vivado design suite [3]. You can specify them manually through ucf or xdc file respectively. Both design suites also offer entry tools for constraints. Here are some of the key timing constrains you may want to look at.

ISE Vivado
TIG Timing Ignore Constraint set_false_path Define false path
TIMESPEC Timing Specification set_multicycle_pathDefine multicycle path

Set synthesis tool options for timing

FPGA design is usually an iterative process where you continuously go back and forth between many design entries, synthesis tools, simulations, and/or hardware tests. To avoid an unnecessary slowdown of build times, the default synthesis settings are usually not the most effective in terms of timing performance; rather, they typically offer a balance between build time, speed, and design area. There are many parameters you can play with to improve the timing. Some of the simplest are the optimization goal and the level effort of the synthesis and implementation tools. I encourage you to play with these options if timing constraints are not met.

Note: if you are generating your bitstream directly from System Generator, you must edit the opt files.


Unfortunately, timing errors might occur even if you follow good design practices within your System Generator model (i.e. you restrict your combinatorial paths to a reasonable amount of logic and that you configure the Xilinx blocks appropriately). There are a lot of different reasons which are unmanageable within System Generator, including bad clock usage, false paths failures, or sub-optimal synthesis options. To fix these timing errors, you have to look outside System Generator.­

In the end, it might even be just impossible to do what you intended to achieve. In this case you may have to redesign or change the targeted FPGA (speed grade or family).­­