cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
vortex1601
Explorer
Explorer
436 Views
Registered: ‎12-11-2017

Simple clock-to-Q spec for DDR I/O read

I'm designing a DDR Hyperbus endpoint. I want to constrain the read data delay as specified as a datasheet clock-to-Q.

The parameters I'm looking for, tCKD and tCKDS, are called in Cypress' Hyperbus spec as the delay between the input clock and read data valid. Stated spec is 1.0 to 5.5ns.

Pretty simple, right? Should be able to be set by a pair of set_output_delay statements, like this:

 

set_output_delay -clock [get_clocks spi_clk] -min 1.0 [get_ports spi_dq*]
set_output_delay -clock [get_clocks spi_clk] -max 5.5 [get_ports spi_dq*]
set_output_delay -clock [get_clocks spi_clk] -min 1.0 [get_ports spi_dq*] -clock_fall -add_delay 
set_output_delay -clock [get_clocks spi_clk] -max 5.5 [get_ports spi_dq*] -clock_fall -add_delay

 


I'm only concerned with clock-to-Q latency, as I also send a source-sync DQS with the read data.

It's really the same problem as a DDR read path, which needs to have some notion of clock-to-data latency so the receive DLL can be properly staged, but otherwise doesn't care about the exact edge-to-edge relationship between CK and DQ/DQS.

The problem I'm seeing is, static timing analysis seems to assume I'm trying to meet the next CK opposite edge, which isn't the case. With the constraints I use, for a 10ns cycle it's showing a negative slack of about -6.1ns. The actual CK to DQ/DQS delay is only about 5.6ns (I use BUFIO through ODDR). So actual negative slack should only be -0.1ns or so.

What would be the right constraint to express this intention? Maybe some set_false_path statements?

0 Kudos
4 Replies
avrumw
Expert
Expert
407 Views
Registered: ‎01-23-2009

Why don't you give us more information. First, what is the period of the clock. Second, show the actual spec - for the numbers of a set_output_delay you need the effective required setup and hold times of the receiving device, but you are talking about min and max delays. 

This looks like a bidirectional DDR bus. As a result, you have two sets of constraints to define

  • set_output_delay will be based on the setup and hold requirement of the inputs of the external device
  • set_input_delay will be based on the clock to output timing of the outputs of the external device

It might be that you are confusing the two...

Once the constraints are taken care of, we can see if the launch/capture edge relationships need to be modified - if so then we need to use the proper set_multicycle_path commands to do so.

Avrum

0 Kudos
vortex1601
Explorer
Explorer
399 Views
Registered: ‎12-11-2017

It's not as complicated as that. The cycle time is 10ns, but this doesn't matter as the tCKD requirement is the same for the three speeds listed by Cypress (well, it's a bit tighter at 5.0 for 200MHz vs. 5.5 for 166 and 100.)

Anyway, I believe I found a solution:

set_max_delay 5.5 -from [get_clocks spi_clk] -to [get_ports spi_dq*]
set_min_delay 1.0 -from [get_clocks spi_clk] -to [get_ports spi_dq*]


This directly expresses the intent of tCKD. So now I only miss by a bit (-89ps negative slack for DQ.)

0 Kudos
avrumw
Expert
Expert
356 Views
Registered: ‎01-23-2009

This is not the way to do an input delay - particularly a DDR input delay...

set_input_delay -max 5.5 -clock spi_clk -to [get_ports spi_dq*]
set_input_delay -min 1.0 -clock spi_clk -to [get_ports spi_dq*]
set_input_delay -max 5.5 -clock spi_clk -to [get_ports spi_dq*] -clock_fall -add_delay
set_input_delay -min 1.0 -clock spi_clk -to [get_ports spi_dq*] -clock_fall -add_delay

You also need constraints for the outputs, which should be based on the setup and hold time requirements of the receiving device.

Of course, it is important for the definition of spi_clk to be correct. Is the spi_clk generated on the board and distributed to both the FPGA and other device (system synchronous), or is it generated by the FPGA (or is it bidirectional as well?)

Avrum

0 Kudos
vortex1601
Explorer
Explorer
296 Views
Registered: ‎12-11-2017

My other question related to the IDDR side, which I resolved by adopting IDELAY, as you suggested. https://forums.xilinx.com/t5/Synthesis/Bidirectional-bus-ODDR-without-IDDR-possible/m-p/1205791#M37613

For this Q, I'm dealing with device-to-host timing. The system is as follows:

 * Host device is clock source, endpoint receives the clock.
 * Host-endpoint outbound signals are source-sync with spi_clk, and center-aligned
 * Endpoint-host inbound are also source sync, but with edge-aligned DQS.

In this it's exactly like memory DDR. The Hyperbus host is responsible for re-timing the inbound data based on DQS; it's expected to have a DLL to do that.

The tCKD / tCKDS doesn't have any specific setup/hold requirement to spi_clk, so there isn't a need to specify a relationship using set_input_delay or set_output_delay. It only specifies the latency from spi_clk. Finally, rhere is a DQS - DQ skew requirement tDSS of +/- 0.8 ns.

Here's what I came up with:

##############################
# SPI I/O TIMING CONSTRAINTS #
##############################

#SPI I/O clock 100MHz, driven by host
create_clock -period 10.000 -name spi_clk -waveform {0.000 5.000} [get_ports spi_clkp]

# SPI Write: DQ and DQS are centered on clock (source-sync timing)
# Validity window vs. spi_clk spec -tIS through tIH, that is -1.0 through +1.0 
# Validity window start: (period/2 - iIS) = (5.0 - 1.0) = 4.0
# Validity window end: tIH = 1.0
set_input_delay -clock [get_clocks spi_clk] -max  4  [get_ports spi_dq*]
set_input_delay -clock [get_clocks spi_clk] -min  1  [get_ports spi_dq*]
set_input_delay -clock [get_clocks spi_clk] -max  4  [get_ports spi_dq*] -add_delay -clock_fall
set_input_delay -clock [get_clocks spi_clk] -min  1  [get_ports spi_dq*] -add_delay -clock_fall

#SPI Read: DQ to DQS launch alignment (source-sync timing)
# DQS-DQ delay (tDSS min, max -0.8, 0.8)
set_output_delay -reference_pin [get_ports spi_dqs] -min -0.800 [get_ports {spi_dq}]
set_output_delay -reference_pin [get_ports spi_dqs] -max  0.800 [get_ports {spi_dq}]

#SPI Read: DQ / DQS launch latency
# Clock-to-output delay (tCKD, tCKDS min 1.0 / max 5.5)
set_min_delay 1.0 -from [get_clocks spi_clk] -to [get_ports spi_dq*]
set_max_delay 5.5 -from [get_clocks spi_clk] -to [get_ports spi_dq*]


The Hyperbus spec is available here: https://www.cypress.com/file/213356/download
 

0 Kudos