Slashdot Mirror

there were a significant number of design changes that motorola made to make the chip capable of 733MHz operation - check out the link here for a quick summation.

The computer engineering program at the University of Waterloo (in Canada) doesn't use a specific OS to learn from (although the textbook uses the traditional ones for examples - NT, *nix, particularly Solaris).

Instead, the project is to design (from scratch, including a design document) and implement a real-time operating system on an embedded system (currently Motorola Coldfires).

One should note that QNX came out of the UW CS real-time course, not the OS course.

i think you'll find a palm v runs at 16MHz and a vx runs at 20MHz ; see here

Accually, you people need to get your facts straight. IBM PPC Roadmap, the IBM PPC Page and Motorola PPC tech doc's. As far as I can tell all the currently available PPC's are using "On Die Tags" Off die SRAM! If you want to talk about future tech thats another story.. The truth of the matter is ALL competitive RISC or otherwise (have you looked at the power consumption of the Alpha? How about the POWER4?) processors are power hogs. The PPC systems that Apple ships are _NOT_ competitive with what is considered a state of the art workstation. Motorola make wonderfull embedded processors.

$269??? Man, they should have just designed a plugin for an external HD! 10gig external HD with USB, $164!!! Sheesh, do they THINK we are fools?

I do.

The Handspring Visor (and other Palm-compatible devices) only has a 20mhz Motorola Dragonba ll CPU. The Dragonball is a MC68000 core with serial and LCD support, among a couple other neat additions. It has nothing like the amount of CPU required to play an mp3.

Not only that, but the USB on the visor is a funky connector which basically requires a cradle or something that snaps onto the body of the unit, making it even thicker. I shouldn't have to tell you that the Visor is already thicker than a Palm V or similar.

I've just purchased two ucSimm modules with a DragonBall and running CLinux. The whole thing, with 8 Megs of RAM, 2 Megs of Flash ROM and an Ehternet chip fits in a single old-style 30 pin RAM socket!

For those who care, a DragonBall is officially a Motorola 68EZ328 processor running at 16 MHz. CLinux is a version of our favorite OS designed for chips with no MMU (Memory Management Unit), and fits nicely into the 2 Megs of flash ROM.

"They are running a chipset that is not Intel or even AMD. It is RISC, and it is a 64 Bit chip"

For starters, a chipset is/are the ASIC(s) that interface the MPU to the rest of the system, not the MPU itself so it cannot be RISC. Secondly the G4 is not a 64 bit processor.

I realise you may be speaking about the AMD or Intel chips. Please pardon my structure. Otherwise:

From the Motorola spec sheet:

MPC7400 microprocessors support the MPX bus architecture with a 64-bit data bus and a 32-bit address bus.

So the data bus is 64 bit, does this not make the chip 64 bit? If not, please correct me.

--

--

Here are some example power figures I found. They all assume that power is supplied at 3.3V; the actual voltage will be lower than this.

(Whatever happened to <pre>?)

I hope the StrongARM has good power management...

I won't argue with you, using an x86 for a console, is a MAJOR flaw. However what do you mean that consoles usually have specially developed CPUs? Consoles usually use an existing chip (or some slightly modified variation) because it's cheaper than developing a new one, testing it, and then having it manufactured. Nintendo and Sega don't have the resources to do that and maintain their central business. The Dreamcast's SuperH4 chip is just a standard component you can get from hitachi as far as I know. Other console's CPUs (OTTOMH) are: Master System/Game Gear -- Z80, NES -- 6502, Genesis -- 68000, SNES -- 65c816, Saturn -- SH2 (two of them), and Playstation and N64 both have MIPS processors (R3000 and R4300 respectively?)...

As far as I know, Motorola has been using a 0.15 micron process for the PowerPC 7400 "G4". I'm guessing IBM will soon, as they're about to ramp up production of their own 7400s.
http://ebu s.mot-sps.com/ProdCat/psp/0,1250,MPC7400~M95064468 6128,00.html

>IIRC, one of those new G3's (and remember, a G3
>consumes *way* less power than any (native) x86
>chip) can barely manage an hour and a half.

Actually, Apple claims that the current PowerBook G3 can run up 5 hours on one battery. See Apple's spec page. Independent reviews of the PB G3 give a "real life" work time of about 3 hours while playing a DVD. (Emphasis mine. 3 hours comes from playing Austin Powers twice, which has a run time of 90 minutes.) A table of the G3 processor's power modes shows that its typical power consumption is not terribly high compared to the TransMeta chips, given the older technology of the G3 and the large number of additional functional units in the G4:

PPC750 (G3) @ 400 MHz
--Typical 5.8 W
--Maximum 8.0 W
PPC7400 (G4) @ ?
--Typical 5 W
--Maximum 8 W

