cancel
Showing results for 
Search instead for 
Did you mean: 
Visitor
Visitor
10,171 Views
Registered: ‎05-23-2014

Spartan 6 Deserializer - inputs

Hi!

 

My question concers -- again -- the deserializers for Spartan-6 (xc6slx45-2). I have sifted through a number fo threads about the topic. For the starters I used a FPGA-fabric code that TI has created to marry their ADC's with Xilinx's FPGA's. Sure I had to push it into Spartan (the original code is for Virtex-4). My question regards the setup/hold paths that I get in this design.

 

Here is the set-up. I consulted the IOWizard (ISE), the ug381.pdf doc., and the xapp1064 code to see how the inputs can be done. So finally my code (n-channels., diff. DDR clock at 50MHz or less, Frame clock with rising edge indicating the end of the word being deserialized) looks like:

 

(DDR_CLKp, DDR_CLKn) -> IBUFDS_DIFF_OUT -> (DDR_CLKp1, DDR_CLKn1) -> 2xIODELAY2 -> (CLKpD, CLKnD)

 

DDR_CLKpD -> BUFIO2 -> DDR_CLK_Buf

DDR_CLKnD -> BUFIO2 -> DDR_CLK_Buf_Inv

 

Data -> n x IBUFDS -> n x IODELAY2's(fixed) -> IDDR2(driven by DDR_CLK_Buf, DDR_CLK_Buf_Inv)

 

... then comes the logic to deserialize data in fabric using the CLKDIV signal derived from BUFIO2 and IDDR2 outputs and routed over BUFG. The input stage is more of less a copy of xapp1064. I am using fixed delays (that is why 'less') to start first with slow data-streams and only then look into calibrating the delays.

 

I implemented the design (playing with the IODELAY values hoping to get a match between CLK delay and Data delay) and start to observe the path delays. For now they are not a problem (for low DDR_CLK freqs), but in the long run I will need to solve this somehow. The setup/hold paths that give me problems are from Data PADS (e.g. D7p_pin) to respective IDDR2. In case of hold path we have (static timing -- I set very tight constraints to show what I mean):

 

"Hold":

   Source:               D7_p_pin (PAD)
   Destination:          DDR_Deser_Inst/DDR_IOBS_Inst_Inst/Gen_DDR_DataVec[1].IDDR2_inst (FF)
   Destination Clock:    DDR_Deser_Inst/DDR_IOBS_Inst_Inst/DDR_CLK_Buf rising at 0.000ns
   Requirement:          0.210ns
   Data Path Delay:      1.732ns (Levels of Logic = 3)
   Clock Path Delay:     1.950ns (Levels of Logic = 3)
   Clock Uncertainty:    0.025ns

 

But for "Setup"...:

   Source:               D7_p_pin (PAD)
   Destination:          DDR_Deser_Inst/DDR_IOBS_Inst_Inst/Gen_DDR_DataVec[1].IDDR2_inst (FF)
   Destination Clock:    DDR_Deser_Inst/DDR_IOBS_Inst_Inst/DDR_CLK_Buf_Inv rising at 0.000ns
   Requirement:          0.290ns
   Data Path Delay:      3.448ns (Levels of Logic = 3)(Component delays alone exceeds constraint)
   Clock Path Delay:     7.021ns (Levels of Logic = 4)
   Clock Uncertainty:    0.025ns

 

The clock path delay changed a lot (much more so than the data path delay). I believe that this results from the clock path being much longer than the data path (thus being affected to a larger degree by PVT) -- is this correct (and how accurate is the result suggesting that clock path delay is between 1.95 and 7.02 ns)?

 

Assuming yes, I am pretty sure that my temporary approach based on fixing IODELAY is never going to work for 50MHz DDR_Clk on Spartan-6.

 

My another question: it seems to me that even if I make an effort and use a DCM to stabilize the clock, the data path delay is not disappearing. It will stay (1.73 ns = 1.76ns wide), ruining the DCM's work on clock and making impossible achieving the goal of using faster DDR_CLk (and tighter datavalidity windows). I start to think that the approach based on in-fabric deserialization (without ISERDES) might not be possible on Spartan-6 (without IODELAY PVT stabilisation). Am I right?

 

Many thanks for any hints. I am away that there must be some thead somewhere that I must have missed.

 

Regards

 

Pawel

 

 

0 Kudos
8 Replies
Highlighted
Instructor
Instructor
10,164 Views
Registered: ‎07-21-2009

Re: Spartan 6 Deserializer - inputs

