Choice of uP

[Rob Wehrli]

Philippe Caillaud wrote:
> 
> Hello world,
> 
> I've discovered MyLinux PLW only a few days ago, and I have to say I'm
> quite impressed about your project (both the goal and the
> organization).

Well, we seem to be lucky enough to be doing it in all the right places
:)

> 
> But I haven't been able to find a mailing list archive, so I have a few
> questions to ask...

There isn't one....I'm too busy to mess around with it...but it is on my
TODO list just as soon as my frame relay connection is back up and
running.

> 
> The first is technical: what were your criteria to choose a SuperH uP,

Quite a few design considerations went into selecting the Hitachi SuperH
32-bit RISC Engine.  Since I've worked quite a bit with Hitachi's
processors (mostly in CE-based products), and because I knew everyone at
Hitachi, I was certainly aiming at the SuperH from the outset.  However,
there are some very good reasons to use it for this design that
transcend just having good contacts at Hitachi.  The most significant is
really 5 distinct things--more or less in order of strength when
compared to MANY other processors I've evaluated over the past few
years:

High level of integration
Low price
Fast clock rates
Small code size
Low power


I'll be happy to comment extensively on this topic for anyone who is
interested in building an embedded design, especially for a battery
powered application...however, here are just a few mumblings that may
interest you.


The high level of integration on these parts is something that really
helps me when designing for a portable device.  On the SH3-7709A that
we've selected for the MyLinux Pocket Linux Workstation, we get serial,
IrDA, PCMCIA, SDRAM, Flash, A/D&D/A and more controllers most without
any external glue logic required.  This essentially means that we have a
portable device design in a single chip where others would require
perhaps another dozen components...the only real component missing in
this part is an LCD controller, and that, I hear, is coming soon in a
very-near-future part.  You also get 4 user DMA channels, and additional
serial port that can be a smart card interface.  The added advantage of
the JTAG-conformant interface is very useful for bringing up new
hardware...in fact, I was jamming code down its throat today using it
:)  You gotta love the Hitachi Debug Interface/JTAG support for getting
a new device up and running quickly!

The fact that the SH is a relatively low priced part makes it attractive
for a lot of REA$ON$...'nuf said about that!  While they're not exactly
cheap, my experience in pricing them along side of the others is that
they are quite a bit cheaper compared to their "relative equals" in the
market, while being only slightly higher priced than most of the
"dramatically lesser" parts.  Every CPU, like every car, is a series of
compromises.  The SuperH has the right combination of features for value
that I want and need when designing a portable.

With just the SH3-7709A in clock rates ranging from 133 to 200MHz, you
can have all of the speed you want and more.  We originally designed our
units around the 133MHz version, since slower clocks save power...but,
we're able to offer faster versions without much headache "just in case"
anyone wants to feel the speed-need.  When we designed the MyLinux PLW,
we knew that we wanted something blindingly fast...however, processor
speed isn't the only thing in the system that can be a bottleneck
source.  All-too-often something else is the deciding factor in slowing
down your system.  Take the MIPS parts like the NEC 4111 and 4181 that
use 16-bit I/O to memory devices.  How much data can a 16-bit bus carry
at 33MHz compared to a SuperH 32-bit bus at 66MHz?  You do the simple
math and fairly soon the choices are rather clearly made for you.

The smaller code size of the SuperH is a deceptively interesting
advantage.  Foremost is the physical size of compiled code.  It tends to
range from 23-ish to 35-ish percent smaller overall than other "embedded
& portable" processors.  However, compared to a few of the other
processors, code size reduction gains of over 55% are not uncommon. 
Think about it...half the code BULK?  This means that you can either
size your memory (Flash and/or RAM) down to meet your smaller code (may
save memory cost) or just stuff a lot more into the same memory
footprint than the competition.  One of the things that we're having
trouble getting right now is Intel's 256Mbit flash parts that we
originally designed into our MyLinux PLWs.  The 256Mbit parts gives us
64 MBytes of onboard Flash...since we're only reliably getting their
128Mbit parts, our flash storage capacity is half of what we originally
designed.  While we do not perceive it as a problem (We've got a
relatively full-blown "compiled for SuperH density" system with X, a
browser and about 100 other apps running in 14MBytes of flash!) but it
doesn't quite live up to our "marketing" claims of 64MBytes of Flash. 
This doesn't present a real problem for us ALSO because we intended half
of the flash to be reserved for USER non-volatile storage space....not
for our system needs.  Since we do have *128MBytes* of battery-back
SDRAM (with low-power, ultra-fast, PC-133 chips from Micron)...early
developer users (while we're waiting for a decent supply of Intel
256Mbit parts) should have no problem finding adequate storage space--if
not entirely non-volatile.  Just because we have a CompactFlash card
slot doesn't mean that users should HAVE to use it just so they can have
storage space for their own stuff.  We'll continue to look for ways to
conserve space while waiting for the higher density flash parts to
become readily available...so you can use your CF slot for a totally
cool 1GB IBM MicroDrive!

