Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 142675

Article: 142675
Subject: Re: Timing properties of FPGA devices at sub-clock frequencies
From: Frank Buss <fb@frank-buss.de>
Date: Tue, 25 Aug 2009 20:33:20 +0200
Links: << >>  << T >>  << A >>
glen herrmannsfeldt wrote:

> There were some interesting designs that Peter Alfke used to
> come up with, but he knew which were and were not going to work.
> 
> Among others, he has a divide by 2.5 counter.  (I don't think
> it uses these tricks, but is interesting anyway.)  They can
> be used for clocking on rising and falling edge, though.

Yes, this is an interesting design. If you are a senior engineer at Xilinx,
you are allowed to do such interesting things, which might fail in
simulators, but works nice in FPGAs. My designs are sometimes the other
way: works in simulators, but fails in real FPGAs :-)

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

Article: 142676
Subject: Re: Timing properties of FPGA devices at sub-clock frequencies
From: Jon Elson <jmelson@wustl.edu>
Date: Tue, 25 Aug 2009 13:47:42 -0500
Links: << >>  << T >>  << A >>
glen herrmannsfeldt wrote:

> This reminds me of the stories of Cray using PC board traces
> to delay signals such that they would arrive at the desired
> time at the destination gate.  
> 
Completely standard practice.  Look at any motherbhoard since the '386 
went out of style, but especially any with DDR memories or PCI slots, 
and you will see "squiggles" in the traces to lengthen the wires that 
came out too short in the routing.  Obviously, you can't make a wire 
shorter without finding a more efficient route between the endpoints. 
If all signals on a bus need equal length, then you add length to the 
short ones.
> Basically, if you take a signal, delay it by two different values,
> then feed the two into an XOR gate, you will get a pulse with
> a length depending on the difference in the delay.
But, yeah, what the OP suggests sounds like a VERY hard way to do 
things, get very unpredictable results, generally find a lot of frustration.

Jon

Article: 142677
Subject: Re: Timing properties of FPGA devices at sub-clock frequencies
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Tue, 25 Aug 2009 18:56:55 +0000 (UTC)
Links: << >>  << T >>  << A >>
Jon Elson <jmelson@wustl.edu> wrote:
< glen herrmannsfeldt wrote:
 
<> This reminds me of the stories of Cray using PC board traces
<> to delay signals such that they would arrive at the desired
<> time at the destination gate.  
 
< Completely standard practice.  Look at any motherbhoard since the '386 
< went out of style, but especially any with DDR memories or PCI slots, 
< and you will see "squiggles" in the traces to lengthen the wires that 
< came out too short in the routing.  Obviously, you can't make a wire 
< shorter without finding a more efficient route between the endpoints. 
< If all signals on a bus need equal length, then you add length to the 
< short ones.

I have noticed those.  The same problem, but on a shorter
time scale.  

<> Basically, if you take a signal, delay it by two different values,
<> then feed the two into an XOR gate, you will get a pulse with
<> a length depending on the difference in the delay.

< But, yeah, what the OP suggests sounds like a VERY hard way 
< to do things, get very unpredictable results, generally find 
< a lot of frustration.

Maybe the frustration is the idea for the whole project.
That is, a practical demonstration of the advantages of
synchronous design.  

It does seem much harder in an FPGA than with TTL gates, though.
Especially with TTL you can build an analog delay with continuous
delay time, adjust it, and watch what happens.  Much harder to
do that inside the FPGA.

-- glen

