FPGAs are definitely cool. I have a friend at Lockheed who is working
with them for high speed automatic control. I just don't know a whole
lot about using them, whereas I know a fair bit about DSPs. The Blackfin
is a great platform, and gcc will compile code for it, though how
optimized it is I don't know. I haven't investigated the I/O as much as
I have the TigerSHARC, but I imagine it's similar and a shared memory
interface is workable. Like I said before, do some benchmarks before you
invest thousands in hardware and software.
On Mon, 2007-04-30 at 21:38 -0400, MadAlexGumstix wrote:
> I second the motion on FPGAs as an ideal addition to the gumstix for hi-
> performance processing and I/O, especially for something like frame-rate
> video processing. For really-high-performance DSP, there are a number of
> folks out there who are now employing high-end FPGAs with built-in,
> dedicated DSP sections for image- processing solutions:
> Of particular interest for gumstix-based applications are FPGAs that use
> anti-fuse or built-in flash technology for configuration memory,
> allowing dramatically lower-power solutions, in extremely small packages
> (but with lower performance than the devices above):
> <http://www.actel.com/> Igloo (Flash) and Axcelerator (Anti-Fuse)
> <http://www.quicklogic.com/> PolarPro and Eclipse II (Anti-Fuse)
> If you want to start with a FPGA-on-a-DIP solution, see somebody like
> FYI, FPGA intellectual property (IP) is available from the FPGA OEMs
> (often free for eval or for simple functions), 3rd-party IP vendors, and
> from open-source sites like OpenCores <http://www.OpenCores.org/>.
> I will say, however (no direspect to the gumstix), that if you need a
> solution with general-purpose processing, flexible I/O, power
> efficiency, DSP, and Linux support, the Analog Devices Blackfin family
> is pretty nice as an alternative to a PXA-based processor:
> On Mon, 30 Apr 2007 17:59:28 -0700, "Craig Hughes"
> <craig@...> said:
> > Rather than a DSP, you might consider looking at an FPGA; integrating
> > an FPGA to the gumstix should be pretty easy, and if you pick the
> > right family of FPGAs, I think you can even get free development tools
> > for them from the manufacturers.
> > On Apr 30, 2007, at 10:51 AM, Ryan Rapetti wrote:
> > > I think the DSP idea may be your best bet. I don't know enough about
> > > the software architecture to give a whole lot of direction here, but
> > > it should be possible to abstract out all the heavy duty computation
> > > to the DSP and go from there. The major downside of DSP is the
> > > development cost. The devel environments are very complex and hence
> > > expensive. GCC won't do the job, so you'll have to get Analog's
> > > software. The upside is that this setup works very, very, well.
> > > Analog has a text that they put out on fundamentals of DSP and
> > > signal/image processing in general that I found very helpful.
> > > Personally, I wouldn't count out the gumstix as a processing tool.
> > > It may work ok. You can write up the code and have gcc compile it
> > > for x86 without floating point and then dig up an old 600MHz linux
> > > box, boot it to console and do some benchmarks. It won't be perfect
> > > but it should ballpark things. I'd get a better idea of the actual
> > > processing needs before I invested in a bunch of TigerSHARCs and 5
> > > or 10K in software. Good luck-
> > >
> > > Ryan
> > >
> > > On Thu, 2007-04-26 at 11:07 -0400, Dave Cubanski wrote:
> > >> Ryan--
> > >>
> > >> Thanks for the overview and background info...
> > >>
> > >> As for the application - it is an image processing application.
> > >> I'm going to be identifying and measuring a large number of
> > >> features in video imagery at 20-30 frames per second, and I'd much
> > >> prefer to have hardware floating point support for the (very
> > >> complicated) underlying mathematics. My gut feeling (though
> > >> incompletely informed) is that software emulated floating point in
> > >> this case is going to be much too slow. I could switch everything
> > >> to integer math, I suppose, but at this point I really don't want
> > >> to do the work of analyzing all of the scaling of values to prevent
> > >> overflows or imprecisions, etc. I've read (via this mailing list)
> > >> that the PXA270 has some support for 64-bit integer operations;
> > >> this might be a useful alternative, but at this point I don't know
> > >> what support there might be for that in gcc/g++.
> > >>
> > >> My thinking at this point is that a DSP chip like a SHARC is
> > >> probably the best choice here; in the end I'm probably going to
> > >> need to build a 120-pin expansion card for the Verdex, that has a
> > >> DSP chip on it to crunch the signal processing math. I kind of
> > >> need to have the Verdex / Linux as part of the system to have
> > >> prebuilt access to networking, storage, communications, etc; I had
> > >> hoped to avoid the software complexity of two separate processors;
> > >> it would have been nice if the Verdex could somehow do everything.
> > >> I've seen reference to an arm- gcc -nofpu option, which somehow
> > >> gave me hope that there might be an easy way to add a memory-mapped
> > >> FPU; maybe not with PXA270, though...
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> gumstix-users mailing list