Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Register Log in

Beginner problem : help me to synchronize an ADC signal DATA with the FPGA clock

Status
Not open for further replies.
H

houly

Advanced Member level 4
Joined
Jan 11, 2010
Messages
110
Helped
0
Reputation
0
Reaction score
0
Trophy points
1,296
Location
France
Activity points
2,151
Hello,
I need help to design a receiver :

I use a AD7626 ADC in "self-Clocked mode" (page 23 in datasheet : https://www.analog.com/static/imported-files/data_sheets/AD7626.pdf )
In this mode, the clock is not present, the data contain an header '010' which permit to the receiver to recover the clock. I'm a beginner in FPGA design and I would want to know what could be the best way to recover the clock from the data ? How does it work ?

I hope that you could help me.

PS : The rate is 10MSPS for 18 bits data (including header - this means 250MHz clock from the FPGA)
 

This doesn't look like a beginner problem to me! ;-)
The recovery method suggested in the datasheet requires that you generate, inside the FPGA, 3 versions of the clock with a difference of phase of 120° (1.33 ns of delay between each pair).
How you are going to generate these clocks really depends on the technology you are working with: PLL, DCO, delay lines ... whatever.

Then you build 3 identical receivers, each using a different clock, all working in parallel on the same data.
The one able to receive the 010 header is the one you get the data from.
 
  • Like
Reactions: houly

    H

    houly

    Points: 2
    Helpful Answer Positive Rating
Hello,
Thanks for you help.

If I understand well, I have to generate the three clocks signal with 120° of difference of phase.
Then, for each process, the DATA is captured, and another process analysis the result of each captured signal and try to identify the "010" header to know which is the good one.
Is that right ?

For 120° phase difference I don't know how I can do, if I use PLL, what can I do to provide the delay for each lines ?

thanks a lot for your help
 

the PLL should be able to do the phase delay for you.
 

Hello TrickyDicky
First, thanks for your reply ;

Since I have 8 ADC, do I must have 8*2 PLL to synchronize the reception ? or since the CLK is the same (without considering PCB tracks delays)
can I imagine only 2 PLL :
the CLK signal (which is the Clock of the ADC)
the CLK2 signal (ADC clock with 120° of phase with PLL1)
the CLK3 signal (ADC clock with 240° of phase with PLL2)

The device that we would want to use is an ARRIA GX (or GZ), but it only contains 6 PLLs, so I'm wondering if it will be sufficient to permit to solve my problem

Here is the overview of ARRIA devices family
Arria II Transceiver-Based FPGA Family Overview
 

Maybe you should drive your 8 ADCs from an FPGA generated clock? Then everything will be synchronized and you won't drive yourself crazy.
 

houly said:
If I understand well, I have to generate the three clocks signal with 120°/.../
Click to expand...


I think you can reduce your logic to 2 clocks only
with a relative shift of 180deg, if one clock slope
is too close to data change point, the second will
have correct timing;
this means you can use the clock and its inversion
what simplifies the solution;
you can also think of connecting adc data to 2 neighbour
pins and set 2 diffrent pin-to-logic delay value
(if your target fpga is not and old, obsolete device)
what gives the same effect as clock shifts;
----
J.A
 

j_andr said:
I think you can reduce your logic to 2 clocks only
J.A
Click to expand...

This is not true; it depends on the setup and hold requirements.

For example, say you've got a 100 MHz clock (10 ns period), a setup requirement of 6ns and a hold requirement of 0 ns. Now assume your data transitions 5.1 ns before the rising edge of your clock. This violates your setup time. But if you use the falling edge, your setup time is only 0.1 ns. Using the 120 degree-shifted clock will work, however.
 
What clock is driving your ADC? The data doesn't come out of your ADC LVDS pins by itself.
If I understand the datasheet well, you need to drive the clk pins to clock the data out of the ADC. The conversion is started by a pulse on the CNV pins. What device is controlling this?
 

houly said:
The device that we would want to use is an ARRIA GX (or GZ), but it only contains 6 PLLs, so I'm wondering if it will be sufficient to permit to solve my problem
Click to expand...
One PLL of the ARRIA is flexible enough to solve your problem.
Just select in the Altera software 3 outputs at 250MHz and specify the delays: the PLL can easily reach 750MHz, so there should be no problem here.
P.S. You are going to feed to the PLL the same 250MHz clock you send to the ADCs.
 

250MHz is quite a fast clock. remember to do some good pipelining.
 

barry said:
Maybe you should drive your 8 ADCs from an FPGA generated clock? Then everything will be synchronized and you won't drive yourself crazy.
Click to expand...

For a 16-bit ADC that's a bad idea. The amount of jitter from an FPGA generated clock is pretty high when compared to the average external clock. And more jitter ==> more aperture uncertainty ==> you kill your effective number of bits.

See for example AN-501 from Analog Devices.
 
barry said:
This is not true; it depends on the setup and hold requirements.
For example, say you've got a 100 MHz clock (10 ns period), a setup requirement of 6ns/.../
Click to expand...

right, but with unrealistic assumptions,
today fpga devices have setup & hold times about or below 1ns;
J.A
 

Another approach is to use input delays (Xilinx devices (and others, I'm sure) have programmable input delays so that you can get your data and clock to line up). I've used this successfully to compensate for PCB delays/skew.

Barry
 

mrflibble said:
For a 16-bit ADC that's a bad idea. The amount of jitter from an FPGA generated clock is pretty high when compared to the average external clock. And more jitter ==> more aperture uncertainty ==> you kill your effective number of bits.
Click to expand...

That's what I meant with my post. If the OP doesn't design this setup carefully, he will lose all the advantages of the approach. At that speed (250MHz) he'll face high speed design challenges. Timing is then very critical - nothing for a beginner.
Don't forget that 120° phase shift is only 3ns!
 

lucbra said:
That's what I meant with my post. If the OP doesn't design this setup carefully, he will lose all the advantages of the approach. At that speed (250MHz) he'll face high speed design challenges. Timing is then very critical - nothing for a beginner.
Don't forget that 120° phase shift is only 3ns!
Click to expand...

120 degrees is actually 1.3 ns at 250MHz, but we've gotten off track here (I retract what I said previously about using an FPGA-generated clock; yes, a PLL or DLL will generate a lot of jitter). If I understand this correctly, the clock in question is the data-capture clock-it latches the serial data out of the ADC, it is NOT the sampling clock, so its jitter has nothing to do with aperture uncertainty, etc. The ADCs and FPGA can both be driven by the same 'clean' clock source, then the FPGA can generate its own capture clock-the jitter on that won't affect sampling performance.

However, you still have to pay attention to the Convert signal...
 

It still isn't a beginners thing. Especially when you're not strong in HDL design nor high speed design.
 

For a 16-bit ADC that's a bad idea. The amount of jitter from an FPGA generated clock is pretty high when compared to the average external clock. And more jitter ==> more aperture uncertainty ==> you kill your effective number of bits.
Click to expand...
A good point for HS ADC - generally. The AD7626 however requires a gated clock, so supplying the clock from FPGA is an fact the obvious solution. My impression is, that although the device offers quite impressive aperture jitter numbers, it's effectively bad suited for low jitter apllications due to this specific behaviour. You would want to utilize an ADC that can be supplied from a continuous crystal clock directly if clock quality is critical. Hopefully, the present application doesn't rely on minimal ADC jitter.

You'll notice, that DCO to D delay is low enough to operate the receiver deserializer circuit clocked from DCO with a fixed phase guaranteed by FPGA timing analysis. In so far the 120° oversampling suggestion isn't the best solution for a FPGA, I think. Availibility of sufficient number of clock inputs can be a problem.

With Arria or Stratix, there's an even more simple solution utilizing the DPA feature of it's hardware SERDES. In this case, you don't need to connect DCO at all. Because separate phase alignment is provided for each input channel, clock resources aren't critical.
 

FvM said:
The AD7626 however requires a gated clock, so supplying the clock from FPGA is an fact the obvious solution. My impression is, that although the device offers quite impressive aperture jitter numbers, it's effectively bad suited for low jitter apllications due to this specific behaviour. You would want to utilize an ADC that can be supplied from a continuous crystal clock directly if clock quality is critical.
Click to expand...
The ADC limitations due to aperture uncertainty depend only on the quality of the conversion strobe (CNV), so it should be enough to guarantee a low-jitter high quality signal here.
Using directly a crystal clock may not be feasable though, because of the duty-cycle requirements on CNV.
The CLK signal is only used for digital communication, so any decent 250-300 MHz clock should do fine.

I also find very smart the implementation suggest by Analog, since you don't have to tune any delay if anything external changes (PCB layout, temperature, etc...)
 
Last edited:

The ADC limitations due to aperture uncertainty depend only on the quality of the conversion strobe (CNV), so it should be enough to guarantee a low-jitter high quality signal here.
Click to expand...
Yes, thanks for correcting this point. The problem of supplying a low jitter CNV signal stays, but if jitter is an issue, it can be achieved by minimal hardwired logic, e.g. an external FF controlled by the FPGA.
 

Status
Not open for further replies.

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top