Article: 142678
Subject: Re: Timing properties of FPGA devices at sub-clock frequencies
From: Andy <jonesandy@comcast.net>
Date: Tue, 25 Aug 2009 14:46:06 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Aug 25, 1:56=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> Jon Elson <jmel...@wustl.edu> wrote:
> < glen herrmannsfeldt wrote:
>
> <> This reminds me of the stories of Cray using PC board traces
> <> to delay signals such that they would arrive at the desired
> <> time at the destination gate. =A0
>
> < Completely standard practice. =A0Look at any motherbhoard since the '38=
6
> < went out of style, but especially any with DDR memories or PCI slots,
> < and you will see "squiggles" in the traces to lengthen the wires that
> < came out too short in the routing. =A0Obviously, you can't make a wire
> < shorter without finding a more efficient route between the endpoints.
> < If all signals on a bus need equal length, then you add length to the
> < short ones.
>
> I have noticed those. =A0The same problem, but on a shorter
> time scale. =A0
>
> <> Basically, if you take a signal, delay it by two different values,
> <> then feed the two into an XOR gate, you will get a pulse with
> <> a length depending on the difference in the delay.
>
> < But, yeah, what the OP suggests sounds like a VERY hard way
> < to do things, get very unpredictable results, generally find
> < a lot of frustration.
>
> Maybe the frustration is the idea for the whole project.
> That is, a practical demonstration of the advantages of
> synchronous design. =A0
>
> It does seem much harder in an FPGA than with TTL gates, though.
> Especially with TTL you can build an analog delay with continuous
> delay time, adjust it, and watch what happens. =A0Much harder to
> do that inside the FPGA.
>
> -- glen

Maybe the goal is not to create asynchronous delays, but rather a
multiphase clock, each phase offset from the next by much less than a
clock period.

DDR would be the simplest form of this.

Andy

Article: 142679
Subject: Reading from ADC and writing to DAC at same time
From: Nicholas Kinar <n.kinar@usask.ca>
Date: Tue, 25 Aug 2009 22:54:31 -0600
Links: << >>  << T >>  << A >>
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.

As the data is harvested from each ADC, I could shift the data into 
SDRAM. Once the measurement sequence is complete, the main system micro- 
controller could read the data from the FPGA SDRAM by using the FPGA as 
an SPI slave.

Is this a good way to proceed? My first initiative is to perhaps use a 
Cyclone III FPGA with 3.3V SDRAM logic, although I think that there are 
probably other FPGAs that could work just as well.

Are there any free/gratis megafunction solutions for SPI and 
communication with SDRAM logic?

What should I choose to be the clock speed on the FPGA, based on the 
maximum SPI bus rates?  The DAC has a maximum SPI clock of 30 MHz, and 
the max clock speed of the ADC is at least 50 MHz.


Article: 142680
Subject: Re: Reading from ADC and writing to DAC at same time
From: "Antti.Lukats@googlemail.com" <antti.lukats@googlemail.com>
Date: Tue, 25 Aug 2009 22:09:18 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Aug 26, 7:54=A0am, Nicholas Kinar <n.ki...@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. =A0A=
t
> the same time, I need to read data from each ADC.
>
> The DAC and the ADCs all communicate over SPI. =A0The maximum sampling
> rate of each 18-bit ADC is 400 kHz. =A0The 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. =A0I believe
> that it is possible to daisy-chain the ADCs.
>
> Perhaps the best way to do this is to use a FPGA. =A0I 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.
>
> As the data is harvested from each ADC, I could shift the data into
> SDRAM. Once the measurement sequence is complete, the main system micro-
> controller could read the data from the FPGA SDRAM by using the FPGA as
> an SPI slave.
>
> Is this a good way to proceed? My first initiative is to perhaps use a
> Cyclone III FPGA with 3.3V SDRAM logic, although I think that there are
> probably other FPGAs that could work just as well.
>
> Are there any free/gratis megafunction solutions for SPI and
> communication with SDRAM logic?
>
> What should I choose to be the clock speed on the FPGA, based on the
> maximum SPI bus rates? =A0The DAC has a maximum SPI clock of 30 MHz, and
> the max clock speed of the ADC is at least 50 MHz.

why do you think you need SDRAM?

what you need is just a statemachine-sequencer-special purpose SPI
engine
that places the results into dual port block ram (available in any
FPGA)

and as you requests are not standard you need to write the code from
scratch

Antti






