Slashdot Mirror
New PPC/Linux PDA Reference Design From IBM
kinema writes "It looks like IBM has released a new Linux/PowerPC based PDA reference design called e-LAP ("embedded Linux application platform"). It features a PowerPC 405LP, 30MB SDRAM, 32MB NOR Flash, 64MB Disk-On-Chip Flash, 240 x 320 color LCD, Stereo speakers, Microphone, USB (both host and client ports), a 3000 gate Xilinx FPGA, SDIO slot and last but not least a TCPA security chip. I for one would love to see some good PowerPC based PDAs on the market."
That's the most obvious one that comes to mind. That translates to longer battery life. If I had to pay a bit more money (and I'm not sure that your "more expensive" claim is true) in order to have more "on the go" time, it might be worth it.
Constitutionally Correct
Why wouldn't they run a Linux version on it with a regular PC chip and be able to sell the device cheaper?
You mean an x86? They eat too much power to use portably.
There are a couple of low-power x86 compatibles - the Transmeta Crusoe and VIA Epic - but don't know if they're low power enough. Plus they're someone else's technology whereas PowerPC is IBM's own.
Wow, great to see IBM getting into the PDA market. For those who don't remember, they pretty much set the gold standard in the laptop industry, and we still live with the benefits today. But while this sounds like a good toy for geeks, I have to wonder about some of the choices made in the design of this device.
PDAs typically use processors designed specifically for embedded environments. They're built from the ground up for low power consumption in preference to blazing speed. The PowerPC is exactly the opposite, as anyone who has sat down at a recent G4 can tell you -- these things scream.
Furthermore, Linux is specifically architectured for the server market, which is why it's seen so much success in the enterprise. Trying to tweak it to run on a PDA is an excercise in feudalism. The choice could also be bad news for Linux, as people will start to think of the OS as suitable for only small devices.
It's a good idea, but I'd like to see them take a more sensible approach.
Karma: Good (despite my invention of the Karma: sig)
Considering that the 405LP that is being used in the reference design could be considered an embedded processor, it's also less complex than say the lowest power consumption x86 or x86-compatible processor. It's also hard to find a x86 processor that has a typical power consumption of under a watt and has all of the features of the 405LP, plus fit into the space requirements of handhelds and other small devices.
Price isn't as much of a concern since you would normally trade cost for portability, and vice versa.
The other benefit of the PPC architecture is the fact that you don't have the kludge of an ISA that is the x86 ISA... meaning that developing apps for a PPC (or an ARM) architecture may not be as bad... and I think code written for the PPC architecture can run on any other PPC processor, provided that you don't include processor specific extensions.
From http://www.ibm.com/ibm/environment/annual2002/prod uct.shtml:
The first product to emerge from the Low-Power Computing Research Center is the low-power 405LP chip, which enables system software to control and reduce active power by dynamically scaling processor performance to the level required to support the application. Wherever possible, the 405LP offloads processor demands by use of hardware accelerators and aggressively shuts off portions of the device when not in use. Standby power is also reduced. The 405LP includes a mode in which power is reduced virtually to zero while still providing "instant-on" response to an external stimulus, such as a pen stylus on a touch screen.
Read the article. Notice that it mentions that the PowerPC 405LP chip not only contains a PPC 405 core, but a substantial number of other devices. DDR Controller, DMA Controller, LCD Controller.. and a myriad of others important ones. This significantly reduces the number of chips a manufacturer needs to put in a device, with the result of dramatically reduced cost.
Also, anecdotal "PowerPC chips are more expensive" _may_ hold for the PC market, but remember that this is a radically different chip geared for a radically different market (the article mentions a top speed of ~380 MHz!). In reality, IBM has priced this particular chip very reasonably -- wholesale price $100. Those numbers ought to be available soon.
Development of this chip was on Linux right from the beginning, and people were using them around the lab as MP3 players throughout! A great platform for hacking around with.
Could be "scratch space", or for future DRM as you point out. I like to think it'll be for more though.
Someday I'd like to see FPGAs in all sorts of things. The classic (albeit somewhat silly) example I like to use is you're driving down the road and you go through a puddle of water which disables your car's computer. So you download the controller core from GM's (or whoever's) site, load it into the FPGA on your PDA, and use it to drive to a service shop.
Kind of a contrived example, but my ultimate point is that with pervasive FPGAs, and perhaps some kind of pervasive "universal connector" wired to the FPGA, you can reconfigure a device to do things it wasn't specifically designed for.
Blue sky thinking aside, I can think of other uses for it, such as the "cell phone" model where you alternatively use it for digital and analog control stuff by reprogramming it. That way you only need one part in the device instead of two, and it makes interconnection circuitry simpler.
You might also program it to be a DSP-microprocessor today (for maybe the media player or something), and then reprogram it to be the cell chip for a Treo-like device tomorrow.
That kind of thing...
This is a typical artifact of RISC chips. Instructions are fixed size, and usually the same size as the general purpose registers. When you load from an immediate value (a value contained in the instruction), the instruction has insufficient room for a value as wide as the instruction itself after specifying the instruction, the destination operand, etc.