Switching down to the internal 20KHz oscillator, the P2 draws 100uA at 1.8V. So, leakage isn't much.
How close to 20kHz did it come out ?
Great to see some 20kHz numbers. My post above calculated (using the same Cpd from your earlier MHz values)
The Cpd formula predicts (for SysCLK + 1 COG)
Vcc=1.8; Pd = Cpd * Vcc^2 * Fi
Fi=20.6k
Id = Cpd * Vcc * Fi = 62uA + 35uA (Iq)
So that makes static Iq quite low.
Can you keep the Xtal Amplifier enabled, when you switch to 20kHz ?
If not, the oscillators I mentioned above, SiT8021 of 1 to 26 MHz, can give 100uA ballpark, low MHz clock sources, for fast SysCLK gear-changes.
If someone wants to use just RCFAST and RCSLOW, I see there are more choices in low uA, MEMS oscillators with 1Hz~8.192kHz 2^N pulse rates.
eg
SIT1534AC-H5-DCC-01.024E SiTIME $0.90535/3k 1.024kHz 1.2 V ~ 3.63 V ±75ppm -10°C ~ 70°C 1.3µA
ASTMK-4.096KHZ-LQ-DCC-H-T Abracon $1.14520/3k 4.096kHz LVCMOS 1.5 V ~ 3.63 V ±100ppm -40°C ~ 85°C 1.4µA
Q: Can P2 hop between RCSLOW and RCFAST and EXTCLK without any forced long pauses ? (ie instant next-edge switch over) ?
With LF MEMS oscillators, a P2 counter pin needs to not miss any edges, and a few-kHz could be useful for faster calibrates/inner timings.
(an 8.192kHz ExtCLK would be ~ 25uA+Iq(35uA),
I can't believe the VCO locks down to 1.25MHz! I had figured it could be conservatively rated for 100MHz-200MHz operation, but I think 25MHz would be okay, too.
Good news. That would have been harder to fix !
It may have poor jitter down there.
What is the highest VCO divider ? (for lowest SysCLK) - Can you divide the Xtal/Osc in, or is the divider only on VCO out ?
Edited to add 20.6kHz and 35uA Iq new data points.
Jmg, you can switch between RC fast, RC slow, and crystal on the next clock. You can have the crystal running while you're in any mode.
The PLL first divides the crystal frequency by a 6-bit value. Then it multiplies that divided frequency in the VCO by a 10-bit value. After that, there is a 4-bit post-VCO divider that can be used to divided the VCO by 2, 4, 6,.. 30, or, 1 (no division).
I've been busy elsewhere and haven't had time to add that abstraction layer to these clock words but you may find them useful for setting the clock interactively. But if you change the clock it changes the baud rate so I have ones that change from my RCFAST of 22.8MHz to 228MHz so that I can select 1,152,000 baud in place of 115,200 baud. The other way I test the clock rate is to add a delay of many seconds or more at the end of the line plus RCFAST to switch it back.
<CLOCK CODE> 30 s RCFAST
Btw, the word for seconds is s which is easier and simpler than having two long words for second and seconds.
The clock words are the basis for building a more comprehensive structure in TAQOZ and perhaps in the respun ROM to change clock rate easily and will probably adjust the baud rate and any timing reports and delays accordingly.
To try it out you have to have P2 silicon and you need to specify all the fields that you want set before finally specifying the SS clock field which then applies the configuration and then a delay if needed and then switch the clock source. So you can mix these parameters around as long as you end up with USEPLL or USEXTAL. The RCFAST and RCSLOW override any other settings. The clock configuration hubset operand has these fields: 0000_000E_DDDDDD_MMMMMMMMMM_PPPP_CC_SS
You could then select your fields like this:
30PF PLLEN 12 XIDIV 180 VCOMUL 1 PLLDIV USEPLL
These words select these fields in this order:
CC E DDDDDD MMMMMMMMMM PPPP SS
But as mentioned you can mix the fields since it only builds the configuration word until you execute USEPLL or USEXTAL.
So this would work exactly the same way: (edit - fixed missing VCOMUL)
PLLEN 12 XIDIV 180 VCOMUL 1 PLLDIV 30PF USEPLL
But if I had a 20MHz crystal and I wanted 180MHz clock then I might do this:
PLLEN 1 XIDIV 9 VCOMUL 1 PLLDIV 30PF USEXTAL
That should work but I want to make it simpler and have code figure out the best PLL settings so that I can say:
12 M CRYSTAL 200 M CLOCK
Just remember that numbers are simply numbers that are stacked until operated on so 12 is pushed onto the stack then M will multiply that by 1 million and still we have only one number on the stack and that is 12,000,000 which is operated on by CRYSTAL. Still nothing is applied, only configured at this stage and then the same with 200 M but this time CLOCK would take all that information and work out XIDIV VCOMUL and PLLDIV for us before using the crystal as the clock source. To have weird crystals and clocks would be as simple and easy as:
11,059,200 CRYSTAL 160,800,500 CLOCK
Remember, this is interactive, there is nothing to compile, just type.
My clock setting code at present:
( CLOCK MODES )
--- 1098_7654_321098_7654321098_7654_32_10
--- 0000_000E_DDDDDD_MMMMMMMMMM_PPPP_CC_SS
long _clk _clk ~
--- set the
: CLKSET _clk @ HUBSET ;
( PLL should run between 100 to 200MHz )
: CLK! ( data mask -- ) _clk @ SWAP ANDN OR _clk ! ;
: PLLEN 24 |< _clk SET ;
: PLLOFF 24 |< _clk CLR ;
: XIDIV ( 1..64 -- ) 1- $1F AND 18 << $00FC0000 CLK! ;
( ends up as multiply)
: VCOMUL ( 1..1024 -- ) 1- $3FF AND 8 << $3FF00 CLK! ;
--- Divide the PLL by 1 2 4 6 ... 30 for the system clock when SS = %11
: PLLDIV ( 2..30 -- ) 2/ 1- $0F AND 4 << $0F0 CLK! ;
: CLKSRC CLKSET DUP 1 > IF 200,000 WAITX THEN 3 AND 3 CLK! CLKSET ;
: USEPLL 3 CLKSRC ;
: USEXTAL 2 CLKSRC ;
: RCSLOW 1 HUBSET _clk ~ ;
: RCFAST 0 HUBSET _clk ~ ;
: CC 3 AND 2 << $0C CLK! ;
: 15PF 2 CC ;
: 30PF 3 CC ;
: 0PF 1 CC ;
: XPF 0 CC ;
--- Set P2 CLOCK to selected MHZ ( simple PLL settings only )
: CLKMHZ ( mhz --- ) 30PF PLLEN 12 XIDIV VCOMUL 1 PLLDIV USEPLL ;
LOL. Maybe I should of posted a video of me spending over an hour clearing some space.
Super paranoid of letting the smoke out of the P2, can't afford any mishaps!
I'm not really sure. I was exploring if it was even practical.
I would need to make my own air gapped capacitor (unless i can find one premade).
The idea is that it would be connected to a shaft and then its value measured as the shaft turned (90 deg rotation max).
My first real question was how to measure this kind of cap fast enough directly from a uC so that I would have reasonable resolution. Most sources I found referenced using an RC circuit and measureing the time it takes the cap to ramp up but that seems completely impractical for quick measurements.
Perhaps the smart pin in this mode answers the speed/resolution question?
j
Yep!. This is one of the applications P2 is really going to shine in.
Also, one of the first things I will try and get working is capacitive finger detection upon the P2 surface - so you can use the chip surface as a kind of trackpad (like some blackberry phones used to have, I think they called it OFN).
It looks the same taking into account P11 and also that I have an SD card showing pullup on P60. So it is not totally random then and even a little bit of capacitance such as the scope probe can help deglitch the pin.
BTW, thanks for the thermal pics too. Maybe you should post them up here too!
We went through most of the pins, but missed 3 which we'll come back to on monday. Here's a table summary of results, and captures attached for completeness.
Glitch investigation - taqoz command eg 7 PIN L H F
5th october 2018
pin number onsemi use capture name voltage dips to rank/comments
0 TCK 100 1.12v
1 TRST 101 1.36v
2 TMS 102 1.88v
3 TDI 103 doesn't dip why not this one?
4 TDO 104 1.16v
5 -
6 TEST_RESET test these for completeness
7 SHIFT_CAPTURE_CLOCK test these for completeness
8 SCAN_EN test these for completeness
9 -
10 SCAN_IN 92 doesn't dip
11 SCAN_OUT 91 1.04v
12 SCAN_IN 93 1.28v
13 SCAN_OUT 94 1.32v
14 SCAN_IN 95 doesn't dip
15 SCAN_OUT 96 0.48v WORST
16 SCAN_IN 97 0.76v 2nd WORST
17 SCAN_OUT 98 1.16v
18 - 99 doesn't dip
Do I recall correctly that OnSemi used a non-standard process to package these test chips? Is it possible that something about that process or the package they used has introduced some unexpected capacitance on the pins that we might not see in the real package?
Do I recall correctly that OnSemi used a non-standard process to package ...
Electrically they're the same. It's a capacitive cross-talk issue due to long run parallel tracks on the silicon. It's always happening but it only negatively affects DIR and OUT because they are unclocked normally.
Once the level of the crosstalk achieves the buffer threshold then it gets amplified into a glitch. The new rules will ensure enough physical separation on the silicon to keep the crosstalk well below the threshold.
Dumb question - given the nature of the problem, couldn't noise couple into DOUT other signals besides DIR? Why is DIR special in this regard beyond the fact that it was observed to have an issue?
Dumb question - given the nature of the problem, couldn't noise couple into DOUT other signals besides DIR? Why is DIR special in this regard beyond the fact that it was observed to have an issue?
Is that due to their non-clocked nature? Assuming so, are there similar signals serving other P2 sub-systems? (I cannot recall any right now?)
Do I recall correctly that OnSemi used a non-standard process to package these test chips? Is it possible that something about that process or the package they used has introduced some unexpected capacitance on the pins that we might not see in the real package?
No these glitches are occurring in the silicon, not the package.
Dumb question - given the nature of the problem, couldn't noise couple into DOUT other signals besides DIR? Why is DIR special in this regard beyond the fact that it was observed to have an issue?
DIR seems to attack OUT on the way to the pin circuit. They are located far apart from each other on the pad ring interface, though. It seems like this is happening:
a) OUT and DIR run parallel for a long ways on the chip.
b) DIR falling when OUT is high induces a low spike into OUT.
c) There is some buffering on OUT, as the glitch results in a full logic-state change that persists for up to 4ns.
I don't know what the juxtaposition of DIR and OUT are on the die, but it seems they are very close to each other.
Doing a 'HUBSET #%0010' switches over to the oscillator circuit which is disabled. This stops the clock, giving us a true quiescent current of:
34uA at 1.8V.
Good to see an Iq value
If you heat the P2 up, then measure Iq whilst cooling, how does it vary with temperature?
How does it vary with Vcore ?
Can you enable the xtal osc but not clock the core, to measure Xtal Amp Icc with various Xtals/resonators.
I noticed the newest SiLabs efm32 specify Xtals to 48MHz, but most older mcu are 25~30MHz
We went through most of the pins, but missed 3 which we'll come back to on monday. Here's a table summary of results, and captures attached for completeness.
Nice table. Did you scope check all pins 0..63, or just the ones in the table ?
It is good to find the worst case pin, and confirm why it is the worst case one.
We did the ones in the table. P15 was done 3 times as it is really bad.
Apart from P59, there seems to be a correlation between 'glitching' and the jtag test pin functions overloaded onto p0..p17. However p3 (TDI) doesn't do it, and at least one scan-in doesn't do it.
This was the last thing we did Friday evening our time, so was in a bit of a hurry. But we'll revisit it on Monday and definitely scope P6..P8 and maybe hunt through
Having the single in-line, 0.05" pitch line of pins kinda makes going pin after pin easy. With what we're going to be able to sense from these pins, you should be able to detect the cro probe touching each pin (I had the probe attached to p11 when i took the lsio capture, resulting in its omission from the recorded take of phantom pulldowns). For each pin I have to insert the probe into the right SIL hole, and type eg 11 PIN L H F. But once able to detect the probe, you could just write a program to loop through the pins, 'type those commands' for wherever the probe is, even potentially collate the results. Anything feels possible, again.
This is to reduce power usage by turning clock off on circuits not being used, right?
I think I'll vote for changing as little as possible so we don't go off the rails...
On the other hand, it seems that onsemi's tools seem to work pretty good (unless we just happened to get lucky) and maybe the danger of falling off of the rails is low...
10% reduction is fine, but sounds like something to try when spinning off a 2 or 4 cog version (unless a major issue is found)
This chip 'feels' a bit like a big V8 engine. You've got 8 cylinders, massive amounts of power available if you "floor it", and its going to chew through the gas if you do. But drive gracefully (spread the load between cogs) and everything is quite workable and able to run from USB (280mA at 5v running 180MHz torture test).
But bolted onto this throbbing V8 you have RCSLOW where you're only drawing a few hundred microamps, low enoug to be able to do battery apps we were previously dissuaded from when the forecast was 1mA leakage.
Part of me wants to just fix the known issues with this one. Gating it could leave us here again, with different issues. OnSemi will have to give a confidence level.
Not gating it, means we advance from here, ideally getting a really great chip, but with less than optimal power consumption.
10% reduction is fine, but sounds like something to try when spinning off a 2 or 4 cog version (unless a major issue is found)
This chip 'feels' a bit like a big V8 engine. You've got 8 cylinders, massive amounts of power available if you "floor it", and its going to chew through the gas if you do. But drive gracefully (spread the load between cogs) and everything is quite workable and able to run from USB (280mA at 5v running 180MHz torture test).
But bolted onto this throbbing V8 you have RCSLOW where you're only drawing a few hundred microamps, low enoug to be able to do battery apps we were previously dissuaded from when the forecast was 1mA leakage.
That 280mA at 5V (before switching regulator) gives you 720 MIPS of 32-bit operations. It's got to cost something, in terms of power.
Running off a 20MHz crystal at 1MHz (using the PLL) takes 3mA at 1.8V. That's for 4 MIPS.
The RCSLOW mode runs at 20.6KHz and takes 100uA at 1.8V.
Quiescent current is only 34uA at 1.8V. You can park the P2 there, until reset.
Comments
How close to 20kHz did it come out ?
Great to see some 20kHz numbers. My post above calculated (using the same Cpd from your earlier MHz values)
The Cpd formula predicts (for SysCLK + 1 COG)
Vcc=1.8; Pd = Cpd * Vcc^2 * Fi
Fi=20.6k
Id = Cpd * Vcc * Fi = 62uA + 35uA (Iq)
So that makes static Iq quite low.
Can you keep the Xtal Amplifier enabled, when you switch to 20kHz ?
If not, the oscillators I mentioned above, SiT8021 of 1 to 26 MHz, can give 100uA ballpark, low MHz clock sources, for fast SysCLK gear-changes.
If someone wants to use just RCFAST and RCSLOW, I see there are more choices in low uA, MEMS oscillators with 1Hz~8.192kHz 2^N pulse rates.
eg
SIT1534AC-H5-DCC-01.024E SiTIME $0.90535/3k 1.024kHz 1.2 V ~ 3.63 V ±75ppm -10°C ~ 70°C 1.3µA
ASTMK-4.096KHZ-LQ-DCC-H-T Abracon $1.14520/3k 4.096kHz LVCMOS 1.5 V ~ 3.63 V ±100ppm -40°C ~ 85°C 1.4µA
Q: Can P2 hop between RCSLOW and RCFAST and EXTCLK without any forced long pauses ? (ie instant next-edge switch over) ?
With LF MEMS oscillators, a P2 counter pin needs to not miss any edges, and a few-kHz could be useful for faster calibrates/inner timings.
(an 8.192kHz ExtCLK would be ~ 25uA+Iq(35uA),
Good news. That would have been harder to fix !
It may have poor jitter down there.
What is the highest VCO divider ? (for lowest SysCLK) - Can you divide the Xtal/Osc in, or is the divider only on VCO out ?
Edited to add 20.6kHz and 35uA Iq new data points.
The PLL first divides the crystal frequency by a 6-bit value. Then it multiplies that divided frequency in the VCO by a 10-bit value. After that, there is a 4-bit post-VCO divider that can be used to divided the VCO by 2, 4, 6,.. 30, or, 1 (no division).
The clock words are the basis for building a more comprehensive structure in TAQOZ and perhaps in the respun ROM to change clock rate easily and will probably adjust the baud rate and any timing reports and delays accordingly.
To try it out you have to have P2 silicon and you need to specify all the fields that you want set before finally specifying the SS clock field which then applies the configuration and then a delay if needed and then switch the clock source. So you can mix these parameters around as long as you end up with USEPLL or USEXTAL. The RCFAST and RCSLOW override any other settings. The clock configuration hubset operand has these fields: 0000_000E_DDDDDD_MMMMMMMMMM_PPPP_CC_SS
You could then select your fields like this: These words select these fields in this order: But as mentioned you can mix the fields since it only builds the configuration word until you execute USEPLL or USEXTAL.
So this would work exactly the same way: (edit - fixed missing VCOMUL)
But if I had a 20MHz crystal and I wanted 180MHz clock then I might do this:
That should work but I want to make it simpler and have code figure out the best PLL settings so that I can say: Just remember that numbers are simply numbers that are stacked until operated on so 12 is pushed onto the stack then M will multiply that by 1 million and still we have only one number on the stack and that is 12,000,000 which is operated on by CRYSTAL. Still nothing is applied, only configured at this stage and then the same with 200 M but this time CLOCK would take all that information and work out XIDIV VCOMUL and PLLDIV for us before using the crystal as the clock source. To have weird crystals and clocks would be as simple and easy as: Remember, this is interactive, there is nothing to compile, just type.
My clock setting code at present:
P2D2 arrived today!
It's alive!
Thanks Chip,Peter. :cool:
Super paranoid of letting the smoke out of the P2, can't afford any mishaps!
Yep!. This is one of the applications P2 is really going to shine in.
Also, one of the first things I will try and get working is capacitive finger detection upon the P2 surface - so you can use the chip surface as a kind of trackpad (like some blackberry phones used to have, I think they called it OFN).
1. The LSIO report showed the following pins have 'phantom' pulldowns:- P0,1,2,4, 11, 12, 13, 15, 16, 17
2. Pin 11 in the LSIO test above should actually be a 'd', but I had CRO
probe attached then cap was taken.
3. We went through and took screen shots of every zoomed in glitch for
the pins labelled d
4. Pin 15's glitch (capture 105 attached) was worst, sinking down to
0.48v before recovering
5. Pin 4's glitch (capture 104 attached) was second worst, sinking down
to 1.16v before recovering.
6. Pin 3 (TDI) and 5 and 14 (scan_) behaved differently (normally),
7. Chip, these pins seem to overlap with many of the pins used for JTAG scan, with a couple unexplained eg p3 and p14
Are you guys able to get the same results on your P2D2's?
BTW, thanks for the thermal pics too. Maybe you should post them up here too!
We went through most of the pins, but missed 3 which we'll come back to on monday. Here's a table summary of results, and captures attached for completeness.
Glitch investigation - taqoz command eg 7 PIN L H F
5th october 2018
pin number onsemi use capture name voltage dips to rank/comments
0 TCK 100 1.12v
1 TRST 101 1.36v
2 TMS 102 1.88v
3 TDI 103 doesn't dip why not this one?
4 TDO 104 1.16v
5 -
6 TEST_RESET test these for completeness
7 SHIFT_CAPTURE_CLOCK test these for completeness
8 SCAN_EN test these for completeness
9 -
10 SCAN_IN 92 doesn't dip
11 SCAN_OUT 91 1.04v
12 SCAN_IN 93 1.28v
13 SCAN_OUT 94 1.32v
14 SCAN_IN 95 doesn't dip
15 SCAN_OUT 96 0.48v WORST
16 SCAN_IN 97 0.76v 2nd WORST
17 SCAN_OUT 98 1.16v
18 - 99 doesn't dip
Nailing down any correction to the boot selects might need going over, though.
Electrically they're the same. It's a capacitive cross-talk issue due to long run parallel tracks on the silicon. It's always happening but it only negatively affects DIR and OUT because they are unclocked normally.
Once the level of the crosstalk achieves the buffer threshold then it gets amplified into a glitch. The new rules will ensure enough physical separation on the silicon to keep the crosstalk well below the threshold.
Clocked signals get protection from this problem by the fact that crosstalk induced ripple has settled down by the time the clock edge arrives.
Dumb question - given the nature of the problem, couldn't noise couple into DOUT other signals besides DIR? Why is DIR special in this regard beyond the fact that it was observed to have an issue?
Is that due to their non-clocked nature? Assuming so, are there similar signals serving other P2 sub-systems? (I cannot recall any right now?)
No these glitches are occurring in the silicon, not the package.
DIR seems to attack OUT on the way to the pin circuit. They are located far apart from each other on the pad ring interface, though. It seems like this is happening:
a) OUT and DIR run parallel for a long ways on the chip.
b) DIR falling when OUT is high induces a low spike into OUT.
c) There is some buffering on OUT, as the glitch results in a full logic-state change that persists for up to 4ns.
I don't know what the juxtaposition of DIR and OUT are on the die, but it seems they are very close to each other.
34uA at 1.8V.
If you heat the P2 up, then measure Iq whilst cooling, how does it vary with temperature?
How does it vary with Vcore ?
Can you enable the xtal osc but not clock the core, to measure Xtal Amp Icc with various Xtals/resonators.
I noticed the newest SiLabs efm32 specify Xtals to 48MHz, but most older mcu are 25~30MHz
Nice table. Did you scope check all pins 0..63, or just the ones in the table ?
It is good to find the worst case pin, and confirm why it is the worst case one.
Apart from P59, there seems to be a correlation between 'glitching' and the jtag test pin functions overloaded onto p0..p17. However p3 (TDI) doesn't do it, and at least one scan-in doesn't do it.
This was the last thing we did Friday evening our time, so was in a bit of a hurry. But we'll revisit it on Monday and definitely scope P6..P8 and maybe hunt through
Having the single in-line, 0.05" pitch line of pins kinda makes going pin after pin easy. With what we're going to be able to sense from these pins, you should be able to detect the cro probe touching each pin (I had the probe attached to p11 when i took the lsio capture, resulting in its omission from the recorded take of phantom pulldowns). For each pin I have to insert the probe into the right SIL hole, and type eg 11 PIN L H F. But once able to detect the probe, you could just write a program to loop through the pins, 'type those commands' for wherever the probe is, even potentially collate the results. Anything feels possible, again.
You're going to want this Chip jmg.
Would you guys like clock-gating if it meant a 10% reduction in Fmax?
I think I'll vote for changing as little as possible so we don't go off the rails...
On the other hand, it seems that onsemi's tools seem to work pretty good (unless we just happened to get lucky) and maybe the danger of falling off of the rails is low...
This chip 'feels' a bit like a big V8 engine. You've got 8 cylinders, massive amounts of power available if you "floor it", and its going to chew through the gas if you do. But drive gracefully (spread the load between cogs) and everything is quite workable and able to run from USB (280mA at 5v running 180MHz torture test).
But bolted onto this throbbing V8 you have RCSLOW where you're only drawing a few hundred microamps, low enoug to be able to do battery apps we were previously dissuaded from when the forecast was 1mA leakage.
Part of me wants to just fix the known issues with this one. Gating it could leave us here again, with different issues. OnSemi will have to give a confidence level.
Not gating it, means we advance from here, ideally getting a really great chip, but with less than optimal power consumption.
That 280mA at 5V (before switching regulator) gives you 720 MIPS of 32-bit operations. It's got to cost something, in terms of power.
Running off a 20MHz crystal at 1MHz (using the PLL) takes 3mA at 1.8V. That's for 4 MIPS.
The RCSLOW mode runs at 20.6KHz and takes 100uA at 1.8V.
Quiescent current is only 34uA at 1.8V. You can park the P2 there, until reset.