Seeking some recommendations for embedded low-power (definitely fanless) uP + DSP that can handle H.264 Basic profile encoding, for VGA frames @ 30fps (or more) with 30% (atleast) motion. At the moment, DaVinci seems the closest choice, but for the price-points I am looking at, DaVinci's are still about 40% more expensive. Blackfin seem the second best choice, but are lack horsepower on DSP end (apparently from some reports) for the kind of H.264 heavylifting.
Given the dual objective of low-power (consumption), and low-cost, are FPGA's a viable alternative ? What could be the potential pitfalls of using FPGA, as against a DSP.
Application context is ruggedized, semi-mobile/portable, communication (VoIP over 3G), control/monitoring device. Control is for resistive load equipment upto 1KW, and monitoring some sensors.
I don't know the specifics of H.264, but I do know some generalities:
An FPGA _may_ be a viable alternative. Power will be a concern, but my experience with video processing in FPGA vs. DSP was that you can't just consider the processor -- the memory for frame buffers is a big "everything hog", and using an FPGA gives you tons more flexibility to interface to memory. Thus, even if an FPGA _by itself_ consumes more power and/or money, an FPGA _with memory_ may be less expensive than a 'cheaper', 'lower power' DPS once you get it hooked up to memory and whatnot.
Designing with FPGAs is much more involved -- HDLs look like C from a distance, but you're working at a level of detail that's a lot more like assembly language than C is. Some operations that are prohibitive in a DSP are easy in an FPGA, some algorithms that are easy in a DSP use up tremendous amounts of FPGA space.
I tend to separate FPGAs and DSPs into two domains -- FPGAs are good for small, tight algorithms that need to run fast. DSPs (and to a greater extent general-purpose microcontrollers) are good for large algorithms with lots of conditional execution that can run more slowly.
Were I you I'd investigate not two, but three possibilities: one, an all-DSP solution; two, an all-FPGA solution; and three, an FPGA with a small processor "helper". Doing so will blow your selection process wide open, because now you have a huge balancing act between the FPGA and the processor, but it also gives you the opportunity to have a cheap little processor doing what processors do best, along with an FPGA doing what FPGAs do best. It also raises the question of whether that processor should be inside or outside of the FPGA.
There's a lot of ways to skin the cat, unfortunately it's not always obvious which ones are any good until you start getting messy.
As an example of this, I used to do a lot of work with imagers that worked at video rate. Detector pixels would need to be individually corrected for gain and offset; it was possible to do this with a DSP, but it'd be such a busy little chip, with an enormous choke point at the memory interface. By the time you were done making that happen in a DSP you had one expensive DSP that was so bogged down in memory accesses that it needed a second processor for "everything else". Given that, we always ended up using an FPGA for that DSP task.
So we'd have the FPGA handle 'pixel rate' stuff, and anything that happened at "human speed" -- i.e. looking for commands (on buttons or comm interfaces) to change overall contrast or level or video mode or whatnot -- was always done with a processor. You could, in theory, do this in an FPGA, but if you did you'd have huge swaths of logic, capable of running tens or hundreds of MHz, sitting idle only to come on once every second or so. So there'd be a processor in charge of talking to the outside world, and that processor would read and write registers on the FPGA to make it do stuff.
Controversy generally raged over what to do with processes that happened at the frame rate or the line rate -- I happened to be in the camp that said that the FPGA should stick with things happening at the pixel rate, and any higher functions (like phase locking frames to external sources, or calculating register values for 25Hz vs. 30Hz operation or corralling frames over a high speed bus) should happen in the processor under a frame interrupt, while the more hard-core FPGA guys would campaign to have the FPGA 'do everything'.
Both answers are right, which is why there was room for the controversy to rage. I will say that doing this with a processor + cheap FPGA _may_ be the best way to go -- but it depends on what you can do with what you have.
--
Tim Wescott
Control system and signal processing consulting
www.wescottdesign.com
While I do not recollect a specific processor or it's part number, going by the specs, and app notes and checking prices at digikey the ~40% price difference is what I found between somewhat similarly specd DaVinci and Blackfin. When I say similarly spec'd, I mean processors whose app notes state similar usage profile.
Don't have the processor number, but this was a dual-processor on a die, meant for video applications.
If I say 'Yes, I am a stupident', will you be help any more ? If not, I'd choose to ignore arsenic licking trolls.
Are yiou a stupident ?
I am sure you do. Are those the only ones, or do you know few more ?
According to digikey.com, the cheapest DaVinci that can do H.264 is DM365 for ~$25 and the most expensive is 1GHz DM6467 for ~$150. That is, H.264-capable DaVincis have 600% price difference between them - so, it *is* important to state which DaVinci you consider 40% above your budget.
In higher qtys and with right distributor it should be possible to get prices 30-50% better than listed on digikey.com
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.