Article: 142681
Subject: Re: Reading from ADC and writing to DAC at same time
From: Frank Buss <fb@frank-buss.de>
Date: Wed, 26 Aug 2009 07:37:06 +0200
Links: << >>  << T >>  << A >>
Antti.Lukats@googlemail.com wrote:

> why do you think you need SDRAM?
> 
> what you need is just a statemachine-sequencer-special purpose SPI
> engine
> that places the results into dual port block ram (available in any
> FPGA)

This depends on how long he wants to sample. If he needs some kilobytes,
block RAM would be ok. If it is below a megabyte, I would suggest SRAM,
because it is much easier to write your own VHDL code for it. And I would
use a ready made module, like this one, at least for the prototyping phase,
if it is going to be a product:

http://shop.trenz-electronic.de/catalog/product_info.php?cPath=1_48&products_id=81

More expensive, but with more pins and SDRAM instead of SRAM:

http://www.enterpoint.co.uk/moelbryn/darnaw1.html

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

Article: 142682
Subject: Re: Reading from ADC and writing to DAC at same time
From: Nicholas Kinar <n.kinar@usask.ca>
Date: Tue, 25 Aug 2009 23:40:37 -0600
Links: << >>  << T >>  << A >>
Thanks for your response, Antti.

> 
> why do you think you need SDRAM?
> 

Perhaps to store large amounts of data from all of the 6 ADCSs?

> what you need is just a statemachine-sequencer-special purpose SPI
> engine
> that places the results into dual port block ram (available in any
> FPGA)
> 

That is an interesting idea. But how much RAM do I generally have available?


> and as you requests are not standard you need to write the code from
> scratch

Would SPI be a challenge to implement in the way that I have described?

Article: 142683
Subject: Re: Reading from ADC and writing to DAC at same time
From: Nicholas Kinar <n.kinar@usask.ca>
Date: Tue, 25 Aug 2009 23:44:31 -0600
Links: << >>  << T >>  << A >>
Frank Buss wrote:
> Antti.Lukats@googlemail.com wrote:
> 
>> why do you think you need SDRAM?
>>
>> what you need is just a statemachine-sequencer-special purpose SPI
>> engine
>> that places the results into dual port block ram (available in any
>> FPGA)
> 
> This depends on how long he wants to sample. If he needs some kilobytes,
> block RAM would be ok. If it is below a megabyte, I would suggest SRAM,
> because it is much easier to write your own VHDL code for it. And I would
> use a ready made module, like this one, at least for the prototyping phase,
> if it is going to be a product:
> 
> http://shop.trenz-electronic.de/catalog/product_info.php?cPath=1_48&products_id=81
> 
> More expensive, but with more pins and SDRAM instead of SRAM:
> 
> http://www.enterpoint.co.uk/moelbryn/darnaw1.html
> 


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

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

Article: 142684
Subject: Re: Reading from ADC and writing to DAC at same time
From: "Antti.Lukats@googlemail.com" <antti.lukats@googlemail.com>
Date: Tue, 25 Aug 2009 22:58:25 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Aug 26, 8:40=A0am, Nicholas Kinar <n.ki...@usask.ca> wrote:
> Thanks for your response, Antti.
>
>
>
> > why do you think you need SDRAM?
>
> Perhaps to store large amounts of data from all of the 6 ADCSs?
>
> > what you need is just a statemachine-sequencer-special purpose SPI
> > engine
> > that places the results into dual port block ram (available in any
> > FPGA)
>
> That is an interesting idea. But how much RAM do I generally have availab=
le?
>
> > and as you requests are not standard you need to write the code from
> > scratch
>
> Would SPI be a challenge to implement in the way that I have described?


SPI =3D VERY simple
SRAM =3D SIMPLE

the amount of BRAM depends on the FPGA, i think smallest cyclone-3 has
66 KByte
(smallest spartan3a has only 6KByte)

for SRAM, well there are of course IP cores that use SRAM, but those
are most
like soft-processor bus attachments, so not necessarily much help for
you

