Electronic – FPGA Timing Constraints

constraintsfpgatiming

I am fairly new to FPGA design and I am working on a project where the FPGA is the SPI Slave.

Are there supposed to be constraints on the Master Clock input signal/ MOSI / Chip select?

What is the importance/reason for constraining inputs?

If so, how are these determined? If you have any suggestions for books or videos which give a deeper explanation I would greatly appreciate it. I just want to learn this so I can implement this module correctly.

Thank you

Best Answer

As some of the commenters observed, timing analysis can be a very complex topic. In this answer, I will try to hit some of the important and practical points.

Q: Why is it important to constrain timing on your design?
A: So that internal (hard) timing constraints are met.

OK, so why is it important to meet internal timing? This fundamentally boils down to the behavior of flip-flops (FFs) in your FPGA. The timing of data relative to clock at each flip flop must meet certain requirements or the flip flop next state is indeterminate. Think of the case where clock and data both change at the same instant at the input of the FF. (what is the correct output value in this case)? This is the gist of most timing issues. So, the idea is to have the data stable for some period before (setup) and after (hold) the clock edge used to capture the data. The tricky part here is that an FPGA is quite flexible on how things are connected inside, and all of the interconnect and logic has measurable, but design and placement dependent, delays associated with it.

The good news here is that modern FPGA (and CPLD) tools make it easy to ensure your circuit will work, if you define some timing constraints. The tools perform the heavy lifting of calculating all the path delays and changing internal placement and routing to meet your constraints (if possible).

The simplest, and most important (IMHO) constraint is to define the maximum frequency of each of your clocks. The FPGA tools will make sure that all internal setup and hold times are met between all of the FFs using that clock. It is a good idea to also constrain your inputs and outputs relative the their related clocks.

The following is not really good advice, but rather a practical observation: At low frequencies, it may be possible to not constrain at all. Especially if the protocol (like SPI) has attributes that naturally provide margin. The tools can identify clocks, and can tell you the max frequency possible for a given clock. You can also determine as-built setup, hold, clock to out parameters. In the absence of constraints, the tools will take a balanced approach to area / performance during compilation.

As an example here: if the SPI_SCLK is 1MHz (or below), you probably don't need to worry about timing being an issue. There is about 500ns of setup and 500ns for hold (data to clock) due to the SPI protocol. That is a lot of margin in a modern programmable.

If you fail to meet (FPGA internal) timing, the circuit behavior can be totally unpredictable. You really want to avoid this.

Related Solutions

Electronic – ASIC timing constraints via SDC: How to correctly specify a multiplexed clock

Define divide by 1 clocks on the and_* nets and declare them to be physically exclusive. Cadence RTL compiler handles the situation correctly by generating 3 timing paths for registers clocked by cpu_clk (one path each for one clock). Registers directly driven by clk0, clk4 and clk_ext have their own timing arcs.

create_generated_clock -source [get_ports clk0] \
-divide_by 1 -name and_clk0    [get_pins and_cpu_1/Y]

create_generated_clock -source [get_ports clk4] \
-divide_by 1 -name and_clk4    [get_pins and_cpu_2/Y]

create_generated_clock -source [get_ports clk_ext] \
-divide_by 1 -name and_clk_ext [get_pins and_cpu_ext1/Y]

set_clock_groups \
-physically_exclusive \
-group [get_clocks and_clk0] \
-group [get_clocks and_clk4] \
-group [get_clocks and_clk_ext]

Electronic – Clock domain crossing timing constraints for Altera

Despite being fairly common in the industry to globally cut all paths between two clock groups, I would strongly advise against this practice as it makes it very hard to spot places where you unintentionally re-sampled a signal between clock domains.

You are better off using a common block for transferring data between domains. Embed the constraints in the common block, or use wildcards in the paths to constrain every instance of the block in your design. Make the use of a common synchronisation block part of your coding guidelines.

You can then report all clock-domain crossings and find places where you weren't using a safe transfer mechanism. You can also include automatic checking in your flow and quickly locate any accidental clock crossings in your design.

You will also be able to use your set_max_delay constraint and not have it ignored :)

Best Answer

Related Solutions

Electronic – ASIC timing constraints via SDC: How to correctly specify a multiplexed clock

Electronic – Clock domain crossing timing constraints for Altera

Related Topic