]. 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 . 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  or Vivado design suite . 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.
|TIG – Timing Ignore Constraint
||set_false_path – Define false path
|TIMESPEC – Timing Specification
||set_multicycle_path – Define 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).