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.
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.
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).
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.
Constraints Guide: Constraint Syntax for UCF, PCF, HDL
Timing Constraints User Guide: Conceptual information on how to constrain a design
Timing Analyzer Help: General information on how to use timing analyser
You must be a registered user to add a comment here. If you've already registered, please log in. If you haven't registered yet, please register and log in.