Forums

ADC with 50MSPS attached to DSP

Started by Stefan Fuchs July 11, 2004
Hi,

I need to analyze echoes of a 13MHz pulse RADAR using a DSP.

I would like to use a 12-bit, > 50MSPS ADC to sample the signal. Is it 
possible to attach the ADC (e.g AD9226) directly to the parallel port of 
a DSP and transfer the data vie DMA?
Did anyone try to attach such high-speed ADCs to a DSP? Which processor 
was used?



Thanks a lot!

Stefan
Stefan Fuchs wrote:

> Hi, > > I need to analyze echoes of a 13MHz pulse RADAR using a DSP. > > I would like to use a 12-bit, > 50MSPS ADC to sample the signal. Is it > possible to attach the ADC (e.g AD9226) directly to the parallel port of > a DSP and transfer the data vie DMA? > Did anyone try to attach such high-speed ADCs to a DSP? Which processor > was used? > > > > Thanks a lot! > > Stefan
Someone will correct me if I'm wrong, but I don't believe that there is a DSP that has a "parallel port" that supports input from this ADC. The ADC is pipelined, which means that once you start clocking it there will always be data coming out. It doesn't have any mechanism for asynchronous reads (which is what you'd need for DMA). I think that whatever you do you're going to need some glue logic between the DSP and the ADC. I would suggest a small FPGA to implement the glue logic, and you may as well implement a FIFO as well -- even the el-cheapo Xilinx Spartan III parts have built-in RAM that can be used for small FIFO's, and while I don't keep track of Altera as closely they'll certainly be keeping up. If you're clever and if you don't mind the DSP being stalled while the transfer is happening you _may_ be able to do direct DMA with a CPLD and a tri-state buffer. This won't save you much board space or BOM money over the FPGA solution, your processor performance will be degraded, the hardware engineering time probably won't be much smaller, and the software engineering time will be significantly longer. I would recommend it only if you're planning on an annual production in the thousands. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com
Tim Wescott wrote:

> Stefan Fuchs wrote: > >> Hi, >> >> I need to analyze echoes of a 13MHz pulse RADAR using a DSP. >> >> I would like to use a 12-bit, > 50MSPS ADC to sample the signal. >> Is it possible to attach the ADC (e.g AD9226) directly to the >> parallel port of a DSP and transfer the data vie DMA? >> Did anyone try to attach such high-speed ADCs to a DSP? Which >> processor was used? >> >> >> >> Thanks a lot! >> >> Stefan > > Someone will correct me if I'm wrong, but I don't believe that > there is > a DSP that has a "parallel port" that supports input from this > ADC. The ADC is pipelined, which means that once you start > clocking it there will > always be data coming out. It doesn't have any mechanism for > asynchronous reads (which is what you'd need for DMA). > > I think that whatever you do you're going to need some glue logic > between the DSP and the ADC. I would suggest a small FPGA to > implement the glue logic, and you may as well implement a FIFO as > well -- even the el-cheapo Xilinx Spartan III parts have built-in > RAM that can be used for small FIFO's, and while I don't keep > track of Altera as closely they'll certainly be keeping up. > > If you're clever and if you don't mind the DSP being stalled while > the transfer is happening you _may_ be able to do direct DMA with > a CPLD and > a tri-state buffer. This won't save you much board space or BOM > money over the FPGA solution, your processor performance will be > degraded, the hardware engineering time probably won't be much > smaller, and the > software engineering time will be significantly longer. I would > recommend it only if you're planning on an annual production in > the thousands. >
Hi. I agree, Tim. Our approach in a current project is like this. We're going to work with a signal up to a few MHZ, sampled at 48MS/s. Since information content has only a small bandwidth, we're going this way: ADC --> Spartan-FPGA --> SPORT (serial link) --> Sharc DSP The FPGA is better equipped for doing high-speed stuff than the DSP would. A sort of mixer (implemented in VHDL) reduces the samples to a fair rate of 96kS/s, which are transmitted to the DSP using an implemented standard interface (SPORT). It's an easy thing to get the FPGA connected to the ADC on one and the DSP on the other side. If we would ever change/replace the ADC, it would be easy again to modify the interface. The DSP, on the other end, can attach to the FPGA via its internal DMA processor, which means that the DSP performance is high, because it need not spend time form shifting data in and out. For prototyping we used an FPGA-board from Cesys and an evaluation board from AnalogDevices. Just connect and go ahead! Since I guess that you, Stefan, deal with 13MHz, but you're interested in the modulation/shape of the signal stream which has much smaller bandwidth, there's a fair chance, that a CPLD or FPGA between ADC and DSP would enrich your system in the same way, by making interfacing easier and by saving expensive processing power of the DSP. Bernhard
Tim, Bernhard, thanks for your answers!


