( ESNUG 412 Item 11 ) ------------------------------------------- [05/22/03]
From: Charlie Ocker <charlie_ocker=user company=starkey lot drawn>
Subject: Newbie Power Compiler User Seeks Help To Not To Reinvent The Wheel
Hi John,
Here is my impressions of Power Compiler from a new user's standpoint.
Setting up Power Compiler was pretty straightforward. The documentation was
good enough to modify analyze/elaborate scripts, etc. and I was up and
running pretty quickly. A quick note on how Power Compiler is used here
would be in order. We mainly wanted the "automatic" clock gating feature,
and understood beforehand that our RTL needed to incorporate some "clock
enable" or "load register" signal for this to occur. This wasn't a problem,
as this was usually needed anyway. We haven't experimented with the
operator isolation feature; we may do this in the future, but for now we're
comfortable with careful inference of transparent latches to keep arithmetic
elements at a known state when they're not being used. Our inital thinking
here was that the operator isolation feature puts in AND/OR gates on the
inputs, and that there would definately be switching activity that would
propagate through the arithmetic elements; whereas with the transparent
latch, there would be no switching activity. Appropriate considerations
with regard to ATPG and transparent latches are incorporated into the RTL.
Our initial experiences w/ power estimation have been a bit more difficult.
I haven't been able to get satisfactory results with the forward annotated
SAIF for RTL power estimation, so I abandoned this for back annotated SAIF
from a gate-level model. We are using ModelSim as our simulator, and the
FLI code supplied by Synopsys seems to work well. With the gate-level
simulation flow, I was able to get some reasonable looking results.
I'm currently using this flow to compare two implementations in regards to
power. The first implementation, the original one, broke up the arithmetic
datapath into 4 functional components. The second implementation is an
experiment to maximize resource sharing whereby the 4 blocks of the original
implementation are rolled into one block. The differences in resource usage
and area are significant between the two implementations. The experimental
implmentation used 20 seperate adders and subtractors of various widths,
while the original implementation used 56. The area was 10 percent smaller,
as well.
Encouraged by this, I compared the power estimation results, taking care to
insure that both designs followed, as closely as possible, the same
synthesis strategy and constraints. What I found was that even though the
area was smaller and used less arithmetic operators, the experimental
implementation consumed 11 percent more power than the orignial one. Both
designs used the same power estimation template testbenches to generate the
backward annotated SAIF files.
Clearly, there exists a relationship between high level RTL operator
inference, logical block partitioning, the amount of resource sharing in
synthesis, and power consumption. Not wanting to reinvent the wheel, I was
wondering if someone could point me to some existing documentation on this
subject, if any exists.
Oh, BTW, in case anyone is interested, the design is a FFT co-processor that
is targeted for our next generation hearing aid platform. Library is a
1.25v, 0.13 um, low power optimized. I used VHDL for this design to take
advantage of the higher level of RTL abstraction (fixed-point arithmetic
overloaded operators, user defined record types, etc. etc.), built in range
checking, etc.
Many thanks in advance!
- Charlie Ocker
Starkey Labs Colorado Colorado Springs, CO
|
|
