FPGA Timing Constraints & HW debug: What could go wrong?

Sometimes we spend long hours or even days in the lab debugging FPGA-related issues because of non-working designs or intermittent HW problems. You may have a design that works for a while then fails or even changes behavior between different place and route implementations. Non-persistent problems and reliability issues are the hardest to debug and can be time-consuming. Design methodology is very important to have a structured way of building your design.

What could be the root cause of these problems? Multiple sources could be identified:

-????????? Poor timing constraints

-????????? Poor reset strategy

-????????? Signal integrity issues

-????????? Power supply problems

-????????? Board Manufacturing defects

-????????? Etc.

In this article we will focus on the importance of timing constraints and how that could impact design implementation. A large percentage of FPGA board failure issues could be related to timing constraints.

In general, a design that passes the functional simulation phase and has proper timing constraints with good timing coverage has a good likelihood of working in hardware.

An FPGA design goes through multiple phases from the specification document to the hardware implementation and test on the board. Proper design methodology is very important to clear problems at an early stage of the design and not have to carry them through the design process when they become much harder to identify and solve. ?Timing constraints are one of the fundamental steps that could play a very big role in minimizing the debugging time in the lab.

Someone may say, my design meets my target frequency, what could go wrong? Let’s explore what types of problems could arise from timing constraints.

• Low Timing Coverage of Your Design

First, what is timing constraint coverage? And why is it important to look at?

Any flip-flop-to-flip-flop path in a digital synchronous design whether internal or external to the FPGA, needs to be constrained. FPGA STA (Static Timing Analysis) tools will analyze all the paths in an FPGA design: Inbound, outbound, and internal paths for timing violations (Setup & Hold). The timing coverage measured in percentage (%) is calculated by dividing the number of paths covered by timing constraints by the total number of paths identified by the STA tool (Any flip-flop to flip-flop connection). Ideally, we should have 100% coverage. If the percentage is lower than 100%, that means that some paths are not constrained in your design. These paths are not optimized by the implementation tools nor reported by the STA. This means that the synthesis and the place-and-route tools do not have any target to optimize these paths against. This situation could obviously lead to different implementations for each run. On the hardware you can have intermittent problems, where design works fine for one implementation and does not on another one.

• Timing Constraints Ignored by the Tool.

Timing constraints resolution is important to understand to avoid having some constraints ignored because of conflict. A variety of management rules are set to resolve the potential conflict between the different timing constraints:

·???????? Pre & Post synthesis constraints: Post-synthesis constraints override pre-synthesis in case of conflict.

·???????? SDC constraint file: The order of constraints matters. SDC file is processed sequentially line by line; line 2 takes precedence on line 1. In case of conflict, line 1 will be ignored and line 2 take effect. ?

·???????? Level of details on the timing constraints: The more specific constraint gets higher priority.

·???????? Timing constraints and exceptions priority (e.g., “set_clock_groups” has higher priority than “create_clock”).

• Wrong Usage of the Timing Exceptions:

Timing exceptions could mask real timing violation. For example, a false path or multicycle path constraints is used to relax the implementation and make the synthesis or place and route tools focus on areas where more aggressive timing needs to be achieved. By unintentionally relaxing certain paths you create a situation where the Synthesis and PAR tools relax paths that should not be relaxed. This will lead to potential hardware timing violation (e.g. a design with 2 clock domains clk1 and clk2, using “set_false_path” between clk1 and clk2 will make the implementation and STA tool ignore any paths between these clock domains even if they are not covered by CDC circuit). Be very careful when applying these exceptions as they could mask some timing errors and lead to hardware failure. Knowledge of the design is very important when adding these types of constraints.

• Clock Domain Crossing (CDC)

Another common pitfall is the clock domain crossing. When a design has multiple clock domains, you may be faced with a situation where a control signal or data path crosses from one clock domain to another. This creates design challenges that need to be covered by a proper CDC circuit. Even when the main clock frequency is the same but coming from a different oscillator (e.g., CLK1: 100Mhz from crystal 1 and CLK2: 100MHz from crystal 2). The phase relationship between the 2 clocks is unknown and could vary based on the crystal ppm (parts per million) difference. You are still considered to be in an asynchronous system. Special attention needs to be taken to build a proper CDC circuit that guarantees a reliable transfer of data between the two clock domains. STA tools will identify and report these paths under the clock summary section.

Conclusion

Field Programmable Gate Arrays (FPGAs) have a very flexible architecture that is well-adapted to multiple end applications. However, that flexibility comes with some challenges that need to be resolved by the designers. Timing constraints are one of these challenges that could have a ripple effect on the hardware implementation. Designing a reliable hardware that meets the required performance heavily depends on proper timing constraints. We have not discussed in this article the impact of poor clocking structure, which is another important part of the design methodology.

Timing constraints is a subject that sometimes overlooked but could end up being very expensive in hardware debugging time. A lot of resources are available to deepen your knowledge on this subject. You can refer to the Lattice Insights training website for further details on this subject or ask for an Instructor-Led training.

Timing constraints deep dive with radiant

FPGA Design Techniques

Enjoy the learning!

MZ.