( ESNUG 378 Item 13 ) ------------------------------------------- [10/03/01]
Subject: ( DAC 01 #6 ) Offis Explains That Orinoco Does "Low Power Binding"
> "The Offis Orinoco guys had some neat ideas about going from C/C++ down
> to gates optimizing for power. However, without an underlying logic
> synthesis engine, I would never trust Orinoco to give me real results.
> The idea of generating scripts to coerce Behavioral Compiler into
> giving them the schedule that they thought was optimal (for power) was
> ridiculous -- not ridiculous in theory, but in practice."
>
> - [ An Anon Engineer ]
From: Frank Poppen <frank.poppen@offis.de>
Hi John,
it was nice meeting you in during the Boston SNUG. Germany seems to be so
far away from the SNUG community. It was really great to finally get to
know all the people. (Though the circumstances where quite shocking with
the terror and no way to fly back home before Sunday.) We at Offis didn't
appreciate part of the comment of the Anon Engineer in the DAC 01 report:
1.) Next to C/C++ (not necessarily SystemC) ORINOCO also processes VHDL.
2.) Orinoco does NOT create a "low power schedule" (yet). We plan to
implement this. What you DO get is a "low power binding". This is a
completely different story and it does work. This comment hit me
someway personally. My SNUG paper proved that with this methodology
power savings are possible up to 20%.
Let me try to explain what I mean with the terms scheduling, allocation
and binding: Designers either do scheduling manually (which operation has
to be executed first depending on the data-dependency-graph) or use Synopsys
Behavioral Compiler. The next step is synthesis. In this step DC,
allocates resources. Depending on the timing constraints and the possible
parallelism in the design, DC might allocate two adders for an algorithm
that contains 100 additions. Some of these operations (not necessarily one
half) will be bound to one allocated adder. The rest will be bound to the
other adder. If we do this step of binding operations on allocated
resources wisely we can save power. Let's assume we have to bind 4
additions to 2 adders:
op1 = 0111 + 0111
op2 = 0000 + 0000
op3 = 0110 + 0111
op4 = 0000 + 0001
High activity means high power consumption. Low activity means low power
consumption.
"bad binding" {op1,op2} => adder1
{op3,op4} => adder2
0000 0000 0000 0001
0111 0111 0110 0111 <- High activity at inputs
| | | |
----------- -----------
\ + / \ + / <- High activity in ALU
--------- ---------
| |
0000 0001
1110 1101 <- High activity at output
This bad binding causes a high power consumption!
"good binding" {op1,op3} => adder1
{op2,op4} => adder2
0110 0111 0000 0001
0111 0111 0000 0000 <- Low activity at inputs
| | | |
----------- -----------
\ + / \ + / <- Low activity in ALU
--------- ---------
| |
1101 0001
1110 0000 <- Low activity at output
This good binding uses much less power.
By using data correlation and not destroying it with a "bad binding" we can
reduce activity dramatically and save power. The complete paper is in the
Boston SNUG'01 proceedings and the title is: "Evaluation of a Behavioral
Low Power Design Flow Based on a Design Case".
- Frank Poppen
OFFIS Research Institute Oldenburg, Germany
|
|
