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."

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

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

Problem solved!

> 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.

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