New keyword 'orif' and its implications

[comp.arch.fpga]

On 28 Aug., 13:23, Marcus Harnisch <marcus.harni...@gmx.net> wrote:

Weng Tianxiang <wtx...@gmail.com> writes:
Weng, take a step back.

First, not under all circumstances the carry chain implementation is
the most efficient of the gated OR selector.
For small number of inputs it fits into a single 6-LUT, for very large
number of inputs the logarithmic delay of the tree will be better than
the linear delay of the carry chain, even though the constants for the
carry chain are better.

Second, the only thing that your orif keyword thos, is a hint to the
synthesizer that the behaviour is undefined for certain input
combinations. You restrict the domain of the function. The following
code has the same semantics:


if E1 + E2 + E3 > 1 then -- (Lazy and incorrect VHDL type handling to
shorten example, you will get the point)
result <= (others => '-');
elsif E1 = '1' then
result <= input1;
elsif E2 = '1' then
result <= input2;
elsif E3 = '1' then
result <= input3;
else
result <= (others => '0');
end if;

You will however notice, that most synthesis tools will not utilize
the optimization potential available from '-'.
I am often annoyed by this. For example if you write an instruction
decoder for a CPU, you do not care about the behaviour of the ALU for
all instructions that use no ALU result. Specifying don't cares would
greatly reduce the amount of logic for the decoder. This is an
improvement that is far more versatile than your proposal and it is
allready in the language.

However most synthesis tools will replace all occurences of '-' with
'0'. The reason behind this is that verification guys hate don't
cares. For regression testing you wan't the hardware to behave the
same if the specification did not change. '-' might be synthesized
differently every time. For formal verification you definitely can't
allow the freedom of don't cares.
In most contexts verification is a far bigger problem then efficient
implementation.

If you really want the most efficient implemetation you should specify
the detailed behaviour.

assert (PSL formulation to guarentee mutual exclusiveness goes here);
result <= (input1 and (result'range => E1) or (input2 and
(result'range => E2) or (input3 and (result'range => E3);

Telling the synthesis tool to implement wide ORs in carry chains is
simpler than to introduce a new keyboard.
This way other uses of wide ORs benefit aswell, as do users of other
languages.

Kolja Sulimma

P.S.: Xilinx has a patent on implementing a wide OR using carry logic.
There is no explicit license that grants you the right to distribute
bitstreams that use that trick. Xilinx says, they do not want to sue
anybody about that. But I bet Unisys had no intent to sue GIF users in
the 80ies. But intentions can change. Do you want to bet your business
on an informal declaration by Austin in a newsgroup?

 

[Jim Lewis]

Weng,

I have to change my keyword 'orif' definition to make it perfect (it
may need more fine tuning with other's help, no matter what is, I am
not a good protocol writer, but I am learning), but the basic idea has
been the same as before and consistent without any change since March
2002 I published a paper with Jim as the paper's reviewer.

So you and I have had some time to discuss and ponder this.

Personally I am worn out and don't have further energy to
afford this issue as I consider it a solved problem.

One of the things that shifted my mind away from "ORIF"
is that there are mutual exclusion problems that it
cannot solve. One you had brought up in a previous
discussion (some time ago) where you had mixed conditions
with some signals mutually exclusive and some not.
I think this is a common case.
Can you post one of the examples you shared with me previously
and explain how this would be handled by "ORIF"?

I have to point out the following code has error:
....
Here is Jim's equation that is wrong !
Please use quoting properly as I can't tell your

referenced text from your new thoughts. As a result,
I cannot follow your line of thought at all, so I can't
comment on all of it - it looks like you included too
much text.

I will make an educated guess that this is the example
on which you wanted to comment:

Also note that if you are using std_logic or bit types, with the
Accellera VHDL-2006 revision you can write:
OutBusA : process(RESET, CLK)
begin
if(RESET = '1') then
OutBus <= (others=>'0');
elsif rising_edge(CLK) then
if (E0 or E1 or E2 or E3 or E4 or E5) = '1' then
OutBus <=
(E0 and Data0) or (E1 and Data1) or (E2 and Data2) or
(E3 and Data3) or (E4 and Data4) or (E5 and Data5) ;
end if ;
end if ;
end process;

Jim, try this set of values: E0 = '1' and E3 = '1', you get data:
Data0 or Data3, not Data0.

Please note that your original example for OutBus used all
"orif" and did not mix elsif with orif, so yes there is no
priority between E0 and E3 here and Data0 or Data3 is the
correct answer.

Can "ORIF" also construct the equivalent to the following?
OutBusBProc : process(RESET, CLK)
begin
if(RESET = '1') then
OutBus <= (others=>'0');
elsif rising_edge(CLK) then
OutBusB <=
(E0 and Data0) or (E1 and Data1) or (E2 and Data2) or
(E3 and Data3) or (E4 and Data4) or (E5 and Data5) ;
end if ;
end process ;


What compelling real hardware problems does "ORIF" solve
that either are not solved by other methods or are
cumbersome using other methods?


Cheers,
Jim

 

[Jim Lewis]

Colin Paul,

|---------------------------------------------------------------------------------------------|
|" But his |
|> > new function name zero_one_hot() still has the same possibility to |
|> > conflict with old signal function name zero_one_hot() if someone had |
|> > used it before, but he never mentioned his same possibility. |
|---------------------------------------------------------------------------------------------|

That would be true for plain VHDL without PSL, but he posted as if
zero_one_hot() is now part of VHDL from PSL (but it is not in my PSL
reference manual, unlike onehot0) so that would not necessarily
require that a VHDL identifier be changed. From the PSL standard:
"[..]

OOPS. I missed that. I had meant to reference the PSL function onehot0.

|---------------------------------------------------------------------------------------------|
|"[..] |
|> zero_one_hot() can always be prefixed with the standard package name |
|> in which it is defined." |
|---------------------------------------------------------------------------------------------|

Andy,

Is zero_one_hot() defined in a package? Even if it is, Weng was
complaining that Jim complained that orif would clash with a
basic_identifier and Weng perceived this as hypocrisy as he thought
zero_one_hot() would also clash with a basic_identifier.

Reserved words have more strength than subprogram names.
I would have to double check, but I think that if you re-use
a subprogram name as a signal name in a design, the subprogram
name becomes hidden and can only be referenced with a
fully selected name. For old designs that do not use the
subprogram, this is ok (or exactly the behavior you desire).
In new designs, this situation is easy to avoid.

If two packages are referenced with the same subprogram name,
then the subprograms are homographs and neither can be directly
referenced and as a result can only be referenced with a fully
selected name. So there is some concern with this, however,
it is not a difficult one for a user to address.

While it is possible that syntax could be given a similar
interpretation, I am not sure it would be a good thing.

Cheers,
Jim

 

[Weng Tianxiang]

On Aug 30, 7:46 am, Jim Lewis <j...@synthworks.com> wrote:

Weng,
I have to change my keyword 'orif' definition to make it perfect (it
may need more fine tuning with other's help, no matter what is, I am
not a good protocol writer, but I am learning), but the basic idea has
been the same as before and consistent without any change since March
2002 I published a paper with Jim as the paper's reviewer.

So you and I have had some time to discuss and ponder this.

Personally I am worn out and don't have further energy to
afford this issue as I consider it a solved problem.

One of the things that shifted my mind away from "ORIF"
is that there are mutual exclusion problems that it
cannot solve. One you had brought up in a previous
discussion (some time ago) where you had mixed conditions
with some signals mutually exclusive and some not.
I think this is a common case.
Can you post one of the examples you shared with me previously
and explain how this would be handled by "ORIF"?

I have to point out the following code has error:
...
Here is Jim's equation that is wrong !

Please use quoting properly as I can't tell your
referenced text from your new thoughts. As a result,
I cannot follow your line of thought at all, so I can't
comment on all of it - it looks like you included too
much text.

I will make an educated guess that this is the example
on which you wanted to comment:





Also note that if you are using std_logic or bit types, with the
Accellera VHDL-2006 revision you can write:
OutBusA : process(RESET, CLK)
begin
if(RESET = '1') then
OutBus <= (others=>'0');
elsif rising_edge(CLK) then
if (E0 or E1 or E2 or E3 or E4 or E5) = '1' then
OutBus <=
(E0 and Data0) or (E1 and Data1) or (E2 and Data2) or
(E3 and Data3) or (E4 and Data4) or (E5 and Data5) ;
end if ;
end if ;
end process;

Jim, try this set of values: E0 = '1' and E3 = '1', you get data:
Data0 or Data3, not Data0.

Please note that your original example for OutBus used all
"orif" and did not mix elsif with orif, so yes there is no
priority between E0 and E3 here and Data0 or Data3 is the
correct answer.

Can "ORIF" also construct the equivalent to the following?
OutBusBProc : process(RESET, CLK)
begin
if(RESET = '1') then
OutBus <= (others=>'0');
elsif rising_edge(CLK) then
OutBusB <=
(E0 and Data0) or (E1 and Data1) or (E2 and Data2) or
(E3 and Data3) or (E4 and Data4) or (E5 and Data5) ;
end if ;
end process ;

What compelling real hardware problems does "ORIF" solve
that either are not solved by other methods or are
cumbersome using other methods?

Cheers,
Jim- Hide quoted text -

- Show quoted text -

Hi Jim,
Simply say, there are several ways to specify that a group of signals
is mutually exclusive.

In other words, there are several ways to do the same things. Now the
question is which is best one to be chosen as part of standard of
VHDL.

The differences between your way and mine are as follows:
1a. Your way advantage
Your function name zero_one_hot() can be more compatible with same old
function zero_one_hot(). But you admit there are still problems over
there and you promise it is not a big problem.

1b. You way disadvantage:
it must be done off-line with 2N+1 extra lines to do the same things:
N signal declaration lines;
N assign statements to new signals
1 assertion call statement.

2a. My way advantages are
a. It provides on-line programming capability.
b. It provides a unified language branch statement structure by mixing
'elsif' and 'orif'.

2b. Keyword 'orif' would conflict other old signal name orif users
might have had used.
I am not sure Colin has proved that it can be avoid or not. In this
respect I would like other experts' help to determine it or resolve
it.

From the following code segment provided by Marcus,
Verilog uses new keyword 'unique' to provide on-line programming

capability to specify mutually exclusiveness.

| module unique_if;
| bit clk, reset;
|
| logic E0, E1, E2, E3, E4, E5;
| logic [0:5] E;
|
| logic [7:0] OutBus;
| logic [7:0] Data [0:5] = '{ 0, 1, 2, 3, 4, 5 };
|
|
| initial begin
| clk <= 0;
| reset <= 1;
| #20ns;
| reset <= 0;
| end
|
| always clk = #5ns ~clk;
|
| always @(posedge clk, posedge reset) begin
| if(reset)
| OutBus <= 0;
| else begin
| void'(randomize(E) with {
| E inside { 1, 2, 4, 8, 16, 32, 10 }; // note the
occurence of 10
| });
|
| {E0, E1, E2, E3, E4, E5} = E;
|
| unique if(E0) OutBus <= Data[0];
| else if(E1) OutBus <= Data[1];
| else if(E2) OutBus <= Data[2];
| else if(E3) OutBus <= Data[3];
| else if(E4) OutBus <= Data[4];
| else if(E5) OutBus <= Data[5];
| end
| end
|
| endmodule : unique_if

