Ken, while you in marketing mood on the forum, may I suggest a clearer naming convention. ie A name that rolls off the tongue easier than P16xxxx etc. TurboProp.... SuperPropeller....
Noted, agreed and shall be done. Was the subject of some internal communication today, too. I have two thoughts on this subject.
We realize that to forum members the previously-named Propeller 2 is not what we're discussing, and that the current chip discussed in this thread has already been called Pn to further cauterize this thought. However, no functional hardware has been fabricated and our return from using the name Propeller 2 for the current design would arguably be higher than calling this Propeller 1.5 or something like that. If we used the name "Propeller" I'd call this chip the Propeller 2. Propeller 3 is coming in the future - things just got designed out of order.
My second thought is exactly what you pointed out. Skip the whole numerical model number bit and go Turbo, Super, etc. Maybe Propeller "2" doesn't do the current design justice and we should skip the sequential bit. Nobody should wait nine years to have Model 2. It's better than that.
So I just talked myself into it, T Chap. Let me sleep on it a bit. Also, Chip has to love the whole thing for it to go: design, graphic, name, etc.
If we refer to a COG as a CORE, and we say multi-core, just what is it about our multi-core that is different, or better than the other multi-core devices out there?
What is the secret sauce?
Now, I would take the idea of a COG, personify it, and in some parts of the world would potentially include a character to represent it, and in others, simply do it by reference, and link the COG to multi-core in a way that implies the secret sauce, that partner that helps you get through, just works, etc... and then play off it all having something different than the other guys and having a nice, compact, well differentiated term for it too. But that's me.
Absolutely agree. Use the term "core" where it is appropriate, but don't bet your house on it - if people compare Propellers with other "muti-core" chips on the numbers alone (i.e. number of cores, number of Mhz, number of kilobytes etc) then the Propeller will lose nearly every time.
Open the capsule door. We've ridden a horse to the universe of Complexity and we're finally taking a ship back to Simplicity.
Especially if there's another way to achieve the same thing as you mentioned, why waste thousands of dollars documenting?
While we're simplifying, I'd like to propose we jettison the word "cog" in favor of "core". When introducing the Propeller - especially to non-native English speakers in their own country, Propeller-specific terms like this become a hurdle to their understanding and sometimes interest level. Each explanation becomes a tangent of its own, sometimes not coming back to the original message about how it works.
What do ya say? Propeller is a multicore processor, not a multicog processor.
Ken Gracey
To be honest when describing the propeller to those that are unfamiliar with it I call the "cogs" cores and have been for a long time. :-)
Since the P1+ was first suggested I felt that discipline and restraint was needed to prevent the chip from growing to big. Keep it lean and mean!!
So what's the natural word progression from Propeller through ____________ to Code Kiln?
If you take away COG, then you can't have COGlets as the outcome when you use hardware multi-tasking.
Like Potatohead said much mlre eloquently, you have a term that differentiates the Propeller architecture in the COG. Other companies seem to be trying other names to make them unique; tiles for example instead of cores.
Sorry to be a PITA Ken. I'm challenging this in the hopes good stuff falls out.
Another brutal example. Laundry soap. Who actually calls it that? Now the truth is, most of the stuff is the same. And they all differentiate in various ways. Some add smells, others add gimmicks, and they all make strong associations to things we find likable, friendly, pure, whatever. Some even personify the product, just as I hinted at above, and they even do it in the US! (which is notable)
The one other thing they do, well a couple of other things, is they never, ever, ever talk about the other guy. Now we can't always do that, and we can't do it because our niche kind of interconnects. But we need to be aware of that dynamic and not co-opt things that are bigger than we are, or we may dilute our value more than we add to it.
"multi-core" is a lot like laundry soap. It's accurate, but it's not something one can differentiate on, and without differentiation, we don't present a choice to prospects and where we do that, they won't also respond to an incentive to choose. Has to be said.
And of course, the laundry soap people are always about "new" and "improved" as is our competition. Something is new, until somebody else successfully makes a counter claim, and then the original must then, "improve" and that game is old and endless.
We don't do new very often. A name that minimizes that is wise. Seconded.
Might be worth splitting off marketing and/or nomenclature from this thread, if we want to keep it manageable and centered on architecture and features.
I get busy for a couple of days and come back to a thread that has over 300 posts and is taking hours to go through. Amazing, and it sounds like the resulting chip will be the same.
There are two items under discussion that caught my attention. One is the desire for hub execution, and based on this post from Chip it seems like it will happen. The other is a push for hardware multitasking in each cog.
Originally Posted by cgracey
One aspect of having 4-long hub transfers is that with a few simple address tags (TLB, David?) we could direct out-of-cog addresses into 4-long register blocks which are serving as instruction caches. Part of the cog register RAM becomes the cache! No cache-line flipflops and mux's needed!
I think hub exec is going to happen, because it won't take much. What would really blow it wide open would be to have a 256-bit hub data path, so that each cog could do an 8-instruction fetch every 8 instructions. That would have the effect of jacking the power up quite a bit, I'm afraid. All cogs could run at 100% speed from the hub without branching or hub accesses.
I think Cluso thought up this possibility on the Prop2 effort.
I am no expert on chip design, so this may not be practical, but I wonder if a simple form of cog multitasking (two tasks only) would be possible. It would be ultra simple, require a second address register, and some number (hopefully very small) of additional gates. The cog would alternate between executing the instructions pointed to by the two address registers. This would give us two tasks running at half speed in the cog.
Since the proposed hub exec can only fetch four longs per hub access, if they could be stored in a four long register block and executed in sequence (no TLB or caching) a cog could then run a cog task at half speed and a hub exec task at almost half cog speed. Of course any jumps would require another hub fetch so there would be some loss of speed.
I agree with Potatohead. Go with uniqueness in naming. Standard terms are loaded with heavy connotations. Starting fresh helps shed the baggage, right off the bat. And baggage is the impediment people face with the Propeller.
I get busy for a couple of days and come back to a thread that has over 300 posts and is taking hours to go through. Amazing, and it sounds like the resulting chip will be the same.
There are two items under discussion that caught my attention. One is the desire for hub execution, and based on this post from Chip it seems like it will happen. The other is a push for hardware multitasking in each cog.
I am no expert on chip design, so this may not be practical, but I wonder if a simple form of cog multitasking (two tasks only) would be possible. It would be ultra simple, require a second address register, and some number (hopefully very small) of additional gates. The cog would alternate between executing the instructions pointed to by the two address registers. This would give us two tasks running at half speed in the cog.
Since the proposed hub exec can only fetch four longs per hub access, if they could be stored in a four long register block and executed in sequence (no TLB or caching) a cog could then run a cog task at half speed and a hub exec task at almost half cog speed. Of course any jumps would require another hub fetch so there would be some loss of speed.
Any thoughts on this idea?
Two tasks are good, but four are really plush. Actually, I've found that three tasks are usually optimal. Four is overkill, but two are too few. Three is just odd, so might as well go with four. In my usage, there is always a main task and a few helper tasks which run in loops and don't do any calls. They are like adding magic peripherals that never could have been anticipated in the chip hardware design. That's what I think of extra tasks: they are peripherals.
Multitasking is very simple. It's just a matter of mux'ing a few sets of Z/C/PC. That's all it needs to be.
Open the capsule door. We've ridden a horse to the universe of Complexity and we're finally taking a ship back to Simplicity.
Especially if there's another way to achieve the same thing as you mentioned, why waste thousands of dollars documenting?
While we're simplifying, I'd like to propose we jettison the word "cog" in favor of "core". When introducing the Propeller - especially to non-native English speakers in their own country, Propeller-specific terms like this become a hurdle to their understanding and sometimes interest level. Each explanation becomes a tangent of its own, sometimes not coming back to the original message about how it works.
What do ya say? Propeller is a multicore processor, not a multicog processor.
Ken Gracey
I absolutely agree, Core(s) it should be!
It will then come up in search entries and be compared with other multi-core chips. We are seeing numerous ARM multi-cores appearing. Microcontrollers will no doubt follow, and then Parallax is clearly in the lead. And you will get a lot of free press because they understand what cores is.
Next, I think the cog memory should be Core RAM Registers/Memory and described as Private Core RAM Memory 2KB (496 x 32bit longs with 128bit wide access to Common Memory).
And lastly, the hub memory should be described as Common RAM Memory 512KB (byte/word/long/quadlong), shared between all Cores, and usable as expanded instruction and/or memory space.
We have to ditch our favourite words to embrace the market that should be able to understand these simpler definitions.
Sorry to be a PITA Ken. I'm challenging this in the hopes good stuff falls out.
Indeed, it's the best result for all that we want. My pride won't be standing in the way of choosing the best approach - I'm also happy to see the discussion and want the decisions to increase our potential for recovering our investment. I do admit to being sensitive to some details though, as I've stood behind this project for eight years and gone to lengths that only our internal team would understand to see it through completion.
Also, I don't pretend to make these decisions like cog v. core - that's up to Chip. But I'm pretty certain that the use of COG is for datasheets, instructions, code examples, but isn't much of a benefit to appear on any first-glance marketing material. If I have to sell you on Propeller between the 1st and 2nd floors, I won't use "cog" because I'd have to follow with "think of it as a core" before I take a question or move to the next point on "why you should use the Propeller".
Might be worth splitting off marketing and/or nomenclature from this thread, if we want to keep it manageable and centered on architecture and features.
Just saying!...
Agreed, Lachlan. Apologies for the diversion along the way.
I absolutely agree, Core(s) it should be!
It will then come up in search entries and be compared with other multi-core chips. We are seeing numerous ARM multi-cores appearing. Microcontrollers will no doubt follow, and then Parallax is clearly in the lead. And you will get a lot of free press because they understand what cores is.
Next, I think the cog memory should be Core RAM Registers/Memory and described as Private Core RAM Memory 2KB (496 x 32bit longs with 128bit wide access to Common Memory).
And lastly, the hub memory should be described as Common RAM Memory 512KB (byte/word/long/quadlong), shared between all Cores, and usable as expanded instruction and/or memory space.
We have to ditch our favourite words to embrace the market that should be able to understand these simpler definitions.
Maybe this should be a thread Ken. It's a worthy discussion. One I personally have considerable experience in. I'm going to take this to some savvy peers. Very curious to see how they would tackle the various scenarios.
Wow! Look at how few times LOCKSET and LOCKCLR were used: 3 and 7, only! I wonder if they were even needed, or used just because their existence suggested they were needed.
Trust me, Chip. When I use locks, it's not because they're a luxury. It's because there was no other way to do it.
Also, don't forget, you're looking at locks used in assembly code only. They're much more prevalent in Spin code. In any event, getting rid of them would be a huge mistake!
Although one master hardware lock is enough (since slave locks can be programmed), it can create a bottleneck. One lock per core has been about right for the P1, so I would suggest the same going forward.
Noted, agreed and shall be done. Was the subject of some internal communication today, too. I have two thoughts on this subject.
We realize that to forum members the previously-named Propeller 2 is not what we're discussing, and that the current chip discussed in this thread has already been called Pn to further cauterize this thought. However, no functional hardware has been fabricated and our return from using the name Propeller 2 for the current design would arguably be higher than calling this Propeller 1.5 or something like that. If we used the name "Propeller" I'd call this chip the Propeller 2. Propeller 3 is coming in the future - things just got designed out of order.
My second thought is exactly what you pointed out. Skip the whole numerical model number bit and go Turbo, Super, etc. Maybe Propeller "2" doesn't do the current design justice and we should skip the sequential bit. Nobody should wait nine years to have Model 2. It's better than that.
So I just talked myself into it, T Chap. Let me sleep on it a bit. Also, Chip has to love the whole thing for it to go: design, graphic, name, etc.
Ken Gracey
You can still keep P16X32B as the part number but it looks more like a "B" revision. Maybe P16C32A. But definitely call it a Propeller 2 or TurboProp or some such name that can be remembered. And agreed, who cares its not the full blown P2. Its looking more like a cut down P2 every minute - Chip's grabbing all the nice simple features.
I stumbled about COGs and HUB also, starting my addiction with Parallax.
Why this different naming? It's just a core isn't it? So I dug deeper. And found out that a COG is not simply a CORE like on other processors. It's WAY more. The same with HUB. It's not just RAM. It's RAM shared between COGs. WOW.
Please keep the naming. These are different animals. Because it is done Chips way and not mainstream. Like those Smart-IO pins. Brilliant.
Like said before by others Parallax 'owns' the words COG and HUB and the technology behind. A COG is way more then just a CORE. And HUB is different from just RAM. Its shared between COGs with support for it.
Sure. We could use CORENEW, CORESTOP, .COREwhatever instead. But a COG is not the same as a CORE on other processors and Parallax should not loose that distinction.
@Ken,
I do understand the strain on you. You know Chip longer than any of us. The Goal here is to get some new Product out to stay in the market.
As you will agree with me it's about sustainability. You know that but a lot of people seem not to understand this.
If your time allows it chime in here and slash the design and feature creep down. PLEASE. Someone has to do this.
We do not have time and the proposed P1+ is already a P2 again. Feature creep.
Agreed, Lachlan. Apologies for the diversion along the way.
Ken Gracey
No need to apologize Ken, I think this would be really valuable and you'd get plenty of feedback. Where's Matt Gilliland?
It's just that we seem to have hit a new level of interest in "The Next Propeller" and threads are growing like topsy, burying good contributions in the deluge.
If, like others, and myself, we describe the Prop to others as having 8 cores, then obviously cores is the correct name to use, at least in marketing.
They can then be described as being much more than cores. But if the users don't find it in their searches, they will never know about the prop. Try and find the prop with generic searces on DigiKey.
How many of you found the prop by accident like I did. I know that a lot of you did!
COGNEW and COGSTART can simply become CORENEW and CORERUN or CPUNEW and CPURUN or CPUSTART.
Trust me, Chip. When I use locks, it's not because they're a luxury. It's because there was no other way to do it.
Also, don't forget, you're looking at locks used in assembly code only. They're much more prevalent in Spin code. In any event, getting rid of them would be a huge mistake!
Although one master hardware lock is enough (since slave locks can be programmed), it can create a bottleneck. One lock per core has been about right for the P1, so I would suggest the same going forward.
-Phil
Thanks for weighing in on this subject, Everybody. Locks are staying, and for good reason.
I understand Yours problem.
And I think You now have good insight in what can be done and even usable from P2 work.
I know You still will come with clever solutions to made that IC usable
I will hang on as long my health give me.
BUT still -- It is possible have Instructions info to last BIN FPGA code --- S I can have any thing I can work on even if not so usable in NEXT STEP of IC.
Only work with electronics hold me little more (as my life last years are sleep and siting with computer with programing/thinking) else it will be only sleeping and that not help my health.
Sapieha,
I will try to get the docs done soon for the current Prop2 FPGA files. This project will carry on, as it's the long-term goal. I think by the time we make it, we'll have built-in DDR3 support for really fast memory.
I am curious. How old are you? I've always gotten the feeling that either you're a really old Swede or you've come from Eastern Europe.
While we're simplifying, I'd like to propose we jettison the word "cog" in favor of "core".
What do ya say? Propeller is a multicore processor, not a multicog processor.
Ken Gracey
I agree, I always describe it as multi core, or eight core. Then, I sometimes explain that the cores are called cogs.
Propeller is a multicore processor, not a multicog processor.
Nope, it's a multicore controller, not a multicore processor nor a multicog processor.
My working life has run pretty much parallel to the development of the 'micro' and, when people like Intel introduced chips like the 8048 and 8051 they were very careful to develop the concept of the "controller" as being a processor plus extra bits around it to make it useful in single-chip environments.
To me a processor is just that, a CPU with legs on it which on its own is pretty useless.
Also, on the smart of Smart IO etc - does the word 'smart' convey enough of the power it looks like we might be getting? SInce it looks like each pin can be, at the very least, a USART, SPI port or timer, the sort of things that other people call 'peripherals' isn't the phrase for the P1+...Peripheral Per Pin?
Comments
Noted, agreed and shall be done. Was the subject of some internal communication today, too. I have two thoughts on this subject.
We realize that to forum members the previously-named Propeller 2 is not what we're discussing, and that the current chip discussed in this thread has already been called Pn to further cauterize this thought. However, no functional hardware has been fabricated and our return from using the name Propeller 2 for the current design would arguably be higher than calling this Propeller 1.5 or something like that. If we used the name "Propeller" I'd call this chip the Propeller 2. Propeller 3 is coming in the future - things just got designed out of order.
My second thought is exactly what you pointed out. Skip the whole numerical model number bit and go Turbo, Super, etc. Maybe Propeller "2" doesn't do the current design justice and we should skip the sequential bit. Nobody should wait nine years to have Model 2. It's better than that.
So I just talked myself into it, T Chap. Let me sleep on it a bit. Also, Chip has to love the whole thing for it to go: design, graphic, name, etc.
Ken Gracey
Absolutely agree. Use the term "core" where it is appropriate, but don't bet your house on it - if people compare Propellers with other "muti-core" chips on the numbers alone (i.e. number of cores, number of Mhz, number of kilobytes etc) then the Propeller will lose nearly every time.
Ross.
Numbers are boring and don't "emote"
HyperProp...
To be honest when describing the propeller to those that are unfamiliar with it I call the "cogs" cores and have been for a long time. :-)
Since the P1+ was first suggested I felt that discipline and restraint was needed to prevent the chip from growing to big. Keep it lean and mean!!
It WOULD be a pain without locks. I've just never designed anything that needed that capability.
If you take away COG, then you can't have COGlets as the outcome when you use hardware multi-tasking.
Like Potatohead said much mlre eloquently, you have a term that differentiates the Propeller architecture in the COG. Other companies seem to be trying other names to make them unique; tiles for example instead of cores.
Another brutal example. Laundry soap. Who actually calls it that? Now the truth is, most of the stuff is the same. And they all differentiate in various ways. Some add smells, others add gimmicks, and they all make strong associations to things we find likable, friendly, pure, whatever. Some even personify the product, just as I hinted at above, and they even do it in the US! (which is notable)
The one other thing they do, well a couple of other things, is they never, ever, ever talk about the other guy. Now we can't always do that, and we can't do it because our niche kind of interconnects. But we need to be aware of that dynamic and not co-opt things that are bigger than we are, or we may dilute our value more than we add to it.
"multi-core" is a lot like laundry soap. It's accurate, but it's not something one can differentiate on, and without differentiation, we don't present a choice to prospects and where we do that, they won't also respond to an incentive to choose. Has to be said.
And of course, the laundry soap people are always about "new" and "improved" as is our competition. Something is new, until somebody else successfully makes a counter claim, and then the original must then, "improve" and that game is old and endless.
We don't do new very often. A name that minimizes that is wise. Seconded.
Just saying!...
There are two items under discussion that caught my attention. One is the desire for hub execution, and based on this post from Chip it seems like it will happen. The other is a push for hardware multitasking in each cog.
I am no expert on chip design, so this may not be practical, but I wonder if a simple form of cog multitasking (two tasks only) would be possible. It would be ultra simple, require a second address register, and some number (hopefully very small) of additional gates. The cog would alternate between executing the instructions pointed to by the two address registers. This would give us two tasks running at half speed in the cog.
Since the proposed hub exec can only fetch four longs per hub access, if they could be stored in a four long register block and executed in sequence (no TLB or caching) a cog could then run a cog task at half speed and a hub exec task at almost half cog speed. Of course any jumps would require another hub fetch so there would be some loss of speed.
Any thoughts on this idea?
Two tasks are good, but four are really plush. Actually, I've found that three tasks are usually optimal. Four is overkill, but two are too few. Three is just odd, so might as well go with four. In my usage, there is always a main task and a few helper tasks which run in loops and don't do any calls. They are like adding magic peripherals that never could have been anticipated in the chip hardware design. That's what I think of extra tasks: they are peripherals.
Multitasking is very simple. It's just a matter of mux'ing a few sets of Z/C/PC. That's all it needs to be.
It will then come up in search entries and be compared with other multi-core chips. We are seeing numerous ARM multi-cores appearing. Microcontrollers will no doubt follow, and then Parallax is clearly in the lead. And you will get a lot of free press because they understand what cores is.
Next, I think the cog memory should be Core RAM Registers/Memory and described as Private Core RAM Memory 2KB (496 x 32bit longs with 128bit wide access to Common Memory).
And lastly, the hub memory should be described as Common RAM Memory 512KB (byte/word/long/quadlong), shared between all Cores, and usable as expanded instruction and/or memory space.
We have to ditch our favourite words to embrace the market that should be able to understand these simpler definitions.
Indeed, it's the best result for all that we want. My pride won't be standing in the way of choosing the best approach - I'm also happy to see the discussion and want the decisions to increase our potential for recovering our investment. I do admit to being sensitive to some details though, as I've stood behind this project for eight years and gone to lengths that only our internal team would understand to see it through completion.
Also, I don't pretend to make these decisions like cog v. core - that's up to Chip. But I'm pretty certain that the use of COG is for datasheets, instructions, code examples, but isn't much of a benefit to appear on any first-glance marketing material. If I have to sell you on Propeller between the 1st and 2nd floors, I won't use "cog" because I'd have to follow with "think of it as a core" before I take a question or move to the next point on "why you should use the Propeller".
Ken Gracey
Agreed, Lachlan. Apologies for the diversion along the way.
Ken Gracey
I like this much better as it conveys what it does.
SmartPin (tm) reserved for Parallax Inc.
Also, don't forget, you're looking at locks used in assembly code only. They're much more prevalent in Spin code. In any event, getting rid of them would be a huge mistake!
Although one master hardware lock is enough (since slave locks can be programmed), it can create a bottleneck. One lock per core has been about right for the P1, so I would suggest the same going forward.
-Phil
Why this different naming? It's just a core isn't it? So I dug deeper. And found out that a COG is not simply a CORE like on other processors. It's WAY more. The same with HUB. It's not just RAM. It's RAM shared between COGs. WOW.
Please keep the naming. These are different animals. Because it is done Chips way and not mainstream. Like those Smart-IO pins. Brilliant.
Like said before by others Parallax 'owns' the words COG and HUB and the technology behind. A COG is way more then just a CORE. And HUB is different from just RAM. Its shared between COGs with support for it.
Sure. We could use CORENEW, CORESTOP, .COREwhatever instead. But a COG is not the same as a CORE on other processors and Parallax should not loose that distinction.
@Ken,
I do understand the strain on you. You know Chip longer than any of us. The Goal here is to get some new Product out to stay in the market.
As you will agree with me it's about sustainability. You know that but a lot of people seem not to understand this.
If your time allows it chime in here and slash the design and feature creep down. PLEASE. Someone has to do this.
We do not have time and the proposed P1+ is already a P2 again. Feature creep.
Worried!
Mike
No need to apologize Ken, I think this would be really valuable and you'd get plenty of feedback. Where's Matt Gilliland?
It's just that we seem to have hit a new level of interest in "The Next Propeller" and threads are growing like topsy, burying good contributions in the deluge.
It's a good problem to have.
If, like others, and myself, we describe the Prop to others as having 8 cores, then obviously cores is the correct name to use, at least in marketing.
They can then be described as being much more than cores. But if the users don't find it in their searches, they will never know about the prop. Try and find the prop with generic searces on DigiKey.
How many of you found the prop by accident like I did. I know that a lot of you did!
COGNEW and COGSTART can simply become CORENEW and CORERUN or CPUNEW and CPURUN or CPUSTART.
Thanks for weighing in on this subject, Everybody. Locks are staying, and for good reason.
Sapieha,
I will try to get the docs done soon for the current Prop2 FPGA files. This project will carry on, as it's the long-term goal. I think by the time we make it, we'll have built-in DDR3 support for really fast memory.
I am curious. How old are you? I've always gotten the feeling that either you're a really old Swede or you've come from Eastern Europe.
Thanks.
Chip
I agree, I always describe it as multi core, or eight core. Then, I sometimes explain that the cores are called cogs.
And then you have to go on to explain that cogs are actually more than simple cores. Where does it end?
Ross.
It ends with the smart IO pins! Or maybe they should be called "IIO" Pins (Intelligent IO).
Better yet, IO - Intelligent, or "IOI". [noparse]
Hey, that's pretty catchy!
How about "Enhanced Intelligent Electronic IO" - or EIEIO!
Nope, it's a multicore controller, not a multicore processor nor a multicog processor.
My working life has run pretty much parallel to the development of the 'micro' and, when people like Intel introduced chips like the 8048 and 8051 they were very careful to develop the concept of the "controller" as being a processor plus extra bits around it to make it useful in single-chip environments.
To me a processor is just that, a CPU with legs on it which on its own is pretty useless.
Also, on the smart of Smart IO etc - does the word 'smart' convey enough of the power it looks like we might be getting? SInce it looks like each pin can be, at the very least, a USART, SPI port or timer, the sort of things that other people call 'peripherals' isn't the phrase for the P1+...Peripheral Per Pin?