Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
13 years ago

How to constrain a DDR input with its clock on a general IO pin?

I am working with a design that involves a high speed ADC with my FPGA (a cyclone 4).

The ADC samples data at 250MHz and puts its output on a LVDS bus 14 bits wide directly to the FPGA (the clock pin is LVDS as well). The data is valid just slightly after the rising and falling edge of the supplied clock.

The design is made slightly more confusing when you consider the fact that the ADC's clock is being supplied via PLL from the FPGA (via general IO) to sample the data, but the ADC then returns its own generated clock to allow synchronization to the data. Here is a visual representation:https://www.alteraforum.com/forum/attachment.php?attachmentid=6885

The ADC in question is the AD9643 from Analog Devices (can't post a link yet). From the datasheet we can derive the relationship between ADC_CLK and ADC_DCO, but I think that relationship is irrelevant to fitting the incoming data ADC_Q.

Any help in constraining the incomming DDR data, or references to look at would be greatly appreciated!

Charlie L.

2 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

    Your design does not seem safe from timing view point. The ADC clock of 250MHz should not have been supplied from the fpga and the DCO should have used dedicated clock pin. I have been through a similar situation and I am afraid it might not work. One way around it is not to use that DCO, instead use an internal clock output from fpga PLL that emulates the DCO in phase and frequency including board delays and is locked to ADC clock.

    Once DCO is safe then entering set_input_delay is straight forward as it represents maximum/minimum data offset from launching edges and there are examples in timequest resource centre.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

    The Cyclone III/IV source-synchronous timing is confusing. You could enter source-synchronous timing constraints, but the timing will be analyzed with micro parameters and not be very good. If it's 500Mbps, it might not pass. But note that the handbook talks about timing these interfaces using TCCS and SW(sampling window) values. In combination with App Note 479:

    http://www.altera.com/literature/an/an479.pdf

    If you don't use timing constraints, you can directly use the Sampling Window. This can be found in the handbook, and is 400ps for most speed grades(higher for the slowest parts). So if your layout is:

    Incoming ADC clock feeds PLL in source-synchronous mode. This PLL drives the DDR input registers through a global. The sampling window is then 400ps, which is really good. You then need to determine how much to phase-shift the clock, so that it is in the middle of the data eye. I didn't look at the datasheet to verify that.

    Finally, note that it is possible to have the incoming clock reference the outgoing clock. You basically put a generated clock on the output clock port, then a generated clock on the input clock port whose -source option is the output. Finally, you need to add set_clock_latency assignments to the incoming clock to specify the max and min external roundtrip delays. That all being said, I would probably treat it as a new clock. At 250MHz, the variation is probably going to be large enough that it can't be successfully related back to the main clock. If you just send the data through a phase-comp FIFO, you can then get it back into the main domain without problem.

    (Another option is to have the first PLL not drive any internal logic, and instead have the return clock drive all the logic in your FPGA. That way it's all off the same domain.)