[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