[Coco] 6809/6309 Power Analysis

Stephen Adolph twospruces at gmail.com
Thu Jan 21 18:26:24 EST 2010


how many supplies on the 6809?
The other consideration is - how do the supplies power the different
blocks in the chip?

Or maybe not...I suppose the "core" is running purely from +5V.



On Thu, Jan 21, 2010 at 6:16 PM, Lothan <lothan at newsguy.com> wrote:
> I'm not so sure this presents that big of a problem. If the intent to is to
> measure pure processor current, you're probably right; however, I think
> think current sourced to read/write memory and used by the circuits in
> support of the processor is meaningful if the intent to support greener
> development methodology as a new branch of science. It could certainly lend
> credence to register-based optimizations to reduce current drain accessing
> memory if that's the scope.
>
> --------------------------------------------------
> From: "Christian Lesage" <hyperfrog at gmail.com>
> Sent: Thursday, January 21, 2010 5:55 PM
> To: "CoCoList for Color Computer Enthusiasts" <coco at maltedmedia.com>
> Subject: Re: [Coco] 6809/6309 Power Analysis
>
>> I believe it's going to be tricky if you intend to measure the power
>> consumption related to the execution unit alone. You have to remember that
>> part of the total power is delivered to the external busses and varies with
>> the input or output levels as well as on the load. For instance, no matter
>> what instruction will be be executed, the power consumption could differ
>> whether you output $FFFF or $0000 on the address bus in order to fetch it.
>> In one case, you are sourcing current, while in the other case, you are
>> sinking current. The same applies to the data bus, but in addition to that,
>> whether you read or write a value will also affect power consumption. As
>> regards the address bus, your program will be outputting a value there
>> whenever it needs to read a new program or data byte. You only have a
>> limited control over the addresses being output. As regards the data bus,
>> your program will always be at least fetching a new program byte every few
>> cycles, and again, you have a limited control over what's being read. I
>> believe the particular opcode of a given instruction as well as the
>> operand's value could affect power consumption (e.g. reading $FF could
>> require more/less power than reading $00). It also depends on whether the
>> busses are buffered from the memory and I/O circuits, and how "efficient"
>> the buffers are (e.g. driving a HCT CMOS buffer requires less power than
>> driving an LS TTL one).
>>
>> Christian
>>
>> Boisy G. Pitre wrote:
>>>
>>> Calling all hardware/electrical engineering gurus on the list...
>>>
>>> As some of you know, I am working on my thesis this semester where I am
>>> exploring power-aware compiler optimizations.  I've selected (surprise) the
>>> 6809/6309 as my evaluation processor and will be retooling RELIC to use the
>>> power information that I am attempting to gather to make decisions about
>>> instruction use based on the current that they draw.
>>>
>>> I'm hoping you hardware gurus can give me some input on the measurement
>>> part, in which I am attempting to determine the current draw of the 6809
>>> when executing specific instructions.  The absolute value is not important;
>>> it is the relative difference of current draw for different instructions
>>> that I need to move forward.
>>>
>>> Just to give you an idea of the type of equipment that I have access to
>>> at the UL campus:
>>>
>>> - Agilent Technologies MS06104A Mixed Signal Oscilloscope with analog
>>> probes as well as two 54620-61601 8-wire Logic Analyzer probe cables
>>> - Agilent Portable Logic Analyzer, don't have the exact model number but
>>> looks like a microwave oven and I am told costs around $55K.
>>>
>>> The ideas brought up so far for measuring current at the instruction
>>> level:
>>> - use a PIC with an A/D convertor to measure the voltage.
>>> - use a shunt resistor (james recommended this method to me as well in
>>> private email) to measure current and outlined here:
>>> http://jet-server.commtest.co.nz/kb2/11624.htm
>>>
>>> On the software side, I have constructed several test executables that
>>> run under NitrOS-9 and execute a particular instruction over and over (with
>>> interrupts masked of course). The baseline measurement instruction is CWAI,
>>> which puts the processor in sleep mode.  The code looks something like this:
>>>
>>>    cwai #^IntMasks
>>>
>>> With interrupts masked there should be no activity and the cwai should
>>> put the processor to a wait mode.  I would then take the measuring device of
>>> choice and measure the current for a fixed amount of time (say 1 second).
>>>
>>> Afterwards, I would run the following program which has a series of 100
>>> MUL instructions (MUL is chosen for presumably higher use of CPU):
>>>
>>>     ldd       #$0000
>>>     orcc     #IntMasks
>>> toploop:
>>>     mul
>>>     mul
>>>     mul
>>>     ....
>>>     mul          * 100th instruction
>>>     bra       toploop
>>>
>>> And again, use the same measuring device to measure the current draw for
>>> 1 second.
>>>
>>> With a low and high mark, I could then begin measuring other instructions
>>> and see where they fall with the high-low current range.
>>>
>>> My concern is the accuracy of the measurement, since I expect that the
>>> difference in current draw between instructions is small.  This is just a
>>> guess, but the level of accuracy that I would need to measure the difference
>>> in current draw between instructions would have to be AT LEAST 10e-3, or
>>> .001 amp (1 milliamp).
>>>
>>> Suggestions?  How would you guys do this? Do I really need the high
>>> dollar equipment that I have access to, or do I need a high accuracy,
>>> sensitive multimeter that can measure current in very very small amounts?
>>>
>>> Any input from the hardware experts here would be much appreciated.
>>> --
>>> Boisy G. Pitre
>>> http://www.tee-boy.com/
>>>
>>>
>>>
>>> --
>>> Coco mailing list
>>> Coco at maltedmedia.com
>>> http://five.pairlist.net/mailman/listinfo/coco
>>>
>>>
>>
>>
>> --
>> Coco mailing list
>> Coco at maltedmedia.com
>> http://five.pairlist.net/mailman/listinfo/coco
>>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>



More information about the Coco mailing list