Timing Analysis

[thunderdan]

G'day all,

I'm really struggling on  this one, but here goes.. I'm using an ML605 development platform with a 4DSP FMC150 ADC / DAC module and ise 13.2. At the moment i'm just using one channel of the ADC which is 6 LVDS lanes of DDR data and one LVDS clock being piped into the HPC connector. The source synchronous ADC clock is running at 61.44MHz. 

1. The ADC clock input routs to an ibufds -> iodelay1 -> bufg and then into a MMCM where I output 61.44Mhz 122.88Mhz and 368.64Mhz clocks. 

2. Each ADC DDR lane is similar but goes to ibufds -> iodelay1 -> iddr and then registered. (clocked by the 61.44MHz MMCM clock)

3. The registered output is fed into in ILA. (ILA clocked from a separate MMCM at 600 MHz - asynchronous to the ADC clock)

However when I view the ADC data (ADC configured in a ramp test pattern)  in chipscope I have glitches. After a number of days of reading and getting up to speed with timing constraints (I should have mentioned, I'm only a month old with FPGA design)  I realised i didn't have any timing constraints.... Easley fixed... i wish. 

from the ADC data sheet I have the setup time as 0.9ns and hold time as 0.95ns i therefore place these line in my UCF:

NET "clk_ab_p" TNM_NET = clk_ab_p;
TIMESPEC TS_clk_ab_p = PERIOD "clk_ab_p" 61.44 MHz HIGH 50%;

NET "clk_ab_p" CLOCK_DEDICATED_ROUTE = FALSE;

OFFSET = IN 0.9 ns VALID 1.85 ns BEFORE "clk_ab_p" RISING;
OFFSET = IN 0.9 ns VALID 1.85 ns BEFORE "clk_ab_p" FALLING;

Now I get a warning Rout:466 - Unusually high hold time violation detected among 21 connections... and a very long PAR time while it attempts to find a solution and finally after all that time, it does rout but fails hold time on my two timing constraints. I've included a snippet of one below:

Paths for end point adc_data_a[3].iddr_inst (ILOGIC_X0Y185.DDLY), 2 paths
--------------------------------------------------------------------------------
Slack (hold path): -5.890ns (requirement - (clock path + clock arrival + uncertainty - data path))
Source: cha_p<3> (PAD)
Destination: adc_data_a[3].iddr_inst (FF)
Destination Clock: clk_61_44MHz rising at 0.000ns
Requirement: 0.950ns
Data Path Delay: 1.621ns (Levels of Logic = 2)(Component delays alone exceeds constraint)
Clock Path Delay: 7.840ns (Levels of Logic = 5)
Clock Uncertainty: 0.621ns

It fails this on three of the adc channels for both the RISING and FALLING constraint. What I can't understand is that the Reference design that came with the FMC ADC card doesn't have any OFFSET IN constraint only a PERIOD on the ADC clock. My design closely mimics that of the reference design so I can't see how it would work correctly either. 

The attachment shows my receiver result, note this is the optimum result I can get by playing with the iodelay1 delay taps (connected to dipswitches) and playing with various options the ADC has for offsetting it's clock.

I'm absolutly stumped, have spent days (&nights) on this and realise I've probably bitten off more than I can chew for my first project, but any ideas would be great.

[tmcdowe]

You might want to take a look at this ADC-specific XAPP from Marc Defossez:

http://www.xilinx.com/support/documentation/application_notes/xapp1071_V6_ADC_DAC_LVDS.pdf

[ajmirg]

Can you please give more details on the paths:

Data Path Delay: 1.621ns (Levels of Logic = 2)(Component delays alone exceeds constraint) 
Clock Path Delay: 7.840ns (Levels of Logic = 5) 

The clock path delay seems quite large.

[thunderdan]

Thanks for your replies, I seemed to have tracked the problem down to the ILA clock oversampling my ADC result register, it must have been sampling on a transition state hence showing the glitch. (when really there was no problem at all!) When i changed the ILA clock to the source sycronus clock I got a perfect result. I was purposly oversampling originally so i could view the DDR clock and data signals and align them by tuning the IODELAY taps.

I still don't understand how to properly use the OFFSET IN i'll have to read into it a bit more... so I only have a period constraint and used the IODELAY taps to delay the data.

for the record Ajmir,

My clcok path is IO -> IBUFDS -> IODELAYE1 -> BUFG -> MMCM (from here i generate my clocks and reproduce a phase aligned version of the source syncronus clock) -> IDDR (clk input)

My data path is IO (pad) -> IBUFDS -> IODELAYE1 -> IDDR

[swapnamala@gmail.com]

hi i am also getting same warning because of that,place and route is taking nearly one hour..

WARNING:Route:466 - Unusually high hold time violation detected among 338 connections. The top 20 such instances are
   printed below. The router will continue and try to fix it
    i_adc4_channel_id_n<1>:PADOUT -> i_adc4_channel_id_p<1>:DIFFI_IN -11307
    i_adc4_channel_id_p<1>:I ->
INST_ADC_INTERFACE_TOP/INST_ADC4_DATA_RECEIVE/INST_ADC_RATE_CONVERTER_I/INST_ADC_ISERDES_2/GEN_INST_ISERDERS[1].INST_ISE
RDERS:D -11307
    i_adc4_channel_id_n<0>:PADOUT -> i_adc4_channel_id_p<0>:DIFFI_IN -11298
    i_adc4_channel_id_p<0>:I ->

if i give offset in constraint then only i am getting this warning

[chrisz]

The "NET "clk_ab_p" CLOCK_DEDICATED_ROUTE = FALSE; " constraint informs the routing engine to not use the global routing resources and use local routing resources.  The local routing resources are much slower and will cause more clock path delay or clock path skew.  In most cases, Xilinx recommends using global resouces, which helps to reduce the clock path delay and clock path skew.