How do you constrain a DDR-style interface where data needs both -clock and -clock_fall input delays?

Short Answer

A DDR (double data rate) interface launches or captures data on both the rising and falling clock edges, so one input delay referencing only the rising edge covers half the data. The -clock_fall option on set_input_delay/set_output_delay (SDC) tells the constraint to reference the falling edge instead, and the rising and falling constraints must be applied together, not one overwriting the other.

Technical Explanation

• Why a single-edge constraint isn't enough. A DDR interface moves twice as much data per clock period by using both clock edges — one data bit is valid around the rising edge, the next around the falling edge. A normal set_input_delay (SDC) constraint, which defaults to referencing the rising edge, only describes half of that behavior.
• What -clock_fall does. Adding -clock_fall to set_input_delay or set_output_delay (SDC) tells the tool to measure that delay relative to the clock's falling edge instead of its rising edge — describing the second half of the DDR data.
• Both constraints must coexist. Applying -clock_fall on a port does not replace the rising-edge constraint already on that port; the tool needs both the rise-referenced and fall-referenced constraints active at once so it can check the path launched or captured on each edge independently.
• -add_delay (SDC) keeps both from colliding. Because SDC by default treats a second set_input_delay on the same port and pin as overriding the first, the -add_delay option is needed so the rising and falling constraints are added as separate, independent delay specifications rather than one replacing the other.
• What this changes in analysis. With both constraints active, the tool now analyzes two separate timing paths through the same physical port — one relative to each clock edge — doubling the effective number of input or output timing checks on that pin, exactly matching how the real DDR protocol uses the clock.

Follow-up Question & Model Response

How would you tell, just from reading a timing report, whether both the rising-edge and falling-edge constraints on a DDR port are actually active?

Candidate Model Response: Run report_timing (PT) or check_timing (PT) on the port and look for two distinct arrival/required timing paths referencing the same physical pin, one clocked off the rising edge and one off the falling edge. If only one edge shows up in the report despite both set_input_delay calls being in the SDC file, that is a strong sign the second call replaced the first because -add_delay was missing. Cross-checking the SDC source against the actual constraints the tool loaded, using report_port or a similar query command, confirms which delay specification survived.