Don't care and optimization

Hi All,

I'm wondering the best way to introduce some form of "don't care" logic
to allow synthesis tools greater freedom with optimization.

Let say I've a multiplexer controlled by a custom typed signal:

-- START VHDL --
type muxSelectType is (inA, inB, inC); -- Mux control signal type
signal muxControl : muxSelectType; -- Mux control signal

signal muxOutput : std_logic_vector(15 downto 0);

MyMux : process(muxControl, and whatever signals)
begin
case muxControl is
when inA =>
muxOutput <= -- something
when inB =>
muxOutput <= -- something else
when inC =>
muxOutput <= -- something else again
end case
end process
-- END VHDL --

The custom type for the mux select signal should allow the synthesis
tools to choose the 'best' encoding, that's fine. My question is, what
if, for a certain situation, I'm not bothered what muxOutput is, say the
signal is not used, what can I drive muxControl with to show that I
"don't care" which input the mux selects.

Would it help if I change the muxControl to a std_logic_vector and drive
it with '-'?

Hope all that makes sense...
Cheers

Andy

--
Dr. Andrew Greensted Department of Electronics
Bio-Inspired Engineering University of York, YO10 5DD, UK

Tel: +44(0)1904 432379 Mailto:
Fax: +44(0)1904 433224 Web: www.bioinspired.com/users/ajg112

Andrew Greensted

Andrew Greensted wrote:
....
> The custom type for the mux select signal should allow the synthesis
> tools to choose the 'best' encoding, that's fine. My question is, what
> if, for a certain situation, I'm not bothered what muxOutput is, say the
> signal is not used, what can I drive muxControl with to show that I
> "don't care" which input the mux selects.

In that case, MyMux is not a
complete description of your logic.

You might want a state type and object
that is updated every clock
to cover all situations.

-- Mike Treseler
_________________________
main : process (clock, reset)
is
....
type situation_t is (
IDLE,
START,
RECEIVE,
STOP,
FULL,
ERR
);
variable situation_v : situation_t;
...
begin

Mike Treseler

"Andrew Greensted" <> wrote in message news:dq0mit$biv$...
> Hi All,
>
> I'm wondering the best way to introduce some form of "don't care" logic to allow synthesis tools greater freedom with
> optimization.
>
> Let say I've a multiplexer controlled by a custom typed signal:
>
> -- START VHDL --
> type muxSelectType is (inA, inB, inC); -- Mux control signal type
> signal muxControl : muxSelectType; -- Mux control signal
>
> signal muxOutput : std_logic_vector(15 downto 0);
>
> MyMux : process(muxControl, and whatever signals)
> begin
> case muxControl is
> when inA =>
> muxOutput <= -- something
> when inB =>
> muxOutput <= -- something else
> when inC =>
> muxOutput <= -- something else again
> end case
> end process
> -- END VHDL --
>
> The custom type for the mux select signal should allow the synthesis tools to choose the 'best' encoding, that's fine. My question
> is, what if, for a certain situation, I'm not bothered what muxOutput is, say the signal is not used, what can I drive muxControl
> with to show that I "don't care" which input the mux selects.

If muxOutput is not 'used' under a certain setting of muxControl, then the
synthesis tool will find that redundancy and likely will already use it to minimize
your logic.

But note that in that case muxControl apparently can 'block' the data flowing
through muxOutput in two spots....If you can find that second spot in VHDL,
then you can fix the redundancy yourself in HDL (by merging the two control points into one)
So then you do not need to rely on a synthesis tool to find the redundancy.

Another note : if muxOutput IS used under every condition of muxControl,
but you simply do not care what the value is, then you should probably use a 'std_logic_vector' type
or something else that has an 'X' value. Synthesis tools DO interpret 'X' as a true don't care value,
and will use these assignments in optimization.


>
> Would it help if I change the muxControl to a std_logic_vector and drive it with '-'?
>
> Hope all that makes sense...
> Cheers
>
> Andy
>
> --
> Dr. Andrew Greensted Department of Electronics
> Bio-Inspired Engineering University of York, YO10 5DD, UK
>
> Tel: +44(0)1904 432379 Mailto:
> Fax: +44(0)1904 433224 Web: www.bioinspired.com/users/ajg112

Rob Dekker

Thanks both for your responses

After a little more thought, it's obvious (at least with the hardware
I'm describing) that the module being synthesised is purely
combinatorial, therefore the synthesis tools (as Rob pointed out) will
no doubt minimize the logic removing any redundancy.

Andy

--
Dr. Andrew Greensted Department of Electronics
Bio-Inspired Engineering University of York, YO10 5DD, UK

Tel: +44(0)1904 432379 Mailto:
Fax: +44(0)1904 433224 Web: www.bioinspired.com/users/ajg112

Andrew Greensted