I don't know if Verilog provides the same function zero_one_hot().

As far as 'orif' is concernd, I would like to ask why 'orif' name
conflict problem is so serious?

In my experiences, I have met more consistency problems between two
VHDL versions about unsigned, std_logic_vec, ... and very confused and
I don't know how to listen to which experts's ideas.

For example, for 200x VHDL version, a new keyword 'orif' will be
added, then you must check if your old design has the words, and
if ...
Is it not enough? Or is it troubled enough to make confusion as large
as unsigned, std_logic_vec, ...?

I will re-post my encoding with 'orif' posted two years ago as Jim
asked.

Weng

 

[Weng Tianxiang]

On Aug 30, 10:08 am, Weng Tianxiang <wtx...@gmail.com> wrote:

On Aug 30, 7:46 am, Jim Lewis <j...@synthworks.com> wrote:





Weng,
I have to change my keyword 'orif' definition to make it perfect (it
may need more fine tuning with other's help, no matter what is, I am
not a good protocol writer, but I am learning), but the basic idea has
been the same as before and consistent without any change since March
2002 I published a paper with Jim as the paper's reviewer.

So you and I have had some time to discuss and ponder this.

Personally I am worn out and don't have further energy to
afford this issue as I consider it a solved problem.

One of the things that shifted my mind away from "ORIF"
is that there are mutual exclusion problems that it
cannot solve. One you had brought up in a previous
discussion (some time ago) where you had mixed conditions
with some signals mutually exclusive and some not.
I think this is a common case.
Can you post one of the examples you shared with me previously
and explain how this would be handled by "ORIF"?

I have to point out the following code has error:
...
Here is Jim's equation that is wrong !

Please use quoting properly as I can't tell your
referenced text from your new thoughts. As a result,
I cannot follow your line of thought at all, so I can't
comment on all of it - it looks like you included too
much text.

I will make an educated guess that this is the example
on which you wanted to comment:

