[MAGEEC] Chip variations: tests, results, and graphs

Simon Hollis cssjh at bristol.ac.uk
Mon Jul 28 12:13:25 BST 2014


Hi James,

These are some really interesting results. The magnitude of the variation
is unexpected to me, and the inverse correlation with temperature even more
so.

A couple of thoughts:

1) Was the same (USB) power source used on both days. A higher supply
voltage would give a higher power reading even if everything else remained
the same. We have the voltage data, so can you check the voltage
measurements on both occasions.

2) Perhaps the oscillator crystal has a positive temperature coefficient on
frequency? So a hotter day would lead to higher frequency operation and
less leakage?

Simon


On 27 July 2014 18:24, James Pallister <James.Pallister at bristol.ac.uk>
wrote:

>  Thanks.
>
> I've focussed on RAM/flash/ALU at the moment, since this is likely what we
> will have to cope with when using the compiler, in MAGEEC. Hopefully the
> variability that may occur the other areas you list won't be affected by
> compiler optimizations too much. However, for the purposes of completeness
> I may extend the tests to do EEPROM and some other peripheral access also.
>
> Cheers,
> James
>
>
> On 27/07/14 17:56, Alex J Lennon wrote:
>
>
> Ah OK. Thanks for the explanation. Very interesting work.
>
> It occurs to me that there may be some interesting results to be obtained
> from testing running, say, repeated interrupts, running timers, access to
> EEPROM, GPIO reads, ADC sampling and so forth?
>
> I guess it would depend what you're trying to look at specifically.
>
> Thanks again,
>
> Alex
>
> On 27/07/2014 17:47, James Pallister wrote:
>
> Ah yes, the flash tests were purely for read access from different areas
> of flash, based on the idea that there may be silicon variation between
> parts of the address space.
>
> It was actually program execution from different areas of flash, by
> putting a tight loop in a specific area and measuring the power. For
> example (flash1):
>
>     .balign 2048
>     .rept 6        ; Change between 0, 6, 126, and 2046 for flash0,
> flash1, flash2, and flash3
>     nop
>     .endr
> loop:
>     nop
>     inc r16
>     cpse r0, r16
>     jmp loop
>
>
> The procedure for each test:
> 1. Invoke the bootloader, and upload program code
> 2. The program code runs, and toggles a pin to trigger the energy
> measurement
> 3. When the test is finished, the ATMEGA328 toggles the pin again to stop
> the measurement
> 4. Measurement results are downloaded from the energy measurement board.
>
> I haven't done any flash writing/erasing tests, but I agree it would be
> interesting to do some. I'd expect the power during a write/erase to be
> much higher.
>
> Hope this helps,
> James
>
> On 27/07/14 17:32, Alex J Lennon wrote:
>
>
> On 27/07/2014 17:27, James Pallister wrote:
>
> No JTAG - the chips are flashed with a bootloader, which is only active on
> chip reset. Everything is programmed via a USB-to-serial thingy.
>
>
> Sorry, I don't think I'm understanding fully James. So the flash area
> tests are via JTAG? I guess that would mean that the test is a read only
> test?
>
> (I'm just asking because I'm quite interested in power utilisation during
> write/erase cycles vs read. If you're not doing that could I suggest it
> might be an interesting test?)
>
> BR. Alex
>
>  On 27/07/14 17:25, Steve Kerrison wrote:
>
> Is JTAG connected during test runs? Interested to know how much difference
> that makes, although it should be constant thus irrelevant.
> On 27 Jul 2014 17:13, "James Pallister" <James.Pallister at bristol.ac.uk>
> wrote:
>
>>  Hi All,
>>
>> Some preliminary findings on variations in the ATMEGA328 chips.
>>
>> I've tested 28 chips. For each chip 9 tests were ran:
>>
>>   flash0
>>  Test the area of flash 0x0800-0x0810
>>   flash1
>>  Test the area of flash 0x080C-0x081C  flash2
>>  Test the area of flash 0x08FC-0x090C  flash3
>>  Test the area of flash 0x0FFC-0x100C  ram0
>>  Repeatedly access 0x0000 - 0x0020
>>   ram1
>>  Repeatedly access 0xF007 - 0xF017
>>   alu
>>  Perform combinations of mul, fmul, inc and dec
>>   nop
>>  Lots of nops
>>   branch
>>  Repeatedly branch randomly in low flash
>>
>> Each test was run 8 times, and outliers excluded. All were run in the
>> same harness, with the same crystal, resistors, etc.
>>
>> Results across each test. These show the distributions of the
>> measurements taken, where the distribution consists of the 28 chips.
>>
>>
>> From the first graph: there is a significant different, even on a day to
>> day basis. I'm not sure what causes this - I'd expect the power to be lower
>> at lower temperatures, which we don't see.
>>
>> For each chip:
>>
>> Mean power for each chip:
>>
>>
>>
>> The average power changes quite a lot, going from < 80mW to > 100mW. In
>> almost all cases, the average power was higher on Saturday - not sure why
>> this is, the temperature difference was only 3-4 degrees (and I'd expect
>> the temperature to go down with lower temperature).
>>
>> The chips tend to vary as a whole, e.g. rather than the ALU varying
>> significantly in one part rather than another. The following graph marks
>> the average power for each test, divided by test type (different
>> color/marker combinations) per chip. This should allow hopefully allow us
>> to do a calibration run first.
>>
>> Legend for the above graph:
>>   Blue cross
>>  ram1
>>   Red star
>>  ram0
>>   Green plus
>>  alu
>>   Black plus
>>  flash3
>>   Green cross
>>  flash2
>>   Blue star
>>  flash1
>>   Red plus
>>  flash0
>>   Black star
>>  nop
>>
>>
>> Any thoughts / ideas for more tests are welcome.
>>
>>
>> James
>>
>
>
>
> _______________________________________________
> mageec mailing listmageec at mageec.orghttp://mageec.org/cgi-bin/mailman/listinfo/mageec
>
>
>
> _______________________________________________
> mageec mailing list
> mageec at mageec.org
> http://mageec.org/cgi-bin/mailman/listinfo/mageec
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mageec.org/pipermail/mageec/attachments/20140728/4425e3ca/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 176160 bytes
Desc: not available
URL: <http://mageec.org/pipermail/mageec/attachments/20140728/4425e3ca/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 120718 bytes
Desc: not available
URL: <http://mageec.org/pipermail/mageec/attachments/20140728/4425e3ca/attachment-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 79329 bytes
Desc: not available
URL: <http://mageec.org/pipermail/mageec/attachments/20140728/4425e3ca/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 44187 bytes
Desc: not available
URL: <http://mageec.org/pipermail/mageec/attachments/20140728/4425e3ca/attachment-0007.png>


More information about the mageec mailing list