Nico Coesel wrote:
> Nicholas Kinar <n.kinar@usask.ca> wrote:
> 
>>> I'd daisy chain the whole lot and use an LPC2000 series controller
>>> from NXP. The 2nd SPI interface has a FIFO (both RX and TX) which is 8
>>> words deep.
>>>
>> Neat idea; I'll look into this.  Thanks, Nico!
> 
> You might need to parallel multiple SPI interfaces to get to your
> required bit rate (one SPI interface as master, the other one as
> slave; clock out externally connected to clock in). You can also look
> into the LPC1700 series. These are even faster than the LPC2000
> series.
> 

I am getting lots of good ideas from this particular thread.  Thanks 
Nico!  The LPC1700 series looks particularly good.

Nicholas Kinar <n.kinar@usask.ca> wrote:

>
>> I'd daisy chain the whole lot and use an LPC2000 series controller
>> from NXP. The 2nd SPI interface has a FIFO (both RX and TX) which is 8
>> words deep.
>> 
>
>Neat idea; I'll look into this.  Thanks, Nico!

You might need to parallel multiple SPI interfaces to get to your
required bit rate (one SPI interface as master, the other one as
slave; clock out externally connected to clock in). You can also look
into the LPC1700 series. These are even faster than the LPC2000
series.

-- 
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
                     "If it doesn't fit, use a bigger hammer!"
--------------------------------------------------------------

> 
> I don't know, if there is a megafunction available for SSC. I've developed
> my own version. It is about 300 lines of VHDL code, provides SSC send and
> receive functions, with a protocol which provides a virtual RAM interface
> to other entities, checksum bits and with interrupt generation, if the a
> threshold is reached. It is for transfering continous multichannel audio
> samples up to 192 kHz in both directions. The other enties which are
> accessed by the SSC RAM interface are mainly ringubffers, but some other
> information can be requested with other virtual addresses. But it is closed
> source for a customer, so I can't publish it.

Okay, 300 lines doesn't seem to be that bad.  I'm not especially fluent 
in VHDL, but it might be possible to do this as well in Verilog.

> 
> But I would suggest to use SRAM, if you are in the designing phase of a
> board and if you can layout it, because then the protocol overhead is
> simpler and you can add some more ADCs later, if needed.
> 

Yes, I'll give SRAM a try.  Thanks Frank!

> 
> You can make life much easier if the memory bus is synchronous (i.e.
> has a clock to which all bus transactions are aligned).
> 

Will do; I'll make the bus synchronous.  Thanks Nico!

Nicholas Kinar <n.kinar@usask.ca> wrote:

>
>> 
>> So this is the chip you are using?
>> 
>> http://www.atmel.com/dyn/resources/prod_documents/doc32015.pdf
>> 
>
>Yes, that is the exact chip.  Thank you so much for looking at the 
>datasheet, Frank!
>
>
>> From the datasheet there are at least the following ports, which could be
>> used for communicating with the FPGA:
>> 
>> - SRAM interface: Yes, the FPGA can behave like a SRAM. This is as simple
>> as accessing a SRAM from a FPGA, just the other way around
>> 
>
>This is probably the best way to go because of the easy way of accessing 
>  the FPGA.
>
>
>> - SSC interface: With 150 MHz master clock, this works up to 75 MHz, so
>> should be fine for reading the ADCs
>> 
>> I've used the SRAM interface with another system with a CPU and a FPGA.
>> From the CPU side this is the simplest communication way, because you just
>> write and read from memory locations. The FPGA gets the chipselect, decodes
>> the address and provides the data or reads in the data. Maybe DMA transfer
>> is possible, too.
>> 
>
>Agreed.  This is probably the easiest way to proceed.

You can make life much easier if the memory bus is synchronous (i.e.
has a clock to which all bus transactions are aligned).

-- 
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
                     "If it doesn't fit, use a bigger hammer!"
--------------------------------------------------------------

Nicholas Kinar wrote:

> How would it be possible to set the FPGA up as an SSC bus slave?  Is 
> there a megafunction available for this type of bus?

I don't know, if there is a megafunction available for SSC. I've developed
my own version. It is about 300 lines of VHDL code, provides SSC send and
receive functions, with a protocol which provides a virtual RAM interface
to other entities, checksum bits and with interrupt generation, if the a
threshold is reached. It is for transfering continous multichannel audio
samples up to 192 kHz in both directions. The other enties which are
accessed by the SSC RAM interface are mainly ringubffers, but some other
information can be requested with other virtual addresses. But it is closed
source for a customer, so I can't publish it.

But I would suggest to use SRAM, if you are in the designing phase of a
board and if you can layout it, because then the protocol overhead is
simpler and you can add some more ADCs later, if needed.

-- 
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

> I'd daisy chain the whole lot and use an LPC2000 series controller
> from NXP. The 2nd SPI interface has a FIFO (both RX and TX) which is 8
> words deep.
> 

Neat idea; I'll look into this.  Thanks, Nico!

Nicholas Kinar <n.kinar@usask.ca> wrote:

