I must be a lot slower than the rest of you because I don't really understand a lot of what was said in this discussion.
I started with Stamps because they were easy to program and had the N&V columns to provide inspiration as well as the hows & whys to everything. I switched to the prop because of the need for more programming space (and the lower cost was a bonus). Since then I have learned how to use additional cogs which is also a huge step forward for the things that I do. The Prop I does everything I can imagine I need right now, but I would like to see some different proto boards. Right now all that are available are the almost-all-in-one boards that include KVM, two regulators and servo headers. I would like to see a slim proto board that just provides power, access to all of the I/O's and either a Prop Stick header or USB. I can fab my own boards, but my skills are limited to DIP (which the PII evidently won't be available in) and with the PI it ends up being about the same overall board size. I would gladly pay the same $20-25 for the same proto boards, but with less "stuff" on it. They would be so much easier to fit into my projects from a size standpoint.
Also, I considered myself an advanced beginner after using Stamps for a while, but still the transition to Prop has had its moments. I wish there were a N&V type column for the Prop & PropII (maybe not feasible due to complexity) and more Parallax written code for OBEX. I appreciate everyone who has submitted code to OBEX, but sometimes I feel like I'm reading Wikipedia. Sure the info is there, but you don't really know how valid it is, or if it has been superseded several times since then and in a lot of cases the documentation is bare bones.
Personally, I'd like to see the next chip powerful enough to support a basic browser and email. Frankly, if I could do internet communication and spin programming on the Propeller, I'd have very little use for a PC. As a PC service technician by day, I know that if folks had an inexpensive way to hook to the internet and do email without the potential for Viruses/Spyware/Malware and the like, money would change hands. I'm not sure the next chip have the power to fulfill this role, but even close may be enough for me. I'm sick of power hungry, windows, PCs.
The Propeller has always suffered from being a great product looking for it's amazing application. The creation of Parallax Semiconductor is a giant step in the correct direction.
OBC
A basic browser and e-mail program would not necessarily require a full GUI, so I am sure the Prop II could handle that. There were some very good menu/graphical front ends for CPM and dos that could provide most of what Windows/OS10/Linux provides now. One area I feel the prop ( I or II ) would be a great fit is in the area of home automation. The energy savings would pay for the prop system in short order, and having a basic browser and e-mail as well would be icing on the cake.
As Chip mentioned, the die is already as big as the package is going to allow. The 32k x4 RAMs are located at the top with some control logic in the middle. The "COG guts" consist mostly of the PLLs COGRAM and DUAL-Port RAM in addition to SIN ROM and CORDIC ROM. The area left for synthesis is just over 9.6 million square microns allowing 1.2 million square microns for the remainder of each synthesized portion of the COG.
Maybe the Prop III can use this technology to be a 3D Prop:
I wish there were a N&V type column for the Prop & PropII (maybe not feasible due to complexity) and more Parallax written code for OBEX. I appreciate everyone who has submitted code to OBEX, but sometimes I feel like I'm reading Wikipedia. Sure the info is there, but you don't really know how valid it is, or if it has been superseded several times since then and in a lot of cases the documentation is bare bones.
Benj
Benj, would like to make sure you've seen these N&V columns for the Propeller:
My experience has been that when debugging tools were available and I leaned on them, my skills as a programmer did not improve. So I quit using them. What has helped my programming more than anything else is a philosophy of building and testing one step at a time. Constant testing is the key. What little debugging is necessary with each step can be accomplished with a serial terminal and an oscilloscope.
The biggest mistake a programmer can make is to write an entire program before testing it. Then -- yeah -- he better have good debugging tools and an extended deadline.
-Phil
Couldn't agree more. Careful design, small routines debugged individually, and careful integration makes for simple debugging.
I hope they do first a downsized version of the Propeller II.
For 99.5% of my Propeller applications I do not need 96 I/O pins, but I would like to have the speed and all the I/O features of the Prop II. I think there is big market for a little Propeller with only 20..28 pins and something like 16 I/Os, 3..4 cogs and 16..32k HubRAM. The die size can be 1/3 of the Prop2 because also the I/O space for 80 pins is not needed. Therefore the chip should cost max. 1/2 of the Prop II.
With the new features of the I/O pins (ADC, DAC) we need only 1 pin for TV, only 5 pins for VGA and an ADC needs only 1 instead of 2 pins, so 16 I/Os will be enough for many applications.
It would be the ideal chip for measuring some sensors and communicate over a fast bus (USB, Ethernet without additional chips).
And with such a low pin count, even a DIP package is possible!
Andy
Andy, how can you say such things!!! That sounds like backsliding or possibly even blasphemy to me ;-) I find myself running out of pins far more often than using all the memory or cogs available. Seriously though also have several projects that used half or fewer of the pins and cogs available so a 28 pin 4 cog prop would have been nice. Making it faster is great, but keep the ram at 32K or more.
I like how in the die layout the blocks for each core is called "cog_guts"...
In any case, I wish that once the chip is made Parallax will take a high quality picture of the die and make a big poster out of it for sale. I'd buy one.
Couldn't agree more. Careful design, small routines debugged individually, and careful integration makes for simple debugging.
The name for this is called "bottom-up" programming. It's the way FORTH forces you to work and why Prof_Braino has accomplished so much. And it's what every CS course has taught you not to do for about the last 40 years.
No, I actually had not seen those articles. I had looked for N&V again just prior to to writing my previous comments and couldn't find it. Now that you point out the location, it seems all too obvious. Thank you.
The name for this is called "bottom-up" programming. It's the way FORTH forces you to work and why Prof_Braino has accomplished so much. And it's what every CS course has taught you not to do for about the last 40 years.
Forth afficianados actually use a combination of top-down and bottom-up development!
No, I actually had not seen those articles. I had looked for N&V again just prior to to writing my previous comments and couldn't find it. Now that you point out the location, it seems all too obvious. Thank you.
It's not a surprise that these files are hard to fine. To be totally honest, the underlying technology of the Parallax web site is very weak with a .Net overlying tool known as DNN. Our marketing department is preparing a massive redesign that will put us into a better tool suite. Drupal is the likely platform under Linux OS. We'll start this discussion pretty quickly, but since we're so close on the heels of Parallax Semiconductor's release we will give them a break for a couple more days. Pushing the issue today would be a mutiny situation if we were on a boat. Your comment just got me thinking. . .
The name for this is called "bottom-up" programming. It's the way FORTH forces you to work and why Prof_Braino has accomplished so much. And it's what every CS course has taught you not to do for about the last 40 years.
Actually, Sal writtens the code, I just write about the code. And while CS courses are evolving, they did not exactly say NOT to do what we do....
Forth afficianados actually use a combination of top-down and bottom-up development!
The process includes Sal writing the low level drivers and implementation, and a discussion on how a less techinacal user (me) would use the fucntions. Iterative top-down and bottom-up development, as Leon stated. This in some ways related to the concept of "test-based requirements". (Modified as we have 11 man hours between two resources per week)
As an ASQ certified software engineer, I am familliar with development process in both regulated (aviation, medical) industries and non regulated industries (almost everything else). The degree of success in regulated industries is dirctly related to the degree of conformance to a defined and controled development process, which includes top-down (from management) and bottom up (from engineering) and feedback from each to the other. The degree of success in unregulated industries (that do NOT a solid process) is related primarily to dumb luck. No offence to anybody, I have only worked with a few dozen non-regulated outfits, my experience is limited.
Parallax is in the minority of companies that appears to have mastered top down, bottom up, and feedback into their operation, which I appreciate. Whether this was by intent or evolved from the combination of individuals and talents is unknown to me. But good process makes the world a better place, and I support it where I find evidence of it.
FORTH tends to highlight that its hard to succede with poor process, and hard to fail with good process. With me at least, other environments are a Smile shoot, due to functions that happen "automagically" beyond my control and understand (which is entirely a problem of my ignorance, but still a problem).
If I may make a prediction: From the user prespective, the prop 2 will likely be another example where sound design leads to success, and inappropriate design leads to head scratching.
It's not a surprise that these files are hard to fine. To be totally honest, the underlying technology of the Parallax web site is very weak with a .Net overlying tool known as DNN. Our marketing department is preparing a massive redesign that will put us into a better tool suite. Drupal is the likely platform under Linux OS. We'll start this discussion pretty quickly, but since we're so close on the heels of Parallax Semiconductor's release we will give them a break for a couple more days. Pushing the issue today would be a mutiny situation if we were on a boat. Your comment just got me thinking. . .
Ken Gracey
That's great to hear, Ken. A Parallax front page ad about DipTrace got me thinking about upgrading from my early 90's layout software and then I put it on the back burner. A few days later I went back to make the purchase and couldn't find it anywhere. Surfing through all of the product pages and even a search turned up nothing. I had to do a google search for "Parallax DipTrace", which led to a twitter post, which led to the Parallax page. I don't know if you guys get anything from sending DipTrace customers, but I wanted to purchase it though you if I could. It was difficult, but I figured it out. So, I hope the search feature works a little better with the new site (all products available) and is somewhat forgiving of misspellings. Right now, if I search for "propeler", I get no results. Maybe a google-style "are you sure you didn't mean" would be in order.
I have to retract my previous comment about desiring a mini-proto board. The newly announced Quickstart looks perfect! And at a great price, with USB built in. Are there any plans for a similar device featuring the P2?
That's an interesting chip layout shot that Beau has posted and RossH's modified version with large areas of "UNIMPORTANT STUFF" got me to thinking...
This might be a stupid question but: Why do we have a large lump of die area taken up with ROM?
Seems to me that:
1) The Propeller is basically non-functional without an EEPROM from which to boot a user application or a serial connection to a loader.
2) Therefore all that die area consumed by ROM is basically redundant.
3) Whatever parts of that ROM is used by an application may as well be downloaded to RAM from a larger EEPROM or from the serial loader along with the user code.
4) Removing all that ROM area frees up space for more RAM which everybody is clamoring for. Looks like there might be room for another 32K
5) Surely the only ROM code required is the boot loader which perhaps is quite small. Even the Spin interpreter is not required for those using C or other languages.
[QUOTE=Heater.;997238This might be a stupid question but: Why do we have a large lump of die area taken up with ROM?[/QUOTE]
I don't think that's a stupid question at all. It seems to me that we don't really need the Spin interpreter in ROM. It could be loaded from EEPROM if it is needed. Of course, the font and math tables being in ROM frees up some hub memory for other uses.
Of course, the font and math tables being in ROM frees up some hub memory for other uses.
Indeed, but if I need any of the font or math tables or interpreter or whatever in my app then I could have them linked with the app and all downloaded to RAM at boot time. If any of those are not required then I have more RAM to play with.
... If any of those are not required then I have more RAM to play with.
One problem as Beau pointed out to me with a nice picture is the difference in SRAM/ROM size. SRAM appears to be almost 8 times bigger than mask ROM. The other problem as mentioned is apparently the squareness of the decoder - powers of 2 are easier to implement in many ways.
It seems that the only possible way to get more memory on board is to dump the per-pin ADC feature. I seriously doubt if that will happen after all the effort put forward on it.
Yes the density of ROM and RAM is vastly different.
Thing is I don't care. Looking at the image of the chip I see that the area of four ROM blocks looks like the area of one 32K RAM block. I'd rather have the RAM.
Hmmm... the squareness of the decoder is interesting. But then perhaps we have to go to 16K RAM. Still a win for me.
Yes the density of ROM and RAM is vastly different.
Thing is I don't care. Looking at the image of the chip I see that the area of four ROM blocks looks like the area of one 32K RAM block. I'd rather have the RAM.
Hmmm... the squareness of the decoder is interesting. But then perhaps we have to go to 16K RAM. Still a win for me.
Maybe the RAM blocks are highly optimized blocks from a library and ROM is a custom block so it's less dense.
Yes the density of ROM and RAM is vastly different.
Thing is I don't care.
Don't get me wrong. I certainly want more on board HUB SRAM too. However, being anchored in reality and generally outspoken (which always gets me in trouble regardless of my honestly good intentions), I have to submit to what Chip thinks is appropriate.
I'm not sure if you've ever worked closely with large FPGA development, but as the percentage of logic used in an FPGA exceeds 80%, the difficulty in getting it right goes up significantly (this may be different because an ASIC is more flexible since it is not generalist). The point is, there is only so much you can do before a design gets unreasonable, and expectations must be lowered. Hope that makes sense.
David, more than likely all of the common elements like SRAM/ROM will come from an IP library this time if they're dealing with an outside vendor for the rest of the layout (mainly speculation on my part).
I think that overall, the way things are implemented in the prop II is a pretty good compromise. I would love to see a 40 bit cog with the extra RAM/program space associated with it but being able to fetch four longs during each access window will speed things up a lot as well. With that, using C becomes a realistic option if you still want to run near full speed. It also allows fairly quick access to HUB RAM. We'll still have to work around the lack of RAM within the cogs to some extent though.
It will be interesting to see how the interface with external RAM is implemented. Will it take a cog? External RAM will make a LOT of what I would like to do possible. Are there any preliminary tests on how quickly data can be shuttled in and out of the external RAM?
In the end, the prop II is really going to be better on all fronts I think. I might be a little cranky about how things have been implemented but you can bet that I'm buying a development system the very day that they come out!
I think the prop II is going to be great for the following reasons:
- All those pins with ADC circuitry, wow! This is an extremely powerful capability.
- 1080i display and much better NTSC/VGA (probably using external RAM)
- All the project boards/protoboards will come with extra RAM and it won't be a big deal to use it (esp. with Catalina)
- Built in SD card loading
- 128K RAM is plenty for me for microcontroller purposes
- Should be powerful enough to have some objects that allow it to function as a USB device
I'm not looking for something to do everything; I'm pleased that parallax is going to do something that does more than what I want right now and something that is unique.
- All of our memories (Total of 4 different memories) are our own custom layout and comparable in size based on TSMC's 6T SRAM cell.
- The ROM's will always be smaller than the RAM because a ROM requires only 1 transistor where a basic 6T SRAM requires 6 transistors.
- There are specialized RAM's located within the COG GUTS:
---The COGRAM require 8 additional transistors to the 6T SRAM core totalling 14 transistors.
---The DUALPORT RAM requires 8 Transistors and is a slight variant of the 6T SRAM
Comments
I started with Stamps because they were easy to program and had the N&V columns to provide inspiration as well as the hows & whys to everything. I switched to the prop because of the need for more programming space (and the lower cost was a bonus). Since then I have learned how to use additional cogs which is also a huge step forward for the things that I do. The Prop I does everything I can imagine I need right now, but I would like to see some different proto boards. Right now all that are available are the almost-all-in-one boards that include KVM, two regulators and servo headers. I would like to see a slim proto board that just provides power, access to all of the I/O's and either a Prop Stick header or USB. I can fab my own boards, but my skills are limited to DIP (which the PII evidently won't be available in) and with the PI it ends up being about the same overall board size. I would gladly pay the same $20-25 for the same proto boards, but with less "stuff" on it. They would be so much easier to fit into my projects from a size standpoint.
Also, I considered myself an advanced beginner after using Stamps for a while, but still the transition to Prop has had its moments. I wish there were a N&V type column for the Prop & PropII (maybe not feasible due to complexity) and more Parallax written code for OBEX. I appreciate everyone who has submitted code to OBEX, but sometimes I feel like I'm reading Wikipedia. Sure the info is there, but you don't really know how valid it is, or if it has been superseded several times since then and in a lot of cases the documentation is bare bones.
Benj
A basic browser and e-mail program would not necessarily require a full GUI, so I am sure the Prop II could handle that. There were some very good menu/graphical front ends for CPM and dos that could provide most of what Windows/OS10/Linux provides now. One area I feel the prop ( I or II ) would be a great fit is in the area of home automation. The energy savings would pay for the prop system in short order, and having a basic browser and e-mail as well would be icing on the cake.
Maybe the Prop III can use this technology to be a 3D Prop:
http://news.yahoo.com/s/ap/20110504/ap_on_hi_te/us_tec_intel_faster_chips
More room for more memory and more COG's.....
Benj, would like to make sure you've seen these N&V columns for the Propeller:
http://www.parallax.com/Resources/NutsVoltsColumns/TheSpinZone/tabid/781/Default.aspx
Ken Gracey
Couldn't agree more. Careful design, small routines debugged individually, and careful integration makes for simple debugging.
Bengj
Jon has been writing articles in Nuts n' Volts since 2006:
http://www.parallax.com/Resources/NutsVoltsColumns/TheSpinZone/tabid/781/Default.aspx
Edit: Ken beat me by a few minutes
Andy, how can you say such things!!! That sounds like backsliding or possibly even blasphemy to me ;-) I find myself running out of pins far more often than using all the memory or cogs available. Seriously though also have several projects that used half or fewer of the pins and cogs available so a 28 pin 4 cog prop would have been nice. Making it faster is great, but keep the ram at 32K or more.
I have yet to do something that left me any pins, and I am always running out of cogs, though I almost never use more than half of hub mem.
In any case, I wish that once the chip is made Parallax will take a high quality picture of the die and make a big poster out of it for sale. I'd buy one.
The name for this is called "bottom-up" programming. It's the way FORTH forces you to work and why Prof_Braino has accomplished so much. And it's what every CS course has taught you not to do for about the last 40 years.
No, I actually had not seen those articles. I had looked for N&V again just prior to to writing my previous comments and couldn't find it. Now that you point out the location, it seems all too obvious. Thank you.
Forth afficianados actually use a combination of top-down and bottom-up development!
It's not a surprise that these files are hard to fine. To be totally honest, the underlying technology of the Parallax web site is very weak with a .Net overlying tool known as DNN. Our marketing department is preparing a massive redesign that will put us into a better tool suite. Drupal is the likely platform under Linux OS. We'll start this discussion pretty quickly, but since we're so close on the heels of Parallax Semiconductor's release we will give them a break for a couple more days. Pushing the issue today would be a mutiny situation if we were on a boat. Your comment just got me thinking. . .
Ken Gracey
Actually, Sal writtens the code, I just write about the code. And while CS courses are evolving, they did not exactly say NOT to do what we do....
The process includes Sal writing the low level drivers and implementation, and a discussion on how a less techinacal user (me) would use the fucntions. Iterative top-down and bottom-up development, as Leon stated. This in some ways related to the concept of "test-based requirements". (Modified as we have 11 man hours between two resources per week)
As an ASQ certified software engineer, I am familliar with development process in both regulated (aviation, medical) industries and non regulated industries (almost everything else). The degree of success in regulated industries is dirctly related to the degree of conformance to a defined and controled development process, which includes top-down (from management) and bottom up (from engineering) and feedback from each to the other. The degree of success in unregulated industries (that do NOT a solid process) is related primarily to dumb luck. No offence to anybody, I have only worked with a few dozen non-regulated outfits, my experience is limited.
Parallax is in the minority of companies that appears to have mastered top down, bottom up, and feedback into their operation, which I appreciate. Whether this was by intent or evolved from the combination of individuals and talents is unknown to me. But good process makes the world a better place, and I support it where I find evidence of it.
FORTH tends to highlight that its hard to succede with poor process, and hard to fail with good process. With me at least, other environments are a Smile shoot, due to functions that happen "automagically" beyond my control and understand (which is entirely a problem of my ignorance, but still a problem).
If I may make a prediction: From the user prespective, the prop 2 will likely be another example where sound design leads to success, and inappropriate design leads to head scratching.
[/rant]
That's great to hear, Ken. A Parallax front page ad about DipTrace got me thinking about upgrading from my early 90's layout software and then I put it on the back burner. A few days later I went back to make the purchase and couldn't find it anywhere. Surfing through all of the product pages and even a search turned up nothing. I had to do a google search for "Parallax DipTrace", which led to a twitter post, which led to the Parallax page. I don't know if you guys get anything from sending DipTrace customers, but I wanted to purchase it though you if I could. It was difficult, but I figured it out. So, I hope the search feature works a little better with the new site (all products available) and is somewhat forgiving of misspellings. Right now, if I search for "propeler", I get no results. Maybe a google-style "are you sure you didn't mean" would be in order.
I have to retract my previous comment about desiring a mini-proto board. The newly announced Quickstart looks perfect! And at a great price, with USB built in. Are there any plans for a similar device featuring the P2?
This might be a stupid question but: Why do we have a large lump of die area taken up with ROM?
Seems to me that:
1) The Propeller is basically non-functional without an EEPROM from which to boot a user application or a serial connection to a loader.
2) Therefore all that die area consumed by ROM is basically redundant.
3) Whatever parts of that ROM is used by an application may as well be downloaded to RAM from a larger EEPROM or from the serial loader along with the user code.
4) Removing all that ROM area frees up space for more RAM which everybody is clamoring for. Looks like there might be room for another 32K
5) Surely the only ROM code required is the boot loader which perhaps is quite small. Even the Spin interpreter is not required for those using C or other languages.
I don't think that's a stupid question at all. It seems to me that we don't really need the Spin interpreter in ROM. It could be loaded from EEPROM if it is needed. Of course, the font and math tables being in ROM frees up some hub memory for other uses.
Indeed, but if I need any of the font or math tables or interpreter or whatever in my app then I could have them linked with the app and all downloaded to RAM at boot time. If any of those are not required then I have more RAM to play with.
Seems like a win to me.
I would much rather have another 32KB of RAM than 32KB of ROM...
The boot loader could simply look for an SPI Flash chip, load the first say 64KB, start cog0 with the first 2K...
So would I but I doubt it's an even trade. I suspect ROM takes up far less space than RAM.
I'm sure that bit for bit it does. But looking at the diagram post by Beau here http://forums.parallax.com/showthread.php?131434-Prop-II-Too-little-too-late&p=996813&viewfull=1#post996813 we see 4 blocks of MEMROM that look like they have a total area about equal to one 32K block of MEMRAM.
So if those 4 ROM blocks were reduced to one tiny block with the loader in it we might get space for almost 32K RAM. Not bad.
Yes, 32k of extra RAM would be nice!
It seems that the only possible way to get more memory on board is to dump the per-pin ADC feature. I seriously doubt if that will happen after all the effort put forward on it.
Yes the density of ROM and RAM is vastly different.
Thing is I don't care. Looking at the image of the chip I see that the area of four ROM blocks looks like the area of one 32K RAM block. I'd rather have the RAM.
Hmmm... the squareness of the decoder is interesting. But then perhaps we have to go to 16K RAM. Still a win for me.
Maybe the RAM blocks are highly optimized blocks from a library and ROM is a custom block so it's less dense.
I'm not sure if you've ever worked closely with large FPGA development, but as the percentage of logic used in an FPGA exceeds 80%, the difficulty in getting it right goes up significantly (this may be different because an ASIC is more flexible since it is not generalist). The point is, there is only so much you can do before a design gets unreasonable, and expectations must be lowered. Hope that makes sense.
David, more than likely all of the common elements like SRAM/ROM will come from an IP library this time if they're dealing with an outside vendor for the rest of the layout (mainly speculation on my part).
It will be interesting to see how the interface with external RAM is implemented. Will it take a cog? External RAM will make a LOT of what I would like to do possible. Are there any preliminary tests on how quickly data can be shuttled in and out of the external RAM?
In the end, the prop II is really going to be better on all fronts I think. I might be a little cranky about how things have been implemented but you can bet that I'm buying a development system the very day that they come out!
- All those pins with ADC circuitry, wow! This is an extremely powerful capability.
- 1080i display and much better NTSC/VGA (probably using external RAM)
- All the project boards/protoboards will come with extra RAM and it won't be a big deal to use it (esp. with Catalina)
- Built in SD card loading
- 128K RAM is plenty for me for microcontroller purposes
- Should be powerful enough to have some objects that allow it to function as a USB device
I'm not looking for something to do everything; I'm pleased that parallax is going to do something that does more than what I want right now and something that is unique.
- Chip has BIG plans for the ROM.
- All of our memories (Total of 4 different memories) are our own custom layout and comparable in size based on TSMC's 6T SRAM cell.
- The ROM's will always be smaller than the RAM because a ROM requires only 1 transistor where a basic 6T SRAM requires 6 transistors.
- There are specialized RAM's located within the COG GUTS:
---The COGRAM require 8 additional transistors to the 6T SRAM core totalling 14 transistors.
---The DUALPORT RAM requires 8 Transistors and is a slight variant of the 6T SRAM