cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Participant
Participant
745 Views
Registered: ‎02-05-2015

Problem with ISERDES - Timing violations

Hello,

 

I have a couple op problems with the Xilinx Select IO Wizard in Diffeential Input Mode

Here some configuration details:

 

10 Bit DDR serialized source with 300 MHz clock

8 Data Channels

LVDS25 inputs are used on Zynq 7020 SoC

Clock is shiftet 90° to data eye

Setup Time is 0.4ns

Hold Time is -0.4ns

 

When I analyze one of the 8 channels after deserializing, the data output doesn't represent the serialized input. I've connected a gpio to the bitslip unit, this works fine but after 10 times slipping the right result isn't there.

I think the solution could be detected by solving the timing violations.

 

I can shift the setup or hold slack by changing the Fixed Delay values for clock and data in the options of the selectio-wizard.

 

But a strange effect is, when I get setup and hold timing these where one on the P input pin and one on the N input pin.

DLO_N_A[0] to system_i/Sensor_A/selectio_wiz_0/inst/pins[0].iserdese2_master/DDLY    Setup -1.039ns

DLO_P_A[0] to system_i/Sensor_A/selectio_wiz_0/inst/pins[0].iserdese2_master/DDLY    Hold   -0.401 ns

 

I have no idea, how to eliminate the slack.

 

I need some help to find the correct settings for setting the input delay values and delay values for Iserdes.

set_input_delay -clock [get_clocks DCLK] -min ??? [get_ports {DLO_P_A[*]}]
set_input_delay -clock [get_clocks DCLK] -max  ??? [get_ports {DLO_P_A[*]}]
set_input_delay -clock [get_clocks DCLK] -min  ??? [get_ports {DLO_P_A[*]}] -clock_fall -add_delay
set_input_delay -clock [get_clocks DCLK] -max  ??? [get_ports {DLO_P_A[*]}] -clock_fall -add_delay

 

Sensortiming.png
0 Kudos
1 Reply
Highlighted
Guide
Guide
697 Views
Registered: ‎01-23-2009

Re: Problem with ISERDES - Timing violations

I have bad news for you....

 

This interface is just to fast to capture statically in an FPGA. Your clock rate (595MHz DDR) is very fast, and your sending device has too much clock/data uncertainty (guaranteeing only 0.8ns of the 1.68ns unit interval being valid). FPGAs need much wider windows for static capture - anything below 1.5 or even 1.75ns is just not possible.

 

I don't know what timing constraints you have used (if they are consistent with the 0.4ns SU/0.4ns H or not), but the tools are showing a violation of 1.44ns in addition to any requirements you have. If your constraints are specifying the 0.8ns window, then the tools are telling you that you need a minimum of 2.24. This is larger than the "best" clocking structure will give you (take a look at this post on capture clocking structures), but is consistent with some other clocking structures.

 

Avrum