P1 will still be used when the power or pins/features are not required of the P2 because P1 will use significantly less power.
Most P1 pasmprograms will port quite easily without making use of new features.
Over the last couple ofdays I converted a spin program that drives the Nokia 5110 LCD to P1 pasm. Then I converted the P1 pasm to P2 pasm, and lastly then to hubexec mode. The hardestpart was spin to P1 pasm.
While there are a few gotchas, most P1 pasm instructions still exist in P2, even though the instruction bitmap has changed.
Because the P1 isn't going away and PropGCC needs to be able to handle both architectures.
So many people seem to be seeing a P1 or P2 world instead of a P1 AND P2 world. The tools need to be able to handle both chips equally and seamlessly as much as possible. While Spin and Spin2 will have different features, I sure don't want to have a Spin development tool and a Spin2 development tool. PropGCC isn't going to have a flavor for each, P1GCC and P2GCC (at least I hope not). Anything done to include the features needed to support P2 can't be done by excluding the P1 it's not going away.
The Spin debate is headed the same way - "You can't do that for Spin2 because then Spin won't work!" - well if somebody is foolish enough to let that happen, then they shouldn't be here. Spin is Spin - there just need to be features and enhancements for Spin2 and P2 added capabilities....nobody says you have to use them and if the tools make you use them or exclude the P1, then somebody made a BIG mistake.
I play with software a lot and that will probably move more and more toward the P2 but when I do hardware stuff, I'll probably use the P1 more unless I really need a P2 feature. I'd rather smoke an $8 dip than a $15-$20 little surface mount bugger on a minimum development board that cost me $50, thank you very much! If the application doesn't need the P2, why use it? Sometimes it's better to dance with the horse that brung ya!
Hub execution will become the norm for the P2. Cog execution will be used only by a few crusty old forumistas who fondly remember the P1 :
Whilst that's true of outer levels of coding, COG modes will remain very important for libraries and critical code.
Most users may not actively write COG modes, but they are more likely to be using COG modes.
One test of good tools, will be how easily they can move something they have just discovered is critical code, and needs to be COG hosted.
OnSemi has been getting ready to do the synthesis and place and route for our main logic block. Today, they got to the point where they have an area and a top speed for our current Verilog design.
The area they'll need is 21.03 square mm. We have 22.9 square mm available. This is good news! There's room for SERDES in there.
At a junction temperature of 150C, they're getting an Fmax of 148MHz. That's military temperature range, which is excessive. I'll ask tomorrow what the Fmax would be at 125C. It should be at least 160MHz. The design is slower from our last synthesis run, since things have grown, but this faster process makes things about equal. So, we're not going to be rated for 200MHz, but we ought to be able to hit 160MHz for industrial temperature range.
ADDED: In the next few work days, we'll get an estimate of power consumption, too.
OnSemi has been getting ready to do the synthesis and place and route for our main logic block. Today, they got to the point where they have an area and a top speed for our current Verilog design.
The area they'll need is 21.03 square mm. We have 22.9 square mm available. This is good news! There's room for SERDES in there.
At a junction temperature of 150C, they're getting an Fmax of 148MHz. That's military temperature range, which is excessive. I'll ask tomorrow what the Fmax would be at 125C. It should be at least 160MHz. The design is slower from our last synthesis run, since things have grown, but this faster process makes things about equal. So, we're not going to be rated for 200MHz, but we ought to be able to hit 160MHz for industrial temperature range.
ADDED: In the next few work days, we'll get an estimate of power consumption, too.
All sounding positive, great there is still room, and it is not a 'Throw stuff overboard' situation, shame the speed is lower.
Do they have a speed spec, for just the counters ?
ie This lower-speed area, is where running the Counters at N times the CPU speed has appeal.
A number of smaller micros now have Timer blocks that can clock faster than the CPU.
OnSemi has been getting ready to do the synthesis and place and route for our main logic block. Today, they got to the point where they have an area and a top speed for our current Verilog design.
The area they'll need is 21.03 square mm. We have 22.9 square mm available. This is good news! There's room for SERDES in there.
At a junction temperature of 150C, they're getting an Fmax of 148MHz. That's military temperature range, which is excessive. I'll ask tomorrow what the Fmax would be at 125C. It should be at least 160MHz. The design is slower from our last synthesis run, since things have grown, but this faster process makes things about equal. So, we're not going to be rated for 200MHz, but we ought to be able to hit 160MHz for industrial temperature range.
ADDED: In the next few work days, we'll get an estimate of power consumption, too.
OnSemi has been getting ready to do the synthesis and place and route for our main logic block. Today, they got to the point where they have an area and a top speed for our current Verilog design.
The area they'll need is 21.03 square mm. We have 22.9 square mm available. This is good news! There's room for SERDES in there.
At a junction temperature of 150C, they're getting an Fmax of 148MHz. That's military temperature range, which is excessive. I'll ask tomorrow what the Fmax would be at 125C. It should be at least 160MHz. The design is slower from our last synthesis run, since things have grown, but this faster process makes things about equal. So, we're not going to be rated for 200MHz, but we ought to be able to hit 160MHz for industrial temperature range.
ADDED: In the next few work days, we'll get an estimate of power consumption, too.
Great. What would be the speed estimate for commercial? Would we get to 192MHz (a nice USB speed)?
Do you now where the speed bottlenecks are?
Great. What would be the speed estimate for commercial? Would we get to 192MHz (a nice USB speed)?
Do you now where the speed bottlenecks are?
The die is going to self-heat, and this is where much of the temperature comes from. If you could keep the junction temperature under 100C, I'm pretty sure it would run 180MHz.
The speed bottlenecks are spread around pretty well. Nothing is sticking out like a sore thumb. I got a timing report today and the longest paths were all over the place, in terms of which Q -> which D.
Great. What would be the speed estimate for commercial? Would we get to 192MHz (a nice USB speed)?
Do you now where the speed bottlenecks are?
If you do USB-Sync in a reload counter, as per my earlier Verilog, then the USB-Speeds for Full Speed are
48MHz,60,72...144,156,168,180MHz... (and finer again for Low Speed USB)
Possible speed/power issues was one reason I wanted to also support odd-number divides as well.
The area they'll need is 21.03 square mm. We have 22.9 square mm available. This is good news! There's room for SERDES in there.
Great news ! Did they use 180nm? How could they do more than a 1/2 reduction of size? Wow ! That's a great job, congratulations.
Have you considered to use a smaller packaging with same number of pins? or the external IO layout is fixed so there is no option to use a smaller packaging? (Several people also asked a second option with lower number of pins: 64 ... 80 ... 100). Die size translates into final price, too. (I think that is something to think about).
I guess that there is no option to increase HUB, COG or AUX size again. That will mean to change the whole instruction opcodes (and also there is no room to fit the address space into a CPU with more than 400 instructions and 32 bits instruction opcodes). Am I right?
At 150C, I don't know that the speed is any slower. It's just not going to make 200MHz.
will there be a way to measure the internal chip temperature, like many other MCUs do using the internal ADCs ??
That would help to check the cooling and even allow to adapt clock based on temperature.
will there be a way to measure the internal chip temperature, like many other MCUs do using the internal ADCs ??
That would help to check the cooling and even allow to adapt clock based on temperature.
There isn't one, yet, but we could add a small RC oscillator that could be measured against a crystal. It would vary with temperature (and voltage, too).
In a Propeller chip, though, you usually need a steady clock rate, as there is not much decoupling between instruction execution and I/O pin activity.
Could you just tie one pin to a resistor with no temperature coefficient, drive it through an internal pullup resistor (that would change value with temperature) and measure the voltage?
Could you just tie one pin to a resistor with no temperature coefficient, drive it through an internal pullup resistor (that would change value with temperature) and measure the voltage?
That's a great idea! That would do the trick.
We could also configure a pin for resistive output and internal schmitt trigger feedback. A capacitor attached to the pin would provide a constant C. The frequency on the IN signal would be a function of temperature, assuming the voltage was stable.
Diodes are commonly used as temperature measurement devices in integrated circuits as they can be set up to be independent of supply voltages (that said if your temperature sensor has the same dependence on Vsup as your ADC it will give you better results than an independent one). Here's a wiki link for anyone interested: http://en.wikipedia.org/wiki/Silicon_bandgap_temperature_sensor, the example uses one junction in each of the BJTs as the sensing diodes.
Diodes are commonly used as temperature measurement devices in integrated circuits as they can be set up to be independent of supply voltages.
True, and you are usually more interested in the centre not-spot temperature, than in the IO ring temperature.
That said, there could also be merit in measuring not only temperature, but "Process Ability" - ie a Frequency value, that is derived from on-chip delays, that tracks Vcc/Temp/Process, and some simple ratio can be used for fMAX
I think there was some PLL mode, where it could 'push up' to fMax_PLL ?
Could 2 PLLs be used, the main SysCLK one is N * xtal locked, and then a local (nice tracking) PLL set for fMAX_PLL, and you have a Process measurement.
This would need that (PLL+Divider) design fMAX needs to be within the Counter's expected abilities.
Chip,
Is there any way that the internal RC oscillator (fast version) could be made more stable. The ATTiny85 has a 1% version that gets trimmed with an eeprom constant that can be changed. We could test and load this value from eeprom (our sw not in the P2 is fine). We just need a way to trim the RC if its possible and uses only a small amount of silicon. Together with the temp measuring, we could construct a table vs temp to change the trimmed value. I presume the trimmed value adjusts a PLL.
It would be nice if we could get a fairly accurate internal RC oscillator without requiring an external xtal. Obviously for accurate results an xtal would be used.
Chip,
Is there any way that the internal RC oscillator (fast version) could be made more stable. The ATTiny85 has a 1% version that gets trimmed with an eeprom constant that can be changed. We could test and load this value from eeprom (our sw not in the P2 is fine). We just need a way to trim the RC if its possible and uses only a small amount of silicon. Together with the temp measuring, we could construct a table vs temp to change the trimmed value. I presume the trimmed value adjusts a PLL.
It would be nice if we could get a fairly accurate internal RC oscillator without requiring an external xtal. Obviously for accurate results an xtal would be used.
We would have to add some bits to tweak its speed. That's too much to bother with, at this point. I don't think anybody will be using this chip without a crystal, though.
We would have to add some bits to tweak its speed. That's too much to bother with, at this point. I don't think anybody will be using this chip without a crystal, though.
What about a means to map a DAC onto the PLL VCO node (which I presume is analog ?)
( that has almost no added cost, besides a single MUX )
Many micros also have the ability to run the FastOSC's and check/calibrate those from a timer.
Often. that means a 32KHz clock crystal Osc to a capture node on a timer clocked from the FastOSC.
Most of the support HW for that should be in P2 already ?
Heater posted "A better plan would be for future PASM drivers to be written in such a way that they can be used from any language. Just a binary "blob" that you load and start a COG and talk to through HUB memory.
I fear that is not going to happen because PASM and Spin are intertwined in the Spin programming system. There is no motivation for a Spin programmer to make that PASM he casually drops into a DAT section of his Spin object generally useful anywhere else.|"
I see your point, Heater, though fragmentation of objects is going to make it tougher to achieve 'critical mass'. Even people who will later adopt SPIN will want C, but if there is a substantial limitation on object availability or ability to use widely in use code then you have two pools of code, not one and you are at much higher risk of getting to that critical mass. One option is to allow only one language, for example C or SPIN. Another one is to make them able to co-exist. This might be more practical on P2 because there is much more memory available. Anyhow, I would imagine that SPIN on P2 may be better compiled than run as an interpreted language anyway. The hub exec mode would make this much more feasible.
I suspect you are right. The Spin guys will do what they like and the C guys will do what they like and PASM reuse will be continue to be the mess it is.
One cannot "allow only one language". Perhaps OBEX could be restricted to Spin but who cares? My code lives on github.
The idea of Spin and C coexisting is interesting and has been discussed here a bit. In my experience though such things are a pain. For example we have a large program written in Pascal with some additions written in C. Technically that is quite an easy combination. It's a mess to manage though.
We would have to add some bits to tweak its speed. That's too much to bother with, at this point. I don't think anybody will be using this chip without a crystal, though.
I think this is absolutely correct. I'd ditch the internal RC for P2... It's a nice option for P1 though.
I don't think we should ditch the internal RC oscillator. It's good for bootup, and provides a secure oscillation source that you know is under control of your code. (assuming the chip package is intact anyway) Also, if the internal RC oscillator could be exposed to a counter while in other clock modes, it'd make a good temperature sensor. (and Vcc sensor) With an external reference, modulation of the P2's power draw and die temperature should also be able to stabilize the internal RC. (oven controlled RC oscillator anyone :cool: )
For the PLL based process monitor, the P1 can already do this. Prop TDR experiments post #38. Basically you just try to run one of the counter PLLs way too fast, and it runs at it's silicon limited max speed. Can the P2 counters pull the same trick?
For the PLL based process monitor, the P1 can already do this. Prop TDR experiments post #38. Basically you just try to run one of the counter PLLs way too fast, and it runs at it's silicon limited max speed. Can the P2 counters pull the same trick?
Yes, it is that type of mode I was meaning - for this the Counters need to be able to reliably count at whatever the PLL+any 50% divider tops-out at.
Even people who will later adopt SPIN will want C, but if there is a substantial limitation on object availability or ability to use widely in use code then you have two pools of code, not one and you are at much higher risk of getting to that critical mass. One option is to allow only one language, for example C or SPIN. Another one is to make them able to co-exist.
Comments
Most P1 pasmprograms will port quite easily without making use of new features.
Over the last couple ofdays I converted a spin program that drives the Nokia 5110 LCD to P1 pasm. Then I converted the P1 pasm to P2 pasm, and lastly then to hubexec mode. The hardestpart was spin to P1 pasm.
While there are a few gotchas, most P1 pasm instructions still exist in P2, even though the instruction bitmap has changed.
Whilst that's true of outer levels of coding, COG modes will remain very important for libraries and critical code.
Most users may not actively write COG modes, but they are more likely to be using COG modes.
One test of good tools, will be how easily they can move something they have just discovered is critical code, and needs to be COG hosted.
Now I do agree that people will not gravitate to it, unless they have needs. Many will run COG mode code from others who grok it and why.
A big part of this come down to the material we make available. Understanding why things are there will be significant, IMHO.
The area they'll need is 21.03 square mm. We have 22.9 square mm available. This is good news! There's room for SERDES in there.
At a junction temperature of 150C, they're getting an Fmax of 148MHz. That's military temperature range, which is excessive. I'll ask tomorrow what the Fmax would be at 125C. It should be at least 160MHz. The design is slower from our last synthesis run, since things have grown, but this faster process makes things about equal. So, we're not going to be rated for 200MHz, but we ought to be able to hit 160MHz for industrial temperature range.
ADDED: In the next few work days, we'll get an estimate of power consumption, too.
All sounding positive, great there is still room, and it is not a 'Throw stuff overboard' situation, shame the speed is lower.
Do they have a speed spec, for just the counters ?
ie This lower-speed area, is where running the Counters at N times the CPU speed has appeal.
A number of smaller micros now have Timer blocks that can clock faster than the CPU.
At 150C, I don't know that the speed is any slower. It's just not going to make 200MHz.
I'm glad, too, that we are not faced with having to jettison anything.
The counters run the same speed as everything else, as they actually have some very long paths within them.
Re/ Fmax... I wonder what it would be at 100'C ?
I can see thermal paste & heatsinks in my P2 future...
Do you now where the speed bottlenecks are?
The die is going to self-heat, and this is where much of the temperature comes from. If you could keep the junction temperature under 100C, I'm pretty sure it would run 180MHz.
The speed bottlenecks are spread around pretty well. Nothing is sticking out like a sore thumb. I got a timing report today and the longest paths were all over the place, in terms of which Q -> which D.
Wot ? No Peltier cooling systems ??
If you do USB-Sync in a reload counter, as per my earlier Verilog, then the USB-Speeds for Full Speed are
48MHz,60,72...144,156,168,180MHz... (and finer again for Low Speed USB)
Possible speed/power issues was one reason I wanted to also support odd-number divides as well.
Great news ! Did they use 180nm? How could they do more than a 1/2 reduction of size? Wow ! That's a great job, congratulations.
Have you considered to use a smaller packaging with same number of pins? or the external IO layout is fixed so there is no option to use a smaller packaging? (Several people also asked a second option with lower number of pins: 64 ... 80 ... 100). Die size translates into final price, too. (I think that is something to think about).
I guess that there is no option to increase HUB, COG or AUX size again. That will mean to change the whole instruction opcodes (and also there is no room to fit the address space into a CPU with more than 400 instructions and 32 bits instruction opcodes). Am I right?
Why is not in the official repository? Is there any specific reason, or is just that we haven't asked them yet to include it?
I'm not sure they did ? - I read those numbers as being 91.83% full, and spare is 1.87 sq mm
That would help to check the cooling and even allow to adapt clock based on temperature.
There isn't one, yet, but we could add a small RC oscillator that could be measured against a crystal. It would vary with temperature (and voltage, too).
In a Propeller chip, though, you usually need a steady clock rate, as there is not much decoupling between instruction execution and I/O pin activity.
That's a great idea! That would do the trick.
We could also configure a pin for resistive output and internal schmitt trigger feedback. A capacitor attached to the pin would provide a constant C. The frequency on the IN signal would be a function of temperature, assuming the voltage was stable.
True, and you are usually more interested in the centre not-spot temperature, than in the IO ring temperature.
That said, there could also be merit in measuring not only temperature, but "Process Ability" - ie a Frequency value, that is derived from on-chip delays, that tracks Vcc/Temp/Process, and some simple ratio can be used for fMAX
I think there was some PLL mode, where it could 'push up' to fMax_PLL ?
Could 2 PLLs be used, the main SysCLK one is N * xtal locked, and then a local (nice tracking) PLL set for fMAX_PLL, and you have a Process measurement.
This would need that (PLL+Divider) design fMAX needs to be within the Counter's expected abilities.
.
Is there any way that the internal RC oscillator (fast version) could be made more stable. The ATTiny85 has a 1% version that gets trimmed with an eeprom constant that can be changed. We could test and load this value from eeprom (our sw not in the P2 is fine). We just need a way to trim the RC if its possible and uses only a small amount of silicon. Together with the temp measuring, we could construct a table vs temp to change the trimmed value. I presume the trimmed value adjusts a PLL.
It would be nice if we could get a fairly accurate internal RC oscillator without requiring an external xtal. Obviously for accurate results an xtal would be used.
We would have to add some bits to tweak its speed. That's too much to bother with, at this point. I don't think anybody will be using this chip without a crystal, though.
What about a means to map a DAC onto the PLL VCO node (which I presume is analog ?)
( that has almost no added cost, besides a single MUX )
Many micros also have the ability to run the FastOSC's and check/calibrate those from a timer.
Often. that means a 32KHz clock crystal Osc to a capture node on a timer clocked from the FastOSC.
Most of the support HW for that should be in P2 already ?
I fear that is not going to happen because PASM and Spin are intertwined in the Spin programming system. There is no motivation for a Spin programmer to make that PASM he casually drops into a DAT section of his Spin object generally useful anywhere else.|"
I see your point, Heater, though fragmentation of objects is going to make it tougher to achieve 'critical mass'. Even people who will later adopt SPIN will want C, but if there is a substantial limitation on object availability or ability to use widely in use code then you have two pools of code, not one and you are at much higher risk of getting to that critical mass. One option is to allow only one language, for example C or SPIN. Another one is to make them able to co-exist. This might be more practical on P2 because there is much more memory available. Anyhow, I would imagine that SPIN on P2 may be better compiled than run as an interpreted language anyway. The hub exec mode would make this much more feasible.
I suspect you are right. The Spin guys will do what they like and the C guys will do what they like and PASM reuse will be continue to be the mess it is.
One cannot "allow only one language". Perhaps OBEX could be restricted to Spin but who cares? My code lives on github.
The idea of Spin and C coexisting is interesting and has been discussed here a bit. In my experience though such things are a pain. For example we have a large program written in Pascal with some additions written in C. Technically that is quite an easy combination. It's a mess to manage though.
I don't think we should ditch the internal RC oscillator. It's good for bootup, and provides a secure oscillation source that you know is under control of your code. (assuming the chip package is intact anyway) Also, if the internal RC oscillator could be exposed to a counter while in other clock modes, it'd make a good temperature sensor. (and Vcc sensor) With an external reference, modulation of the P2's power draw and die temperature should also be able to stabilize the internal RC. (oven controlled RC oscillator anyone :cool: )
For the PLL based process monitor, the P1 can already do this. Prop TDR experiments post #38. Basically you just try to run one of the counter PLLs way too fast, and it runs at it's silicon limited max speed. Can the P2 counters pull the same trick?
Marty
Yes, it is that type of mode I was meaning - for this the Counters need to be able to reliably count at whatever the PLL+any 50% divider tops-out at.
Now they can co-exist. Your request from last summer (?) has been fulfilled. C/C++ programs can call Spin code directly now. http://forums.parallax.com/showthread.php/153919-SpinWrap-a-tool-for-allowing-C-or-C-to-use-Spin-Objects?p=1243144&viewfull=1#post1243144