Prev: some good papers on OFDM/MIMO-OFDM
Next: Exocortex.DSP FFT implimentation? What should my result look like.
From: Tim Wescott on 14 Jul 2010 17:21
On 07/14/2010 10:23 AM, Rob Gaddi wrote:
> On 7/13/2010 10:09 PM, san_jack wrote:
>> The reason we are going for FPGA is we have soft ip cores of all the
>> modules targeted for fpga and we are not going for bulk production. even
>> though speed is less, area requirement of the design is more (about 2
>> spartan-6 lx16) fpgas.
>>
>
> An S6 LX16 is a monster of a part: you've got flops, gates, and RAMs
> coming out your ears. To have to throw two of them at a problem, and
> then to only be clocking them at 20 kHz, seems off.
>
> Let's say you had 1000x as many clock cycles to work with, which would
> push your central clock rate up to a mere 20 MHz. That's plenty of time
> to store one set of data in RAM, pull a different set of data, do
> operations on it, and repeat. Are you 100% sure you're attacking this
> problem correctly?
>
Buy an FPGA-able ARM core?

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" was written for you.
See details at http://www.wescottdesign.com/actfes/actfes.html
From: Manny on 14 Jul 2010 18:30
On Jul 14, 10:21 pm, Tim Wescott <t...(a)seemywebsite.com> wrote:
> On 07/14/2010 10:23 AM, Rob Gaddi wrote:
>
> > On 7/13/2010 10:09 PM, san_jack wrote:
> >> The reason we are going for FPGA is we have soft ip cores of all the
> >> modules targeted for fpga and we are not going for bulk production. even
> >> though speed is less, area requirement of the design is more (about 2
> >> spartan-6 lx16) fpgas.
>
> > An S6 LX16 is a monster of a part: you've got flops, gates, and RAMs
> > coming out your ears. To have to throw two of them at a problem, and
> > then to only be clocking them at 20 kHz, seems off.
>
> > Let's say you had 1000x as many clock cycles to work with, which would
> > push your central clock rate up to a mere 20 MHz. That's plenty of time
> > to store one set of data in RAM, pull a different set of data, do
> > operations on it, and repeat. Are you 100% sure you're attacking this
> > problem correctly?
>
> Buy an FPGA-able ARM core?

Or design the whole thing asynchronously i.e. in a *self-timed*
manner. It'll be a nice exercise, though not a terribly useful one. Or
tell you what: instantiate a picoblaze, run everything in software,
and deallocate your dynamic reconfiguration block when done.

-Momo
From: san_jack on 15 Jul 2010 00:11
Important thing is that we are a product oriented company and want to
capitalize the idea soon to beat the competitor (also to be finished before
next appraisal meet to guard us from screwing). we have good experience in
vhdl and actually starting our first design in FPGA. so we don't want to
broaden our views and spend time for knowing about dsp,arm,etc.


>On Jul 14, 10:21=A0pm, Tim Wescott <t...(a)seemywebsite.com> wrote:
>> On 07/14/2010 10:23 AM, Rob Gaddi wrote:
>>
>> > On 7/13/2010 10:09 PM, san_jack wrote:
>> >> The reason we are going for FPGA is we have soft ip cores of all the
>> >> modules targeted for fpga and we are not going for bulk production.
ev=
>en
>> >> though speed is less, area requirement of the design is more (about
2
>> >> spartan-6 lx16) fpgas.
>>
>> > An S6 LX16 is a monster of a part: you've got flops, gates, and RAMs
>> > coming out your ears. To have to throw two of them at a problem, and
>> > then to only be clocking them at 20 kHz, seems off.
>>
>> > Let's say you had 1000x as many clock cycles to work with, which
would
>> > push your central clock rate up to a mere 20 MHz. That's plenty of
time
>> > to store one set of data in RAM, pull a different set of data, do
>> > operations on it, and repeat. Are you 100% sure you're attacking this
>> > problem correctly?
>>
>> Buy an FPGA-able ARM core?
>
>Or design the whole thing asynchronously i.e. in a *self-timed*
>manner. It'll be a nice exercise, though not a terribly useful one. Or
>tell you what: instantiate a picoblaze, run everything in software,
>and deallocate your dynamic reconfiguration block when done.
>
>-Momo
>
First  |  Prev  | 
Pages: 1 2 3 4
Prev: some good papers on OFDM/MIMO-OFDM
Next: Exocortex.DSP FFT implimentation? What should my result look like.