Suggest you use a PLL to re-generate the serial clock.  In the Clocking Resources User Guide, there are examples of PLL used in source synchronous application to phase align the serial clock (at the ISERDES2 or IDDR2 blocks) to the clock input.  Search the Clocking Resources User Guide for "zero delay buffer", and you should see plain examples of this sort of clock deskewing.  These examples include the use of the BUFIO2FB primitive in the feeback path from IOCLOCK to PLL CLKFBIN pin.

 

-- Bob Elkind

SIGNATURE:
README for newbies is here: http://forums.xilinx.com/t5/New-Users-Forum/README-first-Help-for-new-users/td-p/219369

Summary:
1. Read the manual or user guide. Have you read the manual? Can you find the manual?
2. Search the forums (and search the web) for similar topics.
3. Do not post the same question on multiple forums.
4. Do not post a new topic or question on someone else's thread, start a new thread!
5. Students: Copying code is not the same as learning to design.
6 "It does not work" is not a question which can be answered. Provide useful details (with webpage, datasheet links, please).
7. You are not charged extra fees for comments in your code.
8. I am not paid for forum posts. If I write a good post, then I have been good for nothing.
0 Kudos
Highlighted
Visitor
Visitor
10,114 Views
Registered: ‎05-23-2014

Re: Spartan 6 Deserializer - inputs

Hi!

Many thanks for the reply. Sure I will use your suggestion. But if I may use some more of your time also... I would like to probe further. Even if I deskew the clock with PLL, then my data path which is also vulnerable to PVT (although to a lesser degree than the clock path) will stay unchanged.

 

Is my suspiction correct that the ONLY possible way of dealing with fast clocks (and fast streams of LVDS data -- fast being cir. 50 MHz or so) on Spartan-6 is using the dynamic calibration of the IODELAY's? Just like it was done in xapp1064. A confirmation will for sure save me time I would otherwise use for experimentation with other approaches.

 

Thanks you for hints.

 

Best regards

 

Pawel

0 Kudos
Highlighted
Instructor
Instructor
10,109 Views
Registered: ‎07-21-2009

Re: Spartan 6 Deserializer - inputs

Even if I deskew the clock with PLL, then my data path which is also vulnerable to PVT (although to a lesser degree than the clock path) will stay unchanged.

 

Please analyse which portions of the clock and data paths are likely to skew from each other (rather than track or match each other) because of PVT variations.

 

-- Bob Elkind

SIGNATURE:
README for newbies is here: http://forums.xilinx.com/t5/New-Users-Forum/README-first-Help-for-new-users/td-p/219369

Summary:
1. Read the manual or user guide. Have you read the manual? Can you find the manual?
2. Search the forums (and search the web) for similar topics.
3. Do not post the same question on multiple forums.
4. Do not post a new topic or question on someone else's thread, start a new thread!
5. Students: Copying code is not the same as learning to design.
6 "It does not work" is not a question which can be answered. Provide useful details (with webpage, datasheet links, please).
7. You are not charged extra fees for comments in your code.
8. I am not paid for forum posts. If I write a good post, then I have been good for nothing.
0 Kudos
Highlighted
Visitor
Visitor
10,107 Views
Registered: ‎05-23-2014

Re: Spartan 6 Deserializer - inputs

