PLD Blog

[#1]

Following along the forum traffic, it has come to may attention that timing constraints are often a mystery to new users.  In order to help those who have never had to constrain their timing, I conclude with part 5 on timing constraints.

Dual Data Rate (DDR)

DDR interfacing uses both the rising and falling edges of the clock in a source-synchronous interface to capture or transfer twice as much data per clock cycle.

Arriving DDR

To properly constrain data arriving at the device, you must first constrain the clock being used to capture the data, and also constrain the arrival of the data for both the rising and falling edges of the clock.

For this example, the complete OFFSET IN specification with associated PERIOD constraint is:

NET "SysCLk" TNM_NET = "SysClk";
TIMESPEC "TS_SysClk" = PERIOD "SysClk" 5 ns HIGH 50%;
OFFSET = IN 1.25 ns VALID 2.5 ns BEFORE "SysClk" RISING;
OFFSET = IN 1.25 ns VALID 2.5 ns BEFORE "SysClk" FALLING;

This global constraint covers both the data bits of the bus, as in each clock period two bits are captured: ?data1 and ?data2.

Leaving DDR

Similar to specifying when the data arrives is specifying the output of DDR data.

For this example, the complete OFFSET OUT specification for both the rising and falling clock edges is based on the clock supplied to the DDR register:

NET “CLkIn” TNM_NET = “ClkIn”;
OFFSET = OUT AFTER “ClkIn” REFERENCE_PIN “ClkOut” RISING;
OFFSET = OUT AFTER “ClkIn” REFERENCE_PIN “ClkOut” FALLING;

Note that the complete constraint format is OFFSET=OUT <value>, and this determines the maximum time from the rising clock edge at the input clock port until the data first becomes valid at the data output port of the FPGA device.

When <value> is omitted from the OFFSET OUT constraint, as in the example above, the constraint becomes a report-only specification which reports the skew of the output bus. The REFERENCE_PIN keyword defines the regenerated output clock as the reference point against which the skew of the output data pins is reported.

Of course, do not forget that the output clock also needs a period constraint (it was not needed for the specification of the output timing, but is required for getting the data to the DDR output register).

Summary

In this series we have provided a snapshot of common constraints and how to use them.  Depending on how you liked this series, I can provide further articles on timing, as there is a lot more to say about the reports that can be generated by the timing analyzer.

Austin Lesea



References

Constraints Guide:  Constraint Syntax for UCF, PCF, HDL
http://www.xilinx.com/support/documentation/sw_manuals/xilinx11/cgd.pdf

Timing Constraints User Guide:  Conceptual information on how to constrain a design
http://www.xilinx.com/support/documentation/sw_manuals/xilinx11/ug612.pdf

Timing Analyzer Help:  General information on how to use timing analyser
http://www.xilinx.com/support/documentation/sw_manuals/help/iseguide/mergedProjects/timingan/timinga...

[#2]

It is a very helpful and interesting series. Please continue your writing,

[#3]

It's very interesting and useful.

[#4]

Many thanks Austin for this.

The trouble is not that there is not enough info on the constraints system, but there is sometimes too much! Also, some of it seems contradictory.

This series boils it all down to a straightforward summary.

A very useful follow on would be to explain the static timing report with its negative setup times, worst case data windows, etc.

[#5]

Very practical and concise. Thanks~

[#6]

This is great. Thanks a lot for helping clear up a subject that has been 'muddy' for a long time.

I have a pretty simple question. One of the most difficult challenges I have with making timing constraints is figuring out the exact name of the blocks or clock signals I need to constrain. This is quite difficult, especially through multiple levels of hierarchy, name changes, flattening of the design, etc, etc. What's the best way to determine the name? Just go right to the FPGA editor and hunt around in the implemented design? Or specify clock signals using 'attributes' in the HDL and then using those names? Any other suggestions? Am I missing something obvious?

Thanks for any help.

Regards,

Dan

[#7]

Most constraints are applied to the top level ports.  This would include either a IO pad LOC or OFFSET timing constraint and a clock port PERIOD constraint.  If the clock is connected to a DCM/PLL/CMT/MMCM block the timing constraint will be propagated through to the output ports including any changes due to multiple/divide of the original clock.

In the rare situation that a clock is internally generated or you need to provide register-to-register timing constraints the best place may be to look for the names in the timing analysis report or the PAR report.   If you can't find what you are looking for then the next best place will be FPGA editor or placing the constraint in the HDL.