02-16-2016 04:38 AM
I have observed, what to me is, unexpected behavior in regards to the power consumption of the ZedBoard (Zynq-7000) when a processing core accesses the on board DDR memory in certain situations. I have performed a number of tests were I monitor the power consumption of either the A9 core with DDR or a softcore Microblaze with DDR. For both setups I have found cases where the power consumption of the board when actively running a program that frequently accesses DDR is lower than when the processor is sitting idle. This does not make sense to me as I would expect the power when active to be the power of the core + the power to access DDR versus just the power of the core when idle. I will describe a few of the cases I have tested and what I observed. In all cases the “active” execution is running a version of GUPS (giga updates per second), a program that repeatedly accesses a random location in a memory array of a controllable size.
Setup: Microblaze connected to DDR through the AXI HP0 and HP1 ports of the Zynq A9. The local microblaze memory is only used for startup code. All other code and data is in DDR.
Case 1: Microblaze with 32 kB I and D caches running GUPs with a 192MB working set. When execution is complete the processor is put to sleep using the “sleep” assembly instruction
Observation 1a: With the I cache enabled and D cache disabled (meaning all accesses to the array to be updated should go to DDR) the board level power consumption is 7.2% *lower* when actively running than when put to sleep.
Observation 1b: When both caches are disabled (meaning all accesses should go to DDR), power consumption is 4.7% *lower* when actively running than when put to sleep
Case 2: Microblaze with 32 kB I and D caches running GUPs with 4k working set (meaning it should fit within cache). When execution is complete the processor is put in a loop that continuously accesses the same index of the data array and sums it into a dummy variable.
Observation 2a: With both caches disabled (meaning all accesses should go to DDR), power consumption is 10.6% *lower* in the busy wait than when actively running.
Observation 2b: With both caches enabled (meaning most/all accesses should hit in caches), power consumption is 1.1% higher when actively running than when put to sleep.
Setup: Zynq-7000 A9 connected to DDR.
Case 3: A9 running GUPs with 384 MB working set (meaning most data accesses should go to DDR). When execution is complete the processor is put in idle loop similar to Case 2.
Observation 3a: With caches enabled power consumption is 0.1% *lower* during active execution than when in busy wait.
These observations are counter to a number of my expectations from traditional systems.
Expectation 1: A running core that misses in the cache (or has not cache) and must frequently go to DDR should have higher power consumption than a sleeping core. The former has the power of both the core and DDR while the latter has just the power of a sleeping core (and basic DDR refresh). Observations 1a and 1b are counter to this expectation.
Expectation 2: A core hitting in a local cache should consume less power than a core that has to frequently access DDR. Observations 2a, 2b, and 3a are all counter to this expectation.
I am interested in two items related to the above observations:
02-23-2016 09:47 PM
Moved post to Zynq All Programmable SoC Board
04-05-2016 04:37 PM
04-06-2016 10:26 AM
I'm not sure I quite understand your recommendation. Are you suggesting I use OCM instead of DDR? If so, I'm not sure how that would work as OCM is only 256kB while DDR offers 512MB. Additionally, the observed unexpected behavior was not restricted to just the Microblaze, I also saw odd behavior with the A9+DDR.
04-20-2016 06:34 AM
Do you have any comment on my previous question? Right now I'm not sure a) the possibility or b) the benefit of your suggestion (as I understand the suggestion at least).
04-20-2016 11:44 AM
04-26-2016 10:26 AM
I looked into a few items, but still don't have a clear expalantion.
1) I tried a microblaze + DDR with 2 different cache sizes, 32kB and 4kB I & D cache, running Case 1 from above. The change in power consumption during idle for this 8X decrease in cache size was negligible for the overall system power (<0.2%). It also did not change the "inverted" behavior where idle consumed more power than running gups that should constantly have to go to DDR. This would seem to suggest that it is not cache size issue.
2) As you suggested, I looked into the DRAM termination for the idle state. The reg_phy_idle_local_odt field of DRAM_ODT_reg was set to 0x3. I initially thought this might imply a high ODT in idle. However, when I changed this value to 0x0, the power consumption was substantially higher (~25%). This would seem to suggest that the 0x3 setting is actually no ODT when in idle and that ODT is not the problem (unless there is some other aspect to look into). I also ran a test with reg_phy_idle_local_odt set to 0x2 and while the power consumption was less than 0x0, it was still much higher than 0x3.
3) While I don't think this should make a difference, I will also note that I am running the microblaze+DDR tests with the Microblaze Debug Module enabled.
Are there other suggestions or items I may be overlooking? Thanks.
05-26-2016 09:26 AM
It's been a month since my reply to your post. As noted in the reply, it doesn't seem that any of the noted items are the cause of the problem. Are there other things I should consider? Thanks.