Unique Condition

This was originally VHDL Issue Number 2012

Proposal Details

• Who Updates:
• Date Proposed:
• Date Last Updated:
• Priority:
• Complexity:
• Focus:

Current Situation

Consider a basic equation in hardware design:

Outbus <= (a and ABus) or (b and BBus) or (c and CBus) or (d and DBus) or (e and EBus);

One statement structure in serial mode:

if(a = '1') then OutBus <= ABus;

elsif(b = '1') then Outbus <= BBus;

elsif(c = '1') then Outbus <= CBus;

elsif(d = '1') then Outbus <= DBus;

elsif(e = '1') then Outbus <= EBus;

else Outbus <= '0';

end if;

or in another equal form:

Outbus <= '0';

if(a = '1') then OutBus <= ABus; end if;

if(b = '1') then OutBus <= BBus; end if;

if(c = '1') then OutBus <= CBus; end if;

if(d = '1') then OutBus <= DBus; end if;

if(e = '1') then OutBus <= EBus; end if;

In concurrent mode:

OutBus <= ABus when a = '1'

else BBus when b = '1'

else CBus when c = '1'

else DBus when d = '1'

else EBus when e = '1'

else '0';

In those above 3 situations, a superfluous condition is posed on the equation, it means a priority tree is implied in all three situations. Actually most of time when dealing with main data flow, all above conditions are mutually exclusive, so there is no need to pose the extra conditions on the final equation.

Requirement

There should be a language construct which indicates that the conditions are mutually exclusive. This would allow a synthesis tool to optimize the implementation, and a simulator or property checker to verify that they are indeed exclusive. This avoids the situation where a synthesis pragma incorrectly states mutual exclusion, leading to different simulation results before and after synthesis.

A similar feature exists in SystemVerilog (unique/unique0), but the language differences mean that these keywords are not appropriate. There is no equivalent of the 'when' construct in SystemVerilog. The 'unique' keyword implies an error if none of the conditions is met and there is no 'else', whereas the 'unique0' keyword does not imply this additional check.

Implementation details

The proposed solution is to introduce a new keyword 'elsor', which implies that the conditions are mutually exclusive. The keyword would have to be used throughout the statement, and imply that all the conditions are mutually exclusive. The question of checking whether none of the conditions have been met can be handled by an assertion.

Code Examples

Statement structure in serial mode:

if(a = '1') then OutBus <= ABus;

elsor(b = '1') then Outbus <= BBus;

elsor(c = '1') then Outbus <= CBus;

elsor(d = '1') then Outbus <= DBus;

elsor(e = '1') then Outbus <= EBus;

else Outbus <= '0';

end if;

In concurrent mode:

OutBus <= ABus when a = '1'

elsor BBus when b = '1'

elsor CBus when c = '1'

elsor DBus when d = '1'

elsor EBus when e = '1'

else '0';

Alternative Use Model

An assertion can handle many simple cases very effectively without language syntax:

assert OneHot0 ( (a, b, c, d, e) );

This is open to error, since the conditions have to be duplicated.

Use Cases

Arguments FOR

Arguments AGAINST

The premise that one can declare signals to be mutually exclusive and that such a declaration somehow helps a synthesis tool to optimize is flawed. If the signals truly are mutually exclusive, that will be reflected in the generation of those signals, it is not something that can be 'declared' to be true. Also, if the signals really are mutually exclusive, then the synthesis tool already produces identical results matching what the originator claims as the best form so there is no actual benefit produced.

As an example, using the four code samples listed in this proposal, synthesis tool brand 'Q' produces four identical programming output files which indicates that the exact same logic was generated for all four. This is in direct contradiction to what the originator claimed. There were no 'superfluous conditions posed on the equation', there were no 'priority trees' implemented in any of the three alternates to the first form of code that was presented. Therefore, if the conditions truly are mutually exclusive, the problem that this proposal is said to address, doesn't even exist.

If this proposal is to have any actual utility, then there should first be some use case presented of a situation where one can have mutual exclusion that somehow a synthesis tool did not pick it up. Without such a use case, there doesn't seem to be any merit to this proposal. --Main.KevinJennings - 2015-03-05

General Comments

Supporters

Add your signature here to indicate your support for the proposal