This may not be the place for this question, but maybe is related.
With pipelined instructions, might one have to insert NOPs at times? Like when wz or wc flags are used and a if_z or c is used with a jmp, is that jump delayed until the jump is being processed. This to me is a new scheme (pipelines) and am not familiar with any 'negatives' compared to a non-pipelined processor.
Does anyone also know if there might be other 'new' things to consider with the Propeller 2 instructions we've not dealt with? If so, it might be a good time to read up on them
Harley: the Prop I has a 6 stage pipeline. We have to insert a nop between self-modifying code but the flags are tested correctly. I understand there will be variations here which also includes better smarts for the pipeline. Really we will have to wait longer for better specs. There have been some really interesting features previously released about extra instructions usch as autoincrement/decrement and repeat.
One thing is for sure, we will all be amazed when everyting is revealed!
Ale: I had not thought about Cordic replacing the table requirement. Since ROM footprints are small I had thought this was going to expand significantly.
As with others, I am much more concerned with only 128KB hub ram as this would have been fine 2 years ago, but the world has caught up and I see 128KB in a years time when the Prop II is available as a severe limitation. I would rather the die be larger and cost more. The external SDRAM (which also could be SRAM, FLASH or even a combo of them all) is not the same as hub ram. Large external SDRAM is required for HD video and other things. However, IMHO 128KB ram WILL be a limitation in 1 years time.
As we have said many times, this is fantastic that Parallax shares this info with us all.
1.28 BIPS (160 MIPS x 8 cogs) maximum instruction execution rate! Yes, that is an 8 fold increase in speed, very very impressive. And of course there is more of everything - I/O pins, etc.
WOW, light speed....... Finally the pipeline has one instruction per clock.
Can we adopt a pet name for the Propeller 2? Something like "Tsunami" or "Typhoon" would be cool. or how about the "Cyclotronic bit muncher"?
ADC and DAC on i/o pins, more RAM, on and on.... Wow oh wow oh wow................ Absolutely brilliant.
A DIP package would seem a big waste and a shield might offer better interfaces with the real world.
I am quite interested how a 1.8volts i/o scheme will manage in the 3.3/5.0 volt world of add-on devices.
And since the Ard**NO fanatics have been so hard on the Propeller, it would be fun to come up with a great code name for the Propeller 2's first board/shield, something that will turn heads and make people really wonder.
"Krakatoa" comes to mind. None of those silly Italian tags. When an Ard**NO nut recommends his favorite shield to you, you can just say "No, Thanks. Karakatoa is coming....."
Am I the only one that thinks it is funny that it is has been said time and time again the the Prop 2 will not have a DIP package, but on that page they show DIP IC?
I haven't heard about HD video out before, so I am definitely excited about that!
Very important question ?.
On inf page It declares.
Counter Modules:
2 counter modules, each with
2 integrated waveform generators, per cog
Will it be possible with that waveform generators be possible to generate 3-phase waves for industrial 3-phase MOTOR control in one COG/generator --> And if possible even with simultaneously controlling its amplitude.
If not that will be not so usable in industry
"I thought the I/O pins were going to have pull-up and/or pull-downs ?
Did that get cut ?" - Simple answer is no, the pull-up and/or pull-down would be a selectable 'mode' that the DAC would operate in.
Sapieha,
"Will it be possible with that waveform generators be possible to generate 3-phase waves" - Another function of the DAC output, this type of output control should be very easy to accomplish.
"I thought the I/O pins were going to have pull-up and/or pull-downs ?
Did that get cut ?" - Simple answer is no, the pull-up and/or pull-down would be a selectable 'mode' that the DAC would operate in.
Sapieha,
"Will it be possible with that waveform generators be possible to generate 3-phase waves" - Another function of the DAC output, this type of output control should be very easy to accomplish.
YES. It is that type of control I mean BUT with possibility of detecting Zero-crossing in COG of that generated wave's IT is possible drive that circuit with only 4 I/O Pins.
I will personally author a nice, interleaved 8x8, to compliment the Parallax Font currently in the ROM, just let me know. Having a good 8x8 handy in the ROM would be a good thing, though probably not strictly necessary in the larger RAM space on Prop II.
Interesting. How will they fit a whole development environment into the same 32KB ROM??? Will it load off of SD? Will some things like the internal font be going away????
I recall the internal dev environment mostly going away. I think it was on the second to last big Prop II discussion we had. The one where Chip asked about 32 bits, and concluded that it probably made sense to take all addressing 32 bit, so that it won't change again for future props.
Since the new one appears to have more robust boot options, it probably makes sense to ship dev tools, that run on a Propeller, outside the ROM, perhaps including a subroutine or two in the ROM that makes sense.
I sure hope the internal font we have now does not go away. It's a great font on higher resolution devices, which the Prop II will drive very nicely. Probably a good reason not to include a 8x8, but my offer stands, because... well, because 8x8 fonts just make me happy.
I feel that the lack of on-chip debugging, like the JTAG port that competing devices have, will be a big obstacle to its use in industry. Dispensing with the ROM and using the space for JTAG would be a good idea.
I'm generally opposed to this. Seems to me, incorporating JTAG into the Propeller would introduce a very significant, and potentially limiting, technology dependency. So far, everything in the Propeller is owned by Parallax. That's not a insignificant thing!
Edit: It's not that I'm being a zealot here either. Standards are good things, but only when they have a real return. I'm just not sure that is the case here, and I'm also not sure that can be quantified at this time because the data needed for that has not yet been collected.
Honestly, there are pros and cons here. Let's assume a sufficient level of code protection is achieved on the Prop II.
Given that, just how many hacks depend on JTAG today? Running a Prop may well prove compelling in that regard, depending on how the code protect would actually work. Sometimes being different is good.
Secondly, there is a significant cost in terms of engineering, integration, and user licensing involved. There is a case for that not adding the value needed for a solid return. I think the use value is high for those who have made those investments, however the costs are distributed to all, whether or not they make that investment.
I believe the current approach; namely, distributing the costs associated with external components being well distributed, through the software defined silicon concept, is competitive. Prop I doesn't quite have the scale needed for some of the target niches. This next Prop will, and that's going to be interesting to watch play out.
That same "but it needs to be standard" argument was made for C on the chip, was it not? And given how different the design is, concurrency in multi-processing, wouldn't the JTAG implementation have to be significant to actually add value, given the design differences? We sure see a significant amount of mind share being employed to deal with C. I'll bet those differences would add up nicely with JTAG support in the mix, but I could be wrong here. Interested in what others have to say. My gut says the design would be far less "lean", if that path were taken.
Those same design differences allow for some pretty damn potent on-chip testing with the tools that come with the thing. Some nice tools have been developed too, with modest licensing requirements, and no real dependency included. One is free to use them or not. A lot of things about the chip are predictable too, reducing the need for such testing.
Finally, there is a case for just nailing a few niches being necessary to make Propellers viable. Remember the lesson Apple computer has taught us. It's not necessary to have a majority share. It's only necessary to add value sufficient to bring a good margin back to the business. I'm not sure JTAG would be needed for this. IMHO, another round of development will tell that story, and assuming Parallax has the ability to go that round with Prop II, it's a very smart wager to do so. If it proves out, they get a very nice margin advantage, with few tech dependencies eating away at them in terms of development time, and licensing dollars for patents, software, upgrades, etc...
Incorporating something like this may well significantly increase, or complicate the design process, and that's probably not desirable at the scale Parallax is currently operating at.
Given that, it also seems to me there are niches opening on a near daily basis, and people looking to fill them. The trade-off with a Propeller is highly likely to be near zero software tool license investments being required for development. That's compelling for a lot of reasons, one being the overall stability of the tool chain and acumen required to use it.
Everything costs something it seems.
Why not pay the understanding cost essentially ONCE, then leverage that over a very long period of time?
The scope of possible solutions is going to be very significantly expanded with Prop II. That's going to take it out of the hobby / smaller scale realm. Again, it's a smart wager to understand whether or not, or how it may compete on it's own merits, before making enduring tech dependency decisions.
Edit: One other compelling thing is how the COG / HUB concept works, and how that is related to being able to "see" the working state of things.
A COG is really just 512 longs. Programming that is only going to get so big, so it's not like other devices where interrupts, complex "kernel" type code and such raise the bar for in chip debugging. The predictable nature of things helps with this considerably.
However, if one level of indirection is used, where a debugged "kernel" is used to execute code LMM style, that kernel itself, as well as the other COGs, can output a lot of the same detail, and offer a lot of the same features, at the cost of raw compute speed.
This Prop will have instructions aimed right at LMM / XMM style programs. The compute speed possible will be a significant boost over what is possible now. Seems to me, a very large amount of code can be done that way, or with SPIN, leaving the COGs as that software defined silicon as intended.
Prop I just isn't quick enough, generally speaking, for that to have a significant impact. My point here is, we really don't know the value of that artifact of the design. Now that the technique is known, and is being designed for, it may prove quite competitive.
If Chip give us Full internal communication between COG's it will be very easy write debuger that can connect with PC with Serial-USB.
1. No need for extra hardware.
2. Simpler for users to write theirs own Debuger GUI's.
I feel that the lack of on-chip debugging, like the JTAG port that competing devices have, will be a big obstacle to its use in industry. Dispensing with the ROM and using the space for JTAG would be a good idea.
Don't know what you mean by 'not reliable enough' software is as reliable as what you create.
My variable frequency 3 phase generators work very well. Of course, they are written in assembler, and perhaps your experience may be with Spin, and hence less predictable?
1) I'm kinda sorry to hear about the internal IDE going away. Parallax made a good business and technical decision here, but it's still a personal let-down.
2) JTAG is fantastic. Once you're used to working with it, it's frustrating to be without it. But I'll bet Sapieha is correct - that some outstanding debuggers will become available thanks to the greatly improved inter-cog communication in Prop2.
3) Heater said, "I don't believe that Prop II will have a bus as such for any particular memory technology. Rather it will offer hardware assistance for creating such buses with a little software help."
I think SDRAM support will be a bit more explicit and direct than that. My guess is that a configuration bit (or bits) will change the mode of operation of many of the I/O pins specifically to provide a fast SDRAM interface. Of course I could be dreaming. Wouldn't be the first time.
4) Hardware CORDIC support is an outstanding addition, as are hardware multiplication and division! I'm more interested in Prop2 than I've ever been before.
5) Despite the fact that the external SDRAM is for data only (in other words, code can't execute from it), the chip won't be in our grubby little hands for more than three days before certain individuals will be writing virtual memory drivers for it.
COUNTERS: The counter specs are a bit of a mystery because there was recent mention that they apply to each pin, not per cog. This is being kept under wraps to some extent. Since I don't know I can speculate that the I/O pins are going to be a real killer and we have to wait for more details.
JTAG: I don't think JTAG would help much. I already have a zero footprint debugger running on the prop which converts the code to LMM style execution. We can use these type of things better. If you look at the newer style debug interfaces on the cheaper micros the move is to one-wire debugging.
SDRAM: I too expect (believe) better support for SDRAM than has been released so far.
ROM: Since booting can be done to SD card also, the ROM is not so important as long as we have plenty of hub ram. 128KB will get chewed quickly.
FONT: 8x8 font would be a big asset in ROM. Personally the bigger ROM font seems a waste to me but I know some of you use it. Maybe we will find a way to tap the extra Fifo Ram in each cog for a big benefit.
While I know we are all disappointed that our favourite bits are not as we would like, I am absolutely convinced when the Prop II arrives we will be overjoyed with it and now there is a following, the Prop II will be exploited very quickly. Remember, we have really only started to exploit the Prop I this year and it has been around for quite a few years (5??).
1) Very simple interface only: clocked port out, clocked port in (latch value) all signals have to be manually controlled. You have to dedicate a cog to it.
2) WRxxxx/RDxxxx write and read SDRAM directly. Initialization is manual. Refresh controller is included.
The 2nd one would be very useful and release the pressuro over a smaller HUB RAM.
Hopefully Parallax will provide info for those who have provided us some useful tools, such as PASD and ViewPort. And that those tools don't require drastic changes to work the Prop 2 instruction set so that they will be available about the time we can have a Prop 2 in hand.
Has there been any comments from the tool authors or Parallax on this matter? I may have missed such if so. I trust this is happening quietly in the background.
I've been thinking about this list. Here's the thinking (my port assignments) on the pins and power (my assumed distribution):
Item #pins
-------+--
Port A 32
Port B 32
Port C 20
Port D 8
Xtal 2
Reset 1
BOE 1
-------+--
Subtotal 96
128 pin SMT package
- 96 pins above
------
32 for power/ground
1.8v 4 or 8
3.3v 12 or 8
Gnd 16
----------
32 check!
Hopefully Parallax will provide info for those who have provided us some useful tools, such as PASD and ViewPort. And that those tools don't require drastic changes to work the Prop 2 instruction set so that they will be available about the time we can have a Prop 2 in hand.
Has there been any comments from the tool authors or Parallax on this matter? I may have missed such if so. I trust this is happening quietly in the background.
I'd like to support the Prop 2 with PropBasic. But I don't know when Parallax will have everything finalized enough to release good information.
From what I've heard accessing the registers(INA, OUTA, DIRA, etc) will be done via some kind of index register because Chip said that there will be slightly MORE than 496 longs for each cog (510 if I remember correctly). That would leave room for one index register and one data register. This will require significant changes to any and all compilers. Again this is just a guess, so don't take it as fact.
I built in "some" support for the 64 pin Propeller 1, but I think the Propeller 2 will be out before it is.
Comments
With pipelined instructions, might one have to insert NOPs at times? Like when wz or wc flags are used and a if_z or c is used with a jmp, is that jump delayed until the jump is being processed. This to me is a new scheme (pipelines) and am not familiar with any 'negatives' compared to a non-pipelined processor.
Does anyone also know if there might be other 'new' things to consider with the Propeller 2 instructions we've not dealt with? If so, it might be a good time to read up on them
One thing is for sure, we will all be amazed when everyting is revealed!
Ale: I had not thought about Cordic replacing the table requirement. Since ROM footprints are small I had thought this was going to expand significantly.
As with others, I am much more concerned with only 128KB hub ram as this would have been fine 2 years ago, but the world has caught up and I see 128KB in a years time when the Prop II is available as a severe limitation. I would rather the die be larger and cost more. The external SDRAM (which also could be SRAM, FLASH or even a combo of them all) is not the same as hub ram. Large external SDRAM is required for HD video and other things. However, IMHO 128KB ram WILL be a limitation in 1 years time.
As we have said many times, this is fantastic that Parallax shares this info with us all.
WOW, light speed....... Finally the pipeline has one instruction per clock.
Can we adopt a pet name for the Propeller 2? Something like "Tsunami" or "Typhoon" would be cool. or how about the "Cyclotronic bit muncher"?
ADC and DAC on i/o pins, more RAM, on and on.... Wow oh wow oh wow................ Absolutely brilliant.
I am quite interested how a 1.8volts i/o scheme will manage in the 3.3/5.0 volt world of add-on devices.
And since the Ard**NO fanatics have been so hard on the Propeller, it would be fun to come up with a great code name for the Propeller 2's first board/shield, something that will turn heads and make people really wonder.
"Krakatoa" comes to mind. None of those silly Italian tags. When an Ard**NO nut recommends his favorite shield to you, you can just say "No, Thanks. Karakatoa is coming....."
I haven't heard about HD video out before, so I am definitely excited about that!
Very important question ?.
On inf page It declares.
Counter Modules:
Will it be possible with that waveform generators be possible to generate 3-phase waves for industrial 3-phase MOTOR control in one COG/generator --> And if possible even with simultaneously controlling its amplitude.
If not that will be not so usable in industry
"I thought the I/O pins were going to have pull-up and/or pull-downs ?
Did that get cut ?" - Simple answer is no, the pull-up and/or pull-down would be a selectable 'mode' that the DAC would operate in.
Sapieha,
"Will it be possible with that waveform generators be possible to generate 3-phase waves" - Another function of the DAC output, this type of output control should be very easy to accomplish.
Synchronized with 120 degres (That need strobe all 3 phases in same time)
To have correct Motor control both on current consumption and speed!
Else it are difficult to control Standard 3-Phase Big industrial Motor's that are constructed initially for 3-Phase AC power.
http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2125¶m=en542105
YES. It is that type of control I mean BUT with possibility of detecting Zero-crossing in COG of that generated wave's IT is possible drive that circuit with only 4 I/O Pins.
Ps. Leon THANKS for nice link!
But, can we not already accomplish this easily in a single cog in the current Propeller?
Cheers,
Peter (pjv)
With PWM it is possible to that control BUT it in not reliable enough in Industrial USE in that systems I'm are thinking on.
As it needs correct 120 degrees 3-phase shifting with wide possibility in Amplitude control and width wide frequency control in same time.
Sorry for that as I can't say what system it is ----> BUT it is NOT me that decide to give that info --- AND them will not talk on it.
I will personally author a nice, interleaved 8x8, to compliment the Parallax Font currently in the ROM, just let me know. Having a good 8x8 handy in the ROM would be a good thing, though probably not strictly necessary in the larger RAM space on Prop II.
Since the new one appears to have more robust boot options, it probably makes sense to ship dev tools, that run on a Propeller, outside the ROM, perhaps including a subroutine or two in the ROM that makes sense.
I sure hope the internal font we have now does not go away. It's a great font on higher resolution devices, which the Prop II will drive very nicely. Probably a good reason not to include a 8x8, but my offer stands, because... well, because 8x8 fonts just make me happy.
Edit: It's not that I'm being a zealot here either. Standards are good things, but only when they have a real return. I'm just not sure that is the case here, and I'm also not sure that can be quantified at this time because the data needed for that has not yet been collected.
Honestly, there are pros and cons here. Let's assume a sufficient level of code protection is achieved on the Prop II.
Given that, just how many hacks depend on JTAG today? Running a Prop may well prove compelling in that regard, depending on how the code protect would actually work. Sometimes being different is good.
Secondly, there is a significant cost in terms of engineering, integration, and user licensing involved. There is a case for that not adding the value needed for a solid return. I think the use value is high for those who have made those investments, however the costs are distributed to all, whether or not they make that investment.
I believe the current approach; namely, distributing the costs associated with external components being well distributed, through the software defined silicon concept, is competitive. Prop I doesn't quite have the scale needed for some of the target niches. This next Prop will, and that's going to be interesting to watch play out.
That same "but it needs to be standard" argument was made for C on the chip, was it not? And given how different the design is, concurrency in multi-processing, wouldn't the JTAG implementation have to be significant to actually add value, given the design differences? We sure see a significant amount of mind share being employed to deal with C. I'll bet those differences would add up nicely with JTAG support in the mix, but I could be wrong here. Interested in what others have to say. My gut says the design would be far less "lean", if that path were taken.
Those same design differences allow for some pretty damn potent on-chip testing with the tools that come with the thing. Some nice tools have been developed too, with modest licensing requirements, and no real dependency included. One is free to use them or not. A lot of things about the chip are predictable too, reducing the need for such testing.
Finally, there is a case for just nailing a few niches being necessary to make Propellers viable. Remember the lesson Apple computer has taught us. It's not necessary to have a majority share. It's only necessary to add value sufficient to bring a good margin back to the business. I'm not sure JTAG would be needed for this. IMHO, another round of development will tell that story, and assuming Parallax has the ability to go that round with Prop II, it's a very smart wager to do so. If it proves out, they get a very nice margin advantage, with few tech dependencies eating away at them in terms of development time, and licensing dollars for patents, software, upgrades, etc...
Incorporating something like this may well significantly increase, or complicate the design process, and that's probably not desirable at the scale Parallax is currently operating at.
Given that, it also seems to me there are niches opening on a near daily basis, and people looking to fill them. The trade-off with a Propeller is highly likely to be near zero software tool license investments being required for development. That's compelling for a lot of reasons, one being the overall stability of the tool chain and acumen required to use it.
Everything costs something it seems.
Why not pay the understanding cost essentially ONCE, then leverage that over a very long period of time?
The scope of possible solutions is going to be very significantly expanded with Prop II. That's going to take it out of the hobby / smaller scale realm. Again, it's a smart wager to understand whether or not, or how it may compete on it's own merits, before making enduring tech dependency decisions.
Edit: One other compelling thing is how the COG / HUB concept works, and how that is related to being able to "see" the working state of things.
A COG is really just 512 longs. Programming that is only going to get so big, so it's not like other devices where interrupts, complex "kernel" type code and such raise the bar for in chip debugging. The predictable nature of things helps with this considerably.
However, if one level of indirection is used, where a debugged "kernel" is used to execute code LMM style, that kernel itself, as well as the other COGs, can output a lot of the same detail, and offer a lot of the same features, at the cost of raw compute speed.
This Prop will have instructions aimed right at LMM / XMM style programs. The compute speed possible will be a significant boost over what is possible now. Seems to me, a very large amount of code can be done that way, or with SPIN, leaving the COGs as that software defined silicon as intended.
Prop I just isn't quick enough, generally speaking, for that to have a significant impact. My point here is, we really don't know the value of that artifact of the design. Now that the technique is known, and is being designed for, it may prove quite competitive.
I'm not concerned of that --->
If Chip give us Full internal communication between COG's it will be very easy write debuger that can connect with PC with Serial-USB.
1. No need for extra hardware.
2. Simpler for users to write theirs own Debuger GUI's.
Don't know what you mean by 'not reliable enough' software is as reliable as what you create.
My variable frequency 3 phase generators work very well. Of course, they are written in assembler, and perhaps your experience may be with Spin, and hence less predictable?
Cheers,
Peter (pjv)
2) JTAG is fantastic. Once you're used to working with it, it's frustrating to be without it. But I'll bet Sapieha is correct - that some outstanding debuggers will become available thanks to the greatly improved inter-cog communication in Prop2.
3) Heater said, "I don't believe that Prop II will have a bus as such for any particular memory technology. Rather it will offer hardware assistance for creating such buses with a little software help."
I think SDRAM support will be a bit more explicit and direct than that. My guess is that a configuration bit (or bits) will change the mode of operation of many of the I/O pins specifically to provide a fast SDRAM interface. Of course I could be dreaming. Wouldn't be the first time.
4) Hardware CORDIC support is an outstanding addition, as are hardware multiplication and division! I'm more interested in Prop2 than I've ever been before.
5) Despite the fact that the external SDRAM is for data only (in other words, code can't execute from it), the chip won't be in our grubby little hands for more than three days before certain individuals will be writing virtual memory drivers for it.
JTAG: I don't think JTAG would help much. I already have a zero footprint debugger running on the prop which converts the code to LMM style execution. We can use these type of things better. If you look at the newer style debug interfaces on the cheaper micros the move is to one-wire debugging.
SDRAM: I too expect (believe) better support for SDRAM than has been released so far.
ROM: Since booting can be done to SD card also, the ROM is not so important as long as we have plenty of hub ram. 128KB will get chewed quickly.
FONT: 8x8 font would be a big asset in ROM. Personally the bigger ROM font seems a waste to me but I know some of you use it. Maybe we will find a way to tap the extra Fifo Ram in each cog for a big benefit.
While I know we are all disappointed that our favourite bits are not as we would like, I am absolutely convinced when the Prop II arrives we will be overjoyed with it and now there is a following, the Prop II will be exploited very quickly. Remember, we have really only started to exploit the Prop I this year and it has been around for quite a few years (5??).
1) Very simple interface only: clocked port out, clocked port in (latch value) all signals have to be manually controlled. You have to dedicate a cog to it.
2) WRxxxx/RDxxxx write and read SDRAM directly. Initialization is manual. Refresh controller is included.
The 2nd one would be very useful and release the pressuro over a smaller HUB RAM.
Has there been any comments from the tool authors or Parallax on this matter? I may have missed such if so. I trust this is happening quietly in the background.
Item #pins -------+-- Port A 32 Port B 32 Port C 20 Port D 8 Xtal 2 Reset 1 BOE 1 -------+-- Subtotal 96 128 pin SMT package - 96 pins above ------ 32 for power/ground 1.8v 4 or 8 3.3v 12 or 8 Gnd 16 ---------- 32 check!I'm guessing this isn't too far off?I'd like to support the Prop 2 with PropBasic. But I don't know when Parallax will have everything finalized enough to release good information.
From what I've heard accessing the registers(INA, OUTA, DIRA, etc) will be done via some kind of index register because Chip said that there will be slightly MORE than 496 longs for each cog (510 if I remember correctly). That would leave room for one index register and one data register. This will require significant changes to any and all compilers. Again this is just a guess, so don't take it as fact.
I built in "some" support for the 64 pin Propeller 1, but I think the Propeller 2 will be out before it is.
Bean
No problem for something like the Prop1 even. Prop2 will be able to do most of the work with just the I/O blocks.
As far as tools etc, I am certain Parallax will everyone in the loop. You only have to look at how open they are this far out to realise this.