Intel® Quartus® Prime Software
Intel® Quartus® Prime Design Software, Design Entry, Synthesis, Simulation, Verification, Timing Analysis, System Design (Platform Designer, formerly Qsys)
16592 Discussions

Source Synchronous Interface + PLL Clock shift

Altera_Forum
Honored Contributor II
1,076 Views

Hi! 

 

 

We are working on a source synchronous LVDS interface between two FPGAs. I already read the "Source-Synchronous Timing with TimeQuest" document from Ryan Scoville (many thanks for that!) but need some help with the constraints in combination with the receive PLL phase shift. 

 

 

The interface runs at 150MHz DDR edge aligned (data and clock edges at the same time on the pcb). 

The receiving device has a PLL in source synchronous mode that shifts the clock by 90 degrees (1.66ns). That clock is used for the DDIO IN cells and also drives a small amount of logic inside the fabric. 

The setup described here is exactly the same as the "FPGA to FPGA" interface included in Ryans examples. Quartus Version for this tests is 14.1. 

 

 

We see random bit errors, especially at increased temperature or high link activity (toggle rate). 

We already measured the power supply and external signals but everything looks fine there 

The observed errors/received data indicate that there is a sampling problem and therefore we need to check the timing constraints. 

 

 

We use the same timing constraints as Ryan and errors occur. 

Here are the constraints used in my design. 

 

 

**************************************************************** 

TX Timing Constraints: set INTERFACE_T 6.666 set INTERFACE_90deg # maximum allowed +/- skew set output_skew 0.5 # clock from PLL that is used for clock output set CLK_LVDS_TX_DATAREG $PLL_LVDS_TX_OUTPUT ;# clock for tx data registers # Generated Clock (Clock output at TX clock pin) create_generated_clock -name $CLK_LVDS_TX_CLOCKPIN -source -phase 90 # Output Delays set op_delay_max ;# tx setup set op_delay_min ;# tx hold set_output_delay -clock $CLK_LVDS_TX_CLOCKPIN -max $op_delay_max set_output_delay -clock $CLK_LVDS_TX_CLOCKPIN -min $op_delay_min set_output_delay -clock $CLK_LVDS_TX_CLOCKPIN -max $op_delay_max -clock_fall -add_delay set_output_delay -clock $CLK_LVDS_TX_CLOCKPIN -min $op_delay_min -clock_fall -add_delay  

 

**************************************************************** 

 

 

 

 

**************************************************************** 

RX Timing Constraints (with PLL): set INTERFACE_T 6.666 # maximum expected input +/- skew (sender + board skew) set input_skew 0.7 # clock from RX pll set CLK_LVDS_RX_DATAREG $PLL_LVDS_RX_OUTPUT ;# rx pll output to clock input data registers # define rx clock (at pin) create_clock -name $CLK_LVDS_RX_CLK_AT_PIN -period $INTERFACE_T # define virtual clock create_clock -name $CLK_LVDS_RX_VIRTUAL -period $INTERFACE_T set ip_delay_max ;# rx setup set ip_delay_min ;# rx hold set_input_delay -clock $CLK_LVDS_RX_VIRTUAL -max $ip_delay_max set_input_delay -clock $CLK_LVDS_RX_VIRTUAL -min $ip_delay_min set_input_delay -clock $CLK_LVDS_RX_VIRTUAL -max $ip_delay_max -clock_fall -add_delay set_input_delay -clock $CLK_LVDS_RX_VIRTUAL -min $ip_delay_min -clock_fall -add_delay **************************************************************** 

 

 

We also tested the interface without the PLL and do not see any bit errors. 

Without the PLL we used these constraints. They only differ in the last two lines. 

 

 

**************************************************************** 

RX Timing Constraints (without PLL): set INTERFACE_T 6.666 # maximum expected input +/- skew (sender + board skew) set input_skew 0.7 # clock from RX pll set CLK_LVDS_RX_DATAREG $PLL_LVDS_RX_OUTPUT ;# rx pll output to clock input data registers # define rx clock (at pin) create_clock -name $CLK_LVDS_RX_CLK_AT_PIN -period $INTERFACE_T # define virtual clock create_clock -name $CLK_LVDS_RX_VIRTUAL -period $INTERFACE_T set ip_delay_max ;# rx setup set ip_delay_min ;# rx hold set_input_delay -clock $CLK_LVDS_RX_VIRTUAL -max $ip_delay_max set_input_delay -clock $CLK_LVDS_RX_VIRTUAL -min $ip_delay_min set_input_delay -clock $CLK_LVDS_RX_VIRTUAL -max $ip_delay_max -clock_fall -add_delay set_input_delay -clock $CLK_LVDS_RX_VIRTUAL -min $ip_delay_min -clock_fall -add_delay # set to same edge transfer set_multicycle_path -setup 0 -rise_from -rise_to set_multicycle_path -setup 0 -fall_from -fall_to **************************************************************** 

 

 

I attached screenshots with the results for all 6 settings (TX Setup/hold; RX: with/without PLL Setup/Hold). 

Additionally I added a clock overview. 

 

 

**************************************************************** 

 

 

Now let us have a look at the timing paths. 

 

 

TX Setup:  

- Datapath is 3.853ns 

- Clock Path is 3.412 (without oEXT) 

- Difference: 0,441ns 

-> they are more or less equal in length and the slack is (0.5-0.441)=0.059 as can be seen above. 

-> Should be ok. 

 

 

RX Setup (without PLL): 

- Datapath: 2.383ns (without iExt) 

- Clockpath: 4.205ns 

- Difference: -1.822ns 

-> clock is shifted/delayed by approx. -98 degree, so the sampling point should be in the middle of the UI. 

-> Slack = (1.822-0.7)=1.122ns as reported by timequest 

-> Should be ok. 

 

 

RX Setup (with PLL): 

- Datapath: 3.062ns 

- Clockpath: 2.738ns (entire path over the pll) 

- Difference: 0.324ns -> nearly equal in length 

- ****shift is +17,5 degree -> may be the reason for the transfer errors. 

-> Not Okay. 

- The report is just fine as it calculates from the latch edge. 

 

 

 

 

This observation makes me think if the implemented PLL phase shift of Quartus is correct. That would also be a reason for the sampling errors at increased temperature. 

The phaseshift is shown in the setup relationship, but is that correct, as the clock transition at the clock pin is not at 4.999ns but at 3.333ns - together with the data. 

Why is the phaseshift unconsidered in the clock path from the RX clock pin over the PLL to the DDR input cell? 

Where can I see the actual phase shift of the PLL? I always thought of the -2.778ns to be the compensation step. Is my calculation not correct? 

 

 

Best Regards, 

Martin
0 Kudos
0 Replies
Reply