Testing current consumption while running primes.c - A comparison between P2 Eval RevA and RevB

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
1096 x 822 - 64K
1096 x 822 - 45K
«13

Comments

  • evanhevanh Posts: 8,390
    edited 2019-11-21 - 00:58:17
    I think the fuzz on revA Eval Board is from the VIO switching regulator. It's not very stable. The revB board only has the linear regulators for VIO so doesn't have that switcher.

    We have the vastness of the internet and yet billions of people decided to spend most of their time within a horribly designed, fake-news emporium of a website that sucks every possible piece of personal information out of you so it can sell it to others. And they see nothing wrong with that.
  • Do a run of RCSLOW ending in all cogs stopped. That will give you the quiescent whole board consumption that is useful for mapping any linear trends.
    We have the vastness of the internet and yet billions of people decided to spend most of their time within a horribly designed, fake-news emporium of a website that sucks every possible piece of personal information out of you so it can sell it to others. And they see nothing wrong with that.
  • samuellsamuell Posts: 517
    edited 2019-11-21 - 11:38:09
    evanh wrote: »
    I think the fuzz on revA Eval Board is from the VIO switching regulator. It's not very stable. The revB board only has the linear regulators for VIO so doesn't have that switcher.
    The scale of the fuzz seems to be too big to be just noise from that DC-DC converter, especially because it is running empty, as I'm using the local LDOs on all banks. However, the measuring board uses a 40mΩ resistor to sense current, and the resulting voltage difference gets amplified x50 by an INA180A2. So, any noise in millivolts will translate to a 25mA bump. Even though, that noise still has to bypass a low pass filter. And the time scale is set to 0.1s units, and each point is an average of five samples, making it virtually impossible to capture HF noise caused by the DC-DC converter.

    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.
    evanh wrote: »
    Do a run of RCSLOW ending in all cogs stopped. That will give you the quiescent whole board consumption that is useful for mapping any linear trends.
    How can I do that?

    Kind regards, Samuel Lourenço
  • Might be worth checking the capacitor sizes. I think the Rev A board had 4.7uF caps, which is relatively large and may allow more higher frequency noise.

    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
  • samuell wrote: »
    evanh wrote: »
    Do a run of RCSLOW ending in all cogs stopped. That will give you the quiescent whole board consumption that is useful for mapping any linear trends.
    How can I do that?

    HUBSET #1

    We have the vastness of the internet and yet billions of people decided to spend most of their time within a horribly designed, fake-news emporium of a website that sucks every possible piece of personal information out of you so it can sell it to others. And they see nothing wrong with that.
  • Just retested the RevA using the older measuring board, and the results are quite similar. The amplitude of the "noise" hasn't changed a bit, so this excludes any interference caused by the DC-DC converter. Any of the measuring boards that I've used so far are well filtered (with a 70Hz LPF) and, again, each point is the average of five individual samples. Thus, any HF noise doesn't get a chance to be measured.

    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
  • evanh wrote: »
    Do a run of RCSLOW ending in all cogs stopped. That will give you the quiescent whole board consumption that is useful for mapping any linear trends.
    evanh wrote: »
    samuell wrote: »
    evanh wrote: »
    Do a run of RCSLOW ending in all cogs stopped. That will give you the quiescent whole board consumption that is useful for mapping any linear trends.
    How can I do that?

    HUBSET #1
    Did another comparison, now with both P2s idle. My previous figures were wrong, after all. The RevA board consumes roughly 48mA on average, while the RevB board only consumes about 22mA. Funny, though, HUBSET #1 under TAQOZ had no effect. So, it is as if the P2 was already idle. Or I missed something.

    Kind regards, Samuel Lourenço
    1096 x 822 - 44K
    1096 x 822 - 46K
  • evanhevanh Posts: 8,390
    edited 2019-11-21 - 14:58:04
    I've just tested it myself using a bench-top supply set to 5.1 volts. HUBSET #1 (RCSLOW) is 5.2 mA.

    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!
    We have the vastness of the internet and yet billions of people decided to spend most of their time within a horribly designed, fake-news emporium of a website that sucks every possible piece of personal information out of you so it can sell it to others. And they see nothing wrong with that.
  • I don't know why there's so much noise on the current reading.
  • evanhevanh Posts: 8,390
    edited 2019-11-21 - 15:03:33
    Just using a multimeter on AC: The 60.6 mA from above has 4.5 mAac. And the 5.2 mA has 0.2 mAac. So those are RMS ripple values.

    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.
    We have the vastness of the internet and yet billions of people decided to spend most of their time within a horribly designed, fake-news emporium of a website that sucks every possible piece of personal information out of you so it can sell it to others. And they see nothing wrong with that.
  • evanh wrote: »
    I've just tested it myself using a bench-top supply set to 5.1 volts. HUBSET #1 (RCSLOW) is 5.2 mA.

    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 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.
    I was going to ask what was the methodology that you've used. Now, definitely, I'm going to retest this when I get home.
    cgracey wrote: »
    I don't know why there's so much noise on the current reading.
    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
  • I think the only fair comparison would be to place a Rev A chip on a Rev B board, or vise versa. I highly suspect you are seeing decoupling issues on the supply side of the switcher for the Rev A board.
    Terry's Workbench

    Feel the need for speed between your PC's com port and Prop?
    Try the FTDI 245 and the FullDuplexParallel Object.
    Check out my spin driver for the Parallax "96 x 64 Color OLED Display Module" Product ID: 28087
    22FPS video from the P2 on the Parallax "96 x 64 Color OLED Display Module" https://www.youtube.com/watch?v=ja84rf38QHM
  • evanhevanh Posts: 8,390
    edited 2019-11-21 - 15:09:20
    samuell wrote: »
    I was going to ask what was the methodology that you've used. Now, definitely, I'm going to retest this when I get home.
    Note I've made a significant correction to my testing.

    We have the vastness of the internet and yet billions of people decided to spend most of their time within a horribly designed, fake-news emporium of a website that sucks every possible piece of personal information out of you so it can sell it to others. And they see nothing wrong with that.
  • ke4pjw wrote: »
    I think the only fair comparison would be to place a Rev A chip on a Rev B board, or vise versa. I highly suspect you are seeing decoupling issues on the supply side of the switcher for the Rev A board.
    Any decoupling issues would appear as HF noise, and any of the USB test switches that I've used to measure the current are able to filter that out. I could measure the voltage across the sense resistor on the measuring board while running "primes.c" to rule this out for good.
    evanh wrote: »
    samuell wrote: »
    I was going to ask what was the methodology that you've used. Now, definitely, I'm going to retest this when I get home.
    Note I've made a significant correction to my testing.
    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
  • jmgjmg Posts: 14,149
    cgracey wrote: »
    I don't know why there's so much noise on the current reading.

    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 ?
  • samuellsamuell Posts: 517
    edited 2019-11-21 - 20:55:38
    jmg wrote: »
    cgracey wrote: »
    I don't know why there's so much noise on the current reading.

    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 ?
    The program used as the same for both cases. The code doesn't have anything special. You can see the same attached.

    Kind regards, Samuel Lourenço
    c
    c
    10K
  • Evan ( @evanh ),

    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
  • samuellsamuell Posts: 517
    edited 2019-11-21 - 23:11:09
    @jmg ,

    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
    1096 x 822 - 63K
    1096 x 822 - 58K
    1024 x 768 - 67K
  • samuell wrote: »
    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.
    Oh, yeah, that use of RDLUT is illegal on pre-v33 assemblers. FlexGUI may have a config option for specifying which revision silicon you want to target.

    We have the vastness of the internet and yet billions of people decided to spend most of their time within a horribly designed, fake-news emporium of a website that sucks every possible piece of personal information out of you so it can sell it to others. And they see nothing wrong with that.
  • samuellsamuell Posts: 517
    edited 2019-11-21 - 23:43:45
    evanh wrote: »
    samuell wrote: »
    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.
    Oh, yeah, that use of RDLUT is illegal on pre-v33 assemblers. FlexGUI may have a config option for specifying which revision silicon you want to target.
    As for FlexGUI, I made sure that I was targeting the right revision. It shows the error "invalid addressing mode for first operand of rdlut" on line 78 if I try to compile for P2a. It runs OK for P2b. Probably, the RevA board could be loaded via FlexGUI that way. Anyway, that objective was accomplished. Thanks!

    Kind regards, Samuel Lourenço
  • evanhevanh Posts: 8,390
    edited 2019-11-21 - 23:56:00
    EDIT: Ah, I misread you there. That's all correct, the assembly is written assuming "2b" option is set always. It uses that RDLUT to detect which revision hardware it is running on and adapts itself accordingly.

    PS: I've not used FlexGUI so didn't know what options it has.

    We have the vastness of the internet and yet billions of people decided to spend most of their time within a horribly designed, fake-news emporium of a website that sucks every possible piece of personal information out of you so it can sell it to others. And they see nothing wrong with that.
  • Most of the hardware changes are not in the instruction set, so very unlikely that the same instruction will assemble differently between the two revisions. The one particularly notable change is the encoding of PTRx referencing into hubRAM and lutRAM - Which has gained additional features in revB, but it sacrificed half the offset range that revA had.

    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.

    We have the vastness of the internet and yet billions of people decided to spend most of their time within a horribly designed, fake-news emporium of a website that sucks every possible piece of personal information out of you so it can sell it to others. And they see nothing wrong with that.
  • @evanh,
    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.
    My Prop boards: P8XBlade2 , RamBlade , CpuBlade , TriBlade
    P1 Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    P1: Tools (Index) , Emulators (Index) , ZiCog (Z80)
    P2: Tools & Code , Tricks & Traps
  • evanhevanh Posts: 8,390
    edited 2019-11-22 - 11:53:16
    Here's the more recent core VDD measurements - https://forums.parallax.com/discussion/comment/1478835/#Comment_1478835
    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.
    VIO%20quiescent.png
    1091 x 759 - 36K
    We have the vastness of the internet and yet billions of people decided to spend most of their time within a horribly designed, fake-news emporium of a website that sucks every possible piece of personal information out of you so it can sell it to others. And they see nothing wrong with that.
  • The quiescent current is very low. Amazing!

    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
    1147 x 768 - 210K
  • samuellsamuell Posts: 517
    edited 2019-11-22 - 16:24:30
    I've run the tests again using the "primes.c" program, following the same procedure as in post #1, but using the setup in the post above. In both cases, RevA and RevB, the cleaner Vbus as supplied by the uCharge made a difference. The USB test switch used for the current measurements, behaved pretty much transparently, having no effect whatsoever, as expected.

    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
    1096 x 822 - 50K
    1096 x 822 - 46K
  • evanh wrote: »
    Here's the more recent core VDD measurements - https://forums.parallax.com/discussion/comment/1478835/#Comment_1478835
    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.
    VIO%20quiescent.png

    @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.
    My Prop boards: P8XBlade2 , RamBlade , CpuBlade , TriBlade
    P1 Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    P1: Tools (Index) , Emulators (Index) , ZiCog (Z80)
    P2: Tools & Code , Tricks & Traps
  • Cluso99 wrote: »
    Did you actually test the VIO to the P2 pins using up to ~6.5V?
    Yep, only the once so far. Now that I've been reminded I'm intending to have another shot at lower temperature. I suspect the curve to move left quite a ways.

    We have the vastness of the internet and yet billions of people decided to spend most of their time within a horribly designed, fake-news emporium of a website that sucks every possible piece of personal information out of you so it can sell it to others. And they see nothing wrong with that.
  • evanhevanh Posts: 8,390
    edited 2019-11-23 - 02:53:14
    Just completed a retest of VDD loading on revB silicon. This time with a couple of idling hubexec programs. I've tuned the number of instructions in each to accentuate respective behaviour.
    =====================
       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 V 
    

    The 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.
    We have the vastness of the internet and yet billions of people decided to spend most of their time within a horribly designed, fake-news emporium of a website that sucks every possible piece of personal information out of you so it can sell it to others. And they see nothing wrong with that.
  • Evan,

    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
Sign In or Register to comment.