I've thought about this, too, but lots of nets between all cogs, would take a lot of power. Between adjacent cogs, maybe not so much - if they actually wound up adjacent in the layout.
But I'm sure that's not the case with distributors. They want to sell stuff as much as you do, there is no gain for them in making things hard to find.
They want you to find, what they want you to buy.
The customer ask the seller: "I want X " The seller answers "I don't have X, but I have Y"
Usually:
a) sellers profit margin for Y >> seller's profit margin for X
- keeps original P2 name for P2 as descriped on Parallax Semiconductor
- allows marketing noise "we decided to bring out a low power version first"
- highlights cores and memory, allows more devices in the series (ie 90nm P2LP32X1024)
- allows P2HP prefix for "Propeller 2 High Performance" variant (the P2 that currently lives in our DE2's)
Phil, could you give an example of why you want the CTRs to remain? If the pin brains handle all kinds of things, the only thing I see the CTRs doing is operating on pins that are not close together. The CTRs have random pin access. Pins aside, you do a lot with FRQ and PHS things, right? These are certainly quicker to access than by messaging a pin serially. I don't have any great desire to remove the CTRs, but I do wonder what you see in them. Thanks in advance for any input here.
I was thinking about this a bit. Suppose you were to move the FRQx and PHSx into the hub space, just above the ROM. This would be a block of 128 registers (two per pin). I'm not sure whether you would group them by pin or by function, though grouping by function would allow a single RDQUAD to capture up to four adjacent pin PHSx values. The CTRx would instead use the MSG approach to configure the pin(s) for counter mode.
In terms of performance, I think you would still be okay. The configuration (CTR register vs SYSOP msg) is not the primary concern. It's the interaction with the FRQx and PHSx. In the P1, you can read/write to these every 4 clock cycles, but would realistically access those registers no more frequently than every 4 or 5 instructions (e.g. 4-5 MHz typical). Now, with the P1+, you can access the hub every 16 clocks (12.5MHz typical) with 7 non-hub instruction in between to interact with the captured data. Admittedly, this would not be as fast as keeping them in-cog (20-25MHz every 4-5 instructions), but it would still be faster than the original P1. And if this simplifies the overall design, it's probably a reasonable trade-off.
One additional benefit is that the hub version might work better with tasks. The argument here is that the hub access is guaranteed to be deterministic (timing-wise), while tasks are not (due to branches and waits).
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.
I've been describing cogs as cores not because it's the most correct way to describe them but it's what others understand. Use the term cog first and you're spending 10+ minutes explaining what a cog is and why they're called cogs instead of cores!!
There's no need to rename the commands the have "cog" in them. While not in common use anymore Sun originally called NIS (Network Information Service) YP (Yellow Pages) until AT&T objected. :-) The changed the name to NIS but all the commands that were used with nis were proceeded by yp (ypwhich, ypserv, ypbind, ypcat, etc) never had their name changed and are still proceeded with yp!!
Exactly. The very basic and historical instructions arent marketing.
Regarding paid show talks, if a show is well established, speakers pay fees. If a show is growing, or needs to be established, the speakers often do not pay fees.
Sometimes a speaker never pays fees, and or may require fees to speak.
- keeps original P2 name for P2 as descriped on Parallax Semiconductor
- allows marketing noise "we decided to bring out a low power version first"
- highlights cores and memory, allows more devices in the series (ie 90nm P2LP32X1024)
- allows P2HP prefix for "Propeller 2 High Performance" variant (the P2 that currently lives in our DE2's)
Do you need the "P" or the "x"? For that matter, why have the "power" part in there at all? Why not just P16A512 (Propeller, 16 cogs/cores, rev A, 512KB)? This would make the original P8A32 and the P2 would become P8B256.
This thread is about the new chip we are going to build in the 180nm process.
About code compatibility with Prop1: Is this absolutely mandatory?
...
There are some Prop1 instructions that I've never used, like CMPSX. Maybe we could cull a few of those for other things. Any ideas on getting rid of any of those instructions?
Do we really need to support words any more, with RDWORD/WRWORD? Bytes, I think, are always needed, but I don't think I've ever used words for anything before. Convention says we need them, but do we, really?
Re: PropFORTH - We would only need the subset of instructions used to implement the kernel. Retianing those might be a convenience.
For 16 cores, I think we would probably adapt to just about anything.
VGA is going to simply be a use case of a shifter that drives four DAC outputs to a set of fixed pins attached to each cog.
Simple is generally better.
If I want a display, I can either go small I2C, or use a smartphone over bluetooth as a terminal interface. Smart phone or PC provides significantly more capability than the prop can supply, and I can usually get by fine with no permanent display on the prop.
Just to pile on here... I would also suggest using the term "cores" instead of "cogs".
Also, maybe HUB RAM should be "shared RAM" and COG RAM should be "private RAM"?
Or, HUB RAM as last level cache?
I've spent a lot of years working with SGI and SUN and think of cog memory as "intimate" memory. In the architecture used by Sun and SGI (developed by Cray) the ram in the machine wasn't "pool" memory but based on which board or socket it was plugged into was accessible by a single CPU. That memory could only accessed by the cpu (predates cores) that it was wired to and was referred to as "intimate" to that cpu. If access to that memory was needed by a process running on another cpu that cpu had to request the memory from the cpu that memory was intimate with. I know I'm confusing things and only people familiar with the Sun, SGI architecture will understand it. :-)
When talking to non-unix people that would understand intimate memory (it is intimate since only a given cog can access the memory in the cog) I call it cog ram.
That's exactly the problem, it separates the prop from the world. Nobody reading this gibberish about COGS and HUB and Spin has any clue what the thing is and they move on to the vast array of other devices they can use that are nicely categorized in online catalogues by familiar criteria like RAM size, FLASH size, MIPS, MHz, data/instruction width, IO pin count, number of ADCs, etc.
I believe that calling a spade a "spade" is a very good idea.
Those processors in the Propeller should be referred to as "cores" all the world and his dog (see picture) knows what "cores" are. Or call them "processors" even.
That shared RAM should just be called "RAM", coz that is what it is.
The HUB thing need not even be mentioned in product briefs, that's just a teeny technical detail about how RAM is shared among processors.
Let just call it the Circus chip. The hub can be renamed "The Big Top" and the cogs can be "Trailers" occupied by short, fat programs called "Carnies". When multitasking is on, they become "Fun Houses". All the new pipelined math circuits can be collectively called "Midway". The 512-long program memory can be featured in the "Freak Show". Wait, wait, that's all politically incorrect, nowadays. We need a bold, new name that commands reverence: "Sustainable Diversity Cluster". It thrives in an "Eco System" of mobile apps and exceptionally neutral people who were born about about five minutes ago.
I think of "cores" as something that I am told is there but that I cannot actually touch. I sometimes feel that I would be happier if I could do a core dump, but I never really know until after.
When I were a lad "core" was the memory. Even today you can get a "core dump" from crashed program under Unix/Linux.
How confused am I now?
That's what I was just thinking (not how confused you are) - core was core but now it's core and we used to have a lot of core but now we can have one core or more but not near as many as before. I used to dump core to show me more but now they won't let me dump a core because a core isn't dump-able anymore. Now you get a stack trace that shows you the state of your core back however many you asked it for.
"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.
On the other hand, how many times as an engineer have you received a RFQ from some company where you can tell exactly which competitor's website they were just looking at because of the buzz words they used?
Q: "How many cores do you have?"
A: None. We have cogs. They're different.
(client scratches the propeller off of their list)
The propeller is different by its very design but you have to give people some similarities or else it will just be too weird and they won't take the time to really consider it.
I'm 100% on board with marketing the propeller as having cores instead of cogs. No one knows what a cog is but we all know what a core is. I also like calling COG RAM registers and calling HUB ram shared memory. This is just good marketing since people will understand what that is right away. Even after working with microcontrollers for years, thinking that I only have slightly less that 512 memory locations for my program and my data seems VERY limiting. It is only after you have used the propeller that you see how it isn't really that limiting at all. Yes, calling COG RAM registers isn't quite accurate but it will make the propeller much more attractive to potential customers.
Phil, could you give an example of why you want the CTRs to remain? If the pin brains handle all kinds of things, the only thing I see the CTRs doing is operating on pins that are not close together. The CTRs have random pin access. Pins aside, you do a lot with FRQ and PHS things, right? These are certainly quicker to access than by messaging a pin serially. I don't have any great desire to remove the CTRs, but I do wonder what you see in them. Thanks in advance for any input here.
Here are just a few examples of intensive counter use:
Out of 684 Spin files in my projects directory, 110 use counters in one fashion or another. Counters are the lifeblood of the Propeller. I guess if the P1+/P2 didn't have any, I would happily continue to use the P1.
Even with something as simple as pos w/feedback counter mode, you can build a very sensitive amplifier capable of receiving radio signals directly or the raw output from an ultrasonic transducer. This has become a basic building block for several Propeller projects. With two counters programmed in logic mode (XOR), a very flexible set of I/Q mixers can be constructed. This, again, has become a basic building block for my apps.
If anything, I would like to see additional counter modes and ways to link multiple counters. The main thing is to keep things simple, not "smart." The more and simpler building blocks one has at his disposal, the more creative he can be. The counters, in their present state, with ready access to all their registers, fill that requirement to a "T".
Out of 684 Spin files in my projects directory, 110 use counters in one fashion or another. Counters are the lifeblood of the Propeller. I guess if the P1+/P2 didn't have any, I would happily continue to use the P1.
Even with something as simple as pos w/feedback counter mode, you can build a very sensitive amplifier capable of receiving radio signals directly or the raw output from an ultrasonic transducer. This has become a basic building block for several Propeller projects. With two counters programmed in logic mode, a very flexible set of I/Q mixers can be constructed. This, again, has become a basic building block for my apps.
If anything, I would like to see additional counter modes and ways to link multiple counters.
-Phil
+1 Keep the old CTRs
They are valuable to the people that have been using them for years. Changing that would probably add time to market for those people.
How many of those won't work with the new pin-based counters?
We'll probably all work with them. However, if the effort in keeping them is reasonable it would certainly ease the transition to the new generation propeller.
I think it is Not possible have P1 type counters that work same way as Original P1 can use them.
As with using Smart IO Pins all things that out to IO need one Extra Clock pulse to strobe output
Chip,
You got rid of ADDS, but kept ADDX and SUBX. I think we need ADDS more than the X variants. Signed addition (and thus subtraction because it's signed) is way more useful than ADDX/SUBX in my opinion.
... if the effort in keeping them is reasonable it would certainly...
Exactly. Chip really needs to evaluate the cost - in terms of heat, in terms of mux'ing the CPU to death, and in terms of silicon real estate. Phil has been the most strident voice of all in telling Chip that all such decisions are ultimately Chip's alone.
Chip,
You got rid of ADDS, but kept ADDX and SUBX. I think we need ADDS more than the X variants. Signed addition (and thus subtraction because it's signed) is way more useful than ADDX/SUBX in my opinion.
Roy, addx is used in the fsrw code for accumulating bits into a byte on receive.
There is a risk that some people won't migrate to Propeller 2 without the compatibility... slow learners like myself.
It isn't that we don't want to, but it is difficult to keep up with all the fast learners around here. But the truth is I am not a lot of $$$ in the sales picture. I will buy a few Propeller 2, but may never do much with them. I just have to accept that at 66, enjoying life at a leisurely pace may be more important that mastering the Propeller 2.
The way the world is today, you are likely to have better public acceptance by the more radical departure from the rather stale expectations of the original Propeller 2 specifications.
People will be more curious, but you obviously have more support work cut out for you... publishing another manual, explaining new concepts.
This is getting further and further beyond an entry-level educational sort of product.
In sum, give us the best of what you got and the WOW factor may be worth challenging your followers.
Comments
Or S-Pin (Smart Pin)? Wait, that won't work...
They want you to find, what they want you to buy.
The customer ask the seller: "I want X " The seller answers "I don't have X, but I have Y"
Usually:
a) sellers profit margin for Y >> seller's profit margin for X
and/or
b) availability of Y >> availability of X
I read it quickly, at first blush it looks extremely good.
I'll give it a careful read later, and post any pittfalls (if I run into any)
How about:
P2LP16x512 - Propeller 2 Low Power edition, 16 cogs/cores, 512KB ram
- keeps original P2 name for P2 as descriped on Parallax Semiconductor
- allows marketing noise "we decided to bring out a low power version first"
- highlights cores and memory, allows more devices in the series (ie 90nm P2LP32X1024)
- allows P2HP prefix for "Propeller 2 High Performance" variant (the P2 that currently lives in our DE2's)
I was thinking about this a bit. Suppose you were to move the FRQx and PHSx into the hub space, just above the ROM. This would be a block of 128 registers (two per pin). I'm not sure whether you would group them by pin or by function, though grouping by function would allow a single RDQUAD to capture up to four adjacent pin PHSx values. The CTRx would instead use the MSG approach to configure the pin(s) for counter mode.
In terms of performance, I think you would still be okay. The configuration (CTR register vs SYSOP msg) is not the primary concern. It's the interaction with the FRQx and PHSx. In the P1, you can read/write to these every 4 clock cycles, but would realistically access those registers no more frequently than every 4 or 5 instructions (e.g. 4-5 MHz typical). Now, with the P1+, you can access the hub every 16 clocks (12.5MHz typical) with 7 non-hub instruction in between to interact with the captured data. Admittedly, this would not be as fast as keeping them in-cog (20-25MHz every 4-5 instructions), but it would still be faster than the original P1. And if this simplifies the overall design, it's probably a reasonable trade-off.
One additional benefit is that the hub version might work better with tasks. The argument here is that the hub access is guaranteed to be deterministic (timing-wise), while tasks are not (due to branches and waits).
I've been describing cogs as cores not because it's the most correct way to describe them but it's what others understand. Use the term cog first and you're spending 10+ minutes explaining what a cog is and why they're called cogs instead of cores!!
There's no need to rename the commands the have "cog" in them. While not in common use anymore Sun originally called NIS (Network Information Service) YP (Yellow Pages) until AT&T objected. :-) The changed the name to NIS but all the commands that were used with nis were proceeded by yp (ypwhich, ypserv, ypbind, ypcat, etc) never had their name changed and are still proceeded with yp!!
Regarding paid show talks, if a show is well established, speakers pay fees. If a show is growing, or needs to be established, the speakers often do not pay fees.
Sometimes a speaker never pays fees, and or may require fees to speak.
All depends on who is adding value to what.
Do you need the "P" or the "x"? For that matter, why have the "power" part in there at all? Why not just P16A512 (Propeller, 16 cogs/cores, rev A, 512KB)? This would make the original P8A32 and the P2 would become P8B256.
Re: PropFORTH - We would only need the subset of instructions used to implement the kernel. Retianing those might be a convenience.
For 16 cores, I think we would probably adapt to just about anything.
Simple is generally better.
If I want a display, I can either go small I2C, or use a smartphone over bluetooth as a terminal interface. Smart phone or PC provides significantly more capability than the prop can supply, and I can usually get by fine with no permanent display on the prop.
I've spent a lot of years working with SGI and SUN and think of cog memory as "intimate" memory. In the architecture used by Sun and SGI (developed by Cray) the ram in the machine wasn't "pool" memory but based on which board or socket it was plugged into was accessible by a single CPU. That memory could only accessed by the cpu (predates cores) that it was wired to and was referred to as "intimate" to that cpu. If access to that memory was needed by a process running on another cpu that cpu had to request the memory from the cpu that memory was intimate with. I know I'm confusing things and only people familiar with the Sun, SGI architecture will understand it. :-)
When talking to non-unix people that would understand intimate memory (it is intimate since only a given cog can access the memory in the cog) I call it cog ram.
1+
cogs = confusing
cores = earth people language
I don't think you are paying attention… we have moved this conversation to http://forums.parallax.com/showthread.php/155167-A-Propeller-by-any-other-name...
If you feel the need… you could post these kinds of comments to http://forums.parallax.com/showthread.php/155169-Don-t-name-me-Corey-Cogsworth!-P16x32-Names-and-Terms
But those comments will then be moved to http://forums.parallax.com/showthread.php/155167-A-Propeller-by-any-other-name...
I have asked the moderators to look at your posts.
How confused am I now?
That's what I was just thinking (not how confused you are) - core was core but now it's core and we used to have a lot of core but now we can have one core or more but not near as many as before. I used to dump core to show me more but now they won't let me dump a core because a core isn't dump-able anymore. Now you get a stack trace that shows you the state of your core back however many you asked it for.
On the other hand, how many times as an engineer have you received a RFQ from some company where you can tell exactly which competitor's website they were just looking at because of the buzz words they used?
Q: "How many cores do you have?"
A: None. We have cogs. They're different.
(client scratches the propeller off of their list)
The propeller is different by its very design but you have to give people some similarities or else it will just be too weird and they won't take the time to really consider it.
I'm 100% on board with marketing the propeller as having cores instead of cogs. No one knows what a cog is but we all know what a core is. I also like calling COG RAM registers and calling HUB ram shared memory. This is just good marketing since people will understand what that is right away. Even after working with microcontrollers for years, thinking that I only have slightly less that 512 memory locations for my program and my data seems VERY limiting. It is only after you have used the propeller that you see how it isn't really that limiting at all. Yes, calling COG RAM registers isn't quite accurate but it will make the propeller much more attractive to potential customers.
Here are just a few examples of intensive counter use:
http://forums.parallax.com/showthread.php/123791-Propeller-mediated-Sine-Wave-Frequency-Synthesizer
http://forums.parallax.com/showthread.php/114155-Simple-Class-D-Speaker-Amp-Using-a-MOSFET-Driver
http://forums.parallax.com/showthread.php/110918-Bell-202-Modem-(1200-baud-AFSK)-Object
http://forums.parallax.com/showthread.php/105674-Hook-an-antenna-to-your-Propeller-and-listen-to-the-radio!
http://forums.parallax.com/showthread.php/125877-Propeller-Backpack-based-Antenna-Analyzer
http://forums.parallax.com/showthread.php/135244-Propeller-Backpack-COLOR-NTSC-Capture
http://forums.parallax.com/showthread.php/86376-PropCAM-A-Propeller-imaging-camera
Out of 684 Spin files in my projects directory, 110 use counters in one fashion or another. Counters are the lifeblood of the Propeller. I guess if the P1+/P2 didn't have any, I would happily continue to use the P1.
Even with something as simple as pos w/feedback counter mode, you can build a very sensitive amplifier capable of receiving radio signals directly or the raw output from an ultrasonic transducer. This has become a basic building block for several Propeller projects. With two counters programmed in logic mode (XOR), a very flexible set of I/Q mixers can be constructed. This, again, has become a basic building block for my apps.
If anything, I would like to see additional counter modes and ways to link multiple counters. The main thing is to keep things simple, not "smart." The more and simpler building blocks one has at his disposal, the more creative he can be. The counters, in their present state, with ready access to all their registers, fill that requirement to a "T".
-Phil
Now, add another spoken language into the mix and have the same conversation.
I agree with you.
Ken Gracey
+1 Keep the old CTRs
They are valuable to the people that have been using them for years. Changing that would probably add time to market for those people.
And there's nothing to stop them continuing to do so in the still available P1.
The P1+ is a new chip, in a new package, and with a new way of thinking. So people should expect to put some effort into using it.
How many of those won't work with the new pin-based counters?
We'll probably all work with them. However, if the effort in keeping them is reasonable it would certainly ease the transition to the new generation propeller.
Alex
I think it is Not possible have P1 type counters that work same way as Original P1 can use them.
As with using Smart IO Pins all things that out to IO need one Extra Clock pulse to strobe output
You got rid of ADDS, but kept ADDX and SUBX. I think we need ADDS more than the X variants. Signed addition (and thus subtraction because it's signed) is way more useful than ADDX/SUBX in my opinion.
Exactly. Chip really needs to evaluate the cost - in terms of heat, in terms of mux'ing the CPU to death, and in terms of silicon real estate. Phil has been the most strident voice of all in telling Chip that all such decisions are ultimately Chip's alone.
There is a risk that some people won't migrate to Propeller 2 without the compatibility... slow learners like myself.
It isn't that we don't want to, but it is difficult to keep up with all the fast learners around here. But the truth is I am not a lot of $$$ in the sales picture. I will buy a few Propeller 2, but may never do much with them. I just have to accept that at 66, enjoying life at a leisurely pace may be more important that mastering the Propeller 2.
The way the world is today, you are likely to have better public acceptance by the more radical departure from the rather stale expectations of the original Propeller 2 specifications.
People will be more curious, but you obviously have more support work cut out for you... publishing another manual, explaining new concepts.
This is getting further and further beyond an entry-level educational sort of product.
In sum, give us the best of what you got and the WOW factor may be worth challenging your followers.