Shop OBEX P1 Docs P2 Docs Learn Events
The New 16-Cog, 512KB, 64 analog I/O Propeller Chip - Page 12 — Parallax Forums

The New 16-Cog, 512KB, 64 analog I/O Propeller Chip

1910121415144

Comments

  • Ken GraceyKen Gracey Posts: 7,386
    edited 2014-04-08 20:35
    T Chap wrote: »
    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.

    Ken Gracey
  • RossHRossH Posts: 5,381
    edited 2014-04-08 20:40
    potatohead wrote: »
    Ok, answer me this:

    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.

    Ross.
  • T ChapT Chap Posts: 4,217
    edited 2014-04-08 20:40
    Snow Leopard, Mountain Lion, Mavericks

    Numbers are boring and don't "emote"

    HyperProp...
  • 4x5n4x5n Posts: 745
    edited 2014-04-08 20:49
    Ken Gracey wrote: »
    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!!
  • cgraceycgracey Posts: 14,133
    edited 2014-04-08 20:52
    BTW: how can you warrant atomic reserve of a resource in a parallel environment without a lock?

    It WOULD be a pain without locks. I've just never designed anything that needed that capability.
  • mindrobotsmindrobots Posts: 6,506
    edited 2014-04-08 20:58
    So what's the natural word progression from Propeller through ____________ to Code Kiln? :smile:

    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.
  • potatoheadpotatohead Posts: 10,255
    edited 2014-04-08 21:08
    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.
  • TubularTubular Posts: 4,639
    edited 2014-04-08 21:18
    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!...
  • kwinnkwinn Posts: 8,697
    edited 2014-04-08 21:19
    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.

    Any thoughts on this idea?
  • cgraceycgracey Posts: 14,133
    edited 2014-04-08 21:19
    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.
  • cgraceycgracey Posts: 14,133
    edited 2014-04-08 21:26
    kwinn wrote: »
    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.
  • Cluso99Cluso99 Posts: 18,069
    edited 2014-04-08 21:26
    Ken Gracey wrote: »
    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.
  • Ken GraceyKen Gracey Posts: 7,386
    edited 2014-04-08 21:28
    potatohead wrote: »
    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".

    Ken Gracey
  • Ken GraceyKen Gracey Posts: 7,386
    edited 2014-04-08 21:29
    Tubular wrote: »
    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.

    Ken Gracey
  • kwinnkwinn Posts: 8,697
    edited 2014-04-08 21:30
    + 1 for sure.
    Cluso99 wrote: »
    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.
  • potatoheadpotatohead Posts: 10,255
    edited 2014-04-08 21:35
    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.
  • Cluso99Cluso99 Posts: 18,069
    edited 2014-04-08 21:36
    Ken Gracey wrote: »
    SmartIO is a great term. I don't know what it means yet, but it's somewhat self-explanatory. Thanks to Sapieha.
    Ken Gracey
    Following on from Sapieha, someone suggested it is really SmartPin (tm).
    I like this much better as it conveys what it does.

    SmartPin (tm) reserved for Parallax Inc.
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2014-04-08 21:38
    cgracey wrote:
    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.

    -Phil
  • Cluso99Cluso99 Posts: 18,069
    edited 2014-04-08 21:42
    Ken Gracey wrote: »
    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.
  • msrobotsmsrobots Posts: 3,705
    edited 2014-04-08 21:44
    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.

    Worried!

    Mike
  • TubularTubular Posts: 4,639
    edited 2014-04-08 22:03
    Ken Gracey wrote: »
    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.

    It's a good problem to have.
  • Cluso99Cluso99 Posts: 18,069
    edited 2014-04-08 22:08
    Core vs Cog

    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.
  • cgraceycgracey Posts: 14,133
    edited 2014-04-08 22:17
    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.
  • cgraceycgracey Posts: 14,133
    edited 2014-04-08 22:49
    Sapieha wrote: »
    Hi Chip.

    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.

    Thanks.

    Chip
  • W9GFOW9GFO Posts: 4,010
    edited 2014-04-08 23:39
    Ken Gracey wrote: »
    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.
  • RossHRossH Posts: 5,381
    edited 2014-04-08 23:41
    W9GFO wrote: »
    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.
  • W9GFOW9GFO Posts: 4,010
    edited 2014-04-09 00:16
    RossH wrote: »
    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] :D[/noparse]
  • RossHRossH Posts: 5,381
    edited 2014-04-09 00:17
    W9GFO wrote: »
    It ends with the smart IO pins! Or maybe they should be called "IIO" Pins (Intelligent IO).

    Hey, that's pretty catchy!
  • RossHRossH Posts: 5,381
    edited 2014-04-09 00:25
    W9GFO wrote: »
    It ends with the smart IO pins! Or maybe they should be called "IIO" Pins (Intelligent IO).

    Better yet, IO - Intelligent, or "IOI". [noparse] :D[/noparse]

    How about "Enhanced Intelligent Electronic IO" - or EIEIO!
  • Brian FairchildBrian Fairchild Posts: 549
    edited 2014-04-09 00:44
    Ken Gracey wrote: »
    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?
Sign In or Register to comment.