Time constraints in ISE, help required

Hi all,

I have a V2P design with data and clock coming from an A/D in LVDS format. The clock of 210 MHz is an output from the A/D, so it is aligned with the data with Data to Clock skew of 0.8 ns max according to the A/D datasheet. Due to an error on the board, the clock polarity was reversed relative to the data lines, so essentially I expect the "positive edge" to be in the middle of the data phase at the FPGA pads. I have inserted a wizard-generated DCM clk_deskew for fine tuning. Experimentally I found that the design is most stable when the DCM is programmed to a fixed phase shift of about 70 degrees (0.93 ns at 210 MHz). Below are the snippets from my code and the timing constraints I am using as well as the related timing report summary:

CLK_DESKEW_INST: clk_deskew port map( rst_in => clk_deskew_rst, clkin_p_in => clk_dco_P, clkin_n_in => clk_dco_N, locked_out => dcm_locked, clkdv_out => open, CLK180_OUT => clk_dco_180, -- I tried using this output, but it didn't work well... clkin_ibufgds_out => clk_dco_ibufgds, clk0_out => clk_dco );

G_1 : for I in 0 to 11 generate ADATBUF_INST: IBUFDS_LVDS_25 port map (adat_P(I), adat_N(I), adat(I)); ADAT_CLKIN_P: process(clk_dco) begin if rising_edge(clk_dco) then ll_adat(I)

Reply to
MM
Loading thread data ...

Hi Mikhail, Soz, haven't the time to check your code, but a quick suggestion. Make sure the design is using the INFFs in the IOBs. Use FPGA editor to check. Also, your clock is on a global resource, right? It seems odd that design doesn't work 100% no matter what the DCM phase shift is. The aforementioned flaws could cause that. Good luck mate, Syms.

Reply to
Symon

check.

Yes, I have checked this....

Sure it is.

/Mikhail

Reply to
MM

format.

the

datasheet.

relative to

the

found that

shift

my

timing

but it

negative

----------------------------------------------------------------------------

|
|

----------------------------------------------------------------------------

| 7

|

----------------------------------------------------------------------------

| 1

|

----------------------------------------------------------------------------

satisified for

It may be that the DCM output at phase "0" is not really aligned with the input pin after the differential receiver. DCM's have a built-in fudge factor to make up for the routing delay from the global input pins to the DCM input. This would tend to make the actual relationship of the DCM phase 0 output somewhat negative wih respect to the DCM clock input pin. I'm not convinced the tools do this right with a differential input clock. I have found in similar designes in Virtex2 (not pro) that my phase shift to work well is larger than I waould have expected.

clk_dco_P

4.662 ns.

the

and the

I'm not sure where 4.662 nS comes from, but it looks like the timing simulation is looking at your defined period of 4.550 (not 4.762) for clk_dco and simulating the full period of delay actually used in the DCM to lock to the input clock. You might try setting the period constraint to the exact period used in the simulation to see if this is the cause.

build

might not.

Almost always this occurs due to unconstrained paths, often for signals crossing from one related clock to another, where the tools are not smart enough to infer the required constraints from the input clock period. I have seen this in designs passing signals between 1x and 2x clock outputs from the DCM. I would turn on the "Report Uncovered Paths" option and look at the static post place-and-route timing.

timing

need

dealt

Theoretically you should be able to treat the positive side of a differential input the same as a single-ended input for timing constraints. You may see that the timing report shows a difference in the datasheet numbers for setup and hold to the plus and minus inputs (by a few picoseconds), but you can't do anything to control this.

Reply to
Gabor

I am looking well after the DCM has locked. It actually takes more than one clock cycle to lock... I don't think requested period has anything to do with this, but I will do some experiments...

/Mikhail

Reply to
MM

\Mikhail OK, try sampling the input clock with a IOB INFF clocked from the output from the DCM. As you change the DCM shift you should see the output of the FF change polarity with the phase difference. From this you can work out the phase relationship between the input clock and output of the DCM and hence set the DCM to sample the incoming data at the right place. You probably want to use the DCM's 'dynamic change of phase input' (PSINC?) thingys, unless you like doing P&R. Cheers, Syms. p.s. Here're some more hints

formatting link

Reply to
Symon

the

Symon,

Do you mean to try it in simulation or in real hardware?

/Mikhail

Reply to
MM

Reply to
Symon

Hi Mikhail,

The problem could be becuase of the reset of the DCM. Ensure that the DCM is given a proper reset. Also there are some errat's on the V2P DCM when you use it in fixed phase mode and variable phase mode. Search for the following errats in

formatting link

regards Chander

Sym> Mikhail,

jitter

inadequately

Reply to
cans

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.