Reading from ADC and writing to DAC at same time

> 
> shouldn't need to read and write at the same time if the ADCs have a
> trigger pin,
> 
> write the DAC value, hit the trigger to all ADCs, with a fast spi clk
> there's then
> plenty of time to read the ADCs one at a time before the next cycle
> 
> -Lasse
> 

What would be an approximate latency on the measurement?  Would it be 
more than possible to use a single microcontroller instead of a FPGA?

Nicholas Kinar wrote:

> Sounds good, Frank.  Thank you for your response. Do you think that most 
> of this stuff could be easily done in Verilog as well?

Yes. I prefer VHDL, because the compiler warns me more than Verilog, if I
write dumb code :-)

> SRAM sounds nice, but isn't there some sort of reference 
> implementation/plugin/megafunction for accessing this type of memory?

SRAM is simple. I would just read the datasheet and implement the timing
diagrams, integrated with your statemachine for the ADCs and reading from
your main CPU. This could be easier than to figure out how to use a
megafunction, maybe with lots of options you'll never need, but which you
have to understand and to configure. For SDRAM I would use a megafunction,
if available, because this would be more difficult to write your own code
for it.

But if you don't need to cache lots of data, e.g. if your main CPU is
running some kind of realtime OS, like some realtime Linux patch, then
maybe you have to cache only a small amount of data (depends on the maximum
latency of your operating system and your realtime, i.e. no-bit-loss,
requirements) and block RAM is sufficient.

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

Nicholas Kinar wrote:

> What would be an approximate latency on the measurement?  Would it be 
> more than possible to use a single microcontroller instead of a FPGA?

Most SPI ports for microcontrollers are too slow to handle your
requirements, if you don't access the ADCs in parallel. You have 8 ADCs,
each with 18 bit and max. 400 kHz. This means 57.6 MHz SPI clock, for the
data only. And usually there is some overhead in the SPI communication,
like padding to 24 bits, setting chipselect, register adressing etc. and
maybe your ADCs don't like 57 MHz SPI clock either.

Even if you read the data with a FPGA, you should think how to transfer it
to your main CPU. Using SPI could be difficult, because you'll need more
than 57 MHz, if you don't transfer continously. If the main CPU is the
master, the FPGA has to sample 57 MHz SPI clock, which means you'll need
more than 150 MHz FPGA clock, if you want fail safe detection. This means
more expensive FPGAs, because with lots of wide logic, like saving multiple
18 bit words, it gets slower and your maximum allowed clock maybe slower
than 150 MHz, or you'll need some FIFO and multiple clock inside the FPGA.

One main advantage of FPGAs is the parallel processing. In VHDL you can
write one entity and instantiate it multiple times, even with loops, but
maybe this is possible with Verilog, too. This accumulates the data in
parallel. Then use a parallel interface to your main CPU, if it is
possible, to read the cached and deserialized data.

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

On Aug 27, 5:17=A0am, Nicholas Kinar <n.ki...@usask.ca> wrote:
>
> What would be an approximate latency on the measurement? =A0Would it be
> more than possible to use a single microcontroller instead of a FPGA?

What latency can you tolerate, in absolute terms, and jitter ?
'at the same time' is not telling us much!

With a SPI system even if the clocks are sync, what you shift in, will
be well time advanced from what the DAC finally updates to.

What else happens between the 8 ADC's and the 1? DAC. ?

What are your actual data rates  ?

In the simplest system, you could use Logic to assist a host uC, to
manage 9 SPI ports as a Multichannel Par/SPI peripheral.
The smallest FPGA would manage that, or even a medium-CPLD.

-jg

> Yes. I prefer VHDL, because the compiler warns me more than Verilog, if I
> write dumb code :-)
> 
Agreed.  I'm like that as well too!

> SRAM is simple. I would just read the datasheet and implement the timing
> diagrams, integrated with your statemachine for the ADCs and reading from
> your main CPU. This could be easier than to figure out how to use a
> megafunction, maybe with lots of options you'll never need, but which you
> have to understand and to configure. For SDRAM I would use a megafunction,
> if available, because this would be more difficult to write your own code
> for it.

I think that there's such a megafunction for SRAM and SDRAM available in 
Quartus II from Altera.  Is this freely licensable?

> 
> But if you don't need to cache lots of data, e.g. if your main CPU is
> running some kind of realtime OS, like some realtime Linux patch, then
> maybe you have to cache only a small amount of data (depends on the maximum
> latency of your operating system and your realtime, i.e. no-bit-loss,
> requirements) and block RAM is sufficient.
> 

Would it be possible to have the FPGA copy the data into SDRAM rather 
than stream all of the data through to the main processor?


My application involves sampling data from the ADC for only ~1.0 
seconds.  Then what I would have to do is process the data.

So it would be possible for the data to be leisurely transferred to the 
master by setting up the FPGA as an SPI slave.

