Good post r.daneel. It puts your, and likely many others, position in context. You should definitely bookmark/save it for later re-use.
Parallax is one of the few specialists (The only one to roll an architectural design I'd say) in the education market and Ken's response shows that that counts. Ken didn't say they are committed to an actual Dual-In-line-Package (DIP) but I suspect that he is absolutely costing it up to compare with the adaptor based alternatives.
One benefit of going the adaptor route is the upper pins of port A can be freed of the boot functions that would otherwise be required of a DIP.
Ken didn't say they are committed to an actual Dual-In-line-Package (DIP) but I suspect that he is absolutely costing it up to compare with the adaptor based alternatives.
One benefit of going the adaptor route is the upper pins of port A can be freed of the boot functions that would otherwise be required of a DIP.
I presume by 'adaptor' you mean (compact) PCB module ?
That is the most likely offering, and as well as the small FTDI Module example I gave above at $5.95, there is this one http://parallax.com/product/32810 = $19.80ea / 5+
- and that for a large PCB area ( >> DIP40).
Then main challenge will be driving the labour out of a DIP 40 module, and most of that is in the pin-mounting.
A SMD-mountable PCB module with pins included, but not soldered, is one way to manage that.
If doing DIP40 as one subset pin-out, making that Prop1 pin-mapped would allow inter-mixing of the devices in most use cases.
It's been awhile since I have been into the forums. What is the latest on the release date (when and where we can buy the next generation Propeller chips)?
It's been awhile since I have been into the forums. What is the latest on the release date (when and where we can buy the next generation Propeller chips)?
Thanks,
Tim
Not sure about the chips but there was a prediction that there would be a new FPGA image by Christmas this year. In any case, we're all just keeping busy on other projects and letting Chip work his magic.
I keep imagining that the new P2, when it arrives, will be something totally unexpected. I see Chip going back to the drawing board and making something at least slightly different from what we're expecting. Simpler maybe but more powerful. Should be interesting when it comes.
Hello, I would like to ask a question, in regards to the programming.
I have found that Spin, combined with assembly, makes programming
problematic. I can follow the flow with Spin programming, and, given time,
I think I could do well with Spin. The P2 will have to have programming
language that is different, with the more power and processing. Is there
any way to keep the original spin, and add in different functions?
If there are some assembly commands that are not being used, then
focus them on commands that will be of benefit to the P2, if that is an issue.
Thanks.
I have used many languages in my time and Spin is about one of the simplest. The assembly languages is likewise one of the simplest to use I have ever seen. The integration of Spin and PASM in the same object source files makes for a very simple programming environment.
I suspect Spin may not be a wise choice for large programs where it's very simplicity may be a disadvantage.
I don't think there is any point in making Spin overly complex though. That world destroy is easy entry for beginners. We will have other languages on the P2 to cater for those who think Spin is insufficient. C and C++ for example.
Having said that I'm sure Spin will gain some P2 specific features as it must.
What features are there that you would like to see added to Spin? If people say what they need specifically there is more chance that it will happen sometime.
I have used many languages in my time and Spin is about one of the simplest. The assembly languages is likewise one of the simplest to use I have ever seen. The integration of Spin and PASM in the same object source files makes for a very simple programming environment.
I'm with you, Heater. A few weeks ago I wanted to port my flame algorithm from Spin to the Arduino (for a friend) and nearly ended up tearing my hair out (thankfully, I have a lot of it).
I don't think there is any point in making Spin overly complex though
I doubt Chip would do that; he created Spin to be a simple and elegant language that allowed any person to exploit the capabilities of the Propeller. Would it be nice to have Spin-to-PASM compiler (LMM, perhaps)? Yes -- but that's not stopping anyone from developing a wide range of very serious applications in Spin.
Ah, now I see, programming requires lots of hair. Sadly I'm running out of that commodity
The P2 perhaps changes the Propeller landscape language wise.
It does not have a built in Spin byte code interpreter. It does not require any Spin byte codes to boot the thing up. That puts all possible languages on the same footing.
I have no idea where I'm going with that thought but I can speculate that C/C++ starts to take center stage,
Clearly there is no point in adding complexity to Spin with features when other available languages already have that complexity.
Will the prop 2 run on 3.3 or 1.8 volts? This is something i haven't been able to find a consensus on in the various spec releases
That may be because it will use both
AFAIK the VccIO will be up to 3.3V standard, and the Core Vcc is 1.8V for the process used.
I think VccIO will be banked, so some ports can run at 1,8V if that is a requirement.
There is no on-chip regulator, so an external regulator will be needed
(probably switching for highest MHz:mA targets to keep the thermal issues manageable.)
.
I have found that Spin, combined with assembly, makes programming problematic.
This has already been addressed, but I can't resist the chance to suggest to mklrobo (and anyone else in a similar fix) that what may seem problematic right now might become one of the sweetest pairings they'll ever encounter in the field of embedded control. It is no stretch to say that I love the combination.
It almost makes me sad that the P2 is destined to stray from this paradigm since Spin is not built in.
It almost makes me sad that the P2 is destined to stray from this paradigm since Spin is not built in.
Parallax has stated that they will support Spin on the P2, so there is no reason to be sad. The P1 Spin/PASM paradigm will continue on the P2. It just won't have the Spin VM built into its ROM like P1 does.
Now the thing that makes me sad is that it's been a month since Christmas, and we haven't gotten a P2 FPGA image yet.
Parallax has stated that they will support Spin on the P2, so there is no reason to be sad. The P1 Spin/PASM paradigm will continue on the P2. It just won't have the Spin VM built into its ROM like P1 does.
Now the thing that makes me sad is that it's been a month since Christmas, and we haven't gotten a P2 FPGA image yet.
The fact that the Spin interpreter won't be built in means you can use your own interpreter that doesn't include commands that aren't commonly used, such as lookup and friends, and leaving space for new, custom instructions. A smart enough compiler could build this custom interpreter itself.
Hopefully the P2 instruction set will make the VM more compact and the new P2 instructions can fit while retaining all of the old instructions. The code that supports the Spin bytecodes in the P1 VM is very tangled code. It would be hard to open up any space in the VM unless an entire group of bytecodes is not needed. Of course there are certain bytecodes that require a significant amount of space by themselves, such as the square root instruction. If that is not used it will save several instructions.
I played around with the idea of creating a custom P1 Spin VM that supported only the bytecodes used by a program. I wrote a utility that would scan through a binary file to determine which bytecodes were used. It would then assemble a VM by extracting only the code that was needed for each bytecode that was used. Using a custom unrolled VM I was able to execute Spin code faster than the ROM VM would. For some special cases the custom unrolled VM ran twice as fast as the ROM VM.
The problem is that many programs will use more bytecodes than an custom unrolled VM can fit in 2K of cog memory. One solution is to extend the VM into hub RAM for bytecodes that are rarely used. I did that with the October 2013 P2 FPGA image about a year ago. It's hard to believe that it's been so long since we've had a fully documented P2 FPGA image.
Bytecode binary compatibility isn't important is it? I don't think I've seen a single posting/article/repository with a compiled Spin program in it. They're all in source form. Source compatibility is all that really matters.
And even then, Prop2 programs are quickly going to evolve to use it's features and speed, Spin can be extended at the source level also.
Bytecode binary compatibility isn't important is it? I don't think I've seen a single posting/article/repository with a compiled Spin program in it. They're all in source form. Source compatibility is all that really matters.
And even then, Prop2 programs are quickly going to evolve to use it's features and speed, Spin can be extended at the source level also.
Exactly. A compiler could optimize the interpreter and change around opcodes specifically for the program that will be using the interpreter. Certain programmers often don't use certain instructions, so they don't have to be included. I don't remember ever using a single group 4 opcode (lookup and friends) in anything I've ever written. Group 9 (spr, waitvid) could also be excluded for most applications. These opcodes could be reused for more language features, such as ones like those in block 1 except that they pop method and object numbers off of the stack, to allow easy call by reference. In case there aren't enough opcodes, one group could be for extended, 2 byte, rarely-used opcodes.
However, this would disallow dynamic run-time Spin linking, which actually looks fairly easy on the P1, although I've never actually attempted it because current spin compilers don't understand it and I don't know of anyone else who has attempted it either.
It's also possible to compile Spin into LMM PASM, and not even use a Spin VM. That's essentially what happens when using spin2cpp along with PropGCC. Spin programs are compiles into LMM PASM. The drawback is that the resulting binary code is about twice as big as bytecodes, but it run much faster. Since P2 will have 512K of hub RAM a larger program size may not be a problem.
It's also possible to compile Spin into LMM PASM, and not even use a Spin VM. That's essentially what happens when using spin2cpp along with PropGCC. Spin programs are compiles into LMM PASM. The drawback is that the resulting binary code is about twice as big as bytecodes, but it run much faster. Since P2 will have 512K of hub RAM a larger program size may not be a problem.
I once tried to suggest that spin2cpp become the official implementation of Spin for the P2. In fact, code translated by spin2cpp was the first Spin code to run on the old P2 emulation. Not surprisingly, my suggestion was not received enthusiastically. In fact, I never got a reply to my email. :-)
So, this thread really happened almost a full year ago? Wow, or should I say, wow....
I know the mantra is that Chip is a busy bee, and we should want nothing to interrupt him in his cone of silence, because, well, work!!!
I have to say however, that if he had time to do an interview, is it really asking too much to get a brief update out to to the fanat^h^h^h^hfaithful?
There seem to be a lot of people doing work on their dime for Parrallax and the 'community' at large, aside from themselves.
Its obvious Parallax experimented a bit too much with their outreach and community input on the initial P2.
So the desire to learn from that experience, and cut way back on this attempt is a natural.
But it seems like its overshot its mark, and is probably driving at least some away to solutions that are either available, or coming to fruition elsewhere.
I'd suggest that Parallax really should pull together Ken and Chip over lunch, which they both I'm sure do at least occasionally, and answer some basic Big Picture questions and get some actual detail on current status of some Top 5 features.
This could be 3-4 paragraphs in a Post here, and maybe 50% of the idle, and wasted speculation time would end.
It would also probably give some reassurance that there really is forward movement occurring.
Part of the reason I was initially gung-ho on the 16 core versions was because IIRC, Chip said that this should be somewhat easier as it was an expansion on an earlier proven design. Then the HubExec got argued quite a bit, and added.
So if I had a question I could ask, it would be what feature,/issue is the biggest pain point, and is it worth the delay ultimately?
On the P1, Spin was something that was sold as a major selling point, but which was always received by the majority as a negative. People can argue it til the cows come home, however almost every thread has someone bemoaning that.
Liekwise, is there something that is a timesink or delay on the P2, or the oft-promised image release that is going to ultimately be something that wasn't worth the delay/hassle/$$spent?
Considering where I thought we were near the end of last year, could it be the whole Smart Pins thing?
Note, I do Project Management as well, and I would hate to have to do it with public exposure. However many, many companies do, as its required to keep their partners up to speed and informed, as well as for marketing reasons.
This thread is about the new chip we are going to build in the 180nm process.
About code compatibility with Prop1:
Is this absolutely mandatory? I ask because, having learned a lot of things making the Prop2, we can augment the Prop1-type cogs in a few simple ways to quadruple hub memory bandwidth, which affords way better video and LMM operation. Improved video, alone, is going to break code compatibility. Also, we'll need to support DAC outputs and access pipelined math circuits. I don't see how we can have 100% code compatibility without walking on egg shells.
We can easily make an improved cog that is going to be very familiar looking, though.
The big picture:
I've been hammering out a new, minimalist design that should be along the lines of a Prop1 in cog complexity, with a few things taken away and a few things added.
First, hub memory will be comprised of 16 instances of 32768 x 8 RAM for 512KB. This is going to yield a hub data path of 128 bits. Only the RAMs that are needed on a given cycle will be activated, saving power.
Though the cog memory map is still 512x32, cog RAM will be physically organized as 128 x 128, so we can read or write four contiguous registers with RDQUAD/WRQUAD instructions. This is way better than what we had on the Prop2, because, rather than just affecting mappable overlay registers, these transfers are into and out of the actual cog registers, themselves. These 128 bit paths don't take too much mux'ing and they keep the power down to reasonable levels. Interfaces to any peripherals can take advantage of them, too. This also gives cogs running at 200MHz (100 MIPS) a hub memory bandwidth of 200MB/s, which is enough to do any kind of VGA that we have the internal hub memory to support, at any color depth (up to 24bpp) - without any hub slot reallocation scheme needed to favor particular cogs. LMM greatly benefits from this, too.
VGA is going to simply be a use case of a shifter that drives four DAC outputs to a set of fixed pins attached to each cog. The four channels from highest to lowest can be used as: R, G, B, HSYNC. In some modes, the shifter handles data in ways that is obviously for video, but, otherwise, it's a generic circuit that can simultaneously update four DACs with unique 8-bit data. You can also write the DACs directly in software, with 8 bits of dither, to realize something like 16-bit DACs.
What complicated the heck out of the P2 video was all the accommodation to support fancy color-space conversion for TV's. I plan to get rid of all that, as it's very costly, being full of staged multipliers and CORDIC rotators. Every flat screen TV I've seen has a VGA connector, and it is tidier than component connections, anyway. You can still drive a TV using the DAC shifter to make a 1-wire composite signal, but color modulation is no longer part of the package. This is a little sad, in that a one-wire color signal was nice, but you wouldn't want to have to read small text on a TV, anyway, so it was kind of a novelty.
There are some Prop1 instructions that I've never used, like CMPSX. Maybe we could cull a few of those for other things. Any ideas on getting rid of any of those instructions?
Do we really need to support words any more, with RDWORD/WRWORD? Bytes, I think, are always needed, but I don't think I've ever used words for anything before. Convention says we need them, but do we, really?
Here is the pin-out, as posted earlier in another thread:
This is going to take several weeks, probably, to develop. I'll post FPGA images for the DE0-Nano and DE2-115 boards as soon as we have something working.
I'd suggest that Parallax really should pull together Ken and Chip over lunch, which they both I'm sure do at least occasionally, and answer some basic Big Picture questions and get some actual detail on current status of some Top 5 features.
We agree that it's time to publish an update and plan on doing so shortly. I've got a presentation this evening and expect to be able to work with Chip to write an update over the next week.
We always have much to talk about, but lately I've been keeping the calls to a few minutes so I'm not a distraction to his efforts.
While we wait for a more informative update, I'll provide a quick one right now. Yesterday Chip was finalizing his input to Daniel on the Parallax Propeller 1-2-3 FPGA board. We had a few disconnected pins, the need for a ground here and there, and a couple of small power supply adjustments. These changes have all been identified and are being wrapped into the final board which Chip needs to finish the Verilog properly. Daniel tells me the layout changes can be completed within a day and I've checked that we have all the components for fabrication, so this shouldn't take too long. The manual layout is well underway with Treehouse Designs and we have regular weekly meetings with them where we do the basic project management stuff - reviewing scope, progress, budget, delays, etc and make adjustments to the plan. Chip needed this kind of project management . Chip says he's immersing himself into the Verilog, and that's the part we need detailed from him. There's an overall schedule for internal use which we'd be happy to share if everybody seems supportive and understanding that anything that can change, will change.
The only thing that doesn't change is the fact that things change! The folks that grumble will grumble no matter what you do.
I agree, and we won't let negativity dictate what and when we wish to communicate, how we feel about what we're doing, and what benefits it will bring to our customers.
Our work is visible for everybody to see* and the P2 will be your chip because you're sticking with us through the whole process.
Ken Gracey
*P2 core isn't public yet, but at the right time we'll make it available one of several ways.
Actually, I believe strongly that Parallax needs the impact of the Propeller Two being a pleasant surprise in some way in order to recoup as much of their initial capital outlay as quickly as possible.
And in this day and age, if you tell the public exactly what you plan to do, the competition will produce one better at about the same time.
Best wishes... surprise me.. The only people that really need to know more are likely the competition.
Comments
Parallax is one of the few specialists (The only one to roll an architectural design I'd say) in the education market and Ken's response shows that that counts. Ken didn't say they are committed to an actual Dual-In-line-Package (DIP) but I suspect that he is absolutely costing it up to compare with the adaptor based alternatives.
One benefit of going the adaptor route is the upper pins of port A can be freed of the boot functions that would otherwise be required of a DIP.
I presume by 'adaptor' you mean (compact) PCB module ?
That is the most likely offering, and as well as the small FTDI Module example I gave above at $5.95, there is this one
http://parallax.com/product/32810 = $19.80ea / 5+
- and that for a large PCB area ( >> DIP40).
Then main challenge will be driving the labour out of a DIP 40 module, and most of that is in the pin-mounting.
A SMD-mountable PCB module with pins included, but not soldered, is one way to manage that.
If doing DIP40 as one subset pin-out, making that Prop1 pin-mapped would allow inter-mixing of the devices in most use cases.
Thanks,
Tim
Hopefully we will see a P2 fpga drop soon - it would make for a nice Chinese New Year!
I have found that Spin, combined with assembly, makes programming
problematic. I can follow the flow with Spin programming, and, given time,
I think I could do well with Spin. The P2 will have to have programming
language that is different, with the more power and processing. Is there
any way to keep the original spin, and add in different functions?
If there are some assembly commands that are not being used, then
focus them on commands that will be of benefit to the P2, if that is an issue.
Thanks.
What do you find "problematic" about Spin?
I have used many languages in my time and Spin is about one of the simplest. The assembly languages is likewise one of the simplest to use I have ever seen. The integration of Spin and PASM in the same object source files makes for a very simple programming environment.
I suspect Spin may not be a wise choice for large programs where it's very simplicity may be a disadvantage.
I don't think there is any point in making Spin overly complex though. That world destroy is easy entry for beginners. We will have other languages on the P2 to cater for those who think Spin is insufficient. C and C++ for example.
Having said that I'm sure Spin will gain some P2 specific features as it must.
What features are there that you would like to see added to Spin? If people say what they need specifically there is more chance that it will happen sometime.
I'm with you, Heater. A few weeks ago I wanted to port my flame algorithm from Spin to the Arduino (for a friend) and nearly ended up tearing my hair out (thankfully, I have a lot of it).
I doubt Chip would do that; he created Spin to be a simple and elegant language that allowed any person to exploit the capabilities of the Propeller. Would it be nice to have Spin-to-PASM compiler (LMM, perhaps)? Yes -- but that's not stopping anyone from developing a wide range of very serious applications in Spin.
The P2 perhaps changes the Propeller landscape language wise.
It does not have a built in Spin byte code interpreter. It does not require any Spin byte codes to boot the thing up. That puts all possible languages on the same footing.
I have no idea where I'm going with that thought but I can speculate that C/C++ starts to take center stage,
Clearly there is no point in adding complexity to Spin with features when other available languages already have that complexity.
AFAIK the VccIO will be up to 3.3V standard, and the Core Vcc is 1.8V for the process used.
I think VccIO will be banked, so some ports can run at 1,8V if that is a requirement.
There is no on-chip regulator, so an external regulator will be needed
(probably switching for highest MHz:mA targets to keep the thermal issues manageable.)
.
This has already been addressed, but I can't resist the chance to suggest to mklrobo (and anyone else in a similar fix) that what may seem problematic right now might become one of the sweetest pairings they'll ever encounter in the field of embedded control. It is no stretch to say that I love the combination.
It almost makes me sad that the P2 is destined to stray from this paradigm since Spin is not built in.
Now the thing that makes me sad is that it's been a month since Christmas, and we haven't gotten a P2 FPGA image yet.
Spin and pasm are going to rock a lot harder on P2
The fact that the Spin interpreter won't be built in means you can use your own interpreter that doesn't include commands that aren't commonly used, such as lookup and friends, and leaving space for new, custom instructions. A smart enough compiler could build this custom interpreter itself.
I played around with the idea of creating a custom P1 Spin VM that supported only the bytecodes used by a program. I wrote a utility that would scan through a binary file to determine which bytecodes were used. It would then assemble a VM by extracting only the code that was needed for each bytecode that was used. Using a custom unrolled VM I was able to execute Spin code faster than the ROM VM would. For some special cases the custom unrolled VM ran twice as fast as the ROM VM.
The problem is that many programs will use more bytecodes than an custom unrolled VM can fit in 2K of cog memory. One solution is to extend the VM into hub RAM for bytecodes that are rarely used. I did that with the October 2013 P2 FPGA image about a year ago. It's hard to believe that it's been so long since we've had a fully documented P2 FPGA image.
And even then, Prop2 programs are quickly going to evolve to use it's features and speed, Spin can be extended at the source level also.
Exactly. A compiler could optimize the interpreter and change around opcodes specifically for the program that will be using the interpreter. Certain programmers often don't use certain instructions, so they don't have to be included. I don't remember ever using a single group 4 opcode (lookup and friends) in anything I've ever written. Group 9 (spr, waitvid) could also be excluded for most applications. These opcodes could be reused for more language features, such as ones like those in block 1 except that they pop method and object numbers off of the stack, to allow easy call by reference. In case there aren't enough opcodes, one group could be for extended, 2 byte, rarely-used opcodes.
However, this would disallow dynamic run-time Spin linking, which actually looks fairly easy on the P1, although I've never actually attempted it because current spin compilers don't understand it and I don't know of anyone else who has attempted it either.
I know the mantra is that Chip is a busy bee, and we should want nothing to interrupt him in his cone of silence, because, well, work!!!
I have to say however, that if he had time to do an interview, is it really asking too much to get a brief update out to to the fanat^h^h^h^hfaithful?
There seem to be a lot of people doing work on their dime for Parrallax and the 'community' at large, aside from themselves.
Its obvious Parallax experimented a bit too much with their outreach and community input on the initial P2.
So the desire to learn from that experience, and cut way back on this attempt is a natural.
But it seems like its overshot its mark, and is probably driving at least some away to solutions that are either available, or coming to fruition elsewhere.
I'd suggest that Parallax really should pull together Ken and Chip over lunch, which they both I'm sure do at least occasionally, and answer some basic Big Picture questions and get some actual detail on current status of some Top 5 features.
This could be 3-4 paragraphs in a Post here, and maybe 50% of the idle, and wasted speculation time would end.
It would also probably give some reassurance that there really is forward movement occurring.
Part of the reason I was initially gung-ho on the 16 core versions was because IIRC, Chip said that this should be somewhat easier as it was an expansion on an earlier proven design. Then the HubExec got argued quite a bit, and added.
So if I had a question I could ask, it would be what feature,/issue is the biggest pain point, and is it worth the delay ultimately?
On the P1, Spin was something that was sold as a major selling point, but which was always received by the majority as a negative. People can argue it til the cows come home, however almost every thread has someone bemoaning that.
Liekwise, is there something that is a timesink or delay on the P2, or the oft-promised image release that is going to ultimately be something that wasn't worth the delay/hassle/$$spent?
Considering where I thought we were near the end of last year, could it be the whole Smart Pins thing?
Note, I do Project Management as well, and I would hate to have to do it with public exposure. However many, many companies do, as its required to keep their partners up to speed and informed, as well as for marketing reasons.
We agree that it's time to publish an update and plan on doing so shortly. I've got a presentation this evening and expect to be able to work with Chip to write an update over the next week.
We always have much to talk about, but lately I've been keeping the calls to a few minutes so I'm not a distraction to his efforts.
While we wait for a more informative update, I'll provide a quick one right now. Yesterday Chip was finalizing his input to Daniel on the Parallax Propeller 1-2-3 FPGA board. We had a few disconnected pins, the need for a ground here and there, and a couple of small power supply adjustments. These changes have all been identified and are being wrapped into the final board which Chip needs to finish the Verilog properly. Daniel tells me the layout changes can be completed within a day and I've checked that we have all the components for fabrication, so this shouldn't take too long. The manual layout is well underway with Treehouse Designs and we have regular weekly meetings with them where we do the basic project management stuff - reviewing scope, progress, budget, delays, etc and make adjustments to the plan. Chip needed this kind of project management
Ken Gracey
It all sounds exciting and promising and we're all up for that!
Good news on the 1-2-3 FPGA, I'm still saving my milk money because who doesn't need another FPGA!!
Thanks for keeping it open and real with all of us!
Huumm...I wonder if the new 1.2.3 will fit on the Elev-8?
You need the 4-5-6-7 adapter kit.
I agree, and we won't let negativity dictate what and when we wish to communicate, how we feel about what we're doing, and what benefits it will bring to our customers.
Our work is visible for everybody to see* and the P2 will be your chip because you're sticking with us through the whole process.
Ken Gracey
*P2 core isn't public yet, but at the right time we'll make it available one of several ways.
And in this day and age, if you tell the public exactly what you plan to do, the competition will produce one better at about the same time.
Best wishes... surprise me.. The only people that really need to know more are likely the competition.