cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
rdb9879
Explorer
Explorer
5,544 Views
Registered: ‎09-27-2013

Same edge capture, DDR, output delay

Greetings,

 

I followed this thread for a great description on how to do same clock edge launch/capture for DDR nput delay: https://forums.xilinx.com/t5/Timing-Analysis/How-to-constraint-Same-Edge-capture-edge-aligned-DDR-input/td-p/642969

 

 

The summarized version was this: Create a virtual clock and issue a "set_multicycle_path 0" and utilize this virtual clock for the timing constraints. The description of that thread mentions that the default convention for "set_input_delay" is for the capture clock to be one clock later than the launch edge (a default of "set_multicycle_path 1"). By using "set_multicycle_path 0", you tell the tools to instead use this new same-clock-edge relationship.

 

How do I do same-edge launch/capture for "set_output_delay" on DDR outputs? Is the behavior/convention identical to "set_input_delay", so I would also perform a "set_multicycle_path 0" for this? 

 

0 Kudos
4 Replies
avrumw
Expert
Expert
5,533 Views
Registered: ‎01-23-2009

How do I do same-edge launch/capture for "set_output_delay" on DDR outputs? Is the behavior/convention identical to "set_input_delay", so I would also perform a "set_multicycle_path 0" for this? 

 

Probably - you would need to walk through the same exercise as was done in the referenced post to make sure the launch and capture edges for both setup and hold are the ones you expect.

 

That being said, under what conditions would you want to do this? Generally, when you generate a clock forwarded interface you:

  - use the same internal clock to generate the forwarded clock and data (to generate an edge aligned clock forwarded DDR inteface)

      - you want to specify the required skew of this interface. This is done without needing to change the edge relationships

      - see this post on constraining the skew

      - no set_multicycle_path is needed here

  - use two different clocks (say ones generated by an MMCM that are 90 degrees out of phase) - one to generate the forwarded clock and one to generate the forwarded data (to generate an center aligned clock forwarded DDR interface)

     - when you use two different clocks for the forwarded clock and forwarded data, the edge relationships all change pretty dramatically

        - (assume the forwarded clock is generated by the 90degree clock and the forwarded data by the 0 degree clock)

        - the forwarded data that starts at the rising edge of the 0degree clock is naturally captured by the forwarded clock generated by the rising edge of the 90degree clock

        - no set_multicycle_path is needed here

 

So why don't you describe your application and we can see what constraints apply.

 

Avrum

0 Kudos
rdb9879
Explorer
Explorer
5,520 Views
Registered: ‎09-27-2013

The application is very similar to a DDR[1] memory controller. For some of the signals, I am driving outputs (address, ba, etc) with a 0-degree version of the clock, but for the forwarded clock I am sending a 90 degree version of the clock. This is so the data will be center aligned with the 90-degree version of the clock. The setup/hold times are defined relative to that 90-degree clock.

 

Driving the output data lines work a little differently: I drive a data-strobe line, DQS, which currently is a forwarded copy of the 90-degree clock with an output enable (data pins are centered aligned to DQS, and setup/hold is constrained relative to DQS). I am still outputting the data using the 0-degree clock (not sure if this is the best choice, but seems like it should work). The DQS doesn't work as a typical "clock" in that it is not continuous: it only pulses once at a specific point during the transaction, and the receiving device captures data on both edges. This is why I am asking about having the same launch/capture edge, as it seems to be applicable.

0 Kudos
avrumw
Expert
Expert
5,518 Views
Registered: ‎01-23-2009

From your description, this sounds like it is timed like a conventional clock forwarded center aligned interface.

 

The DQS (which is a clock for timing purposes) is generated from an ODDR using the 90degree clock and the data is generated by an ODDR using the 0degree clock. I presume that making the DQS intermittent is done by changing the value on the D1 input of the ODDR; set it to 1 when you want a pulse, set it to 0 when you want to suppress a pulse... 

 

From the timing point of view, the fact that the clock is intermittent is irrelevant. Define the DQS as a forwarded clock with

 

create_generated_clock -name DQS_CLK -divide_by 1 -source [get_pins <dqs_oddr>/C] [get_ports <DQS_port>]

 

Now define define the setup and hold time of the receiver naturally. Lets say the clock is 100MHz (so 200Mbps DDR) and the device needs 0.3ns of setup and 0.2ns of hold.

 

set_input_delay -clock DQS_CLK 0.3            [get_ports <data_ports>]

set_input_delay -clock DQS_CLK -0.2 -min [get_ports <data_ports>]

set_input_delay -clock DQS_CLK 0.3            [get_ports <data_ports>] -clock_fall -add_delay

set_input_delay -clock DQS_CLK -0.2 -min [get_ports <data_ports>] -clock_fall -add_delay

 

Internally, lets call the rising edge of clk0 as time 0, which makes the falling edge at 5ns, and the rising and falling edge of clk90 at 2.5 and 7.5 respectively.

 

We have two data windows in a period. 

 

Let's look at the window that is centered around the rising edge of clk90 (so at time 2.5). The window is launched based on the rising edge of clk0 at time 0 - this is the launch edge.

 

By default the tool does two setup checks for this launch edge

  - for the first set_input_delay (without the -clock_fall), the capture edge is the "first clock edge after the launch edge"; since the launch edge is at time 0, the first potential capture edge is the rising edge at time 2.5. This is correct and natural

  - for the second set_input_delay (with the -clock fall), it is only looking at falling edges of the clock; this will be captured on the falling edge of the clock at time 7.5. This is incorrect but harmless - if the one at 2.5 meets timing, so will the one at 7.5

 

The same argument is done for the second window; the launch edge is the falling edge of clk0 at time 5, and the capture edges are the clock_fall edge at 7.5 (natural and correct) and the rising edge at 12.5 (incorrect but harmless).

 

Now for the hold.

 

For the launch edge at time 0 and for the capture edge at time 2.5, the hold check is "from the setup launch edge to the edge before the setup capture edge". The capture edge is 2.5, so the rising edge before it is at time -7.5. This is incorrect but harmless (as we will see in a moment).

 

For the launch edge at time 0 and the capture edge at time 7.5 (clock_fall), the same rule has the capture edge be at time -2.5, which is the correct edge. If it meets this hold check, then it will meet the one at -7.5 as well.

 

So, all the edges work out correctly - no set_multicycle_path is required.

 

If you are really ambitious, you can do set_false_path commands for all the incorrect but harmless combinations, but it isn't necessary.

 

Avrum

0 Kudos
rdb9879
Explorer
Explorer
5,497 Views
Registered: ‎09-27-2013

thanks again! I'll give this a shot

0 Kudos