Because they have four variants of ONC18 (G/MS, I4T, 5V/30V, 18V/18). They are currently announcing that LogicEE MTP in is R&D stage for for the high voltage variants.
Would you think that it could be possible to easily move from the low voltage type (G/MS) to the high voltage variant (5V/30) in the future?. A future small package (28-52 pin) P2 with 5V will made a killer MCU.
I honestly cant tell if that's sarcasm or not. My main concern is not producing the 1.8v, its do I need to route it to all 16 different vcc pins, or are they internally connected enough to only need one to be connected?
I honestly cant tell if that's sarcasm or not. My main concern is not producing the 1.8v, its do I need to route it to all 16 different vcc pins, or are they internally connected enough to only need one to be connected?
My main concern is not producing the 1.8v, its do I need to route it to all 16 different vcc pins, or are they internally connected enough to only need one to be connected?
Hmm, hadn't thought of this wrinkle. Routing separate Vdd and Vio traces to all the pins that require it could be challenge on a two-layer board. (And, yes, you do need to connect and separately bypass each and every power pin.) Methinks the only reliable way to do this is with a four-layer board. But geez! It's starting to get complicated.
Hmm, hadn't thought of this wrinkle. Routing separate Vdd and Vio traces to all the pins that require it could be challenge on a two-layer board. (And, yes, you do need to connect and separately bypass each and every power pin.) Methinks the only reliable way to do this is with a four-layer board. But geez! It's starting to get complicated.
The Exposed Pad does not help, either .....
I'd expect the first PCBs will be 4 layer, and then some will experiment on 2 layer, to see what can be done.
If the Core pins are joined, it may be ok to connect only some, and decouple all, or even use more sparse decoupling.
Depends on the MHz being pushed, and the IO pin loads (which will affect system ground bounce)
On the topic of OnSemi, I looked around for Dual regulators, and the choice is sparse with prices climbing, but OnSemi have some low cost single linear regulators, that help spread the thermal load across more area, for sub 10c prices (3k) up to 600mA, or some RF ones with high PSRR (at low freq) and low noise.
A separate NPN 'heat spreader' device could be used to drop the hot spots more. (460mW ~ 2.6c, 625mW ~ 3.6c, to 1.5W SOT223 ~ 8c)
Hmm, hadn't thought of this wrinkle. Routing separate Vdd and Vio traces to all the pins that require it could be challenge on a two-layer board. (And, yes, you do need to connect and separately bypass each and every power pin.) Methinks the only reliable way to do this is with a four-layer board. But geez! It's starting to get complicated.
-Phil
If I understand correctly, you only need to connect VIO for the pins that you are using, which will help somewhat. Also, I'm guessing that many of the designs which use all 64 pins are likely going to need four-layer anyhow.
Chip/Ken, here's a summer internship opportunity! See what it'll take to lay out varying levels of complexity. The outcome of that might provide some good "reference design" documentation.
If I understand correctly, you only need to connect VIO for the pins that you are using, which will help somewhat. Also, I'm guessing that many of the designs which use all 64 pins are likely going to need four-layer anyhow.
Chip/Ken, here's a summer internship opportunity! See what it'll take to lay out varying levels of complexity. The outcome of that might provide some good "reference design" documentation.
Eval boards will not know how many pins will finally be connected, so they will have to err on the upper end.
There is another design point, between eg FLiP / Quickstart and 4 layers, and that is double-sided part mounting.
Costs more than one-side placement, but will be less than 4 layers. (some may use 4 layers and double side placement)
One eval board I have here, uses micro-vias & multiple 0402 decoupling right under the target device.
We've not used two-side placement down a volume SMD line, but my understanding is smaller parts do not need gluing, as they are held in place by surface tension on the second pass, even tho they are on the bottom. (ie just avoid large parts underneath, reasonably easy to do)
We've not used two-side placement down a volume SMD line, but my understanding is smaller parts do not need gluing, as they are held in place by surface tension on the second pass, even tho they are on the bottom. (ie just avoid large parts underneath, reasonably easy to do)
The other way that is done is by using solder with two different melting points .
@Chip, if due to the current design stage and chosen process technology it is not possible to make a package with stacked P2 and eeprom/flash die, it will be possible to give to the hub ram its own power supply? Eg Vhub or Vram?
The internal rom booter can at first check a given address in ram for a certain value and if found then start executing in hub-exec at a defined address.
This will still require an external way to transfer the code the very first time, but if the developer design the Vram power battery backed it will allow for instant execution after successive resets/power-cycles/power-on. How long? It depends on the battery size the designer will choose based on the sram consumption in static mode, on its quiescent current.
Brownout detection can disable ram access (write).
..., but if the developer design the Vram power battery backed it will allow for instant execution after successive resets/power-cycles/power-on. How long?
The DOCs say this :
"Unless preempted by a properly-signed program in a SPI memory chip with a pull-up resistor on P60 (SPI_CK), the serial loader becomes active within 50ms of reset being released."
and also "If an external pull-up resistor is sensed on P61 (SPI_CS), then attempt to boot from SPI:
Load the first 992 bytes ($F8 longs) from SPI into the hub starting at $00000.
Load the next 32 bytes from SPI into a signature buffer.
Compute a SHA-256/HMAC signature on the first 992 bytes, using the first 128 fuses as the key.
Compare the buffered signature against the computed signature.
If signatures match:
Copy the first 992 bytes ($F8 longs) from hub into cog registers $000..$0F7.
If an external pull-up resistor is sensed on P60 (SPI_CK):
Execute ‘JMP #$000’ to run the SPI program. Done.
"
with this note... " In the case of a signature and a large program, it will take about one second per 100KB of loaded program (not sent text) to compute the SHA-256/HMAC signature, before a response character will be sent."
or there is " Wait for serial command(s) on P63 (RX_PIN):
If a program successfully loads serially within 60 seconds:
Execute ‘COGINIT #0,#0’ to relaunch cog 0 from $00000. Done.
"
Looks to be 2 possible minimal pathways to hit 'go', assuming you know you have good-ram, either 992+32 bytes SPI, or minimal Serial.
In both cases, I think no-key is going to be faster restart than checking the key at 10ms/kB.
Taking a educated guess of ~21 bytes to serial-go, that's 21*10/1M = 210us for 1MBd link.
(998+32 bytes + SHA) from SPI will likely take longer.
The internal rom booter can at first check a given address in ram for a certain value and if found then start executing in hub-exec at a defined address.
That's probably far too risky, as RAM can retain some values, for a surprisingly long time. Murphy says your single check location will be the best-lifetime of all RAM
..will (it) be possible to give to the hub ram its own power supply? Eg Vhub or Vram?
That's a can of worms.. The process is Speed-optimized, & separate Vcc's mean special split-rail buffers (slower..), and you only save the die-ratio leakage (ie not much gain)
If you really want low 'ready-to-go' Icc, you would be better looking for Ram-Retention-Voltage on the whole device - ie drop to slowest CLK and Drop Vcc down.
OnSemi may have numbers on the Ram-Retention-Voltage / Icc for this process ?
Or, you can completely remove Supplies and run a separate MCU for uA-wakeup task. That small MCU can load the P2 stage 1 loader, and control Vcc levels as needed.
P2 is not really a low-power targeting device.
I'm not sure what happens in P2, if VCore is Zero, but VIO remains at 3.3v, or if there will be strict sequencing rules ?
Comments
Cluso, before I give you my two cents, are you really considering to have an internal flash not only for storage, but also to execute a program?
Is it ONC18 G/MS, right? and 1.8V low leakage (0.008 nW instead of 0.136nW)?
http://www.onsemi.com/pub/Collateral/ONC18GMS-D.PDF
Because they have four variants of ONC18 (G/MS, I4T, 5V/30V, 18V/18). They are currently announcing that LogicEE MTP in is R&D stage for for the high voltage variants.
Would you think that it could be possible to easily move from the low voltage type (G/MS) to the high voltage variant (5V/30) in the future?. A future small package (28-52 pin) P2 with 5V will made a killer MCU.
See Ken's tweet:
http://forums.parallax.com/discussion/164364/prop2-family/p1
Note that there are separate, multiple pins for VDD and VIO. VDD is 1.8v, while VIO is 3.3v.
See http://forums.parallax.com/discussion/comment/1372050/#Comment_1372050
Lowercorner.png is good for seeing the routing of the power rails. The VDD's, unlike the VIO's, are all connected in a big ring. I'll let you find out the stability and fusing limits though.
-Phil
I'd expect the first PCBs will be 4 layer, and then some will experiment on 2 layer, to see what can be done.
If the Core pins are joined, it may be ok to connect only some, and decouple all, or even use more sparse decoupling.
Depends on the MHz being pushed, and the IO pin loads (which will affect system ground bounce)
On the topic of OnSemi, I looked around for Dual regulators, and the choice is sparse with prices climbing, but OnSemi have some low cost single linear regulators, that help spread the thermal load across more area, for sub 10c prices (3k) up to 600mA, or some RF ones with high PSRR (at low freq) and low noise.
A separate NPN 'heat spreader' device could be used to drop the hot spots more. (460mW ~ 2.6c, 625mW ~ 3.6c, to 1.5W SOT223 ~ 8c)
If I understand correctly, you only need to connect VIO for the pins that you are using, which will help somewhat. Also, I'm guessing that many of the designs which use all 64 pins are likely going to need four-layer anyhow.
Chip/Ken, here's a summer internship opportunity! See what it'll take to lay out varying levels of complexity. The outcome of that might provide some good "reference design" documentation.
Eval boards will not know how many pins will finally be connected, so they will have to err on the upper end.
There is another design point, between eg FLiP / Quickstart and 4 layers, and that is double-sided part mounting.
Costs more than one-side placement, but will be less than 4 layers. (some may use 4 layers and double side placement)
One eval board I have here, uses micro-vias & multiple 0402 decoupling right under the target device.
We've not used two-side placement down a volume SMD line, but my understanding is smaller parts do not need gluing, as they are held in place by surface tension on the second pass, even tho they are on the bottom. (ie just avoid large parts underneath, reasonably easy to do)
The internal rom booter can at first check a given address in ram for a certain value and if found then start executing in hub-exec at a defined address.
This will still require an external way to transfer the code the very first time, but if the developer design the Vram power battery backed it will allow for instant execution after successive resets/power-cycles/power-on. How long? It depends on the battery size the designer will choose based on the sram consumption in static mode, on its quiescent current.
Brownout detection can disable ram access (write).
The DOCs say this :
"Unless preempted by a properly-signed program in a SPI memory chip with a pull-up resistor on P60 (SPI_CK), the serial loader becomes active within 50ms of reset being released."
and also
"If an external pull-up resistor is sensed on P61 (SPI_CS), then attempt to boot from SPI:
Load the first 992 bytes ($F8 longs) from SPI into the hub starting at $00000.
Load the next 32 bytes from SPI into a signature buffer.
Compute a SHA-256/HMAC signature on the first 992 bytes, using the first 128 fuses as the key.
Compare the buffered signature against the computed signature.
If signatures match:
Copy the first 992 bytes ($F8 longs) from hub into cog registers $000..$0F7.
If an external pull-up resistor is sensed on P60 (SPI_CK):
Execute ‘JMP #$000’ to run the SPI program. Done.
"
with this note...
" In the case of a signature and a large program, it will take about one second per 100KB of loaded program (not sent text) to compute the SHA-256/HMAC signature, before a response character will be sent."
or there is
" Wait for serial command(s) on P63 (RX_PIN):
If a program successfully loads serially within 60 seconds:
Execute ‘COGINIT #0,#0’ to relaunch cog 0 from $00000. Done.
"
Looks to be 2 possible minimal pathways to hit 'go', assuming you know you have good-ram, either 992+32 bytes SPI, or minimal Serial.
In both cases, I think no-key is going to be faster restart than checking the key at 10ms/kB.
Taking a educated guess of ~21 bytes to serial-go, that's 21*10/1M = 210us for 1MBd link.
(998+32 bytes + SHA) from SPI will likely take longer.
That's probably far too risky, as RAM can retain some values, for a surprisingly long time. Murphy says your single check location will be the best-lifetime of all RAM
That's a can of worms.. The process is Speed-optimized, & separate Vcc's mean special split-rail buffers (slower..), and you only save the die-ratio leakage (ie not much gain)
If you really want low 'ready-to-go' Icc, you would be better looking for Ram-Retention-Voltage on the whole device - ie drop to slowest CLK and Drop Vcc down.
OnSemi may have numbers on the Ram-Retention-Voltage / Icc for this process ?
Or, you can completely remove Supplies and run a separate MCU for uA-wakeup task. That small MCU can load the P2 stage 1 loader, and control Vcc levels as needed.
P2 is not really a low-power targeting device.
I'm not sure what happens in P2, if VCore is Zero, but VIO remains at 3.3v, or if there will be strict sequencing rules ?