Analog Devices showed in an article that it is possible to attach an 
20-40MSPS ADC to a Sharc DSPs parallel port only using an output buffer.

But from 50MSPS upwards it seems to be an much better idea to use a FPGA 
as FIFO.

The 13MHz (or perhaps even 27MHz) radar pulse would be eg. biphase 
modulated with a rate of 6.5M subpulses/s signal so you would get very 
short subpulses (and very high bandwidth compared to 13MHz).

I would like to be able to extract this biphase modulation. So I don't 
want to decrease the sampling rate. But I have enough time to process 
the data. So once the data is in _any_ memory there is enough time to 
get it to the DSPs memory via DMA.


Now, the major problem, as you can perhaps see from my writing ;-) is 
that I am totally inexperienced with everything. I'm familiar to FPGA 
design (Altera), pcb design, microprocessor programming and digital 
signal processing but have no large practical experience.
...Typical student after 5 years of electrical engineering ;-)

So, what do you think? Can I do this (ADC@50MSPS -> Spartan-III or 
Cyclone-II FPGA -> ADSP-21262 or TigerSharc plus Software) in five months?


Stefan


Bernhard Holzmayer schrieb:
> Tim Wescott wrote: > > >>Stefan Fuchs wrote: >> >> >>>Hi, >>> >>>I need to analyze echoes of a 13MHz pulse RADAR using a DSP. >>> >>>I would like to use a 12-bit, > 50MSPS ADC to sample the signal. >>>Is it possible to attach the ADC (e.g AD9226) directly to the >>>parallel port of a DSP and transfer the data vie DMA? >>>Did anyone try to attach such high-speed ADCs to a DSP? Which >>>processor was used? >>> >>> >>> >>>Thanks a lot! >>> >>>Stefan >> >>Someone will correct me if I'm wrong, but I don't believe that >>there is >>a DSP that has a "parallel port" that supports input from this >>ADC. The ADC is pipelined, which means that once you start >>clocking it there will >>always be data coming out. It doesn't have any mechanism for >>asynchronous reads (which is what you'd need for DMA). >> >>I think that whatever you do you're going to need some glue logic >>between the DSP and the ADC. I would suggest a small FPGA to >>implement the glue logic, and you may as well implement a FIFO as >>well -- even the el-cheapo Xilinx Spartan III parts have built-in >>RAM that can be used for small FIFO's, and while I don't keep >>track of Altera as closely they'll certainly be keeping up. >> >>If you're clever and if you don't mind the DSP being stalled while >>the transfer is happening you _may_ be able to do direct DMA with >>a CPLD and >>a tri-state buffer. This won't save you much board space or BOM >>money over the FPGA solution, your processor performance will be >>degraded, the hardware engineering time probably won't be much >>smaller, and the >>software engineering time will be significantly longer. I would >>recommend it only if you're planning on an annual production in >>the thousands. >> > > > Hi. > I agree, Tim. Our approach in a current project is like this. > > We're going to work with a signal up to a few MHZ, sampled at > 48MS/s. Since information content has only a small bandwidth, > we're going this way: > > ADC --> Spartan-FPGA --> SPORT (serial link) --> Sharc DSP > > The FPGA is better equipped for doing high-speed stuff than the DSP > would. A sort of mixer (implemented in VHDL) reduces the samples to > a fair rate of 96kS/s, which are transmitted to the DSP using an > implemented standard interface (SPORT). > > It's an easy thing to get the FPGA connected to the ADC on one and > the DSP on the other side. > If we would ever change/replace the ADC, it would be easy again to > modify the interface. > > The DSP, on the other end, can attach to the FPGA via its internal > DMA processor, which means that the DSP performance is high, > because it need not spend time form shifting data in and out. > > For prototyping we used an FPGA-board from Cesys and an evaluation > board from AnalogDevices. Just connect and go ahead! > > Since I guess that you, Stefan, deal with 13MHz, but you're > interested in the modulation/shape of the signal stream which has > much smaller bandwidth, there's a fair chance, that a CPLD or FPGA > between ADC and DSP would enrich your system in the same way, by > making interfacing easier and by saving expensive processing power > of the DSP. > > Bernhard
Am Wed, 14 Jul 2004 14:32:08 +0200 schrieb Stefan Fuchs:

> Tim, Bernhard, thanks for your answers! > > > Analog Devices showed in an article that it is possible to attach an > 20-40MSPS ADC to a Sharc DSPs parallel port only using an output buffer. > > But from 50MSPS upwards it seems to be an much better idea to use a FPGA > as FIFO. > > The 13MHz (or perhaps even 27MHz) radar pulse would be eg. biphase > modulated with a rate of 6.5M subpulses/s signal so you would get very > short subpulses (and very high bandwidth compared to 13MHz). > > I would like to be able to extract this biphase modulation. So I don't > want to decrease the sampling rate. But I have enough time to process > the data. So once the data is in _any_ memory there is enough time to > get it to the DSPs memory via DMA. > > > Now, the major problem, as you can perhaps see from my writing ;-) is > that I am totally inexperienced with everything. I'm familiar to FPGA > design (Altera), pcb design, microprocessor programming and digital > signal processing but have no large practical experience. > ...Typical student after 5 years of electrical engineering ;-) > > So, what do you think? Can I do this (ADC@50MSPS -> Spartan-III or > Cyclone-II FPGA -> ADSP-21262 or TigerSharc plus Software) in five months? > > > Stefan
Hi Stefan, we have used a 60 Ms/s ADC in a Lidar (optical Radar). The data goes first to a Altera FPGA ACEX 1k10 as a FIFO and then via serial interface (SSI) to a Motorola DSP56303 DSP board. Evereything works well. Siegbert
Stefan Fuchs wrote:

> Tim, Bernhard, thanks for your answers! > > > Analog Devices showed in an article that it is possible to attach an > 20-40MSPS ADC to a Sharc DSPs parallel port only using an output buffer. > > But from 50MSPS upwards it seems to be an much better idea to use a FPGA > as FIFO. > > The 13MHz (or perhaps even 27MHz) radar pulse would be eg. biphase > modulated with a rate of 6.5M subpulses/s signal so you would get very > short subpulses (and very high bandwidth compared to 13MHz). > > I would like to be able to extract this biphase modulation. So I don't > want to decrease the sampling rate. But I have enough time to process > the data. So once the data is in _any_ memory there is enough time to > get it to the DSPs memory via DMA. > > > Now, the major problem, as you can perhaps see from my writing ;-) is > that I am totally inexperienced with everything. I'm familiar to FPGA > design (Altera), pcb design, microprocessor programming and digital > signal processing but have no large practical experience. > ...Typical student after 5 years of electrical engineering ;-) > > So, what do you think? Can I do this (ADC@50MSPS -> Spartan-III or > Cyclone-II FPGA -> ADSP-21262 or TigerSharc plus Software) in five months? > > > Stefan > >
In five months? That depends on you, your schedule, and whether you want to have any social life. If I had a client who wanted a demonstrator I could get something like that put together by myself in that amount of time, but it would be somewhat rough and I wouldn't have to pass any classes while I was doing it. I would investigate if this could be done with eval boards. You should be able to get eval boards for each piece and rope them together, but you may have signal integrity problems between the FPGA and ADC. You may also be able to use an FPGA eval board and plug in a custom daughter board with and ADC on it (or look for an eval board with FPGA and ADC already). Presumably you can slow down the FPGA->DSP communications as much as necessary, or use a to cut down on the wires. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com
Hello Siegbert,