(Quoted from Motorola's PPC 750 info page and PPC 7400 info page. There is no figure given for the MHz of the G4 on the page.)

Another way to look at this is what percentage of the laptop's power consumption is taken up by the CPU. On a PowerBook G3, we know that one battery holds 50 Watt-hours and the average battery life is 3 hours, so the average power consumption rate is: 50 / 3 = 16.67 Watts. Thus, 5.8 Watts of the power consumed is used by the CPU, and the remaining 10.87 Watts are consumed by the rest of the machine; this is a lot higher than the 4 Watts of other system power on TransMeta's web page and still significantly higher than the assumption of 8 Watts of other system power for the multimedia laptop. Using the TM3120 figure of 2.9 Watts for consumption while playing a DVD, the total power consumption of a hypothetical TransMeta-based laptop is 10.87 + 2.9 = 13.77 Watts, leading to a battery life of 50 / 13.77 = 3.6 hours, only 36 minutes longer than the current PowerBook G3. That's not a revolutionary difference, IMHO.

FWIW, I think that the TransMeta approach has very strong similarities to the AMD Athlon (in its on-the-fly translation of x86 instructions to the RISC-type internal instructions) and also to the Apple 68K emulator for its PowerPC-based machines and Java JITs (caching of the translated instructions after initial execution to speed execution the second time through). The weakness that I see of the TM approach is that they really are losing a fair chunk of the possible performance all of the time by their code-morphing approach. I personally don't see a lot of difference these days between a post-RISC superscalar architecture with strong branch prediction and speculative execution and a VLIW architecture with a translation unit on the front end that takes x86 instructions and turns them into VLIW instructions whose sub-pieces may be executing out of order. Both keep the functional units going a high percentage of the time.

Another weak spot may be that the x86 registers are only shadowed once. If an x86 exception occurs, there is a rollback followed by and in-order execution to figure out where to break for the exception. In post-RISC architectures (both PPC and Athlon), there is a plethora of registers, enough to easily support multiple processor states, not just two. Rollbacks due to exceptions and speculative execution are much less costly in this architecture.

Anyway, enough babbling from me. As a note, I am an Apple WebObjects engineer, but these views are my own. I just couldn't let some Furby ;-) get away with giving a PowerBook G3 only 1.5 hours of battery life.

>IIRC, one of those new G3's (and remember, a G3
>consumes *way* less power than any (native) x86
>chip) can barely manage an hour and a half.

Actually, Apple claims that the current PowerBook G3 can run up 5 hours on one battery. See Apple's spec page. Independent reviews of the PB G3 give a "real life" work time of about 3 hours while playing a DVD. (Emphasis mine. 3 hours comes from playing Austin Powers twice, which has a run time of 90 minutes.) A table of the G3 processor's power modes shows that its typical power consumption is not terribly high compared to the TransMeta chips, given the older technology of the G3 and the large number of additional functional units in the G4:

PPC750 (G3) @ 400 MHz
--Typical 5.8 W
--Maximum 8.0 W
PPC7400 (G4) @ ?
--Typical 5 W
--Maximum 8 W

