Hi.
I have a question.
I have a special y=f(x) function. It takes 32 bit at input and it have
something at output. Function is unrolled, it computes result alsmost
"immediately", and it doesn't contain any memory cells and flip-flops,
it is what called "combinatorial".
I need to fill a table of all possible x's and function results. If x
is 32-bit, I just make 32-bit counter connected to the block which
compute the result and collect results.
As yet it all simple.
But I feel that by rewiring bus between counter and f(x) block, I can
reduce the number of gates changed its state at each counter's
iteration, and vice versa. Thus to reduce power consumption.
(I may have x in any order, my task is just to have all possible
values of x at some moment).
So, is there any tool that can take my f(x) in form of Verilog or VHDL
and tell me what is the most optimal wiring scheme?

[email protected] wrote:
> Hi.
> I have a question.
> I have a special y=f(x) function. It takes 32 bit at input and it have
> something at output. Function is unrolled, it computes result alsmost
> "immediately", and it doesn't contain any memory cells and flip-flops,
> it is what called "combinatorial".
> I need to fill a table of all possible x's and function results. If x
> is 32-bit, I just make 32-bit counter connected to the block which
> compute the result and collect results.
> As yet it all simple.
> But I feel that by rewiring bus between counter and f(x) block, I can
> reduce the number of gates changed its state at each counter's
> iteration, and vice versa. Thus to reduce power consumption.
> (I may have x in any order, my task is just to have all possible
> values of x at some moment).
> So, is there any tool that can take my f(x) in form of Verilog or VHDL
> and tell me what is the most optimal wiring scheme?

For a dedicated once-only purpose, why are you concerned about power?
Are you a student who only has so many Joules allotted for use this
semester?

I know of no tools that could optimize this in a way that would make you
happy.

However, since changing one bit usually has fewer dynamic consequences
than changing many bits, consider a Gray code counter. The Gray code
counters only change one bit per increment. If you know which of your
32 bits typically uses less power when changing the logic through your
f(x), you could assign those to the LSbits of the Gray counter and leave
the "swich everything" x bits to the MSbits of the Gray counter.

If you don't know what a Gray counter is, there are many resources on
the web. A simple registered XOR of a binary counter would give you the
one bit change.

> However, since changing one bit usually has fewer dynamic consequences
> than changing many bits, consider a Gray code counter. The Gray code
> counters only change one bit per increment. If you know which of your
> 32 bits typically uses less power when changing the logic through your
> f(x), you could assign those to the LSbits of the Gray counter and leave
> the "swich everything" x bits to the MSbits of the Gray counter.

Thanks, I know what Gray counter is. But the problem is, that on bus
between counter and f(x) I can make increment in manner of Gray
counter, but I never now that this property of Gray counter will
reflect to each point of f(x) block. I mean that I'm not sure that
Gray counter is simple solution.

[email protected] wrote:
>>However, since changing one bit usually has fewer dynamic consequences
>>than changing many bits, consider a Gray code counter. The Gray code
>>counters only change one bit per increment. If you know which of your
>>32 bits typically uses less power when changing the logic through your
>>f(x), you could assign those to the LSbits of the Gray counter and leave
>>the "swich everything" x bits to the MSbits of the Gray counter.

Besides Binary, and Gray, we have also used Triangle counters (up/Down
binary) where that made better table-mapping sense.

>
> Thanks, I know what Gray counter is. But the problem is, that on bus
> between counter and f(x) I can make increment in manner of Gray
> counter, but I never now that this property of Gray counter will
> reflect to each point of f(x) block. I mean that I'm not sure that
> Gray counter is simple solution.

Since you presumably already have mapping software, to create your
table, then you could modify that to do transistion calculations.

So, you could easily do ALL counter candidates, and run
both an edge count in your own SW, and then also the FPGA tools to
given another power comparison on the candidate designs.

> So, you could easily do ALL counter candidates, and run
> both an edge count in your own SW, and then also the FPGA tools to
> given another power comparison on the candidate designs.

If counter is 32-bit, then 32!=263130836933693530167218012160000000
This is a number of possible rewiring variants.
I'm not feel myself as pioneer, so that's why I think that there must
be some automated way...

