Shiny geek toy?

Ole Tange ole at tange.dk
Thu Dec 7 13:50:49 CET 2006


On 12/7/06, Christopher Heiny <heiny at starband.net> wrote:
> What exactly is it that we want OpenMoko to be?
>
> Do we really want a shiny geek toy?  Something that is super cool and
> technologically advanced, but only nerds will want to hack on?
>
> Or should we be working toward a solid OpenSource platform that will
> encourage other phone manufacturers to build on it and in turn give their
> work back to the community?

I think it is possible to do both.

> To take a recently discussed example: an FPGA is really super cool and
> flexible and you can do just about anything with one.  But the downside is
> that it is HARD to do that stuff.  Even if you, personally, find VHDL or
> Verilog to be easy to work with and understand, the average engineer
> working at someplace like Samsung or Nokia (or wherever) will not have the
> same skills you do.

Sorry, I do not quite understand you there. It sounds as if you think
the _only_ way to program a FPGA is through VHDL or Verilog. One of
the things you can put on a FPGA is a generic microprocessor (e.g. a
PowerPC or SPARC). You can then program the processor as you normally
do. In fact I would expect this approach: Use some of the FPGA for a
generic microprocessor (e.g. handling the UI and phonebook) and only
use the rest of the FPGA for compute intensive operations (e.g.
software radio, video decoding).

Please check out General Purpose, Low Power Supercomputing Using Reconfiguration
http://video.google.com/videoplay?docid=-4969729965240981475
It really opened my eyes to what might be possible.

> Additionally, it takes time (lots of time) even for skilled engineers to
> design, implement, and debug new features for FPGAs.

Agreed. But most of the user facing functionality would be in the
generic microprocessor.

> Time to market is critical for most phone manufacturers, especially in countries such as
> Korea where product lifetimes are often measured in months.

This argument is exactly why I think a FPGA is the right way to go: My
phone does not do WiFi, but I would find it tremendously useful if I
could install WiFi just by installing software. With FPGA you open the
possibility to upgrade the phone with functionality that would
otherwise require a new hardware.

> Five of the critical enablers to this are:
>
>     - rock solid reliablity.  Anything in the phone should "just work", and
> it must do it every time.

By stripping down the FPGA to just include GSM and a generic
microprocessor as default, I think that would be doable.

>     - easy to customize or extend.  Not just by VHDL aces and Perl wizards,
> but by the average C/C++/Java programmer two years out of university.  His
> boss is going to choose a platform that plays to his skills (or lack
> thereof).

I whole heartedly agree. With the generic microprocessor included on
the FPGA this can achieve both goals.

>     - support fast development.  That young coder in the previous bullet is
> going to be under a LOT of time pressure.  His boss is going to choose the
> platform that he feels will best help him meet schedule, and will see C++
> and Java as enablers, VHDL and Perl as barriers.

That depends on what you are trying to develop. If you are trying to
develop video decoding or software radio you might limited by
processing power. This limit might be moved with FPGA. But again: I do
not see any reason why you need to make a choice between VHDL and Java
when you can have both.

I do not see FPGA as realistic for neither v1 nor v2. But for v3 it
just might be a possibility.

/Ole




More information about the community mailing list