It's always refreshing to hear that there really are people who plan ahead several years, let alone five years or more for a product line as important as the Propeller is to Parallax.
One small technical question about what you've said ... What's the 8-contiguous-long accesses per hub read/write?
Chip,
Thanks for that ..... is it possible to continue the 'Update Teasers' similar to that just outlined ?(Obviously we are only too aware how busy you are) but if you did manage a few minutes every now and then it would be much appreciated by all.
Echo that Question by Mike Green and add a further - 'What is the proposed Clock Speed, Internal RC Oscillator and ultimately execution speed ?" .... I know ..... .... I know ..... 'STOP ASKING' - I hear you say
Regards,
Quattro
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ 'Necessity is the mother of invention'
Mike Green said...
It's always refreshing to hear that there really are people who plan ahead several years, let alone five years or more for a product line as important as the Propeller is to Parallax.
One small technical question about what you've said ... What's the 8-contiguous-long accesses per hub read/write?
With 16 cogs and a full-speed hub (not half-speed, like we have now), each cog will get hub access once every 16 clocks (16 instructions). To increase the main memory bandwidth, we will likely put 8 special long registers into each cog at maybe $1E8-$1EF which are read/write data conduits. This way, in your hub turn, you can read or write all 8 of these longs if you want. This will help large-model code and video apps, too. You can 'breathe' 8 times the main memory·than a RDLONG/WRLONG instruction would allow.
QuattroRS4 said...
Chip,
Thanks for that ..... is it possible to continue the 'Update Teasers' similar to that just outlined ?(Obviously we are only too aware how busy you are) but if you did manage a few minutes every now and then it would be much appreciated by all.
Echo that Question by Mike Green and add a further - 'What is the proposed Clock Speed, Internal RC Oscillator and ultimately execution speed ?" .... I know ..... .... I know ..... 'STOP ASKING' - I hear you say
Regards,
Quattro
Well, the internal RC speed will probably be 20MHz, or so, but the PLL-driven execution speed will hopefully be 160MHz. That will be 2,560 MIPS per chip.
And I'm happy to answer questions, I just haven't been on here too much lately. I'm really grateful to all you guys who've been·answering everyone's questions. We owe you a lot!
Chip,
Thanks again .... I was hoping you would say that ... I know it (160Mhz and 2,560MIPS) was banded about earlier ...now confirmed ....got to love that ...
Quattro
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ 'Necessity is the mother of invention'
I suspect that there will need to be a new instruction to do the hub synchronization and to possibly supply the hub memory address like the existing instructions. If there's no way to allow an arbitrary address (perhaps divisible by 8) for the cog block, perhaps there could be a double buffer selectable using a flag register perhaps. I'm not sure how valuable that would be given the higher cog speed, but it would allow some overlap of processing with hub memory access.
I'm pretty sure we're ahead of the BASIC Stamp curve, but things are still nascent in terms of potential.
I'd like to see a Propeller Primer -- something that bridges the manual through the ed kit and demo board·to the 'breakthroughs' of this year. Which to my mind, at least, are indirect processing and self-modifying inner interpreters, eeprom·and sd access, usb port details all the way the compiler, the big memory models, and documented methods (and circuits!) in one spot. Not every method or circuit of course, but ones that everyone should know by heart. (Think: a propeller equivalent to Brody's Starting Forth).
Graham's forum index might·make a decent summary of the table of contents, but I bet a systematic approach would be helpful.
I agree on the 'nascent' and if anything regret that this community is so fixed on PropII. My (grain of salt, beginner here) take is that we've just·begun to use this·chip.
Mike Green said...
I suspect that there will need to be a new instruction to do the hub synchronization and to possibly supply the hub memory address like the existing instructions. If there's no way to allow an arbitrary address (perhaps divisible by 8) for the cog block, perhaps there could be a double buffer selectable using a flag register perhaps. I'm not sure how valuable that would be given the higher cog speed, but it would allow some overlap of processing with hub memory access.
Yes, we could do some double-buffering for writes, but not for reads, as there is a data dependency.
WOW!! I can only imagine what the Gen II will be capable of, if i had to guess, there's probably some improvements to the video and counters as well. Hawkins is right, we havent really made full use of the Gen I chip quite yet (with the exeption of a few godsent DEMO coders and the creators of course). My Twin Prop board seems a bit trivial now, though 75% routed in EWB.
So i'm also guessing this will accumulate to something like a 70-80 something pin LQFP (assuming there will be access to dir
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Definetly a E3 (Electronics Engineer Extrodinare!)
"I laugh in the face of imposible,... not because i know it all, ... but because I don't know well enough!"
256k AND 16 COGS? It looks like we got the best of both worlds!!
Two questions....·does each COG still have 512 LONG 32 bits of memory and what is new in the ROM that·beefs it up to 128k?
The cogs still have 512 longs of RAM. No nice way to increase that. With 8-long read/writes, though, and the large-model paradigm, this 512-long limit will be·less of an issue than with·the current chip.
That bigger ROM is going to be used, eventually, for sinking the entire development system into. This way, we can finally get OFF the PC for good, if we want to. I don't want us to keep wasting our time (and energy) writing perishable Windows apps. We've spent what has got to be cumulative man-years at Parallax wrestling with Windows to get what we needed, while at the same time we're chasing bizarre·bugs which routinely result from Windows patches and upgrades. It's been like building on a sandy foundation all along, and it just gets worse and worse. There's no equity in it. We're going to have to create our own land with a limited Constitutional government.·Liberty for whoever wants OFF. All on about 50 square millimeters of silicon.
Happy·Independence Day!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Post Edited (Chip Gracey (Parallax)) : 7/5/2007 6:45:43 AM GMT
I'd love some more data on how the extended RD/WR's would work; will it be something like RDLONG8X start_dest_addr, start_hubaddr?
As far as the other question about documentation... I've been working on an extensive document on the large memory model, I hope to see it published soon. I was distracted by consulting (designed a rackmount network security tool case / system integration for a client) but I will shortly have more time; I need to finish the test code for the article.
Chip Gracey (Parallax) said...
The cogs still have 512 longs of RAM. No nice way to increase that. With 8-long read/writes, though, and the large-model paradigm, this 512-long limit will be less of an issue than with the current chip.
That bigger ROM is going to be used, eventually, for sinking the entire development system into. This way, we can finally get OFF the PC for good, if we want to. I don't want us to keep wasting our time (and energy) writing perishable Windows apps. We've spent what has got to be cumulative man-years at Parallax wrestling with Windows to get what we needed, while at the same time we're chasing bizarre bugs which routinely result from Windows patches and upgrades. It's been like building on a sandy foundation all along, and it just gets worse and worse. There's no equity in it. We're going to have to create our own land with a limited Constitutional government. Liberty for whoever wants OFF. All on about 50 square millimeters of silicon.
Happy Independence Day!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ www.mikronauts.com - a new blog about microcontrollers
Is not that we do not appreciate your work with the Propeller Tool, but maybe some command line tools would have been faster and simpler to write (and you could still have your ultra-fast asm compiler in it). A listing output easily generated (for DAT parts), instead of messing with a GUI program. Just an opinion . I know, windows users "hate" and/or don't know the command line... but on un*x is the way to go
Will the command "INB" still be reserved (In next Propeller(? This new I/O will need 32 additional pins. Only little people could take an advantage from that. Therefore, I can imagine, it will not be implemented today. Again my question: what to have these I/O's only internally? This could open a pathway to communication between the local cogs. An infinite number of cogs could be connected to form an topology, transparently to the software.
ErNa said...
Will the command "INB" still be reserved? This new I/O will need 32 additional pins. Only little people could take an advantage from that. Therefore, I can imagine, it will not be implemented today. Again my question: what to have these I/O's only internally? This could open a pathway to communication between the local cogs. An infinite number of cogs could be connected to form an topology, transparently to the software.
Of course, it makes little difference if INB _is_ pinned -- you can use INA/B for inter-cog comm's anyway (just need to make sure the pins are appropriately reserved). Right?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
www.norfolkhelicopterclub.co.uk
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again ;-) BTW: I type as I'm thinking, so please don't take any offense at my writing style
Chip Gracey (Parallax) said...
Well, the internal RC speed will probably be 20MHz, or so, but the PLL-driven execution speed will hopefully be 160MHz. That will be 2,560 MIPS per chip. ······ And I'm happy to answer questions, I just haven't been on here too much lately. I'm really grateful to all you guys who've been·answering everyone's questions. We owe you a lot!
Chip, I can't believe what you've managed to squeeze into the 2nd generation prop [noparse]:)[/noparse] a whopping 2560 mips thats mega impressive and certainly should blow away any competition,
Since the Prop1·already beats any other micro already IMHO, I don't know if you know or read my CV on my web page, but I've been in the games industry for 22 years now,
And have only started in the last two years getting into the electronics side too [noparse]:)[/noparse] and I'm currently working on the PS3, and to be honest, I'd rather code the prop than PS3, let alone getting my hands on a Prop2.
It's that much fun to play with... Give me·a prop anyday. I'll be happier coding that [noparse]:)[/noparse]
All I can say is WOW, and keep up the fantastic work you guys at parallax are doing.
I didn't test inb, but I suppose, inb will do nothing just now, as oub will. At a first glance, it makes no sense do have i/o, that is not pinned out. But, if this function is easily implemented, it will make sense: communication between cogs will be transparently possible, even if the cogs are located in different chips.
That bigger ROM is going to be used, eventually, for sinking the entire development system into. This way, we can finally get OFF the PC for good, if we want to...
Happy·Independence Day!
Errrm, really?! So we'll be able (but not forced?) to code spin & PASM _within_ the Prop'?
Initially, that sound exceptional! But what about compiler updates? Surely that won't be possible, unless we go back to using the PC IDE?
I'd actually echo other's comments: we REALLY NEED the compiler as a standalone, command-line (Java?) utility. That way anyone can create an IDE with any bells & whistles they want...
Sorry, that's wandered slightly off topic, but it would enable Parallax to expend less effort on the IDE...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
www.norfolkhelicopterclub.co.uk
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again ;-) BTW: I type as I'm thinking, so please don't take any offense at my writing style
I'm not saying we can use INB now, only when TurboProp arrives (hopefully)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
www.norfolkhelicopterclub.co.uk
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again ;-) BTW: I type as I'm thinking, so please don't take any offense at my writing style
That bigger ROM is going to be used, eventually, for sinking the entire development system into. This way, we can finally get OFF the PC for good, if we want to.
Holy Smile, that is awesome!!! The Prop 2·can be turned into a stand alone computer.
Chip Gracey (Parallax) said...
That bigger ROM is going to be used, eventually, for sinking the entire development system into.
What does that mean in practice? That to develop you'll connect a keyboard, mouse. VGA monitor and an SD disk to a prop, and the ROM will present an IDE for you to program in?
Or will the compiler be in ROM, such that from a PC you can download source code to the Prop from a computer and it's compiled in situ?
In either case, will the size of an object program be limited by the amount of RAM the PROP development system needs to function/hold the source/compile?
I think what the boys (at Parallax) are aiming for is to move the IDE (or a version of - ie. - Prop ASM IDE) onboard the chip itself allowing the use of a TV or VGA and KB/Mouse and no computer. A similar idea of mine to have a Digital Fuel Injection and be able to tune on-the-fly using the prop, TV out (i have an ancient flip-out reciever in my truck that accepts baseband), keyboard and trackball to tweak constants in the program at runtime.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Definetly a E3 (Electronics Engineer Extrodinare!)
"I laugh in the face of imposible,... not because i know it all, ... but because I don't know well enough!"
Even if we can get the whole IDE into the chip, so that you can plug a monitor and keyboard directly in, you'll still be able to work exclusively from a PC/host over a serial link, if you want to. I just think that we are all going to need a computer someday that will do what we ask, and nothing more.
About using INB and OUTB for inter-cog communications on the current Propeller: there is no circuitry on the die to support that, so it won't work in the same way INA and OUTA will.
Chip Gracey (Parallax) said...
That bigger ROM is going to be used, eventually, for sinking the entire development system into.
What does that mean in practice? That to develop you'll connect a keyboard, mouse. VGA monitor and an SD disk to a prop, and the ROM will present an IDE for you to program in?
.....
I'd say you hit the nail on the head with this one. I think that is what the hole hydra project was about, incognito (my Parallax conspiracy theory [noparse]:)[/noparse] Figure out, with the architecture as it was, the most efficient way to get done what they want to eventually done.
Hardcode it in the ROM as a location to call(able), for instance, a SPI, I2C, etc... Most of these routines could be coded to fit a small space of the ROM. The compiler might also be called from a memory location... in situ... to update code... while your datalogging the universe. Wow, a compiler included with the hardware. I don't think it would get any more open source than that, huh? Kudos!
Chip, did you say how big the compiler would be (W.A.G.) of that 128k?
The boys have to save some goodies for launch, and probably the best ones too! Can ya smell what the boys are cookin?!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Definetly a E3 (Electronics Engineer Extrodinare!)
"I laugh in the face of imposible,... not because i know it all, ... but because I don't know well enough!"
Wow, that is the great! If possible I'd turn the prop 2 into a laptop seeing how that is! [noparse]:D[/noparse]
256 kb is decent too! If I get the 512 KB sram It might be even possible to make a GUI thats sort of like an old macintosh! by the time spinstudio comes out well, everything would merge! I can't wait till this comes out. It'd actually make quite a nice retro-compy!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Realize that I am really a mad scientist··· and
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
The comments and code above are proof that a million monkeys with a million propeller chips *could* write Shakespeare!
One small technical question about what you've said ... What's the 8-contiguous-long accesses per hub read/write?
Thanks for that ..... is it possible to continue the 'Update Teasers' similar to that just outlined ?(Obviously we are only too aware how busy you are) but if you did manage a few minutes every now and then it would be much appreciated by all.
Echo that Question by Mike Green and add a further - 'What is the proposed Clock Speed, Internal RC Oscillator and ultimately execution speed ?" .... I know ..... .... I know ..... 'STOP ASKING' - I hear you say
Regards,
Quattro
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Necessity is the mother of invention'
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
And I'm happy to answer questions, I just haven't been on here too much lately. I'm really grateful to all you guys who've been·answering everyone's questions. We owe you a lot!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Thanks again .... I was hoping you would say that ... I know it (160Mhz and 2,560MIPS) was banded about earlier ...now confirmed ....got to love that ...
Quattro
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Necessity is the mother of invention'
Two questions....·does each COG still have 512 LONG 32 bits of memory and what is new in the ROM that·beefs it up to 128k?
Graham's forum index might·make a decent summary of the table of contents, but I bet a systematic approach would be helpful.
I agree on the 'nascent' and if anything regret that this community is so fixed on PropII. My (grain of salt, beginner here) take is that we've just·begun to use this·chip.
Fred
·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
So i'm also guessing this will accumulate to something like a 70-80 something pin LQFP (assuming there will be access to dir
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Definetly a E3 (Electronics Engineer Extrodinare!)
"I laugh in the face of imposible,... not because i know it all, ... but because I don't know well enough!"
The cogs still have 512 longs of RAM. No nice way to increase that. With 8-long read/writes, though, and the large-model paradigm, this 512-long limit will be·less of an issue than with·the current chip.
That bigger ROM is going to be used, eventually, for sinking the entire development system into. This way, we can finally get OFF the PC for good, if we want to. I don't want us to keep wasting our time (and energy) writing perishable Windows apps. We've spent what has got to be cumulative man-years at Parallax wrestling with Windows to get what we needed, while at the same time we're chasing bizarre·bugs which routinely result from Windows patches and upgrades. It's been like building on a sandy foundation all along, and it just gets worse and worse. There's no equity in it. We're going to have to create our own land with a limited Constitutional government.·Liberty for whoever wants OFF. All on about 50 square millimeters of silicon.
Happy·Independence Day!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Post Edited (Chip Gracey (Parallax)) : 7/5/2007 6:45:43 AM GMT
I'd love some more data on how the extended RD/WR's would work; will it be something like RDLONG8X start_dest_addr, start_hubaddr?
As far as the other question about documentation... I've been working on an extensive document on the large memory model, I hope to see it published soon. I was distracted by consulting (designed a rackmount network security tool case / system integration for a client) but I will shortly have more time; I need to finish the test code for the article.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com - a new blog about microcontrollers
Is not that we do not appreciate your work with the Propeller Tool, but maybe some command line tools would have been faster and simpler to write (and you could still have your ultra-fast asm compiler in it). A listing output easily generated (for DAT parts), instead of messing with a GUI program. Just an opinion
Post Edited (ErNa) : 7/5/2007 11:04:12 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
www.norfolkhelicopterclub.co.uk
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again ;-)
BTW: I type as I'm thinking, so please don't take any offense at my writing style
Since the Prop1·already beats any other micro already IMHO, I don't know if you know or read my CV on my web page, but I've been in the games industry for 22 years now,
And have only started in the last two years getting into the electronics side too [noparse]:)[/noparse] and I'm currently working on the PS3, and to be honest, I'd rather code the prop than PS3, let alone getting my hands on a Prop2.
It's that much fun to play with... Give me·a prop anyday. I'll be happier coding that [noparse]:)[/noparse]
All I can say is WOW, and keep up the fantastic work you guys at parallax are doing.
Baggers.
Initially, that sound exceptional! But what about compiler updates? Surely that won't be possible, unless we go back to using the PC IDE?
I'd actually echo other's comments: we REALLY NEED the compiler as a standalone, command-line (Java?) utility. That way anyone can create an IDE with any bells & whistles they want...
Sorry, that's wandered slightly off topic, but it would enable Parallax to expend less effort on the IDE...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
www.norfolkhelicopterclub.co.uk
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again ;-)
BTW: I type as I'm thinking, so please don't take any offense at my writing style
I'm not saying we can use INB now, only when TurboProp arrives (hopefully)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
www.norfolkhelicopterclub.co.uk
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again ;-)
BTW: I type as I'm thinking, so please don't take any offense at my writing style
Sign me up!
The batch HUB operations are an excellent choice! IMHO, that's going to largely eliminate the HUB memory bottleneck --at least for writes.
I'm stoked.
We are in for a fun ride people.
Thanks Parallax for making computing fun again!
What does that mean in practice? That to develop you'll connect a keyboard, mouse. VGA monitor and an SD disk to a prop, and the ROM will present an IDE for you to program in?
Or will the compiler be in ROM, such that from a PC you can download source code to the Prop from a computer and it's compiled in situ?
In either case, will the size of an object program be limited by the amount of RAM the PROP development system needs to function/hold the source/compile?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Definetly a E3 (Electronics Engineer Extrodinare!)
"I laugh in the face of imposible,... not because i know it all, ... but because I don't know well enough!"
About using INB and OUTB for inter-cog communications on the current Propeller: there is no circuitry on the die to support that, so it won't work in the same way INA and OUTA will.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
I'd say you hit the nail on the head with this one. I think that is what the hole hydra project was about, incognito (my Parallax conspiracy theory [noparse]:)[/noparse] Figure out, with the architecture as it was, the most efficient way to get done what they want to eventually done.
Hardcode it in the ROM as a location to call(able), for instance, a SPI, I2C, etc... Most of these routines could be coded to fit a small space of the ROM. The compiler might also be called from a memory location... in situ... to update code... while your datalogging the universe. Wow, a compiler included with the hardware. I don't think it would get any more open source than that, huh? Kudos!
Chip, did you say how big the compiler would be (W.A.G.) of that 128k?
-Parsko
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Definetly a E3 (Electronics Engineer Extrodinare!)
"I laugh in the face of imposible,... not because i know it all, ... but because I don't know well enough!"
Roll me over, this sides done!
256 kb is decent too! If I get the 512 KB sram It might be even possible to make a GUI thats sort of like an old macintosh! by the time spinstudio comes out well, everything would merge! I can't wait till this comes out. It'd actually make quite a nice retro-compy!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Realize that I am really a mad scientist··· and
Don't forget it!
http://raydillon.com/Images/Illustration/GameArt/WildIsle/WildIsle-Ink-ScientistClose.jpg
·