How many Bits has your ADC ?
If you would have a 8-bit ADC this would require a 480Mbit serial interface ?
(Or did I miss something ?)

                                    Thanks, Wolfgang

> Hi Stefan, > > we have used a 60 Ms/s ADC in a Lidar (optical Radar). The data goes first > to a Altera FPGA ACEX 1k10 as a FIFO and then via serial interface (SSI) to > a Motorola DSP56303 DSP board. Evereything works well. > Siegbert
Stefan Fuchs wrote:

> Analog Devices showed in an article that it is possible to attach > an 20-40MSPS ADC to a Sharc DSPs parallel port only using an > output buffer. > > But from 50MSPS upwards it seems to be an much better idea to use > a FPGA as FIFO. > > The 13MHz (or perhaps even 27MHz) radar pulse would be eg. biphase > modulated with a rate of 6.5M subpulses/s signal so you would get > very short subpulses (and very high bandwidth compared to 13MHz). > > I would like to be able to extract this biphase modulation. So I > don't want to decrease the sampling rate. But I have enough time > to process the data. So once the data is in any memory there is > enough time to get it to the DSPs memory via DMA. > > > Now, the major problem, as you can perhaps see from my writing ;-) > is that I am totally inexperienced with everything. I'm familiar > to FPGA design (Altera), pcb design, microprocessor programming > and digital signal processing but have no large practical > experience. ...Typical student after 5 years of electrical > engineering ;-) >
Most important is that the DSP (as far as you need any if you have an FPGA anyhow...) can gather the incoming data stream with its DMA. This results in a zero load of the processor core. If you want the DSP to bother with the ADC's handshake or so, this will overload your DSP, even at 13MS/s: the DSP won't have enough spare time to do the real signal processing. A basic guideline which I learnt is that a DSP is good for algorithmic signal processing, but is is usually the wrong device to deal with bit/pin oriented controller stuff. Therefore, if it is affordable (I guess cost and/or size is not the issue for you), I'd insert an FPGA or CPLD as soon as it is obvious that the internal DMA processor cannot deal with the incoming data without interference of the processor core. If the DMA can stream incoming data with the DSP core staying in the idle state, then you're on the right path...
> So, what do you think? Can I do this (ADC@50MSPS -> Spartan-III or > Cyclone-II FPGA -> ADSP-21262 or TigerSharc plus Software) in five > months?
Start with a proper design on a few sheets of paper, maybe with some simulation of algorithms, thus avoiding loops/restarts. I guess that the most difficult thing in the hardware area will be the analog part (clean RF design, dealing with gain control, etc...). Since you're experienced with FPGA design, use this advantage and do as much as possible in the FPGA (all the interface and protocols stuff...) Use a commonly used link to transfer data into the DSP, SPORT or Link Ports via DMA. Start with one of the demo programs and a very simple data processing algorithm until you are sure that converted signals arrive correctly within the DSP. Five months is a dense timing. Topic must be: avoid risks. However, if you are not distracted by other things during this time, it should be possible to achieve most of these goals. It's quite a difference, if you want solve this problem in an academic way, that it just fulfils its main task and proves itself. If so, go with off-the-shelf evaluation boards. This minimizes the risk to get lost in difficulties which have already been overcome. In contrary, if your solution will be part of a real product and must meet reliability and other quality aspects and all the things which belong to a proper development, you'll certainly need much more than one year. Remember your first FPGA design: how long did it last until it worked? Did it work correctly by design - or just by chance? Where were the pitfalls? Who helped you? Be sure you'll run into new pitfalls, dead-end roads. You may succeed in spite of lack of such help, but it will cost you a lot of time. Take this into account. Bernhard