1. Home
  2. Field-Programmable Gate Arrays
  3. Power Estimation of Microblaze (Power PC) based architectures

Power Estimation of Microblaze (Power PC) based architectures

Hi

I'm trying to estimate the power consumption of an architecture based on either Microblaze or PowerPC running a simple application (bubble sort). Using the EDK and ISE I managed to build the timing simulation model (Post Place and Route Model) for a Microblaze based architecture . Then I tried to simulate this using ModelSim SE 6. When I simulate the architecture using Modelsim it appeared to me that the memory was not initialized with the software program (I'm using only block rams for both instructions and data memories). I knew that because the program counter is incremented and addresses are generated from Microblaze but no data is transferred. After investigation I found out that Modelsim somehow was unable to initialize the block ram with the software program (a VHDL configuration is generated by the EDK to do so but Modelsim just ignored it).

I managed to solve this problem by using data2mem command to convert the ELF file into MEM files and load it into the block ram using Modelsim. Using this approach I managed to simulate the architecture and generate the expected results (except some problems with interrupts).

So the next step was to generate VCD file using Modelsim and then using XPower tried to estimate the power consumption. This seamed to be working fine, and generate some estimation. But when I tried to change the size of the array to be sorted and redo the simulation again, I found out that the power estimation is not affected much with the change I made to the software (although it is a significant one). To Clarify this I started with an array size of 10 integers, this array requires 887 clock cycles to be sorted and the total estimated power consumption was around 488.65 mW. When I increased the array size to 20 integers (which requires 3069 clock cycles to be sorted) the estimated power consumption was 492.28mW with increase of about

3.5 mW. When I increased the number of integers to 40 (11298 clock cycles are needed to sort that), the power consumption just increased by around 2mW to be 494.29mW. When I raised the number of integers to be 80 (43280 clock cycles to be sorted), the power consumption was reduced to 493mW. So it seems that the activities stored in the VCD file are not affecting the power estimation as I expected. When I tried to investigate this issue I found out that XPower gave me a warring saying that it was able to match only 25% of the signals in the VCD file, and it was not able to change the clock frequency to 100 MHz (although when I checked the frequency applied to the clock signals in XPower I found it to be 100MHz). So my two questions are:

1- Why is Modelsim not able to load the software application correctly into the block ram? Is there another approach better than the one I mentioned above?

2- What is wrong with the VCD file and why XPower is not able to correctly estimate the power consumptions?

So if have been through this before I would appreciate your feedback..

Best Regards

Reply to
ahosyney
Loading thread data ...

I just forgot to mention that I'm using ISE 9.2i and EDK 9.2i and Vertix-4 XC4VFX12.

Regards

Reply to
ahosyney

Hello,

First, if you are student, I suggest you ask your professor to enter a webcase on your behalf. The 25% issue sounds like it might be a bug, or a missing or wrong software switch, and is clearly beyond anything I can help you with here.

If you are a customer, again, a webcase is in order.

For the question about why there is only an 8 mW difference (?), that might be correct. In a FPGA device, a great deal of "stuff" is there regardless of what the "software" is doing. Another way of saying this, is that the MicroBlaze(tm) or 405PPC(tm) processors are really incredibly efficient. The 405PPC design in V2P is the lowest power per MHz of any 405PPC at 130nm. In V4 it is still "world class" in its very low power/MHz. So, the processor part of the design is almost nothing (both in power, and die area) compared to IO, clocking, BRAM, etc.

Check using the Excel spreadsheet power estimator for just the 405PPC block (as an example) and change the clock from 1 to 400 MHz, and see what the mW/MHz is. This might give you some idea of how efficient the

405PPC is. The MicroBlaze is not that good (after all, it is soft, not hard IP), but in terms of the total resources, it will provide you with a means of comparison.

At the same time, you may place some clock trees in the Excel spreadsheet, and see how they vary. Same with 32 IO's. Or 512 DFF';s. A bit of experimentation with the spreadsheet will provide you insight into what is primarily responsible for the dynamic power.

Austin

Reply to
austin

ahosyney wrote: [Power estimation using XPower and ModelSim]

Why would you expect the power to be higher? Remember that power is energy-per-second. I would expect the 20 integer case to require much the same power as the 10 integer case, but because it takes 3069/887 times longer, it would use 3069/887 times more energy. A MicroBlaze doesn't consume more energy per instruction or energy per second just because the overall problem size is bigger!

Note that had you used a different solution than a MicroBlaze or PowerPC, for example a parallel solution with greater parallelism for larger problem size, then it is entirely possible that the power consumption would increase for larger problem sizes, while the time to solve the problem remained constant.

Reply to
Philip Potter

Thank you for your reply. I understand what you say. I excpected the power to vary with much more amount than just the 2 mW. I'm using the same array in all the test, so the number of swaps required will vary from test to the other (data has changed), which should result in some change in the power required to access the memory. Actually after installing ISE 10.1 I got a variation of about 20mW. It seems that XPowr 9.2i has a problem loading VCD files.

Reply to
ahosyney

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.