Propeller 1 / II Misc. questions

Dr. Mario

Hey, I'm new to the Parallax Community! And, yes, I have used Propeller 1 (P8X32A Ver. 1)
chip. I like this chip a ton better than PICs. (Except the 80186-based microcontroller do
come closer to simplicity of programming like Propeller chip.)

I'm a bit curious, when I read some of the older threads about the upcoming Propeller II chip.
I'm wondering about the complexity of the COGs (its internal CPU engines, of course),
when Chip and the others said it will be pipelined up to 4x (possibly four 32-bit ALUs)
would the COG be superscalar (like older, original Pentium processor) or just simply
pipelined like a 80486 CPU? And, I was thinking that if the COGs are made to be
out-of-order processor internally, while hub access control / address request remains
in-order, it would be nice to have some extra raw horsepower,·but I'm feeling that it may be
made on later version of Propeller II (made on 90nm SOI process) or new Propeller III
(made on either 90nm SOI or 45nm Hi-k Metal Gate [noparse][[/noparse]HkMG]·process). I'm looking forward
to·be using that new Propeller II chip, as what I read, should be a great·additional to
Propeller family.

Oh, and one more thing, would Propeller II, by any chance, have the FPU circuitries
etched along COG's CPU core? If so, that would eliminate having to buy an expensive DSP
or FPU chips, or to eat up precious board space.

Rayman

Welcome! Sounds like you already know a lot about Prop II...

Regarding your question at the end, I believe Prop II will have something called Cordic, which is supposed to magically do a lot of math functions without tables.
Also, there will be hardware multiply, single cycle 16x16 bit, as I recall.
But, I don't think any of that is in floating point, so no "real" FPU.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Apps:· http://www.rayslogic.com/propeller/Programming/Programming.htm

My Prop Info: ·http://www.rayslogic.com/propeller/propeller.htm
My Prop Products:· http://www.rayslogic.com/Propeller/Products/Products.htm

Mike Green

Nope, no hardware floating point. The software floating point is already pretty fast. Cordic uses integer or fixed point arithmetic to do things like transcendental functions very quickly. Remember that the Propeller is primarily a microcontroller, not a general purpose computer like an ARM or Pentium. There's not much need for blindingly fast floating point in a microcontroller, even a very sophisticated one like the Propeller.

Dr. Mario

I see, it makes sense... I have heard the future Propeller will have 64-bit ALUs so it basically makes sense.

