Prev: What is message collison?
Next: Numonyx/ST M45PE80
From: Tim Wescott on 25 Jun 2010 11:24
On 06/25/2010 01:32 AM, b_dutta wrote:
> Hi,
>
> 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
From: Vladimir Vassilevsky on 25 Jun 2010 11:47


b_dutta wrote:

> Hi,
>
> 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.

Forget about it.

> 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.

DaVinci is a marketing word. It means nothing. Which TI processor do you
mean? What is 40% more expensive compared to what?

> Blackfin
> seem the second best choice, but are lack horsepower on DSP end
> (apparently from some reports) for the kind of H.264 heavylifting.

Which of BlackFins?

> Given the dual objective of low-power (consumption), and low-cost, are
> FPGA's a viable alternative ?

No slightest clue, huh. Just casting buzzwords. Are you a stupident?

> What could be the potential pitfalls of using FPGA, as against a DSP.

What could be potential pitfalls of using a boat, as against a car?

> 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 also know many smart words: surge, gradual improvement, chaos theory,
innovation, digital DNA, hyperstring, nanoparticle.

VLV

 | 
Pages: 1
Prev: What is message collison?
Next: Numonyx/ST M45PE80