>>So, you could easily do ALL counter candidates, and run
>>both an edge count in your own SW, and then also the FPGA tools to
>>given another power comparison on the candidate designs.
>
>
> If counter is 32-bit, then 32!=263130836933693530167218012160000000
> This is a number of possible rewiring variants.
> I'm not feel myself as pioneer, so that's why I think that there must
> be some automated way...

That's a strange number - do you not have any idea what your f(x) might be ?
Is this a real problem, or an academic one ?

[email protected] wrote:
>> So, you could easily do ALL counter candidates, and run
>> both an edge count in your own SW, and then also the FPGA tools to
>> given another power comparison on the candidate designs.
>
> If counter is 32-bit, then 32!=263130836933693530167218012160000000
> This is a number of possible rewiring variants.
> I'm not feel myself as pioneer, so that's why I think that there must
> be some automated way...

Your desire is too specific and never a concern in mainstream design so
there simply is no automated way.

On Sep 10, 4:03 pm, John_H <[email protected]> wrote:
> [email protected] wrote:
> >> So, you could easily do ALL counter candidates, and run
> >> both an edge count in your own SW, and then also the FPGA tools to
> >> given another power comparison on the candidate designs.
>
> > If counter is 32-bit, then 32!=263130836933693530167218012160000000
> > This is a number of possible rewiring variants.
> > I'm not feel myself as pioneer, so that's why I think that there must
> > be some automated way...
>
> Your desire is too specific and never a concern in mainstream design so
> there simply is no automated way.

Well... I'll try to simplify my desire. Is there any tool that can
show me gates count switched if I preset previous state of inputs and
next state?

"John_H" <[email protected]> wrote in message
news:[email protected]
>
> For a dedicated once-only purpose, why are you concerned about power? Are
> you a student who only has so many Joules allotted for use this semester?

> I have a special y=f(x) function. It takes 32 bit at input and it have
> something at output. Function is unrolled, it computes result alsmost
> "immediately", and it doesn't contain any memory cells and flip-flops,
> it is what called "combinatorial".
> I need to fill a table of all possible x's and function results. If x
> is 32-bit, I just make 32-bit counter connected to the block which
> compute the result and collect results.

> But I feel that by rewiring bus between counter and f(x) block, I can
> reduce the number of gates changed its state at each counter's
> iteration, and vice versa. Thus to reduce power consumption.
> (I may have x in any order, my task is just to have all possible
> values of x at some moment).
> So, is there any tool that can take my f(x) in form of Verilog or VHDL
> and tell me what is the most optimal wiring scheme?

In general, I would say no. If the design is in structural
verilog (or the VHDL equivalent), directly instantiating gate
level primitives then it might be possible. (Synthesis from
behavioral verilog is likely not unique.)

It might be that the design can't have any loops.
(They aren't necessarily excluded from combinatorial logic,
as long as they are guaranteed to resolve.) Then iterate through
the design computing how many gate changes are caused by changes
in the inputs for a given set of other inputs. It would seem
likely that gray code (one input changing at a time) is the best
choice, but that isn't guaranteed.

> In general, I would say no. If the design is in structural
> verilog (or the VHDL equivalent), directly instantiating gate
> level primitives then it might be possible. (Synthesis from
> behavioral verilog is likely not unique.)

Well, what if to switch to lower level, some RTL? If so, there're will
be any existing tool to answer my question?

<[email protected]> wrote in message
news:[email protected] ups.com...
>> In general, I would say no. If the design is in structural
>> verilog (or the VHDL equivalent), directly instantiating gate
>> level primitives then it might be possible. (Synthesis from
>> behavioral verilog is likely not unique.)
>
> Well, what if to switch to lower level, some RTL? If so, there're will
> be any existing tool to answer my question?

No tool beyond your own knowledge. By instantiating gate level primitives,
you have the chance to know through your design how many LUTs you're
affecting with any one input signal change. There is no tool that will
summarize the number of gates changed by the change of an input. There is
no tool that will provide the per-bit level of power usage.

Again: why is this important to you? You have the task of building one
table. The assumption we can make is that it doesn't have to be powered by
a hand crank or button-cell batteries. There are no tools that will provide
you with the microscopic scale of power consumption you desire.