>Hello--
>
>I'm setting up a circuit where I need to write data to a DAC at the same 
>time as read data from 8 ADCs.
>
>I need to shift a data word out to the DAC to set an output voltage.  At 
>the same time, I need to read data from each ADC.
>
>The DAC and the ADCs all communicate over SPI.  The maximum sampling 
>rate of each 18-bit ADC is 400 kHz.  The maximum update rate of each 
>16-bit DAC is 400 kHz, the same as the sampling rate as the ADC.
>
>Sampling from each ADC is triggered using a /TRIGGER pin.  I believe 
>that it is possible to daisy-chain the ADCs.
>
>Perhaps the best way to do this is to use a FPGA.  I suppose that I 
>would set up a separate SPI bus for each ADC and DAC, and separate /CS 
>lines. All of the ADCs and DACs would not be on the same SPI bus.

I'd daisy chain the whole lot and use an LPC2000 series controller
from NXP. The 2nd SPI interface has a FIFO (both RX and TX) which is 8
words deep.

-- 
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
                     "If it doesn't fit, use a bigger hammer!"
--------------------------------------------------------------

How would it be possible to set the FPGA up as an SSC bus slave?  Is 
there a megafunction available for this type of bus?

> 
> If I understand it correctly, you don't need to do some realtime
> calculation for the DAC in response to the ADC? You just generate 1 s of
> pre-calculated data at the DAC and at the same time read 1 s data from the
> ADCs?
> 

Yes, you are right about this, Frank.  There is no realtime calculation 
required for the DAC output.  (At least not for my system.)  The input 
signal is a pre-generated Maximum Length Sequence (MLS), which could be 
either stored as a look-up table or generated using a Linear Feedback 
Shift Register (LFSR).  Since the length of the MLS is (2^N - 1), where 
N is a number, the sequence length can grow quite quickly.  So it is 
perhaps better to generate the MLS using a LFSR.  I believe that this 
can be done quite easily with a FPGA.

If N = 14, then 2^14 - 1 = 16383 is the length of the sequence.  If 
there is SRAM or SDRAM attached to the FPGA, then perhaps this sequence 
could be generated before even sampling from the ADCs.  The value of N 
could be much, much larger than just N = 14.  Values of N = 20 or N = 25 
may be used.

The Maximum Length Sequence is produced by the DAC, and the output of 
the system is sampled using a number of ADCs.  Since I initially made 
this post, I've reduced the number of ADCs from 8 to 6.  So there are 
now only 6 ADCs in the system that I am designing.

*******
Let me try and work out a plausible way of attaining what I want to 
obtain from this system.  Does this sound like a logical way of 
proceeding?  Could you suggest a FPGA for what I am trying to do?  What 
should be the master clock speed?
*******

Here are links to the datasheets for the ADC and the DAC:

ADC:
http://www.analog.com/static/imported-files/data_sheets/AD7690.pdf

DAC:
http://www.ti.com/lit/gpn/dac8580


Rather than using an ADC and DAC with parallel buses, I'm using parts 
with serial buses.  What I am trying to do is reduce the PCB footprint 
so that I can fit 6 ADCs and 1 DAC on the same PCB.  A similar ADC or 
DAC with a parallel bus would have a large number of pins.  Each AD7690 
has only 10 pins, whereas the DAC8580 has only 16 pins.

--------------

(1) Use the FPGA to set up a 30 MHz clock, and initialize a counter.

(2) The DAC, a Texas Instruments DAC8580, also operates with a 30 MHz 
serial clock.  The first 16 rising edges of the 30 MHz clock are used to 
shift in a 16-bit voltage output word to the DAC.  At the 17th rising 
edge of the clock, the voltage word has been passed by the DAC to a 
latch and the resulting voltage is produced on the output pin of the DAC.

(3) On the 17th rising edge of the clock, have the FPGA trigger the 
/CONVERT pins of all 6 ADCs.  All /CONVERT pins are triggered at the 
same time.

(4) At least 10 ns after the /CONVERT pin has been triggered, the 
conversion result produced by each ADC should be available.  If a 
pull-up resistor is placed on the MISO pin of each AD7690 ADC, the ADC 
will apparently drop the pin down low when the conversion data is 
available. (As shown in the datasheet, there are a number of other bus 
interfaces available.)  Then the FPGA must apply a clock with at least a 
15 ns period to the serial bus of each ADC to read out the 18-bit 
conversion result.  Each 18-bit ADC is on a separate SPI bus attached to 
the FPGA.  So all of the ADCs can be read at the same time.  Reading all 
of the ADCs at the same time will take 2.7e-7 seconds, less than the 400 
kHz sampling period of 2.5e-6 seconds.

(5) The data from each ADC is transferred to SRAM or SDRAM for storage.

(6) While data is being read from the ADCs, the 30 MHz clock on the FPGA 
is still ticking away, and the counter continues counting the rising 
edges of this clock.  On the 75th rising edge of the clock, the counter 
is reset to zero. By this time, the data will have been read from each 
of the ADCs.  Also on the 75th rising edge of the clock, the FPGA 
begins shifting in another word to the DAC.  Since the counter has been 
reset to zero, on the 17th rising edge of the clock the /CONVERT pin is 
triggered again.  The cycle then contines from (3) to (5) above.

(7) For example, the conversion cycle continues for 1 second.  This 
means, I think, that ((400000sps)(18 bits)(6 ADCs))/(8 bytes) = 5.4 MB 
of data has been accumulated.  The data can then be read from the FPGA 
via the SRAM interface, SSC interface, as you have suggested. Or perhaps 
the master microcontroller could treat the FPGA as a slave SPI device. 
This would be significantly slower, I think, than the other methods that 
you have proposed.