[hpsdr] Cascading ADC/FPGA Pairs
alex
ajbr at btconnect.com
Sat Aug 22 03:17:53 PDT 2009
no because the fpga's wouldn't be able to downsample at 1ghz unless they
had all the samples, you would just get several 150mhz samples
it would need about £1000 in adc's and probably another £1000 in fast fpga
> ***** High Performance Software Defined Radio Discussion List *****
>
> Great answer. Helps me articulate the question better which is:
>
> Can I have a fast master CPU (>3.5 GHz) managing a set of nodes where each
> node is an FPGA/ADC pair, such that the FPGA/ADC pair are less expensive
> than the equivalent SINGLE fast FPGA/ADC.
>
> - Van / AE5CC / wdv.com
>
>
>
> -----Original Message-----
> From: Graham / KE9H [mailto:KE9H at austin.rr.com]
> Sent: Friday, August 21, 2009 5:04 PM
> To: L. Van Warren; HPSDR list
> Subject: Re: [hpsdr] Cascading ADC/FPGA Pairs
>
> Van:
> Great question. The FPGA and its parallelism seems to win when you need
> a real
> fast real-time front end. If you look at Mercury, the FPGA is the A-D
> interface,
> the first local oscillator, the first mixer, and a bunch of filtering
> that roughly corresponds
> to the first/high IF in a superhet radio. All occuring in parallel, in
> real time, locked
> to the A-D sample rate clock.
>
> You might get a real fast CPU to manage multiple A-D converters, if you
> got the OS
> with all of its interrupts out of the picture, but it would then not
> have the real time
> left to do all the other front-end/high IF stuff.
>
> The CPU's seem to still win the human interface and back end signal
> processing.
> There is a group here in Austin of QRP guys that keeps trying to use
> DSP's for the
> backend, and get the CPU out of the radio, but the CPU's (as in packaged
> in a desktop
> or laptop or netbook with the keyboard, displays, interfaces, etc.) keep
> rising in
> performance and dropping in price, faster than they can get a DSP working.
>
> I note that the SuitSat guys are using a 32 bit Microchip CPU for their
> signal
> processing, rather than a Microchip dsPIC.
>
> So CPUs are winning, just not in the real-time front end.
>
> --- Graham
>
> ==
>
> L. Van Warren wrote:
>
>> Gotcha... I was just wondering if there was a hierarchy, or as Ivan
>> Sutherland used to say, "a great wheel of reincarnation" that led us
>> eventually back to managing the whole shebang from a conventional CPU
>> because of max clock rate concerns.
>>
>>
>> - Van / AE5CC / wdv.com
>>
>>
>>
>>
>>
>>
>>
>> -----Original Message-----
>> From: Graham / KE9H [mailto:KE9H at austin.rr.com]
>> Sent: Friday, August 21, 2009 4:22 PM
>> To: L. Van Warren
>> Cc: 'John Nordlund'; hpsdr at openhpsdr.org
>> Subject: Re: [hpsdr] Cascading ADC/FPGA Pairs
>>
>> Hi Van:
>> I resent you a copy, offline, of my email from yesterday where I think I
>> answered
>> your questions. So, what you can get out of a highly parallel FPGA
>> managing 5ea. 16 bit A->D converters is 5x16=80 bits of info at
>> 200 MegaSamples per second, which I don't think the downstream
>> signal processing will care is in that format versus 16 bits at 1000
>> MegaSamples
>> per second, since one of the early things you do with it is decimate it.
>>
>> I am guessing that one FPGA could handle more
>> A-D's if the number of available phase steps is adequate. The issue is
>>
> more
>
>> likely the smearing of values in time in the front end of the A->Ds since
>> they were designed to sample 5 or 6 ns wide samples, and we would be
>> asking them to sample 1 ns wide samples.
>>
>> --- Graham
>>
>> ==
>>
>> L. Van Warren wrote:
>>
>>
>>> ***** High Performance Software Defined Radio Discussion List *****
>>>
>>> If you trace this conversation back, Graham doesn't answer the question,
>>> which is what is the maximum clock rate of an appropriate FPGA, like the
>>> Alterra Cyclone..
>>>
>>> At some point, no matter how much parallelism is in the FPGA, the clock
>>>
>>>
>> rate
>>
>>
>>> of an FPGA-based system determines the maximum sampling rate of the
>>>
>>>
>> signal.
>>
>>
>>> My thought is that if a master CPU running at 3.5 GHz can coordinate the
>>> final results of a set of slaved (and less expensive) FPGA/ADC pairs then
>>>
>>>
>> it
>>
>>
>>> is the clock rate of the CPU and not the FPGA which determines the
>>>
> maximum
>
>>> sampling rate of the system.
>>>
>>> Whether this is true I don't know, but that is the question that I want
>>>
> to
>
>>> see the math for.
>>>
>>> - Van / AE5CC / wdv.com
>>>
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: John Nordlund [mailto:ad5fu at earthlink.net]
>>> Sent: Friday, August 21, 2009 2:31 PM
>>> Cc: L. Van Warren; fallingstar at cauhf.org
>>> Subject: Re: [hpsdr] Cascading ADC/FPGA Pairs
>>>
>>> even better..
>>>
>>> Graham / KE9H wrote:
>>>
>>>
>>>
>>>> L.Van:
>>>>
>>>> That is the beauty of using the FPGA. For dedicated logic tasks
>>>> like playing "put and take" with the output of several A->Ds, the
>>>> FPGA is faster than a CPU, particularly one subject to continuous
>>>> interruptions such as when a modern OS is involved. The FPGA
>>>> can do multiple things in parallel, as opposed to the one thing at
>>>> a time, in series, that is characteristic of a CPU. Note that the
>>>> FPGA the oscilloscope company used is the same Cyclone-III
>>>> family as HPSDR uses on Mercury.
>>>>
>>>> --- Graham
>>>>
>>>> ==
>>>>
>>>> L. Van Warren wrote:
>>>>
>>>>
>>>>
>>>>> ***** High Performance Software Defined Radio Discussion List *****
>>>>>
>>>>> That was a very interesting post about using multiple low cost ADCS
>>>>> to look
>>>>> like a higher rate ADC.
>>>>>
>>>>> I'm wondering if a high-end CPU, running at say 3 GHz could
>>>>> coordinate the
>>>>> traffic coming from multiple ADC/FPGA pairs.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>
>>
>
> _______________________________________________
> HPSDR Discussion List
> To post msg: hpsdr at openhpsdr.org
> Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org
> HPSDR web page: http://openhpsdr.org
> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/
>
1250936273.0
More information about the Hpsdr
mailing list