Although I am curious about one thing: How the COGs will deal with their data.
Would it be in-order or out-of-order? (if it's the OOOE processor, then the only exception would be the HUB which will remain in-order).

Why did I ask about the FPU? I thought it would be nice to have hardware floating-point to deal with whatever is thrown at the Propeller II. (As a side note, Pi contrast in 64-bit floating-point chunks aren't so nice to even the powerful CPU, Phenom II X6.)

Oh well, I would just write PropSIMD floating-point software (providing that the COGs would handle internal OOO operation, this software may even be able to take advantage of four 64-bit ALUs, much faster than what's possible with Propeller I).

Heater.

There is no plan for a 64 bit Prop that I have ever heard on this forum.

Did I start that rumour? A couple of times I have half jokingly proposed a 64 bit Prop just so we could have much bigger PASM address space.

Kye

Where's the 23 bit prop when you need it.

Anyone have a link to that funny post.

Dr. Mario

Yeah. But, 64-bit Propeller II is still possible, although Propeller III will be, since it's proven (scientifically) that it will help with floating point with larger sinc decimal, like with MMX from Pentium processor. Who knows? It's normal for the companies to hide the inner working, like the COGs (the CPU core inside the Propeller II) - why not having 64-bit ALUs since the die will be much smaller (on 130-90nm lithography)?

This thread is really to answer some of my burning question: what if I want to use Propeller II inside the PDA (to be used as a general processor - that will surely help a lot with MPEG4 or H.264 with PropSIMD running) - about the IO, I will use psuedo-spread spectrum signaling (kinda like Hypertransport on Apples PowerMac G5's PowerPC G5 CPU) to be linked with FPGA being used as both 3D GPU and north/southbridge (to provide spaces on DDRII and to provide link to outside world, such as USB 2.0 / 3.0 ports that I can use to back up my files onto external hard drive). Just wanted some basic inner-working questions done so I can write the OS properly (as of what to except in software and hardwares - I kinda doubt the COG will have branch prediction, so i will have to treat it as a VLIW processor to keep the OS from crashing.)

Mike Green

Be careful about how you choose microprocessors for a project. The Prop II is not a general purpose microcomputer. It's a microcontroller. Although it will be able to do floating point faster than the Prop I, it will still be quite slow for that compared to any microcontroller with a built-in floating point processor. It will have a 32-bit ALU, not a 64-bit one (although it, like the Prop I, will be able to do multiple precision arithmetic with one instruction per 32-bits).

Remember also that the Prop II will be limited to 496 long words of instructions / data per cog just like the Prop I. That limits the size and complexity of the algorithms to be programmed without a loss of speed from using some kind of interpreter (and its overhead).

Dr. Mario

Well, there are plentiful way to enhance it (have it stopped anyone in using Propeller I in HVAC or any robots, has it? Same thing, really. Before anyone objects, Robotics is a very complex job for a microcontroller, let alone a cannibalized Pentium processor chip). I am planning to link the Propeller II via the FPGA for the southbridge functions (as well as supplying the Propeller II the DDRII spaces - GPU and CPU will use the same RAM).

I am fully aware that it have limitation, however, the rule can be smashed, as long as you have the understanding of what the Propeller II will work with the IO and the boot firmware (as noted, I am going to treat it as a VLIW processor anyways. Oh yeah, I will include PropSIMD to help with complex math too - software floating point on steroid. There are many thing I will have to make of, like virtual IRQ nested vectors - there are plentiful of horsepower on the chip already).

Plus, it's not impossible to run uCLinux on it. (Luminary Micro Cortex M3 LM3S102 has only 2KB RAM and yet, uCLinux worked fine on it. AND I would never be too surprised if I see a bootscreen from uCLinux on Propeller I / II chip connected via VGA monitor.)

pharseid

I hate to mention a non-Parallax product on this board, but doesn't TI make chips made to order for your application? I think they pack an ARM, a VLIW DSP, and a GPU on one chip. Props have certainly been stretched beyond typical microcontroller applications, but this has got to be a bridge too far.

But while on the subject of VLIW processors, is it too soon to be thinking about a VLIW Prop ]I[? Superscalar execution is certainly not in the philosophy of the Prop, being expensive in both design costs and silicon real estate, but VLIW designs are frugal, particularly if you have a model like TI's, where the instruction size only grows if you have another instruction that can be run concurrently with the first one. It would probably be possible to have an assembly language which is backward compatible with Prop ][ PASM. This would give another level of parallelism on the Prop, a very fine-grained level to complement multi-cog parallelism.

This is yet another thought spawned by the thread about the texture mapping op-code on the Prop ][. If you're doing 3D on the Prop, you have to project from camera coordinates to screen coordinates and that takes a divide, a fairly expensive operation. Why not amortize that cost by doing the divide simultaneously with a (transform matrix) x (vertex vector) multiplication? Food for thought anyway.

-phar

Dr. Mario

Well, there are room to cherry-picking, anyways. The point is, I am not going to run out and build the PDA based on Propeller II MCU blindly. I just have to develop some softwares first to see how well the Propeller II will handle the job as a CPU (inter-layer IO communication to the FPGA to provide video interface and RAM space as well as the SRAM on FPGA as a Level-2 cache RAM). I am sure it won't be easy, since there are complicated, mind-twisting jobs to do such as developing the PropSIMD (I decided to go with VLIW programming concepts since COG will be pipelined and it makes packing the floating-point data easier - I would do away with regular one too, but I would rather wait until they all come together and then test it on video files / 3D model, to see which is best - ATMEL Dataflash is, sure, cheap but it's best to keep its content small, anyway) - there are still lot of decision, anyways.

As noted, I will have to test it on prototype board first. (Keepin' the problems on basic level.)

Mike Green

You're a bit too far out on the development curve at this point. There is no specification for the Prop II. Although many of the features mentioned so far are expected to be on the chip, there's no commitment from Parallax to include them (nor will there be) because, during the process of chip development, some may have to be dropped or added due to unforseen issues that arise.

There's no way to develop software for the Prop II as yet. We don't even know the format of some of the new instructions. The boot firmware isn't written. It's been suggested that the boot firmware will be able to boot from an SD card, but this isn't firm yet.

Dr. Mario

Yeah, I guess I will have to wait and grab the hard-earned information when it's available...

Oh well. There are much more useful things to do with Propeller I, though, like for DPSS laser driver board and many other, but not computing... (HUB RAM and the internal constructions of the COG really get in the way...)

BTW, I had fun driving the RGB LED, toggling it so fast I get pinkish white (pulsing it as far as I can!) - and I noticed if I programmed it to do ultra short flash, it would flash very dim, with the LED "on" being 1:1000, "off" being super-duper long - shall I say, "weird"? I know, because it's of the LED's "I^R" current compensation effects - Gallium Nitride (Green to Vacuum UV) being a bit more sensitive than Gallium Arsenide (Red and IR)... I did drive red LED straight to 3.3 Volts with transistor, it did flash brightly without a harm (no blackened spot on LED die) - it's interesting.

And, yes, anyone can build a programmable inverter with it. I did this, with an ignitor transformer being driven by Propeller chip tied to Base of Darlington transistor (via 1 kiloohms resistor to avoid frying it) - it produced 1,000 volts throughout to LED via 1 megaohms resistor across secondary coil's charge pump circuitry (and it's disabled because the current's flowing to the LED, and have nothing left to charge the capacitors in it).