Note that the smaller code size is obtained through two principle
factors:  SuperH 16-bit instructions and decently optimized compilers by
Hitachi, Microsoft and, of course, GNU's gcc.  I know that this is not
the crowd to preach to regarding Microsoft's cross compilers, however,
let me state that they've spent quite a bundle (along with Hitachi!) on
making them work right for their respective product lines.  On the other
hand, Hitachi's very strong and long-term relationship with Cygnus (now
Redhat) has evolved probably the world's best SH cross compiler for all
of us to use for free.  Note that Hitachi even maintains office space
for a "Cygnus/Redhat" group at their US corporate offices in San
Jose...that's how close they like to be to the "tire meeting the
pavement" when it comes to supporting things like egcs/gcc and open
source/embedded Linux projects such as the MyLinux project.  To give you
an idea of how long they've been doing embedded Linux, I first reviewed
a full-blown X Window system running Mosaic, an MP3 and MPEG3 players,
full httpd and a lot more all running on a 60MHz SH3-7708 with 16MBytes
of RAM with NO SWAP partition!  While I'll be the first to admit that it
wasn't exactly a blinding speed demon, it *was* as fast as a decent 486
running a full blown X system...which, since this was a 1995/6 box
running a 1.2.13 kernel, was certainly very impressive to me!  Imagine
our PLW with 8x the memory and 2.8x the CPU *clock speed* and twice the
L1 cache...and twice the bus speed...and 8x the memory speed and you'll
start to get an idea of why we feel good about not going with the Intel
SA11xx parts...especially when you knock off a third or more of the code
footprint!  The last time I was up at San Jose, the Hitachi guys were
boiling over with practical implementations of Linux on SuperH.  I know
of at least a dozen projects using SuperH and Linux in my narrow field
of vision.  With the kind of support that Hitachi FAEs and Hitachi
corporate provide for SuperH customers, I couldn't justify using any
other micro choice.  I'm one of those kind of people who find something
that I like well and start using it, find out how to really maximize it
and drop the power consumption to nil and spend the rest of my time
laughing when someone tries to get me to design in a competing part. 
You can't beat the SuperH for speed/price/features and it doesn't matter
how many "power management levels" the other guys have (AMD tried to
sell me on an x86 Elan that has something like 9 different power
management settings, but draws a watt and a half during normal
operation!)...with the SuperH, once you figure out how to selectively
conserve power, you write a relatively simple algorithm to bring up/down
peripherals as desired.  The key then is to just fine tune it until it
gives you the most bang for the battery without being insensitive to the
user.

Which brings me to low power:  The part is inherently "lower powered"
than just about anything else you're likely to find out there...however,
it isn't explicitly a "super low power" design, which is kinda hard when
you're pushing 200+ MHz anyway!  Let me postfix this statement with the
obvious "I'm a complete moron when it comes to CPU design."  What I do
know is comparative analysis.  I've looked at just about every suitable
"portable device" processor you can imagine that would adequately
support a windowing system like CE or the X Window System.  Sure, you
can probably find a 4-bit micro that can be coerced into doing some kind
of proprietary "GUI," but I'm not a complete, full-on masochist..and we
*do* happen to be right smack dab in the middle of a "point-n-click"
world.  Look at the Motorola Dragonball EZ328...it is a really beautiful
processor if all you ever want to do is relatively limited Palm-OS kinda
functionality.  I looked very closely at it three years or so ago.  You
gotta love it for all that it is, power, speed, integration, etc...but
hey, it ain't no Porsche by a LONG WAY...unless your code is 2bpp and
drawing on a 160x140 LCD.  When we designed the MyLinux Pocket Linux
Workstation, we wanted a bare minimum of 8bpp Active Matrix color LCD
panel.  I chose to use the Seiko Epson controller to externalize that
requirement while getting the many added benefits that come in that
part, such as the SwivelView(tm) and Picture-in-Picture capability that
seemingly nobody on the planet has in a "PDA" device.  The fact that we
can go up to 16bpp for really awesome MPEGs and such, well, that's just
gravy...and, since the SED part is the industry's lowest power unit,
well, I felt damn good designing them in--and, since they had no less
than a dozen SuperH reference designs for me to look at...you just can't
get any easier than that...oh, and they also directly support the
industry's BEST 3.9" LCD panel, which is the transflective Sharp display
we're using.  That display uses 69mw of power during normal
operation...and it is *very sexy*!

