FPGA interface to serial ADC

What you see is normal undershoot/overshoot, not really much to worry about unless it goes well beyond the spec of the device. However, I am not sure you are doing proper measurement. Whether what you see on the scope is really what's going on depends on the probe, how it is connected, and the scope itself, but I bet your problem is not related to the shape of this signal.

No. It only applies to a sampling clock and only if jitter/phase noise of the clock is critical for the application.

/Mikhail

I had no problem in driving a typical serial ADC's system clk and control impulses @60Meg and above, which is already very close to the ADCs spec!

A common problem is, to generate an approp riate clock with a valid duty cycle. Here a PLL can be used to obtain a freq which ist no directly synthesizeable from the FPGAs system clock (just like 100Megs from out of 60Meg internal or 20Meg external).

But typically, you will run a ADC with half of the system freq, in order to be able to do processing and decisions within one bit clock, and toggle the required signal outputs for any of the peripheric devices easily.(e.g. Bit0 of a counter, running at clock speed)

A special case is running the data aquisition fully pipelined, where ADC's clock is equal to the fpga clock: With most programmable devices, you will somehow violate the system clock net in simply passing out the freq itself! You will have to use dual data rate cells instead (which also should be placed in the io-blocks for best performance).

If you are not familiar with this: The ddr-cell is a switch for two channels controlled by a) the high level and b) as well the low level of the cells's clock. By feeding the ddr cell with static 1 and 0 at its inputs, it is somehow "abused" to switch a 1 at clk hi, and a zero at clk lo. Thus it doubles the frequency to obtain the virtual factor 2 mentioned above (toggeling).

With a (pll based) well clk inside the FPGA, you will have a nice and perfectly driven system clk outside too, with a dc of 50:50 (nearly).

The next issue is aquiring the ADCs output correctly according to the given delay at the board: Some ADCs pass out their data at the falling edge, and with a tycical delay of 10ns, so you will find the data valid in beneath of the next rising edge of the receiving flip flops. To avoid this, simply generate a doubled system clk and generate a delayed clock for the ddr-cells' clock to delay the ADCs clock. You may also invert 0/1 to push the phase in a way, that the incoming data perfectly meets to aquiring clock.

Thanks for all of the advice above. I've tested the ADC using function generators to drive SCLK and CS and it works just fine. So the problem is definitely with my self-generated signals where I have been running the ADC at half the FPGA board speed (and like homoalteraiensis says) deriving the SCLK from the LSB of a counter in the FPGA. But this isn't working.

Ki

homoalteraiensis wrote:

Did you succed now with the design? Did you try the DDR architecture (assuming full fpga clock speed is needed here ?)

homoalteraiensis, the design is working now. Not sure why. I haven't changed anything major so possibly had to do with incorrect setup. Sorry, I didn't try your suggestion because I'm afraid I didn't quite understand it, but thanks for your advice.

Ki