Also note that if you are using std_logic or bit types, with the
Accellera VHDL-2006 revision you can write:
OutBusA : process(RESET, CLK)
begin
if(RESET = '1') then
OutBus <= (others=>'0');
elsif rising_edge(CLK) then
if (E0 or E1 or E2 or E3 or E4 or E5) = '1' then
OutBus <=
(E0 and Data0) or (E1 and Data1) or (E2 and Data2) or
(E3 and Data3) or (E4 and Data4) or (E5 and Data5) ;
end if ;
end if ;
end process;

Jim, try this set of values: E0 = '1' and E3 = '1', you get data:
Data0 or Data3, not Data0.

Please note that your original example for OutBus used all
"orif" and did not mix elsif with orif, so yes there is no
priority between E0 and E3 here and Data0 or Data3 is the
correct answer.

Can "ORIF" also construct the equivalent to the following?
OutBusBProc : process(RESET, CLK)
begin
if(RESET = '1') then
OutBus <= (others=>'0');
elsif rising_edge(CLK) then
OutBusB <=
(E0 and Data0) or (E1 and Data1) or (E2 and Data2) or
(E3 and Data3) or (E4 and Data4) or (E5 and Data5) ;
end if ;
end process ;

What compelling real hardware problems does "ORIF" solve
that either are not solved by other methods or are
cumbersome using other methods?

Cheers,
Jim- Hide quoted text -

- Show quoted text -

Hi Jim,
Simply say, there are several ways to specify that a group of signals
is mutually exclusive.

In other words, there are several ways to do the same things. Now the
question is which is best one to be chosen as part of standard of
VHDL.

The differences between your way and mine are as follows:
1a. Your way advantage
Your function name zero_one_hot() can be more compatible with same old
function zero_one_hot(). But you admit there are still problems over
there and you promise it is not a big problem.

1b. You way disadvantage:
it must be done off-line with 2N+1 extra lines to do the same things:
N signal declaration lines;
N assign statements to new signals
1 assertion call statement.

2a. My way advantages are
a. It provides on-line programming capability.
b. It provides a unified language branch statement structure by mixing
'elsif' and 'orif'.

2b. Keyword 'orif' would conflict other old signal name orif users
might have had used.
I am not sure Colin has proved that it can be avoid or not. In this
respect I would like other experts' help to determine it or resolve
it.

From the following code segment provided by Marcus,

Verilog uses new keyword 'unique' to provide on-line programming
capability to specify mutually exclusiveness.

| module unique_if;
| bit clk, reset;
|
| logic E0, E1, E2, E3, E4, E5;
| logic [0:5] E;
|
| logic [7:0] OutBus;
| logic [7:0] Data [0:5] = '{ 0, 1, 2, 3, 4, 5 };
|
|
| initial begin
| clk <= 0;
| reset <= 1;
| #20ns;
| reset <= 0;
| end
|
| always clk = #5ns ~clk;
|
| always @(posedge clk, posedge reset) begin
| if(reset)
| OutBus <= 0;
| else begin
| void'(randomize(E) with {
| E inside { 1, 2, 4, 8, 16, 32, 10 }; // note the
occurence of 10
| });
|
| {E0, E1, E2, E3, E4, E5} = E;
|
| unique if(E0) OutBus <= Data[0];
| else if(E1) OutBus <= Data[1];
| else if(E2) OutBus <= Data[2];
| else if(E3) OutBus <= Data[3];
| else if(E4) OutBus <= Data[4];
| else if(E5) OutBus <= Data[5];
| end
| end
|
| endmodule : unique_if

I don't know if Verilog provides the same function zero_one_hot().

As far as 'orif' is concernd, I would like to ask why 'orif' name
conflict problem is so serious?

In my experiences, I have met more consistency problems between two
VHDL versions about unsigned, std_logic_vec, ... and very confused and
I don't know how to listen to which experts's ideas.

For example, for 200x VHDL version, a new keyword 'orif' will be
added, then you must check if your old design has the words, and
if ...
Is it not enough? Or is it troubled enough to make confusion as large
as unsigned, std_logic_vec, ...?

I will re-post my encoding with 'orif' posted two years ago as Jim
asked.

Weng- Hide quoted text -

- Show quoted text -

Hi Jim:
1. Your previous coding has error.
"Please note that your original example for OutBus used all
"orif" and did not mix elsif with orif,"
Please check my first posting over there and it mixes the use of
'orif' and 'elsif' starting from the first posting and it never uses
keyword 'orif' only.

And your coding example is directly copied from your first post on
this thread without any change.

You wrote two assertion statements to show your assertion statement
ability, but coding is wrong. You never wrote a assertion that
includes 6 signals from E0 to E5, but your coding was based on it. It
is a little error not affecting out discussions.

2. Jim asked:
Can "ORIF" also construct the equivalent to the following?
OutBusBProc : process(RESET, CLK)
begin
if(RESET = '1') then
OutBus <= (others=>'0');
elsif rising_edge(CLK) then
OutBusB <=
(E0 and Data0) or (E1 and Data1) or (E2 and Data2) or
(E3 and Data3) or (E4 and Data4) or (E5 and Data5) ;
end if ;
end process ;


Here is the answer:

A : process(RESET, CLK)
begin
if(RESET = '1') then
OutBus <= (others=>'0');
elsif rising_edge(CLK) then
if(E0 = '1') then
OutBus <= Data0;
orif(E1 = '1') then
OutBus <= Data1;
orif(E0 = '1') then
OutBus <= Data2;
orif(E0 = '1') then
OutBus <= Data3;
orif(E0 = '1') then
OutBus <= Data4;
orif(E0 = '1') then
OutBus <= Data5;
else
OutBus <= Zero_64;
end if;
end if;
end process;

"ORIF' can not only do the above as an beginner would like to do, but
also do the following equations you showed before more efficiently:

-- assert zero_one_hot (E0, E1, E2) ; -- Jim wrote
-- assert zero_one_hot (E3, E4, E5) ;
assert zero_one_hot (E0, E1, E2, E3, E4, E5) ; -- Weng adds this line
to make code correct

-- It is Jim's coding
OutBusA : process(RESET, CLK)
begin
if(RESET = '1') then
OutBus <= (others=>'0');
elsif rising_edge(CLK) then
if (E0 or E1 or E2 or E3 or E4 or E5) = '1' then
OutBus <=
(E0 and Data0) or (E1 and Data1) or (E2 and Data2) or
(E3 and Data3) or (E4 and Data4) or (E5 and Data5) ;
end if ;
end if ;
end process;

I don't know which VHDL version permits the operation: (E0 and Data0),
even though It is not a problem here

