Testing current consumption while running primes.c - A comparison between P2 Eval RevA and RevB
samuell
Posts: 554
in Propeller 2
Hi,
I've been doing some current measurement tests on my own, using the customary prime number calculation program (click on the link to refer to it). Of course something similar was done here, and if you want a full comparison, then you should refer to the post: http://forums.parallax.com/discussion/170380/new-p2-silicon/p1. However, nevertheless, I thought it would be useful to do some tests of my own, and share my findings.
Basically, I measure the USB current as consumed by the boards, for both Rev. A and Rev B. The tests are run using "primes.c" loaded via FlexGUI. The program executes at 160MHz by default. For both boards, I measured the current from attachment to detachment of the USB cable. The program execution procedure consists on finding prime numbers between 1 to 100000, and then between 1000000000 to 1000100000, while measuring the current on the go. The results that the program outputs are not within the scope of this analysis.
So, attached are the results that I've got with my RevA and RevB boards. There is also a zip file containing the raw data. In both graphs, you can see that the current dips while the program calculates prime numbers (first between 1 to 100000, and then between 1000000000 to 1000100000). I find this odd, because the P2 is actually consuming more power while waiting for user input than when doing the actual calculations. Perhaps the explanation is that the program is also busy outputting results to serial when performing calculations, hence the drop in power consumption, but I have to confirm this with both boards.
However, it is confirmed that the new revision consumes roughly half the power, and even less when the P2 is not programmed. In fact, from the start, the RevA consumes 20mA, while the RevB only consumes 6mA! One thing though, is that the graph for RevA shows a lot of peaks and dips. This is not noise or anything, as each data point uses 5 samples, and the electronics on the board, that is being used to take the measurements, are very well filtered. The graph for the RevB board is very smooth, except when the program is calculating big prime numbers between 1000000000 and 1000100000.
P. S.: Mind that the time scale is set in units of 0.1s each (so, 10 points per second, approximately). Will post more results soon!
Kind regards, Samuel Lourenço
I've been doing some current measurement tests on my own, using the customary prime number calculation program (click on the link to refer to it). Of course something similar was done here, and if you want a full comparison, then you should refer to the post: http://forums.parallax.com/discussion/170380/new-p2-silicon/p1. However, nevertheless, I thought it would be useful to do some tests of my own, and share my findings.
Basically, I measure the USB current as consumed by the boards, for both Rev. A and Rev B. The tests are run using "primes.c" loaded via FlexGUI. The program executes at 160MHz by default. For both boards, I measured the current from attachment to detachment of the USB cable. The program execution procedure consists on finding prime numbers between 1 to 100000, and then between 1000000000 to 1000100000, while measuring the current on the go. The results that the program outputs are not within the scope of this analysis.
So, attached are the results that I've got with my RevA and RevB boards. There is also a zip file containing the raw data. In both graphs, you can see that the current dips while the program calculates prime numbers (first between 1 to 100000, and then between 1000000000 to 1000100000). I find this odd, because the P2 is actually consuming more power while waiting for user input than when doing the actual calculations. Perhaps the explanation is that the program is also busy outputting results to serial when performing calculations, hence the drop in power consumption, but I have to confirm this with both boards.
However, it is confirmed that the new revision consumes roughly half the power, and even less when the P2 is not programmed. In fact, from the start, the RevA consumes 20mA, while the RevB only consumes 6mA! One thing though, is that the graph for RevA shows a lot of peaks and dips. This is not noise or anything, as each data point uses 5 samples, and the electronics on the board, that is being used to take the measurements, are very well filtered. The graph for the RevB board is very smooth, except when the program is calculating big prime numbers between 1000000000 and 1000100000.
P. S.: Mind that the time scale is set in units of 0.1s each (so, 10 points per second, approximately). Will post more results soon!
Kind regards, Samuel Lourenço
1096 x 822 - 64K
1096 x 822 - 45K
Comments
As a litmus test, I will perform the same measurement with P2Eval RevA and an older measuring board, that uses a 100mΩ resistor and an INA180A1 that only has a gain of 20. So, we should see a 2.5 times noise reduction, if it is in fact noise that we are seeing.
How can I do that?
Kind regards, Samuel Lourenço
The regulator arrangement is different on ES revB, I'm not sure what is used now
Just a thought/observation. Not criticising the choices, just may explain a bit of what you're seeing
HUBSET #1
I would bet that this rather low frequency noise may be caused by the P2 chip itself. I wonder if Chip could give us an insight on that.
Kind regards, Samuel Lourenço
Kind regards, Samuel Lourenço
But what's likely the easiest way to compare is the power up idle state where the prop2 is waiting for serial input. For this I get 60.6 mA 19.4 mA at 5.1 Volts. A lower voltage increases the current.
PS: No, I didn't use TAQOZ. I downloaded one of my earlier test programs that does lots of waits so is effectively stopped. See attached.
PPS: Using a rev B Eval Board.
EDIT: Correction from 60.6 to 19.4 because I'd forgotten the EEPROM was booting. Oops!
EDIT: Correction, the 60.6 was with the EEPROM booting. The correct power idle draw at 5.1 Volts is 19.4 mA, with a lower 0.1 mAac ripple than in RCSLOW.
If you are referring to the tests done using "primes.c", yes, the fuzz is clearly caused the the board (especially the RevA). Regarding the previous tests done with the P2 "idle", I'll have to check if some of the noise is generated by the measuring board (say, the USB test switch). For that I'll do a measurement using a resistor as load.
In summary, I'll have to repeat the idle current measurement tests using Evan's program, plus an extra measurement to see what degree of noise is due to the DC-DC converter inside the test switch itself.
Kind regards, Samuel Lourenço
Thanks! I don't have any program inside the EEPROM, and all switches are off in both boards. As long as your program runs, I'll be fine.
Kind regards, Samuel Lourenço
It's understandable ES2 has lower current than ES1, & maybe boards can explain some base ripple differences but more puzzling is
why the ES2 has one test that varies ripple significantly ? What is special about that code ?
Kind regards, Samuel Lourenço
Finally, I was able to run tests using your program. I should mention that FlexGUI shows a compilation error, as well as PNut v32i. I had to test both boards with PNut v33L, and surprisingly, it worked for both boards.
As you can see, low power current consumption is circa 13mA for the RevA board and just 7mA for the RevB board. The higher plateau represents the current before programming.
More testing will follow, today and tomorrow. There are some points that I want to clear for good.
Kind regards, Samuel Lourenço
It seems that the background noise is created by the nasty USB hub supply. I did some measurements using a 100Ω resistor as a load, and managed to find the same kind of background noise. If I use a USB charger (the uCharge) instead, I get a significantly cleaner graph.
So, I'll have to retest with "primes.c" again, but this time using uCharge to supply the boards, via the USB test switch (so I can measure the current).
Kind regards, Samuel Lourenço
Kind regards, Samuel Lourenço
PS: I've not used FlexGUI so didn't know what options it has.
So, that difference is used there just as a detection mechanism for altering the mode settings sent to the streamer. The streamers had a bit of an overhaul in revB.
Just went searching for all your current tests.
Do you have a link by chance?
And are there any figures for the 3V3 rail?
I'm curious to know what we might expect on the 3V3 rail excluding any I/O drive that may be necessary other than the serial.
Here's the one where we were investigating ideas for the sudden On Semi failures - https://forums.parallax.com/discussion/comment/1477672/#Comment_1477672
I started a more extensive test set for the VIO quiescent currents. I intended to try different temperatures but never got there. NOTE: This graph covers only 8 of 64 I/O, and crystal operation would be more too.
PS: The graph data combines two rounds of testing that were at slightly different room temperature so there is a kink at 5.6 volts. The other kink at 4.2 volts is due to rounding in my note taking - You can see the inverse curve of the line below 4.2 volts.
Anyway, I'll redo some of the tests. I've "eliminated" the noisy hub power supply, and all the Vbus to the P2 Eval boards comes from the uCharge module (lower right corner in the photo). The current measuring board will be the same, and it is the ITUSB2 USB Test Switch (experimental, not released yet, but known good current measurement capability- upper right corner).
Kind regards, Samuel Lourenço
I was surprised to see much less noise in the case of the RevA board. Most of the fuzz we saw earlier was perhaps exacerbated due to the nature of the power supply used to supply the USB hub, which in turn supplied its VBus to the eval board via the USB test switch. There is still some residual "fuzz", which is clearly caused by the P2 prototype, but it is no longer worsened by the low quality power supply used before.
In the case of the RevB board, that residual noise we saw earlier is not there anymore. Again, this was caused by the different nature of the power supplies that were used to supply Vbus to the board. However, the difference was not extreme, and pretty much expected.
I'll have to redo the low power tests using Evan's program, but I'll have to leave them for tomorrow. As before, you can find the raw data in a zip file, as well as the graphs attached.
Edit: Comparing the graphs, I concluded that the power consumption decreased a bit for both of the boards, while retesting with the cleaner power supply. This probably was due to the fact that the USB hub power supply previously used is weak and tends to sag quite a bit. In face of a lower voltage, it is natural that the DC-DC converter on any of the P2 Eval boards will demand more current. The fact that the hub power supply is weak also explains the increased noise.
Kind regards, Samuel Lourenço
@evanh,
Did you actually test the VIO to the P2 pins using up to ~6.5V?
Anyway, that's a nice low figure for the VIO current so we are pretty much governed by what is connected to the I/O pins to determine the current - which is pretty much what I expected although I was expecting there may be a few mA of idle current.
Thanks for the links - I am just on my way out so I'll take a look at them later.
===================== One Cog Running ===================== | Prop2 revB-globtop (VDD = 1.86 V) | PGM0 PGM1 PGM2 PGM3 PGM4 PGM5 --------|------------------------------------------------------- RCSLOW | 90 uA 86 uA 94 uA 103 uA 92 uA 92 uA RCFAST | 33.1 mA 28.9 mA 38.9 mA 47.4 mA 34.1 mA 32.1 mA 50 MHz | 66.1 mA 57.8 mA 77.4 mA 94.3 mA 68.1 mA 64.2 mA 100 MHz | 132 mA 115 mA 154 mA 187 mA 135 mA 128 mA 180 MHz | 234 mA 205 mA 273 mA 333 mA 242 mA 228 mA 250 MHz | 322 mA 282 mA 376 mA 457 mA 334 mA 315 mA 300 MHz | 385 mA 337 mA 448 mA 546 mA 398 mA 376 mA 360 MHz | 459 mA 403 mA 535 mA 650 mA 476 mA 449 mA | 1.828 V 1.831 V 1.823 V 1.817 V 1.827 V 1.829 V ======================== Eight Cogs Running ======================== | Prop2 revB-globtop (VDD = 1.86 V) | PGM0 PGM1 PGM2 PGM3 PGM4 PGM5 --------|------------------------------------------------------- RCSLOW | 113 uA 82 uA 149 uA 204 uA 126 uA 114 uA RCFAST | 59.1 mA 23.5 mA 101 mA 169 mA 75.8 mA 61.0 mA 50 MHz | 118 mA 47.3 mA 201 mA 335 mA 151 mA 121 mA 100 MHz | 233 mA 94.1 mA 395 mA 653 mA 299 mA 241 mA 180 MHz | 414 mA 168 mA 693 mA 1136 mA 532 mA 429 mA 250 MHz | 570 mA 235 mA 943 mA 1530 mA 729 mA 590 mA 300 MHz | 676 mA 277 mA 1112 mA 1794 mA 868 mA 703 mA 360 MHz | 802 mA 331 mA 1309 mA 1970 mA 1031 mA 836 mA | 1.810 V 1.835 V 1.784 V 1.749 V 1.799 V 1.810 VThe measurements have been done with a little more care this time. There is a couple of changes: The inline current measuring wires have been upgraded and shortened, resulting in slightly higher readings in general. And I found that my supposedly good multimeter is not so good at microAmps so swapping them over for RCSLOW measuring made a difference there. It has developed a habit of losing power too, so I guess it's a little decrepit now.
Source code attached.
Here's link to earlier testing with revA silicon - https://forums.parallax.com/discussion/comment/1478835/#Comment_1478835
Your figures are very high for eight cores. So, it seems that "primes.c" is spending more time outputting to serial than actually performing calculations. I have to figure out why. Definitely, on my "to do" list.
Kind regards, Samuel Lourenço