Question: Propeller architecture in ? family?
mklrobo
Posts: 420
I would like to ask a question, where permissible.The propeller architecture, insofaras the family it is in, in not on the data sheet. I could not
find any documentation on it. Does anyone know what family the MCU resembles?
The structure of the 8 processor, or 8 cogs, is unquie. what about the MCUs, themselves?
Comments
Does that help?
-Phil
If you look in the datasheet you can see a diagram of the chip with the hub servicing 8 cores in a rotary fashion. It looks reminiscent of a Propeller from which it derives it's name. Since it is the first of it's kind it is unique but when P2 is unleashed and not forgeting all the nascent P1 FPGA variants (then possibly silicon) then they will all be part of the Propeller family. The actual 32-bit core as mentioned alreadty is mostly Von Neumann and the instruction set reminds me of a blend of many different processors but not an interrupt in sight, so really they are unique too.
Now why all these academic questions though? Don't you have something to design or build?
There is no architectural overview of either the SOC or the processor.
For what it's worth, the processor is quite simple. There is a single instruction encoding scheme described on page 251 of the manual. The concepts of memory and registers are very poorly articulated and that is compounded by the lack of architectural description of the SOC.
The best way to conceptualize the Propeller chip is as an SOC with eight processor cores and a small fistful of shared resources.
Each processor core has a 9-bit address space organized as 496 x 32-bit of local memory that cannot be addressed by any of the other processors and 16 x 32 bits of the local address space are decoded as internal registers - some are shared, some are read-only and some are local.
In addition to the local memory, there's a Z and C condition code.
That's all the state in the processor architecture. It's important to note what's absent - no interrupts, no stack, no registers.
Instructions are fixed-length 32-bit encodings that name two operands. There is a 6-bit opcode field with 3 operation modifiers that control whether the carry flag, zero flag and destination register get modified as a result of the instructions execution. Operands are named with a 9-bit address and nearly all instructions perform "Dest := Src op Dest". There is an Immediate mode bit that controls whether the Src is interpreted as a literal value or a memory address. There are four predicate bits that control whether the instruction executes or is a nop.
In the vast majority of encoded instructions, the 4 predicate and 3 modifier bits are "unused", resulting in very poor opcode space utilization, which is a shame as it would be so easy to combine and encode most of the useful combinations and free up two bits that could be used to extend from 9-bit addressing to 10-bit addressing.
Another significant draw back is that there is no indirect addressing mechanism at all - self modifying code is used instead.
If you wanted to compare the processor architecture to anything, I believe the best comparisons are to the Data General Nova and the original ARM. Like the Nova, it's possible to write remarkably compact codes. Like the ARM, a lot of the instruction encoding space is squandered on predication that is rarely used. The upside is highly predictable execution at throughputs that are quite good because there's no OS, no interrupts, no context switching, no wait states - just direct execution of perilously small (512 instruction, max!) programs.
The SOC is comprised of eight cores plus a 32KB shared memory, 32KB shared ROM, some clock control, power management, complex inter-coupled counters that can generate wave forms and 32 GPIO pins. The ROM contains some bootstrap, a byte-code interpreter (see below) and some tables for accelerating trig, logarithm, anti-logarithm and a character generator for a bitmapped font.
Interestingly, the vast majority of software written for the SOC doesn't rely on the underlying processor architecture in any way. Instead, it's written in a proprietary language, compiled into byte code for a stack-based p-code interpreter. That interpreter resides in ROM and interprets byte code streams from the 32KB of shared memory. The hardware bootstrap loads the 32KB shared memory from an external serial eprom and copies the interpreter from ROM into Processor 0 local memory and transfers control to that interpreter. The program that's running can spawn additional processes directly onto any of the other 7 processors or even onto its own processor. Those processes can be either interpreted or assembly language that is directly executed.
Hope that helps ...
Considering how poor you think the docs are, you seem to have gleaned quite a bit of good information from them, as do most other users of the Propeller! Of course, I and most other long-time Prop users woudl take issue with your negative judgement calls, since we've managed actually to spend time programming the Prop and find it very friendly and powerful. Hopefully, once you've gotten some hands-on experience with it, you will too.
-Phil
You wouldn't happen to be a food or art critic would you? You must take all things into context and what the 4004 was for corporate Intel isn't this really a much larger achievement for one guy and a small family company? Having a lot of experience with various processor architectures over the years I find it incredible that Chip managed to design a unique chip and get it into silicon first time without the usual errata sheets as well.
With your critical analysis and comparisons you have come across as a big academic but where is your "Propeller"? Trouble with using old terms are the concepts that they bring to mind which would in itself be misleading. At least Parallax document their products, and support them and make them easily available, and now even make it an OpenCore, WOW!
It's always appropriate to show appreciation for a great achievement, if you can appreciate it, but then food and art critics are rarely great chefs and artists themselves.
Hmmm... I don't think this is correct. At least it isn't my experience. The only code I use from OBEX is nearly all PASM. And 80% of what I write is also PASM. Where do you get the "...vast majority..." idea?
BTW, I think you ought to remove the invective, then flesh out your post by about 4x and publish it as a succinct Propeller intro. I wish I'd read your post years ago when it might have saved me some time.
And while I'll repeat what I said "The upside is highly predictable execution at throughputs that are quite good". The device, for it's numerous faults, does have a niche and I'd suggest it's success, such as it is, comes despite rather than as a result of the documentation.
I'll also stand by what I said regarding the apparent distain for the terminology developed over the past 50+ years and the disservice done by that choice, especially for a product that strives to be an educational building block. It's indefensible.
And I'll add that I've exchanged countless e-mails with Parallax in attempts to get clarification on details of operation where the documentation is just completely wrong or so inadequate that it's impossible to understand. Why there's not a rolling effort to revise and publish the documentation is really beyond me.
And Phil - in the last five years, I've shipped several different revenue products based on Propeller and am about to release two more.
Sorry kstld, just serving up what you ordered although I do appreciate your insight, as I said it needed to be taken into context and if OnSemi or TI were anything like Parallax then Parallax wouldn't stand a chance! The fact that they can make such an impact as they do is noteworthy. But as much as the big companies produce "documentation", although the information is there, I don't think it's all that clear or correct anyway and there is absolutely no way of talking to anybody who really knows, of making any difference, Oh, that part number has been superseded......
A nice description of the Propeller.
However I think you are a bit hard on the documentation. For sure documentation can always be improved. However pretty much everything is in the Propeller Manual. From time to to time people have debated errors and omissions but they always seem to be about odd edge cases that are not going bother most people most of the time.
Certainly the Propeller documentation and architecture is a lot easier to understand and as well documented as say the XMOS devices. Judging by the very long discussions in their forums as to how that thing actually worked.
As for use and abuse of terminology. Things like talk of "COG" and "HUB" can have you scratching your head for may be two or three seconds but is soon assimilated. Not a big deal. Certainly not as bad as XMOS, again, referring to hardware scheduled threads as "cores" and actual cores as "tiles", that is not just confusing it's dishonest.
Documentation can also be perfectly complete and accurate but still useless. I have you ever tried to program an Intel 860? It was so complicated that even Intel did not know how to get the maximum speed out of that thing. Users did figure it out in a few specific cases.
Parallax has now released the Verilog design files of the Propeller as open source. If there are any questions about the finer points of it's operation the answers are in there. If you happen to find some corner cases where the real chip does not behave like the published source then that is a bug I'm sure we'd all like you raise an issue on.
Finally, I do hope you find time to post the results of those exchanges somewhere. If you have had problems with the documentation I'm sure many others have as well. If you have received clarification on such issues then for sure others could also benefit from your discoveries. We look forward to that.
@Everyone,
Is it really helpful to classify the Prop as Von Neumann?
When one thinks of Von Neumann one thinks of processor (ALU, registers, control) separate from memory (RAM, ROM, where your code and data is.) There are many block diagrams of the Von Neumann architecture on the net that look like that and much talk of the "Von Neumann Bottleneck", that slow pipe between processor and memory.
A COG on the other hand has it's processor, it's registers, it's data and program store all mixed up together. Registers are registers in some normal sense. Registers are program store. Registers are the working memory.
This is quite unlike any Von Neumann block diagram.
@Everyone,
I just realized another way to think about the Prop not having interrupts....
The idea is totally wrong, the Propeller has nothing but interrupt handlers, 8 of them!
What it does not have is a main line....
Waitpeq and waitpne could maybe kinda sorta be thought of as interrupt devices.
It's not like they are POLLING a pin anyway...
Sorry another long essay coming.... Very true.
But notice I did not say "...the Propeller has nothing but interrupts" I said "...the Propeller has nothing but interrupt handlers". That is very different.
What is an interrupt handler?
It's a chunk of code in a program that is not called by the program anywhere but rather sits around waiting to be run when some external event happens. Hopefully very soon after the event happens. It does not care how it came to be running or whatever else was going on that got interrupted to allow it to run.
Now. If I have a Propeller with 8 COGS with code waiting on some events, WAITxx, that looks exactly like 8 interrupt handlers to me. With the bonus of course that they all get minimal latency to their events, none of them steals time from any of the others (no nested prioritized nonsense) or any back ground task.
Having worked on systems where everything was scheduled off of interrupt handlers, where even what you might call the "main line" was hooked to a 100ms or 1s timer tick and the actual background code was nothing much more than an empty idle loop, these things look remarkably similar. In fact, the same. Yes, they do serve a purpose. They simulate a multi-processor machine on a single processor. They do it very poorly, what with making the code more complex, and having bad timing interactions and generally slowing things down.
If you can add a core for every possible event that you might otherwise assign to an interrupt you would never need interrupts! Here you have hit on a very interesting point. One glaring omission from the Propeller is the absence of a WAIT on HUB memory change. Or if not memory change WAIT on some hardware signal that can be sent from some other process.
For example consider a UART transmitter. Before it can do anything it has to check some HUB memory to see if the application has put something there to send. In a mail box or FIFO say. Currently we have to poll that HUB memory as you say. Not good. We can't WAIT, we can't go to a low power state.
The only way for a process can send such a signal to another COG to wake it up from a WAIT is by using an I/O pin to connect them together. This is why many have asked if the 32 Port B pins exist internally they would be great for such signalling with out using valuable external pins. True. The slow down is not so critical though. After all your peripheral COGs should be doing the speed critical stuff. Also the overheads of checking half a dozen mail boxes is not so great in a lot of applications. Nah, I would put all the mail box checking at the top of my code and have it dispatch to whatever it needs to do when data arrives in them. Basically structuring the main application code in an event driven style, like you do in JavaScript, except you have to code that event loop yourself.
Which brings us to the idea that perhaps the Propeller should have some hardware that allows COGs to wake each other up from WAITs and perhaps exchange some data at the same time. For example a COG would execute a RDCHAN which puts it to sleep until another COG writes some data out with a WRCHAN. At that point the sleeping COG wakes up and has the sent data to work on immediately. Perhaps just a LONG that is the actual data or a pointer to some mailbox or FIFO that has become full.
This of course is what XMOS, and the old Transputer, do to exchange data between cores and threads and has been suggested in the P2 development threads for years...
That's all I have to say about that.
I appreciate the info from everyone, especially Ksltd. When you ask questions, you may be suprised
at the different perspectives and insights that you get! Ya'll have save me tons of heartache!
If I want to attach things together, probably wooden things in this case, I have range of options: Nails, screws, glue, dovetail joints, dowels, God knows what.
All of these techniques have a few things in common: expense, complexity, effort, effectiveness, to some degree or other. Some may be more versatile or applicable to different situations than others.
Having weighed up all the pros and cons of the various options I might decide on one of those and tool up my factory to use that. This will incur some investment into nail guns, or electric screw drivers or dovetail routers, whichever. Basically I'm deciding that my factory does this process and if you have a job that really does need something else then you have to go next door where they do that. I can't afford to invest in more, different, tooling and training for my work force. However look, your problem can be solved the way I do it here, even if it is not 100% optimal it's good enough.
At that point having someone turn up and say that for this particular product screws would be better than the nails I have tooled up for is of no interest to me. It's not worth the bother.
So, there is my long winded analogy. The Propeller is an investment in tackling problems a particular way. Cores instead of interrupts. It covers a lot of application space. It perhaps makes some jobs harder or impossible. But then the same can be said the other way around.
Having taken that direction, mixing the chosen solution (cores) with a different solution to the same problems (interrupts) just adds expense and complication for little benefit.
I have no problem with interrupts, as long as they work where I want them to, having been using interrupts for decades. However if you want interrupts you can go next door to the ARM and Co. factory where I believe they do that very well I'm told:)
Is it way off base to say the Propeller has at least 27 available interrupt pins?
I mean, after the interrupt pin goes high/low, things have to happen in software after that, yes?
I finally got the courage to ask this question... I only know the propeller, but I have heard about interrupts, just not real clear on how they work.
-Tommy
Do while ina[16] ! = 1
Do stuff
or
If not ina[16] then
Do stuff
I am not trying to be funny or anything, it's just I've heard this before, and it only confuses me about interrupts and the Prop. I am not a professional code writer, so maybe I am missing some subtle definition of "interrupt".
All fine and good.
Really, the Propeller took a different direction, and is unique in that respect, as well as a few others. Rather than dilute that down with interrupts, I would much rather see the approach maximized. P1 is small. P2 will be bigger, and with that comes all the stuff we've learned how to do. Add in the features we know would seriously improve "The Propeller Way", and it's that much better.
Maximizing it, given it's uniqueness, seems to make the most sense.
Having done that, and we find interrupts would make sense, then let's add 'em. But not until we've actually blown "The Propeller Way" out fully, so that we can realize the benefits and not just compensate for having a smaller CPU and a growing desire to take on larger tasks.
Re: Von Newman
Heater, yes. It's hard to put it into one box. The way the COG is made is "Sir Gracey" However, if one is force to choose, it's just not Harvard, leaving Von Newman. BTW, there is this nice little street in the Portland area, "Von Newman Drive" and I was on it yesterday, almost took a sign to share with peeps here.
And that bit is part of why I didn't like "core" and still don't. The COG is differentiated enough to warrant a lexicon that captures those differences rather than dilute them.
"CORE" gets used for lots of stuff, and the more stuff it gets used for, the less we actually say with "CORE" Labeling a COG, a CORE really dilutes CORE some, just as much as it does what we know to be a COG.
That said, I get the call for more standardized information. However, with that information comes a lot of assumptions, not all of which will apply. Seems lazy, and coarse to me. Perhaps this is an artifact of when we all did computing too. Documentation varied widely early on. Terms were introduced in the context of a product line. We read that stuff, understood those machines and moved onward. Today, a lot of stuff is generic, not so differentiated. In that context, I agree a more standard documentation makes sense. However, if something actually IS differentiated, the reasons for doing docs that are differentiated have not changed, and that's another way to put where I'm at on this.
Try this post for information about why the Propeller doesn't have interrupts and a basic explanation of how they work.
http://www.savagecircuits.com/showthread.php?318-Why-Doesn-t-The-Propeller-Chip-Have-Interrupts
Park a COG on a pin and that PIN becomes your Interrupt pin. Event happens, pin changes, COG runs and does it's assigned soft interrupt tasks and goes back to sleep on the pin. OK,so it wasn't disruptive to the other COGs; to the outside world, it looked like an interrupt handler. You can even have multiple #1 priority interrupts (until you run out of COGs) before you need to start thinking about prioritizing interrupts and worrying about ISR response times and such.
If folks get hung up on having the identical mechanics in place in order to compare solutions then that is their loss. In most anything, your chosen solution is just A way, not the ONLY way!
With the Propeller we can't actually interrupt whatever a cog is doing although a spare cog can be sitting in reserve just waiting for that important thing that needs to be done right away, So the spare cog that has been setup to respond to that important signal is like a personal butler ready to do whatever it needs to do without having to drop something else and run over. This is so much better than having a single core and having to chop and change all the time. The end result is the same, the signal gets looked after, but the Propeller offers that personal service via each signals own private cog.
Also conventional CPUs have a rich peripheral set such as UARTS, I2C, SPI, ADC, TIMERS etc which are typically serviced by the interrupts which will grab and process and store the data or whatever. Not so the Propeller as it doesn't have these peripherals really but that private cog doesn't just sit around twiddling it's thumbs, it emulates the UART for instance and also processes the data and stores it etc and since it did then there is no actual need to request an "interrupt" signal, it's all done and tucked away already. Again, so much more flexible than a conventional CPU.
If every programmer could dedicate a processor to these tasks that normally require an interrupt then that is what they would do if they were smart but unfortunately they don't have any extra processors to dedicate and they are none the wiser as they only know one way of doing it, like lining up at a public phone vs having your own. I know who will get the first call in without interrupting "anybody" else.