What all this means is that when I sat down to specify the primary
components for the PLW I came up with a list of "can't miss" items that
were designed to be interoperable AND low power consumers.

Hitachi SuperH SH3-7709A 		~110mw
SED1376	graphics controller		~ 10mw
Sharp HR-TFT display			~ 69mw
Micron Memory				~120mw *1
Intel StrataFlash			~ 50mw *2
					-------
					 359mw

*1 All four chips combined--actively bursting data, drops to 50mw when
on active standby!
*2 Both chips combined--actively erasing blocks.  Typical page mode read
is 25mw!

I use "milliwatts" rather than milliamps to contrast the Elan's 1.5
watts!  We're at about 1/3rd of a watt during normal operation running
full bore.  Note also that these numbers are calculated from component
manufacturer's measurements rather than actually measured from our
device.  I'll be happy to provide a report on actual power consumption
when we've got a real measurement of it.  For now, I think we're looking
good.  For the record here, none of this includes using a PCMCIA device
in the unit...which, at 5v for most cards, is likely to be a real power
hog.  This is one of the most important reasons for going with  such low
power components as noted above.  The thinking is that we'd have more
battery life for heavy hitting peripherals such as a PC-Card 802.11b
device or CDMA/GSM cell phone/modem card.

Also, we wanted to build a unit with EVERYTHING thrown in at
once...while it does make the device somewhat more bulky than Palm, we
think that we've stuffed it into a relatively small package that does
fit in the hand but carries around with it everything you'd want from a
sub-notebook form-factor...without the added size of a sub-notebook. 
You see, we really wanted to build a Pocket Linux Workstation :)  All
the time I get questions that ask, so how are you different than a Palm
or an iPaq.  Depending on how much energy I have at the moment,
sometimes I get elaborate and other times I say "we just are a lot
different."  Sometimes I tell people that we're not a mega-billion
dollar company with ultra-million dollar budgets, but a team of unpaid
hackers who essentially said, hell yeah, we can build a better box
because we know what we want and need in it.  People in droves are
buying WinCE boxes and converting them to run Linux...we thought, hey,
what if they had another choice?  I said, I *want* another choice, not a
WinCE box that kinda sorta runs Linux but was designed for WinCE.  We
designed this unit from the ground-up to be a pure Linux box.  We're not
picky or tight about it...if you wanna run FreeBSD or even WinCE on it,
hey, change out the OS to anything you want...even Palm OS...if you're
so inclined!  (Talk about overkill!)  What we wanted was a box to run
Linux from, faster, better, longer and with more connectivity and
peripheral support than anyone else seemed to want to provide.  I don't
think either Shane or I would have ever considered doing this thing if
we could have found what we needed sitting on a shelf down at CompUSA.
(Sorry, I don't know the French equivalent to CompUSA--having only been
to France twice.)  If I want to run Gnome on a palmtop, where'mi (where
am I) gonna go?  So, we opened up the cabinet of all the cool parts we
could find, stuffed them into the smallest box that we could make them
fit into without having to sell our race cars...and blasted off for
parts unknown!  We've learned a lot about it along the way, but I
wouldn't change a single component designed in at this time.  I think
that we've picked out the best of the best for this unit and going
forward, I think everyone who gets to know and love the SuperH as much
as me will find that it is one of the smallest, fastest running RISC
"Engines" out there.


> and not for instance a StrongARM? (And nope, I don't have any share of
> ARM or Intel).

