Specification, wish list and time frame for Propeller II device
woodrowg
Posts: 17
I noticed a number of recent posts making reference to a 'Prop II' or 'Propeller II' device. Is this a real development effort? If so, what is time frame for introduction of the 2nd generation part? Have you published a list/description of design goals and/or proposed enhancements to the original Propeller part?
Is it too late to submit ideas for wish list?
thanks
Is it too late to submit ideas for wish list?
thanks
Comments
Thank you!
27 pages, happy reading
wg
I can't speak for Parallax, but I suspect they will always listen to well thought out ideas that haven't been discussed before. The time for a "wish list" though is probably well past.
In terms of a formal specification, there is no public one and it's been made clear that there is no commitment to further public information until the development is done. There are little comments from Chip and others from time to time that suggest possible features or possible implementation of features, but that's all.
Post Edited (Mike Green) : 3/10/2008 11:12:39 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
With all due respect, I was criticizing neither your marketing nor your engineering efforts. I wanted to find out if the next version of the part is still vaporware or if it is scheduled for release in 2008? I suspect that question would be answered by the bottom line department.
The features I would like to see, I believe could be implemented with as few as two or three additional I/O pins and some unknown allocation or expansion of core (HUB) ROM or microcode space.
Adding more COG's to the part, one suspects, should be a straightforward tiling exercise, with attendant yield implications. My suggestion points toward augmentation of the Hub architecture.
wg
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
jazzed·... about·living in·http://en.wikipedia.org/wiki/Silicon_Valley
Traffic is slow at times, but Parallax orders·always get here fast 8)
The intent appears to be - 16 Cogs, 64 I/O, 256KB RAM, 128KB ROM, faster execution, fewer clock cycles per instruction, some new PASM instructions, improved Cog-Hub interfacing. Cogs to remain 496 x 32-bit. 1V8 core with 3V3 I/O - All discussed in more details in various other threads, particularly there's a summary on the last page of the thread Clemens posted a link to.
Any conceivable architecture can be embellished, always with tradeoffs for cost vs market potential. Who could (or did) predict the real market for the 8051 in the early days?
I am not invested in, nor conversant with the critical cost/benefit analysis this design has endured, so I conceive enhancements with impunity.
wg
Please read the 27 page thread mentioned above which includes a table on the last page listing the additional features in the Prop II as well as the dates in the thread where these were mentioned.
You might also read the relatively short essay on the history of the Propeller and you should get some idea of why the Prop II is not vaporware. As an engineering driven product, the delivery date will be determined more by technical issues, on how quickly and easily the device comes together, whether there are any unforseen production glitches, etc.
Any suggestion involving the dedicated use of I/O pins would have to be of major importance. I believe the device is planned for a standard 80 pin package with at least 78 pins already spoken for.
There is a nice summary on the Wiki here:
http://propeller.wikispaces.com/Propeller+II
"I suspect that question would be answered by the bottom line department."
Please read this document: http://www.parallax.com/Portals/0/Downloads/docs/article/WhythePropellerWorks.pdf
With all due respect:
It is extremely likely the Propeller II will be the logical extension of Propeller I, with none of the core design elements changed, meaning it will be a deterministic chip, will contain features that are of the highest utility possible, and will feature symmetry everywhere possible --particularly the COGs and their relationship to the HUB.
It's a software oriented design. That means few dedicated purpose elements, and where those are present, they are present in all COGs, to be used as the developer / designer sees fit. The scope of uses is generally as wide open as is practical.
What's gonna happen is the chip will not be released until it's absolutely as robust as is possible. Given the growing success of the Propeller I, and the expectations that come with that, there is very little reason to do otherwise.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
I see the picture coming into focus.
I have not mastered the Prop I part. I have much to learn about its possibilities. It is possible I can build what I'm dreaming with Prop I.
My use of the term 'vaporware' was not intended pejoratively. Just wondered if it (P_II) is moving towards completion. As one responder commented, 'Everything is vaporware until it is finished'.
I too was wondering about Prop II way back last year. So put together a table of info about various points brought up by Parallax designers.
Someone posted the table on their web site; forgot who now. But if you look into the 27 pages of "What would you want more of, Cogs or RAM?" near the end page(s) you'll see my summary of info. To my knowledge not too much additional has been brought up since. Everyone involved at Parallax on this chip is BUSY.
But most all of us are impatiently waiting for more info, for sure.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
Vaporware is a software or hardware product which is announced by a developer well in advance of release, but which then fails to emerge, either with or without a protracted development cycle. The term implies unwarranted optimism, or sometimes even deception; that is, it may imply that the announcer knows that product development is in too early a stage to support responsible statements about its completion date, feature set, or even feasibility.
Source[noparse]:http:[/noparse]//en.wikipedia.org/wiki/Vaporware
Personally I don't see how that term has relevance in this case. I have never been a Parallax customer in the past (hopefully soon for a prop kit) but I have followed their product line for a good many years and I don't know of anything that Parallax has ever done as a company to be considered as deceptive nor have they provided any unwarranted optimism for Prop 2. I think that most all of us are optimistic about prop 2, we just don't know the release date.
Ok Ill go back to my cave
oops!! , how could I forget the wonderful Javelin that got me started in Microcontrollers
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Aka: CosmicBob
Post Edited (Bob Lawrence (VE1RLL)) : 3/12/2008 4:01:18 AM GMT
In this case, it's particularly strange because everything about the current Prop is directly applicable to the future Prop so all the time spent "jumping up and down" about what you don't have would be best spent expanding knowledge about what you DO have....
Just my own observation....
Not having register-indirect opcodes is a particular pain in many cases. To update an array in Cog memory is often convoluted, uses a considerable amount of code, slows execution, and needs more design effort. How much easier it would be with register-indirect is I think clear to many.
Is there any commitment to even consider register-indirect opcodes ?
Didn't see any reference to this on the prop II list.
Is there room for new opcodes ? ... set is packed.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
jazzed·... about·living in·http://en.wikipedia.org/wiki/Silicon_Valley
Traffic is slow at times, but Parallax orders·always get here fast 8)
I can only see four possibilities without changing the Cog in a major way from what it is now and I don't think any of us would want that -
* Extending the HUBOP instruction. Presumably this will be done to support any block-reads, but there's not a lot of scope for real flexibility in terms of spare bits.
* Extending RET. The <dst> field isn't used so bits there could be used to enhance the instruction but would result in only a limited number of destination registers accessible for that purpose.
* Extending NOP. There's a full 63 extra opcodes which could be added with full 9-bit <dst> and <src> registers and usual WC, WZ, NR, and # bits allowed even though they could not be made conditional. That could mess some existing code up, although my money would be on 'fake NOPs' being number constants with condition code and msb's all cleared.
* Adding a 'prefix' instruction, as with Z80/80x86 to change the operation of the subsequent instruction. An enhanced RET could be useful there with enough bit fields to say if the next instruction's <dst> and/or <src> were indirect or direct, and whether <dst> and/or <src> should be pre/post incremented/decremented or not.
However it's done, determinism shouldn't generally be affected, although extra clock-cycles will almost certainly be needed to implement something complex with <dst> and <src> indirection, pre-inc and post-inc.
Others might point to a lack of other video capabilities, but it was never AFAIK ever intended to be a comprehensive 'Graphics Processor'.
One assumes that as long as Parallax remains a viable company, the Propeller product line will either evolve, or will cease to exist.
To Paul - I don't know that anyone is jumping up and down about anything under discussion here. That was not my frame of mind when I opened the thread. I wanted to find out if there was any announcement about availabilty or revised time frame for introduction of the Prop II part. It looks to me that question has been answered and essentially beat to death. If the part is nearing completion, there's not much point proposing or criticizing wish list enhancements. A number of people posted serious suggestions for enhancements months or years ago. Lets hope that some or all those suggestions received serious consideration.
As one contemplates use of a new microprocessor architecture, there are potholes and minefields all over the place that must be avoided. The Propeller is a unique architecture and as such it poses unique possibilities and problems. Some of the problems are evident after examination of the block diagram and the instruction set. Due to the richness (complexity?) of the architecture, it is of course possible that work arounds can be devised to deal with some of the problems.
If I may add one last opinion, adding more COG's and more memory to each COG will certainly be a good thing and should alleviate some bottlenecks. These changes seem like more or less predictable scaling evolutions typical of successful microprocessor designs. But it seems there were/are some other enhancements (hopefully feasible) that could open up a much wider range of design possibilities.
Unless anyone from Parallax wants to make a bold statement here, I think there may be no point to
continue this thread. After Prop II is introduced, we can all climb back in the ring and start 'jumping up and down' all over again. Till then, I think I'll keep my powder dry and see if I can manage to get where I'm trying to go within Prop I capabilities/possibilities.
Thanks to all responders.
Are you talking about video timing and control? Please define PAL CVBS?
IF it is what I suspect, this criticism would be quite specific to your application.
Is that not a rather obscure flaw? Are there not others, more obvious? What prevents or complicates, generation of this (these) signals?
An alternative to universal register-indirect addressing (which is overkill, IMO) might be to use the shadow registers that accompany the four read-only SFRs (PAR, CNT, INA, and INB) as index registers. These would map to content registers at $1EC-$1EF and would be initialized on a COGNEW with those registers' addresses. Any non-immediate operation on $1EC as a source address, for example, would actually use the address in PAR's shadow as the source address and fetch from that location. Any operation on $1EC as a destination address would use the address in PAR's shadow as the destination address. Likewise for the other three register pairs.
Now you can see the reason for preloading the shadow registers with the addresses of their content registers. By doing this and never disturbing the shadow registers, reads and writes using the content registers will proceed as they do now, as if the index registers did not exist.
Of course, timing is still an issue. Reads could be done without an additional pipeline step by having the actual contents of the content registers act as a cache to be kept current by separate hardware. Writes would entail an extra cycle, though, to copy those contents to the addressed memory location.
Anyway, just a thought...
-Phil
Post Edited (Phil Pilgrim (PhiPi)) : 3/14/2008 6:53:20 PM GMT
I couldn't personally give a definition of PAL CVBS beyond 50Hz, 625 lines, etc, etc, but I've never seen an entirely satisfactory display on a PAL compatible TV. Basically, I don't believe I could produce a propeller-based product which relied on the Propeller TV output generation for use with PAL TV's without facing a high risk that the customer would return it as not fit for purpose.
Over the air NTSC will go away, and gradually composite video will too, being replaced probably by YC, DVI, HDMI and VGA.
So I wouldn't suggest putting a lot of effort into dying standards.
No, I don't expect composite video to die anytime soon, just because broadcasters no longer use it. It has too many other applications.
-Phil
Remember that ret is just a jumpret.
There are two ways of making no-ops for most instructions (this does not apply to rdlong, wrlong etc and wait instructions). You can either set all the condition bits to 0 or you can set the WC, WZ and WR flags to 0. I think that how the rd, wr and wait instructions work is enough to make them not do this although it could be useful.
While interesting I think that a prefix instruction will cause more harm than good. You can do this to some extent though by using movs and movd though. Like I said before RET isn't actually an instruction. It gets turned into a jmret by the compiler.
To sum up, I think that there will be very few changes to the instruction set or cog. I think that we will see the grayed out instructions in the data sheet, updates to the timers/counters and block-reads from the hub. Anything else would require a fairly major redesign which I don't think that they want to do.