"would it be possible simply to bias those corresponding bits of RAM on power-up to contain the "ROM" code?" - We thought about doing something like that early on as a means to be 'tricky' with the data and essentially pack more information in a given space, Chip tried several simulations and there was enough degree of uncertainty that he abandoned that idea. Essentially you could still keep the bit cell as a 6T, you simply change the physical size of the transistor. <-- Another reason this idea was abandoned. The current 6T bit cell is comparable to TSMC's bit cell for the 130nm process if you scaled it to the 180nm process that we are currently using. The reason for the 130nm process reference is because at the time of our development of the 6T SRAM the only reference available from TSMC was for their 130nm. So in the development of our SRAM for 180nm we used the 130nm as a model guideline.
It all boils down to size and the more you can shave off in a single BIT cell, the better. ... Especially when it comes to memories, because they have a tenancy to step multiply rather quickly when it comes to available real-estate.
"would it be possible simply to bias those corresponding bits of RAM on power-up to contain the "ROM" code?" - We thought about doing something like that early on as a means to be 'tricky' with the data and essentially pack more information in a given space, Chip tried several simulations and there was enough degree of uncertainty that he abandoned that idea. Essentially you could still keep the bit cell as a 6T, you simply change the physical size of the transistor. <-- Another reason this idea was abandoned.
So that physical size gives a capacitive skew, and loads that way ? - thus needing a critical dV/dT on Vcc rise ?
What if you applied Phil's idea to the COG RAM, - as that is where the Main RAM init needs to be shifted to, to actually run ?
If I understand the situation correcty RAM cells are much bigger than ROM cells. In the Prop II we have space for 128K of RAM.
BUT it is possible to butcher some of the RAM cells to make ROM, in the same address space. Still taking the same physical space as what would have been RAM.
So, the more code you make in ROM the less RAM you have. Ergo the ROM monitor is eating valuable RAM for little benifit in general usage.
Yes, usually ROM is die size smaller, but you can patch RAM to make ROM, and doing that makes sense when the ROM is very small, as it delivers ROM at RAM speeds, with no RAM access cost penalty.
However, this ROM has no tables, or (I think) anything that might be run-time useful, it has to be copied into a COG before it can run.
Another drawback with patched RAM, is it is a compile-time choice, you cannot do as a single-metal ROM in the more conventional flow sense.
The other reality check is video RAM sizes, and there is one value at 640x400*4, which leaves 3072 bytes spare from a full 2^17 RAM.
If the ROM consumes 3,840 Bytes, this will not fit. (short by 768 bytes)
If the ROM consumes 1,456 Bytes, we have 1,616 bytes spare for FIFOs, Palette, etc.
If the size is creeping up, and compromises are biting, then perhaps it needs a look at a tiny genuine ROM, which gives back all RAM, and does allow top-metal changes.
Cheapest COG-sized serial memory, seems to be i2c, 11c TSSOP8 or 17c SOT23-5, and SPI look to be around 30c, with MSOP8 of 2x3mm UFDN, and the Serial FLASH are not much of a step up, to 32c for 64KB
Well, it's run time useful in that any user program can make use of the monitor, and or potentially the auto-baud and encryption.
If it's a copy to COG deal, that would require instructions and such to drop it in under user control as well as at boot time. This way, it's kind of done, not disturbing the synth path, which is the critical path.
I personally don't think it's a big deal. At 128K RAM, people will hit, "I need 20 more longs" and do so at the same scale of complexity / capability as people attempting it at 124K...
The answers are to refactor or compress operations, and both of those again are similar at both RAM sizes.
If we were talking 256K vs 128 or 192K, then the argument for more RAM would actually have a significant impact on the chip applicability use cases. This size difference really doesn't, IMHO.
One use case is video. At the larger RAM sizes initially discussed, video using standard methods would be possible and practical above VGA resolution. At this RAM size, dynamic drawing techniques like we've boot strapped on P1 will be required to realize the higher resolutions and or bit depths, unless external RAM is employed. We don't know the limits of that yet. Good news on P2 is that multi-threading, new waitvid features and CLUT will very significantly improve low and moderate resolution video COG capability. One COG could likely be doing what we use a few for today! This further diminishes the RAM change impact, IMHO.
(*wants or will build ASAP a dev board with a reasonable 1MB or so external RAM to start that process)
So that decision was made a long time ago. The monitor really doesn't impact "native" video capability. Because of that, the better video options will either require specialized code, or force the use of external RAM.
In both scenarios, the monitor + booter is a freebie, particularly given time to release would be extended taking other paths. I really don't want to see that, as the optimal product adoption window is NOW. And passing...
Summary: No significant use case is off the table that wasn't already off the table, or forced into external RAM that wasn't already missing due to design decisions and physical requirements much earlier on.
When we place ROM bits into hub memory, it's true that they are only 1 transistor, but they snap in the place of what was meant for a 6-transistor SRAM cell.
Well, it's run time useful in that any user program can make use of the monitor, and or potentially the auto-baud and encryption.
If it's a copy to COG deal, that would require instructions and such to drop it in under user control as well as at boot time. This way, it's kind of done, not disturbing the synth path, which is the critical path.
I personally don't think it's a big deal. At 128K RAM, people will hit, "I need 20 more longs" and do so at the same scale of complexity / capability as people attempting it at 124K...
The answers are to refactor or compress operations, and both of those again are similar at both RAM sizes.
If we were talking 256K vs 128 or 192K, then the argument for more RAM would actually have a significant impact on the chip applicability use cases. This size difference really doesn't, IMHO.
One use case is video. At the larger RAM sizes initially discussed, video using standard methods would be possible and practical above VGA resolution. At this RAM size, dynamic drawing techniques like we've boot strapped on P1 will be required to realize the higher resolutions and or bit depths, unless external RAM is employed. We don't know the limits of that yet. Good news on P2 is that multi-threading, new waitvid features and CLUT will very significantly improve low and moderate resolution video COG capability. One COG could likely be doing what we use a few for today! This further diminishes the RAM change impact, IMHO.
(*wants or will build ASAP a dev board with a reasonable 1MB or so external RAM to start that process)
So that decision was made a long time ago. The monitor really doesn't impact "native" video capability. Because of that, the better video options will either require specialized code, or force the use of external RAM.
In both scenarios, the monitor + booter is a freebie, particularly given time to release would be extended taking other paths. I really don't want to see that, as the optimal product adoption window is NOW. And passing...
Summary: No significant use case is off the table that wasn't already off the table, or forced into external RAM that wasn't already missing due to design decisions and physical requirements much earlier on.
You seem to be assuming that all uses of the P2 will involve video. Do we really expect that to be true or is this another example of the off-beat applications that we hobbyists tend to pursue?
Not at all. Video was included as one example where earlier choices had the serious applicability impact, where the monitor choice made recently basically doesn't.
I don't have an easy way to express this... Let's look at P1. Would 2K of extra RAM have made the difference in applicability? 2/32 = 6 percent On P2, it's 3.5/128 3 percent RAM change delta.
Looking back at all the stuff people did on P1, the "on chip" sweet spot would not have made a significant difference before requiring external hardware to assist, or where simply not doing that task at all ended up being the result. 34K just isn't much different than 32K is when we think in terms of what a Propeller can do with it's on-chip resources. The set of edge cases, where making this decision is dubious wouldn't change size much plus or minus 2K of RAM. And had it gone the other way, 30K instead of 32, a whole lot of stuff will still have happened, leaving the picture today not a whole lot different from how we understand it to be today.
How people ended up employing the propeller wouldn't have been significantly different at 34K or 30K, compared to how they did use it at 32K.
I'm saying the change in RAM on P2 will work the same way. There will be the on chip, native capability use cases, and there will be all the use cases that require more RAM than is on chip, and the edge ones that are difficult to determine. Those sets of cases really don't look different at 124K than they would have looked at 128K.
To really impact that, the RAM change delta would have to be much larger. In the end, if it can be done on a P2 without external RAM, it's likely as possible and practical to do at 124K as it would be at 128K. We originally were thinking 384K, then 256, etc... Those were big steps that seriously changed what the "on chip" expectations were. This much smaller step just doesn't.
I honestly would have preferred a path that didn't impact HUB RAM, but I also honestly think the position of the chip release date relative to potential technology adoption is growing increasingly costly. Because the synth work was the critical path, doing this didn't change that, and it added features that may well see significant use without significantly impacting potential uses in like kind.
Because of that, I see it as a net gain overall.
Say we didn't do it at all, and it's 126K, no monitor, just the booter and necessary things discussed so far. Would the impact be less? If so, how much less, and how much relative to some of the potentials having the monitor brings to the table? I don't see it being significant, and thus my "freebie" comment.
The real rub is getting to a point in the design path where it would have been good to add an extra address line to map the ROM outside the RAM space, preserving all the HUB. Had we this discussion then, the HUB would be 128K... Even then, that's just not the same kind of impact as 192K, 160k, etc... would really have been.
this question just pops up: is the ram of arbitrary content at power up or is it set or reset? If yes: what makes it come up in a given state and could this be used to set initial information which then is overwritten? It should even be possible to make an ECC over initial content in case of the data being not 100% repeatable.
this question just pops up: is the ram of arbitrary content at power up or is it set or reset? If yes: what makes it come up in a given state and could this be used to set initial information which then is overwritten? It should even be possible to make an ECC over initial content in case of the data being not 100% repeatable.
Not at all. Video was included as one example where earlier choices had the serious applicability impact, where the monitor choice made recently basically doesn't.
I don't have an easy way to express this... Let's look at P1. Would 2K of extra RAM have made the difference in applicability? 2/32 = 6 percent On P2, it's 3.5/128 3 percent RAM change delta.
Looking back at all the stuff people did on P1, the "on chip" sweet spot would not have made a significant difference before requiring external hardware to assist, or where simply not doing that task at all ended up being the result. 34K just isn't much different than 32K is when we think in terms of what a Propeller can do with it's on-chip resources. The set of edge cases, where making this decision is dubious wouldn't change size much plus or minus 2K of RAM. And had it gone the other way, 30K instead of 32, a whole lot of stuff will still have happened, leaving the picture today not a whole lot different from how we understand it to be today.
How people ended up employing the propeller wouldn't have been significantly different at 34K or 30K, compared to how they did use it at 32K.
I'm saying the change in RAM on P2 will work the same way. There will be the on chip, native capability use cases, and there will be all the use cases that require more RAM than is on chip, and the edge ones that are difficult to determine. Those sets of cases really don't look different at 124K than they would have looked at 128K.
To really impact that, the RAM change delta would have to be much larger. In the end, if it can be done on a P2 without external RAM, it's likely as possible and practical to do at 124K as it would be at 128K. We originally were thinking 384K, then 256, etc... Those were big steps that seriously changed what the "on chip" expectations were. This much smaller step just doesn't.
I honestly would have preferred a path that didn't impact HUB RAM, but I also honestly think the position of the chip release date relative to potential technology adoption is growing increasingly costly. Because the synth work was the critical path, doing this didn't change that, and it added features that may well see significant use without significantly impacting potential uses in like kind.
Because of that, I see it as a net gain overall.
Say we didn't do it at all, and it's 126K, no monitor, just the booter and necessary things discussed so far. Would the impact be less? If so, how much less, and how much relative to some of the potentials having the monitor brings to the table? I don't see it being significant, and thus my "freebie" comment.
The real rub is getting to a point in the design path where it would have been good to add an extra address line to map the ROM outside the RAM space, preserving all the HUB. Had we this discussion then, the HUB would be 128K... Even then, that's just not the same kind of impact as 192K, 160k, etc... would really have been.
You may be right but I hate to see even 2K "wasted" with a feature that, while cool, probably won't be used by most people. The limit we're far more likely to bump into that isn't even addressed in P2 is the tiny COG memory space. Because that remains essentially the same as P1, we are forced into virtual machine implementations to handle programs of any significant size. I guess that's more likely to be a problem than the lack of 2K of additional hub memory.
Perhaps because I'm from the generation that only had 2K or RAM giving that much up seems extravagant for monitor which I can't see getting all that much use and that can be downloaded if needed anyway.
The limited COG space will be fixed in Prop III which will be 64 bit allowing src and dest fields of instructions to be 25 bits giving a COG address space of 128MB. At that point we can ditch the HUB RAM for programs and just use it for inter-cog comms.
Perhaps because I'm from the generation that only had 2K or RAM giving that much up seems extravagant for monitor which I can't see getting all that much use and that can be downloaded if needed anyway.
The limited COG space will be fixed in Prop III which will be 64 bit allowing src and dest fields of instructions to be 25 bits giving a COG address space of 128MB. At that point we can ditch the HUB RAM for programs and just use it for inter-cog comms.
Dreaming, dreaming...
I'm a little bit confused, I do understand the limited cog space, and I also agree with heater amd David, but is there any kind of trade for the hub ram versus cog ram? What I mean is, does the size of the hub ram affect the possible size of the cog ram?
I'm a little bit confused, I do understand the limited cog space, and I also agree with heater amd David, but is there any kind of trade for the hub ram versus cog ram? What I mean is, does the size of the hub ram affect the possible size of the cog ram?
Not really since the size of COG RAM is limited architecturally to 512 longs or 2K bytes because PASM instructions use a 9 bit address field. Indirect addressing of COG memory could get past this limit but it isn't available on P1 or P2.
Not really since the size of COG RAM is limited architecturally to 512 longs or 2K bytes because PASM instructions use a 9 bit address field. Indirect addressing of COG memory could get past this limit but it isn't available on P1 or P2.
So essentially, PASM it's self would need to be modified to really increase the cog memory. Would any kind of bank switching methods be possible?
So essentially, PASM it's self would need to be modified to really increase the cog memory. Would any kind of bank switching methods be possible?
This has been discussed many times before, and a few methods have been proposed to get around the 9-bit limitation. Bank switching is one method that would work. Bank switching was used in the SX and it works fine. I can understand the philosophy on P1 that maintained a nice clean RISC-type instruction set. However, the instruction set on P2 has many special-purpose instructions and modes of operation. It seems like bank switching would just be one more special mode of operation. Ultimately it comes down to chip space and prioritizing which features are more important to have.
This has been discussed many times before, and a few methods have been proposed to get around the 9-bit limitation. Bank switching is one method that would work. Bank switching was used in the SX and it works fine. I can understand the philosophy on P1 that maintained a nice clean RISC-type instruction set. However, the instruction set on P2 has many special-purpose instructions and modes of operation. It seems like bank switching would just be one more special mode of operation. Ultimately it comes down to chip space and prioritizing which features are more important to have.
Ah that also helps me see things more clearly...pardon my lack of knowledge. Personally, from the preliminary feature list, I'd like to see what kind of computing power I can get from this chip! I think that all the special modes of operation really help with I/O, it kinda seems like most of those special purpose instruction is for some kind of interfacing to other devices...
I think that all the special modes of operation really help with I/O, it kinda seems like most of those special purpose instruction is for some kind of interfacing to other devices...
Well, this is a microCONTROLLER after all! Interfacing to the outside world is kind of its reason for existence! :-)
Well, this is a microCONTROLLER after all! Interfacing to the outside world is kind of its reason for existence! :-)
Controller yes.
But I'm crazy, with the CLUT, and the ability to quickly stream data from external ram sources to the CLUT, I want to build a processor out of it!
Controller yes.
But I'm crazy, with the CLUT, and the ability to quickly stream data from external ram sources to the CLUT, I want to build a processor out of it!
Yes, that will be tempting! What processor do you want to build? I'm looking forward to a more detailed description of P2 so we can start coming up with cool applications for it!
Yes, that will be tempting! What processor do you want to build? I'm looking forward to a more detailed description of P2 so we can start coming up with cool applications for it!
I think that something on par with i386 or even pentium I processor could be very possible! I don't have to much to compare with, but I want something that is small, doesn't get hot but can handle applications that require lots of math and or computing in a decent time. Now I suppose there are already things like out better suited, but come on, propeller II!!!
I think a cool application would an extension of this http://obex.parallax.com/objects/413/
But with better speed optimization. Also C should be pretty fun as well!
Here is what the Prop2 looks like if the 128-bit key has been set to some non-zero value and you don't know what that value is:
Here is what you face if the key is still zero, but you want to download a program which could potentially set the key. You'll need to sign your program with a key of zero:
And here is what you get if the key is still zero, but no signed program was downloaded or found in a serial flash chip. This is the monitor. Everybody is welcome here, no questions asked:
I'm hoping that the monitor will encourage people to make development tools, as no SHA-256/HMAC signing is required to download a program, and they can just send text strings to get the chip to do anything they want. It would even allow the Prop2 to act as an I/O expander without writing any code. If you need a little more than simple I/O via the monitor commands, squirt a little program into memory and launch it into a cog. Then, you could communicate with it via hub ram and the monitor. No special tools needed.
Of course, any complex development tool will take care of the SHA-256/HMAC signing for you, but those tools will take more investment to develop. The monitor makes it very easy to start developing a tool system. One "paste" from the clipboard could download and execute a complete Prop2 application.
If you need a little more than simple I/O via the monitor commands, squirt a little program into memory and launch it into a cog. Then, you could communicate with it via hub ram and the monitor. No special tools needed.
If we need a monitor couldn't we just load it and save a few bytes of RAM? Maybe the ROM monitor is the same size that a simple loader would be, and I'm just misunderstanding the need for a monitor in ROM.
If we need a monitor couldn't we just load it and save a few bytes of RAM? Maybe the ROM monitor is the same size that a simple loader would be, and I'm just misunderstanding the need for a monitor in ROM.
Yes, you could - if you had a development system, already.
I know that if I saw the Prop2 and wanted to make a tool system for it, it would be easier to use a monitor to get my toes into the water than having to commit to fully jumping in, at the outset.
Yes, you could - if you had a development system, already.
I know that if I saw the Prop2 and wanted to make a tool system for it, it would be easier to use a monitor to get my toes into the water than having to commit to fully jumping in, at the outset.
A document describing the download protocol would make it easier to build a toolchain too! :-)
I'm hoping that the monitor will encourage people to make development tools, as no SHA-256/HMAC signing is required to download a program, and they can just send text strings to get the chip to do anything they want.
- but the loader allows that too, via hex text strings ?
It would even allow the Prop2 to act as an I/O expander without writing any code.
This I agree with, and some resource that allows this is a good idea.
A simple stub from the loader, should allow memory R/W and some COG control register access.
Smallest COG core that allows RAM-IO, is what ? under 10 lines ? Could even use threading to make R/W dual port in feel.
I am less convinced it needs things like embedded help strings in the ROM.
If you need a little more than simple I/O via the monitor commands, squirt a little program into memory and launch it into a cog. Then, you could communicate with it via hub ram and the monitor. No special tools needed.
? - but you need a Prop tool chain, which is special tools - or did you mean No special download tools ?
Of course, any complex development tool will take care of the SHA-256/HMAC signing for you, but those tools will take more investment to develop. The monitor makes it very easy to start developing a tool system. One "paste" from the clipboard could download and execute a complete Prop2 application.
I'm all for KISS, but a terminal that included the help strings, instead of consuming ROM for example, would be a better idea.
The I/O expander pathway is an important one, and you might like to look at how Cypress handle Modules in their PSoC.
Their tools maintain a library that hides much of the low level stuff, and users choose from a menu.
They update and improve those blocks.
Why not an open source 'better terminal' that effectively has the Monitor Help on the PC, and sends only what it needs to RAM/EEPROM.
A user would select their "I/O syntax support set", and that becomes like virtual firmware.
The PC side can manage, and test, any "I/O syntax support set" (including users own), and when done, the Prop can easily slave to the smallest controller.
You could even drive it as IO from a 6 Pin Micro, or Serially from almost anything.
Some might want RS232-Monitor link, some might prefer i2c, some i2s, and some SPI or QuadSPI - that choice will depend on WHAT they have, that is talking to the Smart IO expander that is Prop II. You do not want that choice locked in ROM.
The Memory choices I see are :
Nothing at all : 'Loader+' operation, one link choice. Allows simplest IO expander.
Smallest i2c - choose 1 COG size (16k) as practical limit, these are $0.11385@Reel SOT23/TSSOP/SO8
(very little saving in going smaller, 2-3c max) - covers all IO expander users
Best value SPI - Here that seems to be Winbond's W25Q80B, which is : $0.36432/Reel
Note this low price gives you QuadSPI, and enough storage to fully load 6.4 Prop II memory images.
Comments
"would it be possible simply to bias those corresponding bits of RAM on power-up to contain the "ROM" code?" - We thought about doing something like that early on as a means to be 'tricky' with the data and essentially pack more information in a given space, Chip tried several simulations and there was enough degree of uncertainty that he abandoned that idea. Essentially you could still keep the bit cell as a 6T, you simply change the physical size of the transistor. <-- Another reason this idea was abandoned. The current 6T bit cell is comparable to TSMC's bit cell for the 130nm process if you scaled it to the 180nm process that we are currently using. The reason for the 130nm process reference is because at the time of our development of the 6T SRAM the only reference available from TSMC was for their 130nm. So in the development of our SRAM for 180nm we used the 130nm as a model guideline.
It all boils down to size and the more you can shave off in a single BIT cell, the better. ... Especially when it comes to memories, because they have a tenancy to step multiply rather quickly when it comes to available real-estate.
So that physical size gives a capacitive skew, and loads that way ? - thus needing a critical dV/dT on Vcc rise ?
What if you applied Phil's idea to the COG RAM, - as that is where the Main RAM init needs to be shifted to, to actually run ?
Yes, usually ROM is die size smaller, but you can patch RAM to make ROM, and doing that makes sense when the ROM is very small, as it delivers ROM at RAM speeds, with no RAM access cost penalty.
However, this ROM has no tables, or (I think) anything that might be run-time useful, it has to be copied into a COG before it can run.
Another drawback with patched RAM, is it is a compile-time choice, you cannot do as a single-metal ROM in the more conventional flow sense.
The other reality check is video RAM sizes, and there is one value at 640x400*4, which leaves 3072 bytes spare from a full 2^17 RAM.
If the ROM consumes 3,840 Bytes, this will not fit. (short by 768 bytes)
If the ROM consumes 1,456 Bytes, we have 1,616 bytes spare for FIFOs, Palette, etc.
If the size is creeping up, and compromises are biting, then perhaps it needs a look at a tiny genuine ROM, which gives back all RAM, and does allow top-metal changes.
Cheapest COG-sized serial memory, seems to be i2c, 11c TSSOP8 or 17c SOT23-5, and SPI look to be around 30c, with MSOP8 of 2x3mm UFDN, and the Serial FLASH are not much of a step up, to 32c for 64KB
If it's a copy to COG deal, that would require instructions and such to drop it in under user control as well as at boot time. This way, it's kind of done, not disturbing the synth path, which is the critical path.
I personally don't think it's a big deal. At 128K RAM, people will hit, "I need 20 more longs" and do so at the same scale of complexity / capability as people attempting it at 124K...
The answers are to refactor or compress operations, and both of those again are similar at both RAM sizes.
If we were talking 256K vs 128 or 192K, then the argument for more RAM would actually have a significant impact on the chip applicability use cases. This size difference really doesn't, IMHO.
One use case is video. At the larger RAM sizes initially discussed, video using standard methods would be possible and practical above VGA resolution. At this RAM size, dynamic drawing techniques like we've boot strapped on P1 will be required to realize the higher resolutions and or bit depths, unless external RAM is employed. We don't know the limits of that yet. Good news on P2 is that multi-threading, new waitvid features and CLUT will very significantly improve low and moderate resolution video COG capability. One COG could likely be doing what we use a few for today! This further diminishes the RAM change impact, IMHO.
(*wants or will build ASAP a dev board with a reasonable 1MB or so external RAM to start that process)
So that decision was made a long time ago. The monitor really doesn't impact "native" video capability. Because of that, the better video options will either require specialized code, or force the use of external RAM.
In both scenarios, the monitor + booter is a freebie, particularly given time to release would be extended taking other paths. I really don't want to see that, as the optimal product adoption window is NOW. And passing...
Summary: No significant use case is off the table that wasn't already off the table, or forced into external RAM that wasn't already missing due to design decisions and physical requirements much earlier on.
Source: http://forums.parallax.com/archive/index.php/t-141706-p-3.html
I don't have an easy way to express this... Let's look at P1. Would 2K of extra RAM have made the difference in applicability? 2/32 = 6 percent On P2, it's 3.5/128 3 percent RAM change delta.
Looking back at all the stuff people did on P1, the "on chip" sweet spot would not have made a significant difference before requiring external hardware to assist, or where simply not doing that task at all ended up being the result. 34K just isn't much different than 32K is when we think in terms of what a Propeller can do with it's on-chip resources. The set of edge cases, where making this decision is dubious wouldn't change size much plus or minus 2K of RAM. And had it gone the other way, 30K instead of 32, a whole lot of stuff will still have happened, leaving the picture today not a whole lot different from how we understand it to be today.
How people ended up employing the propeller wouldn't have been significantly different at 34K or 30K, compared to how they did use it at 32K.
I'm saying the change in RAM on P2 will work the same way. There will be the on chip, native capability use cases, and there will be all the use cases that require more RAM than is on chip, and the edge ones that are difficult to determine. Those sets of cases really don't look different at 124K than they would have looked at 128K.
To really impact that, the RAM change delta would have to be much larger. In the end, if it can be done on a P2 without external RAM, it's likely as possible and practical to do at 124K as it would be at 128K. We originally were thinking 384K, then 256, etc... Those were big steps that seriously changed what the "on chip" expectations were. This much smaller step just doesn't.
I honestly would have preferred a path that didn't impact HUB RAM, but I also honestly think the position of the chip release date relative to potential technology adoption is growing increasingly costly. Because the synth work was the critical path, doing this didn't change that, and it added features that may well see significant use without significantly impacting potential uses in like kind.
Because of that, I see it as a net gain overall.
Say we didn't do it at all, and it's 126K, no monitor, just the booter and necessary things discussed so far. Would the impact be less? If so, how much less, and how much relative to some of the potentials having the monitor brings to the table? I don't see it being significant, and thus my "freebie" comment.
The real rub is getting to a point in the design path where it would have been good to add an extra address line to map the ROM outside the RAM space, preserving all the HUB. Had we this discussion then, the HUB would be 128K... Even then, that's just not the same kind of impact as 192K, 160k, etc... would really have been.
See post #1441, earlier on this page.
See recent post http://forums.parallax.com/showthread.php?125543-Propeller-II-update-BLOG&p=1140458&viewfull=1#post1140458 above.
Having ECC might make it work reliably but it would also require extra storage bits.
Perhaps because I'm from the generation that only had 2K or RAM giving that much up seems extravagant for monitor which I can't see getting all that much use and that can be downloaded if needed anyway.
The limited COG space will be fixed in Prop III which will be 64 bit allowing src and dest fields of instructions to be 25 bits giving a COG address space of 128MB. At that point we can ditch the HUB RAM for programs and just use it for inter-cog comms.
Dreaming, dreaming...
Well, this is a microCONTROLLER after all! Interfacing to the outside world is kind of its reason for existence! :-)
But I'm crazy, with the CLUT, and the ability to quickly stream data from external ram sources to the CLUT, I want to build a processor out of it!
I think a cool application would an extension of this
http://obex.parallax.com/objects/413/
But with better speed optimization. Also C should be pretty fun as well!
Thanks,
Tim Gilmore
Here is what you face if the key is still zero, but you want to download a program which could potentially set the key. You'll need to sign your program with a key of zero:
And here is what you get if the key is still zero, but no signed program was downloaded or found in a serial flash chip. This is the monitor. Everybody is welcome here, no questions asked:
I'm hoping that the monitor will encourage people to make development tools, as no SHA-256/HMAC signing is required to download a program, and they can just send text strings to get the chip to do anything they want. It would even allow the Prop2 to act as an I/O expander without writing any code. If you need a little more than simple I/O via the monitor commands, squirt a little program into memory and launch it into a cog. Then, you could communicate with it via hub ram and the monitor. No special tools needed.
Of course, any complex development tool will take care of the SHA-256/HMAC signing for you, but those tools will take more investment to develop. The monitor makes it very easy to start developing a tool system. One "paste" from the clipboard could download and execute a complete Prop2 application.
Yes, you could - if you had a development system, already.
I know that if I saw the Prop2 and wanted to make a tool system for it, it would be easier to use a monitor to get my toes into the water than having to commit to fully jumping in, at the outset.
A document describing the download protocol would make it easier to build a toolchain too! :-)
This I agree with, and some resource that allows this is a good idea.
A simple stub from the loader, should allow memory R/W and some COG control register access.
Smallest COG core that allows RAM-IO, is what ? under 10 lines ? Could even use threading to make R/W dual port in feel.
I am less convinced it needs things like embedded help strings in the ROM.
? - but you need a Prop tool chain, which is special tools - or did you mean No special download tools ?
I'm all for KISS, but a terminal that included the help strings, instead of consuming ROM for example, would be a better idea.
The I/O expander pathway is an important one, and you might like to look at how Cypress handle Modules in their PSoC.
Their tools maintain a library that hides much of the low level stuff, and users choose from a menu.
They update and improve those blocks.
Why not an open source 'better terminal' that effectively has the Monitor Help on the PC, and sends only what it needs to RAM/EEPROM.
A user would select their "I/O syntax support set", and that becomes like virtual firmware.
The PC side can manage, and test, any "I/O syntax support set" (including users own), and when done, the Prop can easily slave to the smallest controller.
You could even drive it as IO from a 6 Pin Micro, or Serially from almost anything.
Some might want RS232-Monitor link, some might prefer i2c, some i2s, and some SPI or QuadSPI - that choice will depend on WHAT they have, that is talking to the Smart IO expander that is Prop II. You do not want that choice locked in ROM.
The Memory choices I see are :
Nothing at all : 'Loader+' operation, one link choice. Allows simplest IO expander.
Smallest i2c - choose 1 COG size (16k) as practical limit, these are $0.11385@Reel SOT23/TSSOP/SO8
(very little saving in going smaller, 2-3c max) - covers all IO expander users
Best value SPI - Here that seems to be Winbond's W25Q80B, which is : $0.36432/Reel
Note this low price gives you QuadSPI, and enough storage to fully load 6.4 Prop II memory images.