If Vs Case

[SmiG]

Hi guys,

I need help about a simple process optimization.
I have n input signals and I have to set another signal with one of these
input values. The assignment have to be conditioned by a index value.
My issue is that my FPGA is full and the P&R became problematic. On this
assignment operation I have a little slack and I should have to optimize
this process.
I make it with a simple IF-Elsif construct and I will try to substitute it
with a CASE construct. Wich is the most efficent of implementation?

Thanks to everybody,
SmiG

PS I'm using ISE 7.1 SP4.

 

[Andy]

Hi guys,

I need help about a simple process optimization.
I have n input signals and I have to set another signal with one of these
input values. The assignment have to be conditioned by a index value.
My issue is that my FPGA is full and the P&R became problematic. On this
assignment operation I have a little slack and I should have to optimize
this process.
I make it with a simple IF-Elsif construct and I will try to substitute it
with a CASE construct. Wich is the most efficent of implementation?

Thanks to everybody,
SmiG

PS I'm using ISE 7.1 SP4.

If you can describe the behavior with a case statement, that means the
selection criteria is mutually exclusive, so it would not matter
whether you used a case or if/elsif statement; the synthesis tool
should optimize out any implied priority from the if/elsif
representation. If the selection criteria is not mutually exclusive,
you can't use a case statement anyway. I prefer to use case statements
instead of if statements as a visual cue that the conditions are
mutex. However, whenever I see a case statement with a bunch of
numeric target expressions, I think to myself; "Is there a way to use
a for loop and/or an array for this?"

On the other hand, if it is known that the input conditions are
mutually exclusive (i.e. you know that only one of the selector inputs
is '1' at at time), but it is not obvious to the tool (say these are
external inputs and the synthesis has no such knowledge of them), you
usually have to create an and-or tree to optimize out any priority
manually.

Another trick is to code it as if it were a tri-state bus, with
multiple drivers on it. Then set the option to convert tristate bus to
a multiplexer, and the synthesis tool will assume all the tri-state
driver enables were mutex.

I would love to have a standard function or functions that could
verify that a collection of inputs is mutex (i.e. one-hot, etc.), and
then be able to call that function in a vhdl assertion, and have the
synthesis tool recognize that assertion/function as a hint that the
set of inputs is in fact mutually exclusive.

Andy

 

[Mike Treseler]

If you can describe the behavior with a case statement, that means the
selection criteria is mutually exclusive, so it would not matter
whether you used a case or if/elsif statement; the synthesis tool
should optimize out any implied priority from the if/elsif
representation.

Yes, for a mutex it doesn't matter.
I use whatever is easier for me to read.

If the selection criteria is not mutually exclusive,
you can't use a case statement anyway. I prefer to use case statements
instead of if statements as a visual cue that the conditions are
mutex. However, whenever I see a case statement with a bunch of
numeric target expressions, I think to myself; "Is there a way to use
a for loop and/or an array for this?"

I agree. A case that looks too clean
can often be covered by a simpler description
select := select+1;
select := foo(n);
etc.

On the other hand, if it is known that the input conditions are
mutually exclusive (i.e. you know that only one of the selector inputs
is '1' at at time), but it is not obvious to the tool (say these are
external inputs and the synthesis has no such knowledge of them), you
usually have to create an and-or tree to optimize out any priority
manually.

I prefer to waste a LUT or two to cover
the case that I might be wrong about
what the inputs will do.

I would love to have a standard function or functions that could
verify that a collection of inputs is mutex (i.e. one-hot, etc.), and
then be able to call that function in a vhdl assertion, and have the
synthesis tool recognize that assertion/function as a hint that the
set of inputs is in fact mutually exclusive.

Hmmm. I'm missing something here.
How could a function determine anything
about undriven input values other what is
already guaranteed by their type?

-- Mike Treseler

 

[Andy]

Yes, for a mutex it doesn't matter.
I use whatever is easier for me to read.


I agree. A case that looks too clean
can often be covered by a simpler description
select := select+1;
select := foo(n);
etc.


I prefer to waste a LUT or two to cover
the case that I might be wrong about
what the inputs will do.


Hmmm. I'm missing something here.
How could a function determine anything
about undriven input values other what is
already guaranteed by their type?

-- Mike Treseler

Simply define a standard function that returns true if one and only
one bit of the vector argument is a '1'. Then assert that that
function on that vector is always true (or just true on every rising
edge, etc.). The synthesis tool could recognize the standard function
in an assertion, and conclude that the vector's bits can be treated as
mutually exclusive (since the simulation would have failed anyway if
they weren't, thus there is no reason to implement additional hardware
that does not match the simulation).

Andy

 

[Mike Treseler]

Simply define a standard function that returns true if one and only
one bit of the vector argument is a '1'. Then assert that that
function on that vector is always true (or just true on every rising
edge, etc.). The synthesis tool could recognize the standard function
in an assertion, and conclude that the vector's bits can be treated as
mutually exclusive (since the simulation would have failed anyway if
they weren't, thus there is no reason to implement additional hardware
that does not match the simulation).

OK. I see.
A simulation process would do
a statistical proof of mutex vectors.

Thanks for the explanation.

-- Mike Treseler