but SRAM access is really very simple, not compared to the pain that
it is needed for SDRAM

GOP200 module is real nice small cute thing, I have one on my desk too
trenz is also very soon having S3ADSP low cost modules with SDRAM
/ but S3ADSP1800 has already 126KB of BRAM

Antti














Article: 142685
Subject: Re: Reading from ADC and writing to DAC at same time
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Wed, 26 Aug 2009 08:15:54 +0000 (UTC)
Links: << >>  << T >>  << A >>
Nicholas Kinar <n.kinar@usask.ca> wrote:
 
< 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.

How fast is SPI?
 
< Sampling from each ADC is triggered using a /TRIGGER pin.  I believe 
< that it is possible to daisy-chain the ADCs.

Maybe not if the bus isn't that fast.
 
< 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.

Separate SPI bus would allow each to run at full speed.
 
< As the data is harvested from each ADC, I could shift the data into 
< SDRAM. Once the measurement sequence is complete, the main system micro- 
< controller could read the data from the FPGA SDRAM by using the FPGA as 
< an SPI slave.

Why store it in SDRAM?  Process it and send it out immediately.

Well, 400kHz isn't so fast, but you could just build a state
machine in the FPGA.  Otherwise you might just as well use
any old processor.
 
-- glen

Article: 142686
Subject: Re: Reading from ADC and writing to DAC at same time
From: Nicholas Kinar <n.kinar@usask.ca>
Date: Wed, 26 Aug 2009 09:16:15 -0600
Links: << >>  << T >>  << A >>

> 
> SPI = VERY simple
> SRAM = SIMPLE
> 

Yes, I agree that SPI and SRAM are simple.


> 
> GOP200 module is real nice small cute thing, I have one on my desk too
> trenz is also very soon having S3ADSP low cost modules with SDRAM
> / but S3ADSP1800 has already 126KB of BRAM
> 
> Antti


I'll check it out, thanks Antti.



Article: 142687
Subject: Re: Reading from ADC and writing to DAC at same time
From: Nicholas Kinar <n.kinar@usask.ca>
Date: Wed, 26 Aug 2009 09:21:19 -0600
Links: << >>  << T >>  << A >>
Thanks, Glen.

> How fast is SPI?
>  

Maximum 30MHz, I believe.

> 
> Why store it in SDRAM?  Process it and send it out immediately.
> 

Perhaps what this would guarantee is "real-time," especially when 
working with Linux-based microcontrollers.


> Well, 400kHz isn't so fast, but you could just build a state
> machine in the FPGA.  Otherwise you might just as well use
> any old processor.
>  

Sure, even if the processor is running Linux, "almost real-time" is 
sometimes less complex than real-time.

Perhaps all of the ADCs and the DAC could be wired to the same bus?

Article: 142688
Subject: Re: Why there is multi-source error in these VHDL code?
From: KJ <kkjennings@sbcglobal.net>
Date: Wed, 26 Aug 2009 09:07:32 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Aug 25, 1:36=A0pm, Brian Drummond <brian_drumm...@btconnect.com>
wrote:

> Look at documentation for the simulator's "drivers" command; this may hel=
p you
> identify the unwanted signal source.
>

To add on to Brian's suggestion...

Then, after having identified the offending drivers, but before you
put the change in to fix the problem, try this:

