Source Synchronous LVDS Design - Phase Shift in the Timing Analysis?

Hi,

I plan to interface a 250MHz ADC with an Spartan 3E-1600. The ADC gives out 8 data lines and 1 clock line, all via LVDS. The data should be captured an put into a blockram. The OFFSET IN constraint, which I want to meet, says, that the DATA should be available 0.97ns before the CLOCK.

So far I have the data-lines into their IBUFDS (8 times) and into the data-input of the BRAM. Clock goes into a IBUFGDS, into the DCM, into a BUFG and into the clock of the BRAM. DCM_FEEDBACK is fed from the BUFG as well.

I have learned that from "UG331", the "Spartan-3 User Guide".1] So I set the DCM to "SOURCE_SYNCHRONOUS" and the phase shift to 0, for testing. I get in the Timing Analysis:

Slack: -2.134ns = 0.97ns setup - (4.5ns datapath - 1.4 ns clockpath)

So i set the PS to 120, just for curiousity:

Exactly the same results. The phaseshifting is accounted, in the DATASHEET the internal clock (which is correctly infered from the external clock on the input of the DCM) is displayed with a phase from

1.875ns, but this is not reflected in the constraints. Am I missing something?

Thanks a lot, Christian

1] It says there: "The SOURCE_SYNCHRONOUS setting essentially zeros out any phase difference between the incoming clock and the deskewed output clock from the DCM. The FPGA application must then adjust the clock timing using either the Fixed or Dynamic Fine Phase Shift mode."
Reply to
Christian Wiesner
Loading thread data ...

Indeed I was missing something:

The param "IFD_DELAY_VALUE => "AUTO" from the IBUFDS of the DATA-lines was set to AUTO. I do not know what the ISE Webpack did there, I got an delay from nearly 6ns while the DATA went from the PIN thru the IBUFDS to the input-FF. I assume, it controls the delay through the PAD. So I got horrible setup-times.

When I changed this value back to "0", my constraints were met. I used the "Language Templates" provided in the Webpack.

But this doesn't solve my issue concerning the Phase of the DCM. If I change the phase, nothing changes in the setup-time. Only the "datasheet"-section in the timingreport reflects the phasechange correct.

regards, Christian

Reply to
Christian Wiesner

Problem solved!

As the friendly guy from the websupport told me, the OFFSET-IN- Constraint does not reflect the phase of the DCM, if you use the keyword "HIGH" or "LOW".

Example:

Connection like mentioned before, adc_DCLK_P goes into the DCM, is renamed to CLK and clocks the FFs, where ADC_DATEN is registered.

First the grouping-constraint: NET "adc_DATA_P" TNM = "ADC_DATEN";

Then the OFFSET-IN: TIMEGRP "ADC_DATEN" OFFSET = IN 0.97 ns BEFORE "adc_DCLK_P" HIGH; This does not reflect any phase changes you made in the DCM. Instead use: TIMEGRP "ADC_DATEN" OFFSET = IN 0.97 ns BEFORE "adc_DCLK_P"; -- don't use the HIGH-Keyword.

It's so simple :(

regards, Christian

Reply to
Christian Wiesner

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.