(Quoted from Motorola's PPC 750 info page and PPC 7400 info page. There is no figure given for the MHz of the G4 on the page.)

Another way to look at this is what percentage of the laptop's power consumption is taken up by the CPU. On a PowerBook G3, we know that one battery holds 50 Watt-hours and the average battery life is 3 hours, so the average power consumption rate is: 50 / 3 = 16.67 Watts. Thus, 5.8 Watts of the power consumed is used by the CPU, and the remaining 10.87 Watts are consumed by the rest of the machine; this is a lot higher than the 4 Watts of other system power on TransMeta's web page and still significantly higher than the assumption of 8 Watts of other system power for the multimedia laptop. Using the TM3120 figure of 2.9 Watts for consumption while playing a DVD, the total power consumption of a hypothetical TransMeta-based laptop is 10.87 + 2.9 = 13.77 Watts, leading to a battery life of 50 / 13.77 = 3.6 hours, only 36 minutes longer than the current PowerBook G3. That's not a revolutionary difference, IMHO.

FWIW, I think that the TransMeta approach has very strong similarities to the AMD Athlon (in its on-the-fly translation of x86 instructions to the RISC-type internal instructions) and also to the Apple 68K emulator for its PowerPC-based machines and Java JITs (caching of the translated instructions after initial execution to speed execution the second time through). The weakness that I see of the TM approach is that they really are losing a fair chunk of the possible performance all of the time by their code-morphing approach. I personally don't see a lot of difference these days between a post-RISC superscalar architecture with strong branch prediction and speculative execution and a VLIW architecture with a translation unit on the front end that takes x86 instructions and turns them into VLIW instructions whose sub-pieces may be executing out of order. Both keep the functional units going a high percentage of the time.

Another weak spot may be that the x86 registers are only shadowed once. If an x86 exception occurs, there is a rollback followed by and in-order execution to figure out where to break for the exception. In post-RISC architectures (both PPC and Athlon), there is a plethora of registers, enough to easily support multiple processor states, not just two. Rollbacks due to exceptions and speculative execution are much less costly in this architecture.

Anyway, enough babbling from me. As a note, I am an Apple WebObjects engineer, but these views are my own. I just couldn't let some Furby ;-) get away with giving a PowerBook G3 only 1.5 hours of battery life.

Well, let's see. I when I played SimCity originally, it was on a 16MHz MC68030 . The Palms use a 16MHz MC68328. Should be just like old times!

Well, let's see. I when I played SimCity originally, it was on a 16MHz MC68030 . The Palms use a 16MHz MC68328. Should be just like old times!

All "Contemporary" Logic Design is OUT OF DATE!!!

Traditional, clocked Boolean logic is flawed as numerous design failures have begun to occur - e.g. the original designs of the AMD K5/6, IBM PPC620, Intel Coppermine, etc... which set back product releases anywhere from 6-36 months

Why? Synchronizing millions of gates at near-GHz speeds is next to impossible. As such, even the Semiconductor Industry Association (SIA) knows that the industry must return to asynchronous and "clockless" logic as laid out in its 2001, 2003 and 2005 milestone plans.

We at Theseus Logic have the answer. This post if VERY COINCIDENTAL since we just annouced a STRATEGIC ALLIANCE with Motorola (Press Release Here) to bring our patented Null Convention Logic (NCL) technology to Motorola's 8 and 32-bit product designs.

Like other async technologies, NCL benefits fro async's inherit no/low-power, low-EMI emissions and high EMF tolerance. But UNLIKE TRADITIONAL ASYNC DESIGNS, NCL not only can co-exist with clock boolean logic in the same circuit, but you can use off-the-self sync design tools to design in NCL (via the use of a post-processor for many industry tools like Synopsys).

And lastly, as clocked boolean designs have to be redesigned for each feature size reduction (e.g. 0.25um -> 0.18um, etc...) and voltage variations (e.g. 3.3V vs. 2.5V, etc...), NCL circuits require LITTLE OR NO REDESIGN when new technology becomes available! As such, we call NCL designs "Timeless Solutions(TM)" because they deliver on both the delay-insensitive nature of async *AND* NCL designs can be re-used over and over again for a log period of time!

Again, visit Our Web Site to learn more about NCL technology and design. Note, content is slightly out of date, but the technology is nothing new. The technology was invented in the '70s, researched in the '80s and has finally become viable in the '90s.

The University of Central Florida has graduate programs in NCL design and technology which usually involve Theseus sponsorship and/or employment at Theseus (both during and post-educational).

-- Bryan "TheBS" Smith

I have not been able to find any info on the Dragonball on Motorola SemiConductor Products website. I would like to see the technical docs on the Dragonball VZ. Has anyone else had any luck?

What exactly would be the advantage of having a plug-in LAN on a die? Why would you want to network with yourself?

It's already being done. The example I know about is Motorola's QUICC core, which they combine on the same die as a CPU. The 68360 is essentially a 68040 (except they use the CPU32 architecture, which has a slightly stripped-down instruction set from the full 68040) plus the QUICC core. There are also the PowerPC 860 variants, which are a PowerPC 60x (not sure of the exact model) plus QUICC on the same die. These are fairly popular chips to design embedded communications systems around.

I do embedded software, not board designs, so I don't know all the tradeoffs of having this type of CPU core. I assume that keeping the chip count down is one of the major advantages. The QUICC is an incredibly flexible unit -- it can handle framing for most any protocol. Ethernet, ATM, T1, SONET, LAPB/D, etc. So, it eliminates the need for specialty framing logic, perhaps even an ASIC, as long as you get the firmware set up right.

There are some pretty interesting notes about the QUICC (more than I'm going to read!) on the Motorola Semiconductor web site. Just enter "QUICC" in the "Search" box.

(Disclaimer: I don't work for Motorola, I've just had to program on a number of these chips and have been impressed by what gets stuck on the same die with the CPU.)

This is not true... the 604e has 2 fpu units and 2 integer units...

That's not what Motorola's PowerPC 604e product summary says. It lists 3 integer units (2 single-cycle and 1 multi-cycle) and 1 floating point unit. If there's documentation to the contrary, I'd like to see it.

--Troy