1. Change the data type for that signal from 'std_logic' (or
'std_logic_vector') to 'std_ulogic' (or 'std_ulogic_vector').
2. Recompile and watch the compiler immediately flag the multiple
drivers for you without any debug effort or newsgroup posting.
3. Ask yourself if you really like spending your time debugging this
type of error or if having the compiler flag it for you isn't the
better way to go?
4. Throw mental darts at the picture of whoever first taught you VHDL
and told you that std_logic was the way to define signals with little
or no mention of std_ulogic.
5. Start using std_ulogic for signals that can only be driven by one
driver (hint:  that's most signals)

Kevin Jennings

Article: 142689
Subject: Re: Reading from ADC and writing to DAC at same time
From: "langwadt@fonz.dk" <langwadt@fonz.dk>
Date: Wed, 26 Aug 2009 09:34:13 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 26 Aug., 06:54, Nicholas Kinar <n.ki...@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. =A0A=
t
> the same time, I need to read data from each ADC.
>
> The DAC and the ADCs all communicate over SPI. =A0The maximum sampling
> rate of each 18-bit ADC is 400 kHz. =A0The 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. =A0I believe
> that it is possible to daisy-chain the ADCs.
>
> Perhaps the best way to do this is to use a FPGA. =A0I 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.
>
> As the data is harvested from each ADC, I could shift the data into
> SDRAM. Once the measurement sequence is complete, the main system micro-
> controller could read the data from the FPGA SDRAM by using the FPGA as
> an SPI slave.
>
> Is this a good way to proceed? My first initiative is to perhaps use a
> Cyclone III FPGA with 3.3V SDRAM logic, although I think that there are
> probably other FPGAs that could work just as well.
>
> Are there any free/gratis megafunction solutions for SPI and
> communication with SDRAM logic?
>
> What should I choose to be the clock speed on the FPGA, based on the
> maximum SPI bus rates? =A0The DAC has a maximum SPI clock of 30 MHz, and
> the max clock speed of the ADC is at least 50 MHz.

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




Article: 142690
Subject: Re: Reading from ADC and writing to DAC at same time
From: Nicholas Kinar <n.kinar@usask.ca>
Date: Wed, 26 Aug 2009 11:17:24 -0600
Links: << >>  << T >>  << A >>

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

Article: 142691
Subject: Re: Reading from ADC and writing to DAC at same time
From: Frank Buss <fb@frank-buss.de>
Date: Wed, 26 Aug 2009 19:35:38 +0200
Links: << >>  << T >>  << A >>
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

Article: 142692
Subject: Re: Reading from ADC and writing to DAC at same time
From: Frank Buss <fb@frank-buss.de>
Date: Wed, 26 Aug 2009 19:51:21 +0200
Links: << >>  << T >>  << A >>
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

Article: 142693
Subject: Re: Reading from ADC and writing to DAC at same time
From: -jg <jim.granville@gmail.com>
Date: Wed, 26 Aug 2009 12:43:36 -0700 (PDT)
Links: << >>  << T >>  << A >>
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

Article: 142694
Subject: Re: Reading from ADC and writing to DAC at same time
From: Nicholas Kinar <n.kinar@usask.ca>
Date: Wed, 26 Aug 2009 14:42:31 -0600
Links: << >>  << T >>  << A >>

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



Article: 142695
Subject: Re: Reading from ADC and writing to DAC at same time
From: Nicholas Kinar <n.kinar@usask.ca>
Date: Wed, 26 Aug 2009 14:50:56 -0600
Links: << >>  << T >>  << A >>

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



Article: 142696
Subject: Re: Reading from ADC and writing to DAC at same time
From: Nicholas Kinar <n.kinar@usask.ca>
Date: Wed, 26 Aug 2009 14:54:06 -0600
Links: << >>  << T >>  << A >>

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




Article: 142697
Subject: Re: Reading from ADC and writing to DAC at same time
From: Nicholas Kinar <n.kinar@usask.ca>
Date: Wed, 26 Aug 2009 15:03:17 -0600
Links: << >>  << T >>  << A >>
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.

Article: 142698
Subject: Re: Reading from ADC and writing to DAC at same time
From: Frank Buss <fb@frank-buss.de>
Date: Thu, 27 Aug 2009 01:38:27 +0200
Links: << >>  << T >>  << A >>
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

Article: 142699
Subject: Re: Reading from ADC and writing to DAC at same time
From: Frank Buss <fb@frank-buss.de>
Date: Thu, 27 Aug 2009 02:02:21 +0200
Links: << >>  << T >>  << A >>
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



Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search