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

James Pallister James.Pallister at bristol.ac.uk
Mon Jul 28 14:29:53 BST 2014


> But important to know. Does using a cuttlefish reduce this problem?  J
Perhaps - it will remove the +-0.5mW difference I'm seeing from moving
the chip in the ZIF socket. However, all of the pins on the ATMEGA328
are just brought out to headers in the cuttlefish - they would need to
be grounded separately. I get quite consistent readings if the pins
aren't grounded (it just seems to combine with the ZIF socket in a bad
way), so with calibration it may not be such an issue.

On 28/07/14 13:59, Jeremy Bennett wrote:
> On 28/07/14 13:48, James Pallister wrote:
>> *sigh*
>>
>> It seems a combination of changing the placement of the chips in the
>> socket and some of the pins not being grounded (despite being tristated
>> in the chip) may be responsible for some (or a lot) of the variation.
>> I'll repeat the tests whe I get chance.
> But important to know. Does using a cuttlefish reduce this problem?  J
>
>> (Also the same power supply was used - the voltages seem to be stable
>> around 5.18-5.22)
>>
>> James
>>
>> On 28/07/14 12:13, Simon Hollis wrote:
>>> 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
>>> <mailto: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
>>>>>>>>     <mailto: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 list
>>>>>>>     mageec at mageec.org <mailto:mageec at mageec.org>
>>>>>>>     http://mageec.org/cgi-bin/mailman/listinfo/mageec
>>>
>>>     _______________________________________________
>>>     mageec mailing list
>>>     mageec at mageec.org <mailto:mageec at mageec.org>
>>>     http://mageec.org/cgi-bin/mailman/listinfo/mageec
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> mageec mailing list
>>> mageec at mageec.org
>>> http://mageec.org/cgi-bin/mailman/listinfo/mageec
>>
>>
>> _______________________________________________
>> mageec mailing list
>> mageec at mageec.org
>> http://mageec.org/cgi-bin/mailman/listinfo/mageec
>>
>




More information about the mageec mailing list