-- It is my coding
A : process(RESET, CLK)
begin
if(RESET = '1') then
OutBus <= (others=>'0');
elsif rising_edge(CLK) then
if(E0 = '1') then
OutBus <= Data0;
orif(E1 = '1') then
OutBus <= Data1;
orif(E2 = '1') then
OutBus <= Data2;
orif(E3 = '1') then
OutBus <= Data3;
orif(E4 = '1') then
OutBus <= Data4;
orif(E5 = '1') then
OutBus <= Data5;
else
OutBus <= OutBus;
end if;
end if;
end process;

The above equation would be implemented in Xilinx chip with carry
chain with initial input data to the carry chain being OutBus. The
following enable equation would be eliminated from Jim's coding:
(E0 or E1 or E2 or E3 or E4 or E5) = '1'

It is not a LUT or two saving as some suggesed. For a up to 400MHz
project, every extra logic would kill a design. Because it takes more
route resources. When route resources exhausted, the running frequency
would drop dramatically and would kill a otherwise successfu design.
LUT is less than a cent in a FPGA.

The above two example show that with mixed 'elsif' and 'orif' language
branch statement structure, HDL will provide more powerful and concise
way to deal with mutually exclusiveness, especially for VHDL
beginners. VHDL beginner would need to go a long way to write the code
type Jim had written.

Weng

 

[Jim Lewis]

Weng,
Note the working group is staffed by volunteers. Initial
proposals are ranked. If they rank high enough, they
get passed to the extensions group. There if someone is
interested in championing a proposal, it gets worked on.
Without a champion, the proposal gets no where - even if
it is something really good - ie: people do not have to
work on things.

What the group tries to do first is to consider issues and
not consider solutions. The person championing a proposal
in fact, can either pick up the proposed solution or go in
a direction that they think solves the problem.

My advice to you is to write a paper that is composed of
two sections:
Part 1:
Identify the problem you are trying to solve. Since this is
hardware centric, it would be appropriate to show schematics or
block diagrams and code. With respect to the code, there should
be several examples.

Part 2:
Explain how your proposed solution solves the problems at
hand and why it is as good as or better than other solutions.
Show what it fails to do.


So far, I have not seen anything there that would warrant
me investing more time in it, however, with your additional
input in the form of a paper, may help.


Note, the most current revision of VHDL that is ready for
vendor adoption is the Accellera draft 3.0, VHDL-2006.
This revision includes PSL which includes the onehot0 built-in
function (thanks to Colin Paul for the correction).
So you would need to show what it does beyond what is
currently available.


Cheers,
Jim

 

[Mike Treseler]

comp.arch.fpga wrote:

The following code has the same semantics:

if E1 + E2 + E3 > 1 then -- (Lazy and incorrect VHDL type handling to
shorten example, you will get the point)
result <= (others => '-');
elsif E1 = '1' then
result <= input1;
elsif E2 = '1' then
result <= input2;
elsif E3 = '1' then
result <= input3;
else
result <= (others => '0');
end if;

This clarifies these long discussions for me.

In most contexts verification is a far bigger problem then efficient
implementation.

I couldn't agree more.

If you really want the most efficient implemetation you should specify
the detailed behaviour.

