homoalteraiensis wrote:

> > deriving the SCLK from the LSB of a counter in the FPGA. But this isn't
> > working.
>
>
> 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

> deriving the SCLK from the LSB of a counter in the FPGA. But this isn't
> working.


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

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:
> 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.

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.

> The SCLK signal on the ADC board looks
> distorted when I probe it with the scope

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.

> I've just been reading elsewhere on this forum that it is not advisable
> to drive the ADC clock inputs with an FPGA. I was wondering if the term
> 'clock' also refers to the SPI SCLK 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'm trying to get an FPGA (Spartan-II) to communicate with an ADC
(Serial interface, with a maximum throughput rate of 2Msps and the
maximum signal bandwith I'm sampling is 200kHz). I've been using a
counter to generate both the SCLK and CS signals and find that the ADC
doesn't seem to be sampling. The SCLK signal on the ADC board looks
distorted when I probe it with the scope and more worrying, I also see
the same distorted SCLK signal on the output data only biased about
ground! SCLK looks something like:

|||
| |
|  |
|   ||||
|      |        |
|      |        |
|      |        |
|      |        |
|      |        |
       |    ||||
       |   |
       |  |
       |||

I've just been reading elsewhere on this forum that it is not advisable
to drive the ADC clock inputs with an FPGA. I was wondering if the term
'clock' also refers to the SPI SCLK signal? The recommendations on the
forum say to use an (analog?) PLL to drive the ADC clock and the FPGA
separately. Would a clock distribution IC like AD9513 (I need 2 ADC
clocks and 1 FPGA clock, all CMOS compatible) do the job, or can I use
an EPROM clock generator like CY2071A?

Thanks
Ki