...The SA11xx series of parts is very attractive, but, without directly
contrasting the differences between it and the SuperH, which is an open
invitation to a flame war, I'll simply say that my SuperH choice is
still the better choice for the needs of the MyLinux PLW.  I do not
remember if the SA LCDC directly interfaces the Sharp HR-TFT, but I do
feel that its UMA design serves to spend more CPU time with graphics
handling than the SH using an external graphics controller.  I'm fairly
sure that it doesn't support SwivelView(tm) or Picture-in-Picture.  The
other thing being the size of code...the SA code density does not
compare with the SuperH.  Only the CISC x86 has smaller code.  The next
nearest competitor to SuperH has code that compiles to ~15-25% larger. 
My thinking is that I can stuff in more instructions for bigger
applications like Netscape in the same space as everyone else.  Given
that my flash resources are rather finite, I'd rather stuff more code
into them thus offering more applications/features than talk about how a
206MHz part is somehow faster than a 200MHz part.  If "More Megahertz"
was the answer to all of our worries, I could easily have decided on a
400MHz SH5 and used all the extra bandwidth to track missles for the
government or something!

I've looked very closely at DEC's part that Intel bought and is now
further improving...and note that the SA first saw PDA life in a Newton!
...and, if there was no SuperH, I'd pick it over all the others I've
seen.  But, given the performance, price, power and features of the
SuperH, you really can't go wrong with what amounts to a core design
with twice the road time as nearly all the others combined.  Oh, and
there is yet another reason that I chose specifically the 7709A and that
is because of two things that are distinctly different, but happen to be
very related.

The 7729 is pin compatible with the 7709A as a drop-in replacement.  The
"29" features an on-board DSP.  This means that from our basic MyLinux
boards, we can dump on a "29" and start playing around with the DSP to
see if there is anything fun we can do with it...like VoIP or some other
cool codec.  The second part of that not-so-related, but similar issue
is that having what amounts to TWO different part numbers from a
"stocking distributor's inventory" perspective means that we can, in a
pinch, use either part number in the base units should allocation ever
become an issue.  While I don't really know how many of each kind of
part there is in the world, I tend to think that having two parts on
shelves somewhere to drop in to fill one of my core needs is better than
the alternative of having just one part number in the world that will
work...multiply that by a factor of 2 or 3 when you consider the
different speed choices...and now we're talking about a likelihood of
never having to worry about allocation-related problems with getting
processors...not that it is a problem or even will be, but, hey, in this
world, you never know.  If my processor choice can help remove the
possibility for free, then I'm sitting in a better position because of
it.

> 
> The second is economic: what is the estimated cost for a Developer
> Edition PLW? (I'm rather excited about hacking one of these cute
> devices, but as a student...).

This is an interesting question.  We're not selling developer units. 
We'll loan them out to people who want to write code that we need for
them.  If that person is a substantive contributor of needed code, we'll
happily give him/her a free production unit.  Someone who has more time
to devote to producing the kind of code that we need to get these units
up and operational is the kind of person we need and want to send a
unit.  I've talked about the possibility of selling developer units in
the past, but I think that it would be a bad idea for now.  Maybe after
we've built a few hundred of these, but this early on, it really is a
device best suited for Linux Hackers not "reviewers" and "lookie-loos." 
I don't mean to be antagonistic or a complete dick head, but we need to
keep our focus, build to my plan and not get dispersed by supporting
users who are not adequately prepared for what amounts to prototype
hardware.

> 
> Last but not least: keep up the good work, guys!

Sure man.  We've invested far too much time and far too much money and
far too much *energy* into getting this far...we'll keep going!  Don't
forget that you can make a donation to the project, which would be a
great help...or, if your pockets are not as full as you'd like, feel
free to convince someone you know to make a donation instead!  We'll be
happy to send you one of our extremely cool "SuperH RISC Engine"
t-shirts provided by Hitachi especially in support of our Open Source
project!

> --
> PhC. (intern engineer) mailto:Philippe.Caillaud@irisa.fr
> Disclaimer: ideas expressed here are only mine, not IRISA's...

Well, then, tell ole Irisa to get her own damn ideas out here! :)  ...we
need and want the input from everyone who wants to help make this thing
a really great success in being a useful tool for the *entire* Linux
Community...from around the globe!  Thank you for your contribution to
the MyLinux Pocket Linux Workstation project.

Take Care.

Rob!