assert (PSL formulation to guarentee mutual exclusiveness goes here);
result <= (input1 and (result'range => E1) or (input2 and
(result'range => E2) or (input3 and (result'range => E3);

I agree.
I should describe what I care about,
not what I don't care about.
This simplicity eliminates confusion.

Telling the synthesis tool to implement wide ORs in carry chains is
simpler than to introduce a new keyboard.
This way other uses of wide ORs benefit aswell, as do users of other
languages.

Yes.
I like to keep the logic description separate
from the device and tool options.

-- Mike Treseler

 

[Jim Lewis]

Weng,
This is correct for your "State_A" example:

-- assert onehot0 (E0, E1, E2) ; -- Jim wrote
-- assert onehot0 (E3, E4, E5) ;

This is correct for your "OutBus" example.

assert onehot0 (E0, E1, E2, E3, E4, E5) ; -- Weng adds this line

Note I did not write an assertion for your OutBus
example as although it would be nice to have for
simulation, it is not needed at all to get the
hardware you desire.

The above two example show that with mixed 'elsif' and 'orif' language
branch statement structure, HDL will provide more powerful and concise
way to deal with mutually exclusiveness.
Not sure I am comfortable with mixing elsif with orif without

other syntax to reinforce the intent. I am concerned that this
would increase the design risk. Are you certain your
testbench is good enough?

Without more analysis, I would rather write a separate
specification for mutual exclusion (via the assertion)
as this clearly states intent.

VHDL beginner would need to go a long way to write the code
type Jim had written.
Why is a beginner too inept to write an assert statement

especially for your trival code above?

You mention that the big draw back to using complex conditions is
that you would have to create intermediate signals. Why is that
bad? Again, I need to see compelling code cases.


Cheers,
Jim

 

[Jim Lewis]

Kolja,

result <=
(input1 and (result'range => E1)) or
(input2 and (result'range => E2)) or
(input3 and (result'range => E3)) ;

This is another of the correct, but annoying pieces of code
that some synthesis tools (Synopsys) did not implement the last
I checked. Anyone know if they fixed this?

This is the primary reason for the new overloading on logic operations
(AND, OR, ...) that allow mixing a scalar (std_ulogic) with a vector
(std_logic_vector). As a result, with the new revision or old revision
with supplemental overloading one can write:

result <= (input1 and E1) or (input2 and E2) or (input3 and E3);

Cheers,
Jim

 

[Andy]

Weng,

I'll say this: I admire your tenacity.

The coding Jim provided was to illustrate a way, with today's standard
(not including PSL), to code your orif example such that the synthesis
tool would give the equivalent implementation.

Since you seem to be in favor of powerful and concise ways to
implement this, an even better way to code this function would be to
use arrays, particularly with more than just 6 choices involved:

process (reset, clk) is
variable: temp : std_logic_vector(outbus'range);
begin
if reset = '1' then
outbus <= (others => '0');
elsif rising_edge(clk) then
temp := (others => '0');
for i in e'range loop
temp := temp or (e(i) and data(i));
end loop;
if unsigned(e) /= 0 then
outbus <= temp;
end if;
end if;
end process;

Now, if we are allowed to extend the standard (not the language), with
the use of a synthesis-aware assertion and zero_one_hot() function,
this can be greatly simplified, while also making it more functionally
clear:

process (reset, clk) is
begin
if reset = '1' then
outbus <= (others => '0');
elsif rising_edge(clk) then
for i in e'range loop
if e(i) = '1' then
outbus <= data(i);
exit;
end if;
end loop;
assert zero_one_hot(e);
end if;
end process;

However, a loop of if/then statements is not compatible with your
proposed orif keyword.

Therefore, we have a more powerful and concise example of coding this
function with zero_one_hot() than is possible with a new keyword
'orif'.

So, zero_one_hot() can do everything 'orif' can do and more, while
doing so more concisely, and not requiring a language syntax change.

Why do we need 'orif'?

Andy

 

[Weng Tianxiang]

On Aug 30, 1:21 pm, Andy <jonesa...@comcast.net> wrote:

Weng,

I'll say this: I admire your tenacity.

The coding Jim provided was to illustrate a way, with today's standard
(not including PSL), to code your orif example such that the synthesis
tool would give the equivalent implementation.

Since you seem to be in favor of powerful and concise ways to
implement this, an even better way to code this function would be to
use arrays, particularly with more than just 6 choices involved:

process (reset, clk) is
variable: temp : std_logic_vector(outbus'range);
begin
if reset = '1' then
outbus <= (others => '0');
elsif rising_edge(clk) then
temp := (others => '0');
for i in e'range loop
temp := temp or (e(i) and data(i));
end loop;
if unsigned(e) /= 0 then
outbus <= temp;
end if;
end if;
end process;

Now, if we are allowed to extend the standard (not the language), with
the use of a synthesis-aware assertion and zero_one_hot() function,
this can be greatly simplified, while also making it more functionally
clear:

process (reset, clk) is
begin
if reset = '1' then
outbus <= (others => '0');
elsif rising_edge(clk) then
for i in e'range loop
if e(i) = '1' then
outbus <= data(i);
exit;
end if;
end loop;
assert zero_one_hot(e);
end if;
end process;

However, a loop of if/then statements is not compatible with your
proposed orif keyword.

Therefore, we have a more powerful and concise example of coding this
function with zero_one_hot() than is possible with a new keyword
'orif'.

So, zero_one_hot() can do everything 'orif' can do and more, while
doing so more concisely, and not requiring a language syntax change.

Why do we need 'orif'?

Andy

Hi Andy,
I would like to answer your this question.

process (reset, clk) is
begin
if reset = '1' then
outbus <= (others => '0');
elsif rising_edge(clk) then
for i in e'range loop
if e(i) = '1' then
outbus <= data(i);
exit;
end if;
end loop;
assert zero_one_hot(e);
end if;
end process;

Good example !

you have claimed in other place the following:
1. define e;
2. Assign e's every bit a combinational value;

You have missed the most important things: what conditions they are !

Here is an example from my coding that shows orif usage: in-line
programming capability

if(TWindowLoad_E0_L_H and nC_BE_R0(3) = '0') then
TWindow_3(10 downto 8) <= AD_R0(26 downto 24);


orif(TWindowLoad_E0_H_H and nC_BE_R0(7) = '0') then
TWindow_3(10 downto 8) <= AD_R0(58 downto 56);
end if;


Please ask Verilog group why they introduce 'unique' keyword to
provide in-line programming tool to specify the mutually exclusiveness
if I don't misunderstand as following example shown by Marcus:

| module unique_if;
| bit clk, reset;
|
| logic E0, E1, E2, E3, E4, E5;
| logic [0:5] E;
|
| logic [7:0] OutBus;
| logic [7:0] Data [0:5] = '{ 0, 1, 2, 3, 4, 5 };
|
|
| initial begin
| clk <= 0;
| reset <= 1;
| #20ns;
| reset <= 0;
| end
|
| always clk = #5ns ~clk;
|
| always @(posedge clk, posedge reset) begin
| if(reset)
| OutBus <= 0;
| else begin
| void'(randomize(E) with {
| E inside { 1, 2, 4, 8, 16, 32, 10 }; // note the
occurence of 10
| });
|
| {E0, E1, E2, E3, E4, E5} = E;
|
| unique if(E0) OutBus <= Data[0];
| else if(E1) OutBus <= Data[1];
| else if(E2) OutBus <= Data[2];
| else if(E3) OutBus <= Data[3];
| else if(E4) OutBus <= Data[4];
| else if(E5) OutBus <= Data[5];
| end
| end
|
| endmodule : unique_if


Weng

 

[Weng Tianxiang]

Hi Jim and Colin,
Your assert zero_one_hot() (or any other function name) may not be the
one I want.

Your zero_one_hot() tells simulator to check if all bits meet the zero
or one active conditions. If it meets, return '1', otherwise return
'0'.

The code doesn't have any AUTHORITY to let VHDL compiler to do any
optimization, and it just has the AUTHORITY to let simulator run the
function and check its correctness.

An assertion function is not authorized to transfer information to
VHDL compiler !

In strict computer language meaning, any VHDL compiler has no
OBLIGATION to do optimization work based on information of inputs from
zero_one_hot() code even though they are designed to do so for the
purpose.

What an assertion function can do is to return its value: true or
false, how can it be used to transfer mutually exclusive information
to VHDL compiler? IT IS ILLEGAL !

If so, that is totally different from 'orif' meaning: for 'orif' It
not only gives the mutually exclusive information, but also orders:
1. VHDL compiler to do code optimization based on the mutually
exclusive information;
2. Simulator to check if related mutually exclusiveness is met.

Because it is a keyword, it has AUTHORITY to issue two different
commands to VHDL compiler and simulator, respectively, and the orders
are mandated and it has no code to execute.

Finally I got my point.

Weng

 

[Colin Paul Gloster]

Jim,

In news:13ddnbc8cckdr7b@corp.supernews.com timestamped Thu, 30 Aug
2007 08:08:26 -0700, Jim Lewis <jim@synthworks.com> posted:
|-------------------------------------------------------------------------------------------------|
|"Colin Paul, |
|[..] |
|> That would be true for plain VHDL without PSL, but he posted as if |
|> zero_one_hot() is now part of VHDL from PSL (but it is not in my PSL |
|> reference manual, unlike onehot0) so that would not necessarily |
|> require that a VHDL identifier be changed. From the PSL standard: |
|> "[..] |
|> |
|OOPS. I missed that. I had meant to reference the PSL function onehot0." |
|-------------------------------------------------------------------------------------------------|

Muw wah hah hah, all shall bow down to my superiority.

|-------------------------------------------------------------------------------------------------|
|"[..] |
| |
|While it is possible that syntax could be given a similar |
|interpretation, I am not sure it would be a good thing. |
| |
|Cheers, |
|Jim" |
|-------------------------------------------------------------------------------------------------|

If we ever need to consider it, we can assess the pros and cons then.

Cheers,
Colin Paul

 

[Andy]

Weng,

You're right, the loop code example is a good example. It beautifully
illustrates the fatal flaw in 'orif': it cannot be applied to an
arbitrary (parameterized) number of conditions. You still have not
acknowledged this flaw.

As for "extra" declarations and assignments, I took YOUR example that
had separate signals for E0, E1... E5, (which must have been declared
and assigned separately somewhere else), and simply combined them into
an array (with one fifth the signal declarations). Likewise I took
YOUR data0, data1...data5 signals (which also must have been declared
and assigned somewhere else), and combined them, with a similar
SAVINGS in declarations. So, tell me again how it would take more code
to use the arrays that it did the separate signals?

This is one of my biggest pet peeves when I see others' code that has
signals named the same, with incrementing suffixes: Use an array, and
once it is in an array, use a loop. It takes less code, not more, to
use an array.

As for your later example:

assert zero_one_hot(((TWindowLoad_E0_L_H and nC_BE_R0(3) = '0'),
(TWindowLoad_E0_H_H and nC_BE_R0(7) = '0')));

I simply cut and pasted the expressions that were deemed mutually
exclusive from your code. Not a lot of typing going on there.

If, on the other hand I wanted your original code to be a little more
readable, I might have declared/assigned a signal/variable or two,
aptly named, to represent the conditions in a more human readable
form. Then those same signals and variables could be used in the
asserted function call as well. Yes, a little more code, but a little
more readable too.

I don't know about everyone else, but I don't want VHDL to look like
Verilog! Verilog does some really stupid things, and I don't want us
jumping off the same cliff they just did.

Take a closer look at that (System?)Verilog code. They started out
with an array (E) filled with random values, and then broke it back
out into discrete signals to use in the 'if' tree (could they have
just used elements of E?). All because they can't use 'unique' in a
loop! That is a fantastic example of the folly of unique/orif! Thanks!

Andy

 

[Andy]

On Aug 30, 10:32 pm, Weng Tianxiang <wtx...@gmail.com> wrote:

Hi Jim and Colin,
Your assert zero_one_hot() (or any other function name) may not be the
one I want.

Your zero_one_hot() tells simulator to check if all bits meet the zero
or one active conditions. If it meets, return '1', otherwise return
'0'.

The code doesn't have any AUTHORITY to let VHDL compiler to do any
optimization, and it just has the AUTHORITY to let simulator run the
function and check its correctness.

An assertion function is not authorized to transfer information to
VHDL compiler !

In strict computer language meaning, any VHDL compiler has no
OBLIGATION to do optimization work based on information of inputs from
zero_one_hot() code even though they are designed to do so for the
purpose.

What an assertion function can do is to return its value: true or
false, how can it be used to transfer mutually exclusive information
to VHDL compiler? IT IS ILLEGAL !

If so, that is totally different from 'orif' meaning: for 'orif' It
not only gives the mutually exclusive information, but also orders:
1. VHDL compiler to do code optimization based on the mutually
exclusive information;
2. Simulator to check if related mutually exclusiveness is met.

Because it is a keyword, it has AUTHORITY to issue two different
commands to VHDL compiler and simulator, respectively, and the orders
are mandated and it has no code to execute.

Finally I got my point.

Weng

Weng,

Your logic is completely, fatally flawed.

For example, an integer declaration like:

signal myint: integer range 0 to 255;

Only tells the simulator that it cannot put a value outside the range
of 0 to 255, inclusive, into myint. There is no authority to command
that a synthesis tool implements myint as an 8 bit value, but every
single synthesis tool in existence will do just that.

Taken a step further, a counter, coded with an integer, will not roll
over automatically. Yet the synthesis tool understands that the
definition of the integer type means that when the maximum value is
incremented (and stored back to the integer!), the result is undefined
(i.e. would cause an assertion in the simulator). With this
information, the synthesis tool creates the circuit such that it would
roll over if that ever happened, since it is free to do so because
there is no simulator behavior to match in that case. The reason the
synthesis tool creates such a hardware counter is that it takes less
hardware to roll over than to do anything else. Again, the language
did not command the synthesis tool to do it, but the language gave the
synthesis tool enough information that it could make the optimization.

I have seen cases where I defined a counter with a range of 0 to 5.
The synthesis tool optimized the decode function for the value 5
because it knew that 7 was not allowed (this may have also been the
result of a reachability analysis on the code for the counter). There
was no command to do that, it just did it, because it could do so,
while preserving the behavior of the code.

Likewise, an assertion does not "command" a synthesis tool anything.
But, just like ranges on integers, the assertion gives the synthesis
tool information that it can use to optimize the circuit
appropriately.

Declaring an array of vectors, and accessing only one or two elements
(single or dual port) per clock cycle, does not "command" the
synthesis tool to do anything. Yet most, if the target allows it, will
implement the circuit with a RAM, because the synthesis tool
recognizes that a RAM is the most efficient way to implement the
behavior.

Your concept of the VHDL language "commanding" the synthesis tool to
do things is not accurate. The synthesis tool simply, to the best of
its ability, creates a circuit that exhibits the same behavior that
the code would exhibit in a simulator. There are standardized methods
of describing the behavior (e.g. clock edge specifications, etc.) so
that all tools will recognize the same behavior and implement it in a
similar manner, but the language is not commanding the synthesis tool
to do anything except implement the behavior in a circuit.

Andy

 

[Jim Lewis]

Weng,
Synthesis tools already commonly handle some form of
attributes and metacomments.

Attributes (I have used flavors of the following in both
Xilinx and synplicity):
signal T1, T2 : std_logic;
Attribute keep : boolean ;
Attribute keep of T1, T2 : signal is true ;

Metacomments:
-- pragma synthesis_off
-- pragma synthesis_on


Assertions are nothing more than a simple extension.
I thought I heard that Synplicity is already
synthesizing some assertions of their own.

Jim

 

[Weng Tianxiang]

On Aug 31, 9:12 am, Jim Lewis <j...@synthworks.com> wrote:

Weng,
Synthesis tools already commonly handle some form of
attributes and metacomments.

Attributes (I have used flavors of the following in both
Xilinx and synplicity):
signal T1, T2 : std_logic;
Attribute keep : boolean ;
Attribute keep of T1, T2 : signal is true ;

Metacomments:
-- pragma synthesis_off
-- pragma synthesis_on

Assertions are nothing more than a simple extension.
I thought I heard that Synplicity is already
synthesizing some assertions of their own.

Jim

Hi Jim,
If you use Attributes to declare mutually exclusiveness, I think it is
OK, no problem. Because attributes is only used for compilers. But
your method is using a function whose input contents are expected to
be transferred to compiler, it is unprecedented !!!

Using an attributes is certainly more natural than Jim's assertion
function().

Adam,
I don't dispute your claim that if mutually exclusive group is
declared, they have their advantages over 'orif'. In my paper in 2002,
I declared two methods, one for 'orif', another for keyword
'Exclusive' to declare not only a group of signals, but a group of
state machines. At that time, I knew both had their own advantages in
different situations.

Now the problems are:
1. Jim's method uses assertion function(); Why don't we use attribute?
No precedent example can be found by using a assertion function()
structure to transfer information to VHDL compiler.

2. Including a group mutually exclusive method shouldn't expel another
on-line programming method 'orif'. That is my point !!! Get two
methods and let engineers to determine what best fit their demand.

3. There are a lot of situations that your variable counter method
fails, but 'orif' method best fits.

I will re-post my longest 'orif' code segment from my coding to show
you the other alternative way to do the same things.

Please count how many conditions contained in if() and elsif() whose
equations in any of your project you use loop structure to generate,
and tell me the ratio.

My ratio is 95/5 in favor of on-line programming.

In my opinion, your mutually exclusive situations should be expected
to have the same ratio.

4. Your coding has a big and fatal problem and never should be used in
any situations like that:
assert zero_one_hot(((TWindowLoad_E0_L_H and nC_BE_R0(3) = '0'),
(TWindowLoad_E0_H_H and nC_BE_R0(7) = '0')));

Why? I will tell you later. Think of it yourselves and you should know
why.

Weng

 

[Andy]

I don't dispute your claim that if mutually exclusive group is
declared, they have their advantages over 'orif'. In my paper in 2002,
I declared two methods, one for 'orif', another for keyword
'Exclusive' to declare not only a group of signals, but a group of
state machines. At that time, I knew both had their own advantages in
different situations.

I tend to prefer one method over two, as long as the one method
handles every situation that the second method does, and already
exists within the syntax of the language. If I write a zero_one_hot()
function today, and use it in my code, there is not a single tool out
there that will fail on it. Synthesis tools may not yet know how to
use it, but they'll just ignore it and go on. On the other hand, if I
put 'orif' in any of my code, then every tool (editor, simulator,
formal analyzer, synthesis, etc.) I use it on will have to be updated
to accept it, or they will error out. That takes a lot longer to
happen, and no tool can effectively support it until most/all tools
do. That would be acceptable if a keyword/statement change were the
only effective way to get the capability we desire, but it's not.

Now the problems are:
1. Jim's method uses assertion function(); Why don't we use attribute?
No precedent example can be found by using a assertion function()
structure to transfer information to VHDL compiler.

An assertion (psl or native vhdl) is verified during simulation and/or
formal analysis. An attribute is a piece of information that is
assumed to be true, but not verified. If we used attributes, then
there would be no way to determine that we had correctly specified the
attribute.

2. Including a group mutually exclusive method shouldn't expel another
on-line programming method 'orif'. That is my point !!! Get two
methods and let engineers to determine what best fit their demand.

I think the engineers here have spoken (not that this forum is a/the
standardization authority); you're just not listening. I'm not in
favor of adding a statement/keyword to the language for a purpose that
is better served within the bounds of the existing language, when
there has been essentially no support for it from anyone except you.

3. There are a lot of situations that your variable counter method
fails, but 'orif' method best fits.

I will re-post my longest 'orif' code segment from my coding to show
you the other alternative way to do the same things.

Please count how many conditions contained in if() and elsif() whose
equations in any of your project you use loop structure to generate,
and tell me the ratio.

My ratio is 95/5 in favor of on-line programming.

I can tell.

In my opinion, your mutually exclusive situations should be expected
to have the same ratio.

Nope, I use arrays and loops closer to 95% of the time. I hate typing
and checking long if/elsif statements to make sure I have the right
suffixes matched up. If I find myself using one, I back up and figure
out where I went wrong.

4. Your coding has a big and fatal problem and never should be used in
any situations like that:
assert zero_one_hot(((TWindowLoad_E0_L_H and nC_BE_R0(3) = '0'),
(TWindowLoad_E0_H_H and nC_BE_R0(7) = '0')));

Why? I will tell you later. Think of it yourselves and you should know
why.

Look, I'm not here to play games with you, nor is anyone else. If you
see a bug, tell us; we've all got better things to do that wait for
you to enlighten us.

Andy

 

[Weng Tianxiang]

On Aug 31, 1:52 pm, Andy <jonesa...@comcast.net> wrote:

I don't dispute your claim that if mutually exclusive group is
declared, they have their advantages over 'orif'. In my paper in 2002,
I declared two methods, one for 'orif', another for keyword
'Exclusive' to declare not only a group of signals, but a group of
state machines. At that time, I knew both had their own advantages in
different situations.

I tend to prefer one method over two, as long as the one method
handles every situation that the second method does, and already
exists within the syntax of the language. If I write a zero_one_hot()
function today, and use it in my code, there is not a single tool out
there that will fail on it. Synthesis tools may not yet know how to
use it, but they'll just ignore it and go on. On the other hand, if I
put 'orif' in any of my code, then every tool (editor, simulator,
formal analyzer, synthesis, etc.) I use it on will have to be updated
to accept it, or they will error out. That takes a lot longer to
happen, and no tool can effectively support it until most/all tools
do. That would be acceptable if a keyword/statement change were the
only effective way to get the capability we desire, but it's not.



Now the problems are:
1. Jim's method uses assertion function(); Why don't we use attribute?
No precedent example can be found by using a assertion function()
structure to transfer information to VHDL compiler.

An assertion (psl or native vhdl) is verified during simulation and/or
formal analysis. An attribute is a piece of information that is
assumed to be true, but not verified. If we used attributes, then
there would be no way to determine that we had correctly specified the
attribute.



2. Including a group mutually exclusive method shouldn't expel another
on-line programming method 'orif'. That is my point !!! Get two
methods and let engineers to determine what best fit their demand.

I think the engineers here have spoken (not that this forum is a/the
standardization authority); you're just not listening. I'm not in
favor of adding a statement/keyword to the language for a purpose that
is better served within the bounds of the existing language, when
there has been essentially no support for it from anyone except you.



3. There are a lot of situations that your variable counter method
fails, but 'orif' method best fits.

I will re-post my longest 'orif' code segment from my coding to show
you the other alternative way to do the same things.

Please count how many conditions contained in if() and elsif() whose
equations in any of your project you use loop structure to generate,
and tell me the ratio.

My ratio is 95/5 in favor of on-line programming.

I can tell.



In my opinion, your mutually exclusive situations should be expected
to have the same ratio.

Nope, I use arrays and loops closer to 95% of the time. I hate typing
and checking long if/elsif statements to make sure I have the right
suffixes matched up. If I find myself using one, I back up and figure
out where I went wrong.



4. Your coding has a big and fatal problem and never should be used in
any situations like that:
assert zero_one_hot(((TWindowLoad_E0_L_H and nC_BE_R0(3) = '0'),
(TWindowLoad_E0_H_H and nC_BE_R0(7) = '0')));

Why? I will tell you later. Think of it yourselves and you should know
why.

Look, I'm not here to play games with you, nor is anyone else. If you
see a bug, tell us; we've all got better things to do that wait for
you to enlighten us.

Andy

Andy,
1. Thank you for your response. I learn something very important from
you through this topics discussion.

2. Why? Never copy any dynamic code segment to other place. Because
code is changing and you have two code copied at two different places.
When you change one copy, most of time, you would forget the 2nd copy.
The fatal error is a timing bomb, not now.

3. I really don't understand how you reach 95% ratio to use loop to
write data bus.

For example, a data bus (63-0) loading, you have 5 cases, how can you
use loop to implement the code? because each loading condition
equations are different. It is unbelievable that you would 1) define a
unsigned(4-0) in the definition area; 2) assign each condition to each
bit at concurrent area; 3) then do a loop in a sequential area; 4)
don't forget assert function().

That is why Verilog introduce unique keyword. Now you favors one over
another, it is OK, but it doesn't guarantee that you will never use
another alternative method if it is available.

All side kick signals, 1 bit each, they are very short, but very
important to control data flow, most of them must be written in
separate conditional equations, how can you do them in a loop? In one
of my designs, there are 2,500 lines for signal definition part, there
may be 500 side kick signals, their coding is very short, but most of
time the loading is mutually exclusive. It would be very pain to use 3
steps to define mutually exclusive situations if only one definition
is used.

Thank you.

Weng

 

[Weng Tianxiang]

On Aug 30, 7:28 am, "comp.arch.fpga" <ksuli...@googlemail.com> wrote:

On 28 Aug., 13:23, Marcus Harnisch <marcus.harni...@gmx.net> wrote:> Weng Tianxiang <wtx...@gmail.com> writes:

Weng, take a step back.

First, not under all circumstances the carry chain implementation is
the most efficient of the gated OR selector.
For small number of inputs it fits into a single 6-LUT, for very large
number of inputs the logarithmic delay of the tree will be better than
the linear delay of the carry chain, even though the constants for the
carry chain are better.

Second, the only thing that your orif keyword thos, is a hint to the
synthesizer that the behaviour is undefined for certain input
combinations. You restrict the domain of the function. The following
code has the same semantics:

if E1 + E2 + E3 > 1 then -- (Lazy and incorrect VHDL type handling to
shorten example, you will get the point)
result <= (others => '-');
elsif E1 = '1' then
result <= input1;
elsif E2 = '1' then
result <= input2;
elsif E3 = '1' then
result <= input3;
else
result <= (others => '0');
end if;

You will however notice, that most synthesis tools will not utilize
the optimization potential available from '-'.
I am often annoyed by this. For example if you write an instruction
decoder for a CPU, you do not care about the behaviour of the ALU for
all instructions that use no ALU result. Specifying don't cares would
greatly reduce the amount of logic for the decoder. This is an
improvement that is far more versatile than your proposal and it is
allready in the language.

However most synthesis tools will replace all occurences of '-' with
'0'. The reason behind this is that verification guys hate don't
cares. For regression testing you wan't the hardware to behave the
same if the specification did not change. '-' might be synthesized
differently every time. For formal verification you definitely can't
allow the freedom of don't cares.
In most contexts verification is a far bigger problem then efficient
implementation.

If you really want the most efficient implemetation you should specify
the detailed behaviour.

assert (PSL formulation to guarentee mutual exclusiveness goes here);
result <= (input1 and (result'range => E1) or (input2 and
(result'range => E2) or (input3 and (result'range => E3);

Telling the synthesis tool to implement wide ORs in carry chains is
simpler than to introduce a new keyboard.
This way other uses of wide ORs benefit aswell, as do users of other
languages.

Kolja Sulimma

P.S.: Xilinx has a patent on implementing a wide OR using carry logic.
There is no explicit license that grants you the right to distribute
bitstreams that use that trick. Xilinx says, they do not want to sue
anybody about that. But I bet Unisys had no intent to sue GIF users in
the 80ies. But intentions can change. Do you want to bet your business
on an informal declaration by Austin in a newsgroup?

Hi Kolja,
This topics has two groups of people, one for how to best define
mutually exclusiveness in VHDL, another who don't believe it may
provide any benefits to design.

You are the one of second group.

I would like to repeat a famous English sentence from Altera I learned
when I wan installing Altera software: What you can do, we can do
better.

My opinion is when VHDL compilers get more information about mutually
exclusive information, what you can do, the VHDL compilers can do
better.

VHDL compilers can generate all coding you showed for one level of
mutually exclusiveness. You may not write efficiently for code with
two levels or even three levels of mutually exclusiveness. Personal
power is limited and VHDL compilers can be trained to do more
mechanical things than any human.

-- It is Jim's coding
OutBusA : process(RESET, CLK)
begin
if(RESET = '1') then
OutBus <= (others=>'0');
elsif rising_edge(CLK) then
if (E0 or E1 or E2 or E3 or E4 or E5) = '1' then
OutBus <=
(E0 and Data0) or (E1 and Data1) or (E2 and Data2) or
(E3 and Data3) or (E4 and Data4) or (E5 and Data5) ;
end if ;
end if ;
end process;


I don't know which VHDL version permits the operation: (E0 and
Data0),
even though It is not a problem here


-- It is my coding
A : process(RESET, CLK)
begin
if(RESET = '1') then
OutBus <= (others=>'0');
elsif rising_edge(CLK) then
if(E0 = '1') then
OutBus <= Data0;
orif(E1 = '1') then
OutBus <= Data1;
orif(E2 = '1') then
OutBus <= Data2;
orif(E3 = '1') then
OutBus <= Data3;
orif(E4 = '1') then
OutBus <= Data4;
orif(E5 = '1') then
OutBus <= Data5;
else
OutBus <= OutBus;
end if;
end if;
end process;


The above equation would be implemented in Xilinx chip with carry
chain with initial input data to the carry chain being OutBus. The
following enable equation would be eliminated from Jim's coding:
(E0 or E1 or E2 or E3 or E4 or E5) = '1'


It is not a LUT or two saving as some suggesed. For a up to 400MHz
project, every extra logic would kill a design. Because it takes more
route resources. When route resources exhausted, the running
frequency
would drop dramatically and would kill a otherwise successfu design.
LUT is less than a cent in a FPGA.


The above two example show that with mixed 'elsif' and 'orif'
language
branch statement structure, HDL will provide more powerful and
concise
way to deal with mutually ...

You are a doubtor of the technology, Verilog has formally introduced
the technology, and VHDL will follow.
It is a trend.

I prefer writing 'if...end if' statements than your and Jim's coding.
Why? It is really not a VHDL language, but an ASM language and there
are many pains.

I am fighting for an alternative, concise and simple method to do the
same job as Jim has suggested.

Thank you.

Weng