> 
> Most SPI ports for microcontrollers are too slow to handle your
> requirements, if you don't access the ADCs in parallel. You have 8 ADCs,
> each with 18 bit and max. 400 kHz. This means 57.6 MHz SPI clock, for the
> data only. And usually there is some overhead in the SPI communication,
> like padding to 24 bits, setting chipselect, register adressing etc. and
> maybe your ADCs don't like 57 MHz SPI clock either.


I'm using the AD7690 SAR ADC from Analog Devices.  This particular ADC 
has a serial SPI bus.

> 
> Even if you read the data with a FPGA, you should think how to transfer it
> to your main CPU. Using SPI could be difficult, because you'll need more
> than 57 MHz, if you don't transfer continously. If the main CPU is the
> master, the FPGA has to sample 57 MHz SPI clock, which means you'll need
> more than 150 MHz FPGA clock, if you want fail safe detection. This means
> more expensive FPGAs, because with lots of wide logic, like saving multiple
> 18 bit words, it gets slower and your maximum allowed clock maybe slower
> than 150 MHz, or you'll need some FIFO and multiple clock inside the FPGA.
> 

The total time of measurement is ~1 second. So the ADCs and the DAC will 
only be operating for ~1s.  Would it be better to simply have the FPGA 
cache the data in SRAM/SDRAM, and then have the main microcontroller 
read the data from the FPGA as a slave?  Would this still work, or are 
there still challenges associated with using serial ADCs with a FPGA?


> One main advantage of FPGAs is the parallel processing. In VHDL you can
> write one entity and instantiate it multiple times, even with loops, but
> maybe this is possible with Verilog, too. This accumulates the data in
> parallel. Then use a parallel interface to your main CPU, if it is
> possible, to read the cached and deserialized data.
> 

I'm using the AVR32 AP7001 from Atmel.  There's only a parallel memory 
bus on this processor.  Unfortunately, there's no specialized bus for 
just communicating with the FPGA.

> 
> Most SPI ports for microcontrollers are too slow to handle your
> requirements, if you don't access the ADCs in parallel. You have 8 ADCs,

BTW, I could reduce the number of ADCs from 8 to 6.  Would this help to 
reduce the throughput requirements somewhat?

Thanks for your response, jg!

> 
> What latency can you tolerate, in absolute terms, and jitter ?
> 'at the same time' is not telling us much!

I can't tolerate much latency since what I am doing is using the DAC to 
produce a waveform which is then used as the input for a Linear Time 
Invariant system.  The outputs of the system are being digitized at the 
same time by the 8 ADCs.  I am interested in determining the impulse 
response of the device under test, knowing the input and the output of 
the system.

How much latency would this type of application tolerate?   Perhaps as 
little as can be attained.

> 
> What else happens between the 8 ADC's and the 1? DAC. ?

I need a way to perhaps cache the data. The idea is to run the ADCs for 
~1 second sampling time, and then process the data.

> 
> What are your actual data rates  ?
> 
> In the simplest system, you could use Logic to assist a host uC, to
> manage 9 SPI ports as a Multichannel Par/SPI peripheral.
> The smallest FPGA would manage that, or even a medium-CPLD.
> 

That's really quite an interesting idea.  I need to sample at a minimum 
rate of 200 kHz.

Nicholas Kinar wrote:

> I can't tolerate much latency since what I am doing is using the DAC to 
> produce a waveform which is then used as the input for a Linear Time 
> Invariant system.  The outputs of the system are being digitized at the 
> same time by the 8 ADCs.  I am interested in determining the impulse 
> response of the device under test, knowing the input and the output of 
> the system.
> 
> How much latency would this type of application tolerate?   Perhaps as 
> little as can be attained.

I think jg means, if you have to generate the DAC signal in response of the
ADC signals and how much latency you can tolerate, e.g. you measure some
ADC value and then 1 ms later you need to generate a new calculated DAC
value.

I've found this page for Linear Time Invariant system:

http://en.wikipedia.org/wiki/LTI_system_theory

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?

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

Nicholas Kinar wrote:

> I'm using the AVR32 AP7001 from Atmel.  There's only a parallel memory 
> bus on this processor.  Unfortunately, there's no specialized bus for 
> just communicating with the FPGA.

So this is the chip you are using?

http://www.atmel.com/dyn/resources/prod_documents/doc32015.pdf

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

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

SSC is another nice interface. I've used this in another Atmel chip (9g20)
with PDC transfer. This makes it really easy, compared to the usual DMA
setup procedure: You just setup the number of words you want to receive,
the address to which it should write and then it reads the SSC interface
and issues an interrupt when done. The drawback would be, that you are at
the limit with the speed for the SSC for 400 kHz for 8 ADCs, but it should
work.

With SRAM you'll have lots of bandwith. Make sure to clock the FPGA with
the master clock, then you don't need to do edge detection and the like.
Maybe this works: Use block RAM for a small ringbuffer for the ADC and DAC
values, generate interrupts on FIFO thresholds and use the DMA on the CPU
side to transfer the data. SRAM PCB routing to the FPGA could be more
difficult than the SSC interface.

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