I must be getting this wrong, probably, but I believe I get that exactly kind of analysis when I look into Static Timing report. In my case the info there says that:
Hold data path - delay is 1.732ns
Setup data path - delay is 3.448ns
The data path is already short (I am using 0-tap delay and BUFIO2's). Thus, the variation in delays caanot be improved with better routing. If I am not wrong I won't be able to eliminate these with deskewing clock. Am I wrong, if I think like this about the situation at hand?
Regards

Pawel
0 Kudos
Highlighted
Instructor
Instructor
10,104 Views
Registered: ‎07-21-2009

Re: Spartan 6 Deserializer - inputs

If you posted the bit rate and/or clock frequency, I have yet overlooked it.  Before you jump to IODELAY blocks, please review the skews between data and clock paths without IODELAY blocks.  If timing uncertainty is such that you need IODELAY blocks, the analysis of skews without IODELAY blocks should help make that clear.

 

-- Bob Elkind

SIGNATURE:
README for newbies is here: http://forums.xilinx.com/t5/New-Users-Forum/README-first-Help-for-new-users/td-p/219369

Summary:
1. Read the manual or user guide. Have you read the manual? Can you find the manual?
2. Search the forums (and search the web) for similar topics.
3. Do not post the same question on multiple forums.
4. Do not post a new topic or question on someone else's thread, start a new thread!
5. Students: Copying code is not the same as learning to design.
6 "It does not work" is not a question which can be answered. Provide useful details (with webpage, datasheet links, please).
7. You are not charged extra fees for comments in your code.
8. I am not paid for forum posts. If I write a good post, then I have been good for nothing.
0 Kudos
Highlighted
Visitor
Visitor
10,095 Views
Registered: ‎05-23-2014

Re: Spartan 6 Deserializer - inputs

Many thanks for the post. I have removed the IODELAY blocks from the clock/data paths. Now, I only have IBUFDS_DIFF_OUT (for DDR clock) or IBUFDS (for data, and frame clock), then come:

for clock -- 2 BUFIO2 blocks

for data -- IDDR block (clocked with my DDR clock diff. signal)

 

Now I get the following delays on the hold/setup paths:

Setup

   Data Path Delay:      1.276ns (Levels of Logic = 2)
   Clock Path Delay:     1.309ns (Levels of Logic = 2)

Hold

   Data Path Delay:      2.537ns (Levels of Logic = 2)
   Clock Path Delay:     3.554ns (Levels of Logic = 2)

 

I would like to work with DDR clocks with period of cir. 2.5ns to 5ns (depending on the sampling rate),  and read data from ADC chip with specs saying that:

    for low sampling rates setup time is 0.7ns with 1ns of hold time

    for faster sampling rates these figures change to 0.25ns (setup) and another 0.25ns (hold) -- possibly this is too fast

 

I wonder if you could give me any hints as to which direction are worth following when it comes to data-clock alignment .

 

Many thanks

Pawel

 

0 Kudos
Highlighted
Instructor
Instructor
10,093 Views
Registered: ‎07-21-2009

Re: Spartan 6 Deserializer - inputs

The clock path delay from input pin through input buffer through clock distribution buffer to data input register is longer than the data input path delay.  This is not surprising.  Note also that the skews between the two paths are greatly reduced, with the uncertainty (skew) of the IODELAY2 blocks removed.

 

Now add in the PLL to regenerate the serial clock, with BUFIO2FB in the feedback path to the PLL.  This will phase align the clock at the data input registers to the input clock at the output of its input buffer (IBUFG or IBUFGDS).  This effectively nulls the differences in the clock and data paths.

 

The specs you quoted for the ADC are too ambiguous to settle all timing concerns.  The essential information is minimum data valid time at the output of the ADC, before and after each output clock edge.  This may also be expressed as minimum and maximum data propagation delay from each clock edge (at the clock output pin) to data output.

 

What you describe is a classic example of source-synchronous design.  This is well-covered by doc UG382.  See Figure 1-16 and Figure 3-5.

 

-- Bob Elkind

SIGNATURE:
README for newbies is here: http://forums.xilinx.com/t5/New-Users-Forum/README-first-Help-for-new-users/td-p/219369

Summary:
1. Read the manual or user guide. Have you read the manual? Can you find the manual?
2. Search the forums (and search the web) for similar topics.
3. Do not post the same question on multiple forums.
4. Do not post a new topic or question on someone else's thread, start a new thread!
5. Students: Copying code is not the same as learning to design.
6 "It does not work" is not a question which can be answered. Provide useful details (with webpage, datasheet links, please).
7. You are not charged extra fees for comments in your code.
8. I am not paid for forum posts. If I write a good post, then I have been good for nothing.
0 Kudos
Highlighted
Visitor
Visitor
10,086 Views
Registered: ‎05-23-2014

Re: Spartan 6 Deserializer - inputs

Many thanks for the description. If I understand you correctly, you suggest:

1) Remove IODELAYS, which will bring the signal delays to much lower levels.

2) Employ PLL to align data and clock.

 

OK, my concern is that many designs for FPGA and ADC have the delay blocks. My understanding is that this way it is simply possible to care a bit less for the PCB track lengths -- any irregularities there can be accounted for by software means. However if this is the way to go -- according to you -- I'll give it a try before following xapp1064.

 

> The essential information is minimum data valid time at the output of the ADC, before and after each output clock edge.

 

OK, sorry for the misunderstanding. Here are some information in exactly this format (setup time -- time when data are output at the ADC pins prior the active clock edge -- and hold time -- the time after the active edge of the clock when the data are no longer valid at the ADC pins). Let's choose one of the tightest operation mode of my chip (ADS5263):

 

1) fs = 50 MHz, 1-wire communication, 16x serialization will produce DDR clock of 400 MHz, and it is guaranteed that the chip generates the data with setup time of 0.27 ns and hold time of 0.35 ns.

 

and a much less demanding mode for comparison:

 

2) fs = 50 MHz, 2-wire comm., 8x serialization will generate DDR clock of 200 MHz, and the setup time in this case is 0.66 ns and the hold time is 1 ns.

 

#1 looks terribly tight, to play with without any delays, and/or dynamic alignment of clock-data. But maybe I am wrong being afraid of this mode. #2 is probably quite doable this way -- but again, I might be qrong here also. Will very much appreciate any suggestions.

 

Regards

 

Pawel

0 Kudos