New keyword 'orif' and its implications

[Weng Tianxiang]

Hi,
I open a new topics from previous one to try to stir another round to
introduce a new keyword 'orif'.

Weng,

What would happen in a simulator if the "orif" conditions were not
actually mutually exclusive? How would you allow the user to define
said behavior? Is zero-hot and option, or is one-hot guaranteed? How
would the user define that?

The existing language allows for mutually exclusive conditions, but
said conditions must be statically verifiable as mutex and complete
(case statements). For dynamic mutex inputs, verification is best
handled in an assertion. If a standardized one_hot() or zero_one_hot()
function could be created (to operate on an unconstrained vector of
booleans, for example), then synthesis could recognize their use in an
assertion, and make the appropriate optimizations automatically,
without affecting the syntax or structure of the language. The
assertion (or other code) could also control what happens when, in
fact, the conditions are not mutually exclusive (the same way the
language handles indices out of bounds, etc.). In other words, in
order to gain that level of control over what happens if mutex is not
true, you'd have to use the same amount of code for either solution,
and the latter solution does not require a change to the language.
Additionally, the use of an assertion is such an application allows
the code more flexibility in describing the resulting behavior,
without resulting to a single if-orif tree. Simply tell the synthesis
tool that, by the way, x and y are one_hot, and it can make
optimizations (like sharing resources) efficiently, independent of the
rest of the structure.

Finally, "orif" would be a very poor choice for such a keyword, even
if the feature were a good idea. "Orif" by name implies that multiple
conditions are potentially true (logical 'OR' function), and all
statements associated with all true conditions would be executed,
which is precisely the opposite of what you described. This behavior
is equivalent to multiple, non-nested if-then statements.

Andy- Hide quoted text -

- Show quoted text -

Hi Andy,
A group of signals is defined as mutually exclusive if either no
signal or only one signal in the group is asserted on any cycle.

Keyword 'orif' has the same language grammar definition as 'elsif'
with one exception: conditional signal contained in leading 'if' or
'elsif' segment and conditional signals contained in the subsequent
and contiguous 'orif' segment in an 'if' statement are mutually
exclusive. Where keyword 'elsif' can be used in a VHDL code, there
keyword 'orif' can be used.

Here is an example on how to use keyword 'orif':

If(E0 = '1') then
State_A <= E0_S;
Orif(E1 = '1') then
State_A <= E_S;
Orif(E2 = '1') then
State_A <= E2_S;
elsIf(E3 = '1') then
State_A <= E3_S;
Orif(E4 = '1') then
State_A <= E4_S;
Orif(E5 = '1') then
State_A <= E5_S;
elsIf(E6 = '1') then
....

It has two mutually exclusive signal groups: signals E0, E1 and E2 are
mutually exclusive. So are signals E3, E4 and E5.

The implementation benefits with FPGA are huge !!!

For example:

OutBus has 64-bit width.

OutBusA : process(RESET, CLK)
begin
if(RESET = '1') then
OutBus <= (others=>'0');
elsif(CLK'event and CLK = '1') 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;
end if;
end if
end process;

1. If the keyword 'orif' is adopted as a VHDL standard, the above
equation would be executed in FPGA chips not by mux, not by case
statement implementation method, but by the most efficient method:
carry chain in Xilinx chips !!!

It would be executed like a sum of products: In assembly language for
shortness:
OutBus = E0*Data0 + E1*Data1 + ... + E5*Data5;

The new keyword 'orif' is most beneficial to FPGA users !!!

Please check Xilinx application note about how to implement sum of the
products (I failed to find it)

In other words, if keyword 'orif' is introduced into VHDL standard,
Xilinx carry chain structure would become part of VHDL standard in a
natural way. 'orif' will be refered to carry chain in FPGA
structure !!!

Xilinx Peter, what your idea is about the keyword 'orif'?

2. If the keyword 'orif' is adopted as a VHDL standard, it can specify
that during simulation, if a simulator detects two signals being
active in a mutually exclusive group on current cycle, simulator
issues a fatal error and stops without any user's interference !!!

Simple and reliable !!!

3. I expect Xilinx would be the first company to implement the new
keyword 'orif', because its fastest carry chain feature would be best
used in the situations without users' efforts to change its writing
patterns. You may imagine 64-bit data bus would occupy a lot of space
and resources if not the best carry chains are referenced. And the
routine timing will be hugely saved and running frequency will hugely
boosted.

4. 'orif' name is very appropriate. It means if above conditional
equation is not met, or try this one, or try next, or try the
last, ... it meets the equation above in assembly.

5. Most of programmers never use mutually exclusive property in their
designs and they fear the property would be violated some times. But
here are some hints the violation situation will never happen if it is
appropriate.

a. Data buses are always mutually exclusive !!!

If two data conditions on a data bus may be active at the same cycle,
add minimum additional conditions to make them mutually exclusive.

b. Count loadings are always mutually exclusive !!!

c. All group of register's loadings are always mutually exclusive !!!

d. All FIFO input data loadings are mutually exclusive !!!

6. Keyword 'orif' is useless for IC chip design. Because IC compilers
do their best to optimize them.

7. Mutually exclusiveness is ubiquitout in logic design and I am very
sorry for VHDL without a special keyword to deal with it.

Any comments are welcome.

Weng

 

[Jonathan Bromley]

I open a new topics from previous one to try to stir another round to
introduce a new keyword 'orif'.

Weng,

It seems to me that what you are trying to do is very similar
to SystemVerilog's "unique" and "priority" keywords. It is
not completely clear from your posts exactly what the semantics
of "orif" should be, but as I understand it you intend that
"orif" should have exactly the same behaviour as "elsif",
together with a mutual-exclusivity check so that it is an
error if more than one of the "if" conditions is true.
I agree that this is a desirable thing to be able to say.

I do not fully understand how your combinations of "orif"
and "elsif" are intended to work.

It is also desirable to be able to specify that *at least*
one of the conditions is true. And then you can combine
the "at-least-one" and "at-most-one" tests to guarantee
that there is EXACTLY one condition true. Note that
SystemVerilog got this wrong, in my opinion: "unique"
enforces exactly-one, and "priority" enforces at-least-one,
so there is no easy way to specify at-most-one.

It is easier in VHDL than Verilog, because the test
expressions cannot have side-effects.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
(e-mail address removed)
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[Marcus Harnisch]

[lots of stuff]

What you are looking for seems to be more or less equivalent to
SystemVerilog's `unique if' statement. It could have been written
using a case statement instead but I was trying to stay close to the
proposed VHDL syntax.

Synthesis and formal tools *may* use that information. Simulation
gives you a run-time error in case of a violation.

,----
| 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
`----

Regards,
Marcus

 

[Mike Treseler]

I open a new topics from previous one to try to stir another round to
introduce a new keyword 'orif'.

The old bait and switch.
I've been trolled again.

-- Mike Treseler

 

[KJ]

Hi,
I open a new topics from previous one to try to stir another round to
introduce a new keyword 'orif'.

Jim Lewis doesn't own the VHDL language standard nor is he a
gatekeeper that prevents suggestions from being submitted. His clout
kicks in more after the submission....but that's off on a tangent.

Keyword 'orif' has the same language grammar definition as 'elsif'
with one exception: conditional signal contained in leading 'if' or
'elsif' segment and conditional signals contained in the subsequent
and contiguous 'orif' segment in an 'if' statement are mutually
exclusive. Where keyword 'elsif' can be used in a VHDL code, there
keyword 'orif' can be used.

Here is an example on how to use keyword 'orif':

If(E0 = '1') then
State_A <= E0_S;
Orif(E1 = '1') then
State_A <= E_S;
Orif(E2 = '1') then
State_A <= E2_S;
elsIf(E3 = '1') then
State_A <= E3_S;
Orif(E4 = '1') then
State_A <= E4_S;
Orif(E5 = '1') then
State_A <= E5_S;
elsIf(E6 = '1') then
...

Doesn't grab me much but I don't find it offensive either, just
different.

It has two mutually exclusive signal groups: signals E0, E1 and E2 are
mutually exclusive. So are signals E3, E4 and E5.

Only because you say they are mutually exclusive though. I can
guarantee exclusivity by using existing VHDL enumerated types and a
single signal.

The implementation benefits with FPGA are huge !!!

Might want to consider less use of the exclamation point in the
future.

For example:

OutBus has 64-bit width.

OutBusA : process(RESET, CLK)
begin
if(RESET = '1') then
OutBus <= (others=>'0');
elsif(CLK'event and CLK = '1') 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;
end if;
end if
end process;

1. If the keyword 'orif' is adopted as a VHDL standard, the above
equation would be executed in FPGA chips not by mux, not by case
statement implementation method, but by the most efficient method:
carry chain in Xilinx chips !!!

It would be executed like a sum of products: In assembly language for
shortness:
OutBus = E0*Data0 + E1*Data1 + ... + E5*Data5;

You seem to be forgetting the multiply operation in your above
equation it's not 'just' adding Data0, Data1, etc. Also, if I were
faced with this situation and today's syntax I would probably code it
as...

OutBus = F(E0, Data0) + F(E1, Data1) + ... + F(E5, Data5);

where F() is a function that returned either the second argument or 0
based on how the first argument is set...in other words a simple
couple line function that accomplishes a specific task. If the number
of 'Data' elements was parameterized I might decide to embed that into
the function as well and pass in an array of 'Data' instead of
'Data0'...'Data5'....but that's just me.

Please check Xilinx application note about how to implement sum of the
products (I failed to find it)

Hmmm....don't think you gain much credibility with that statement.

In other words, if keyword 'orif' is introduced into VHDL standard,
Xilinx carry chain structure would become part of VHDL standard in a
natural way. 'orif' will be refered to carry chain in FPGA
structure !!!

You seem to be forgetting something very basic....if it can be
implemented with a carry chain at all, it can be done with today's
syntax as well.

2. If the keyword 'orif' is adopted as a VHDL standard, it can specify
that during simulation, if a simulator detects two signals being
active in a mutually exclusive group on current cycle, simulator
issues a fatal error and stops without any user's interference !!!

Hmmm....but you said that they were mutually exclusive but now you're
alluding to the possibility that they might not. So what would happen
in the implemented hardware? No assertions there, just logic
implemented as LUT (FPGA), and/or (CPLD), gates (ASIC). The hardware
will do something and it probably will do something inappropriate
without a language guarantee that the collection is mutually exclusive
as it is supposed to be....which is precisely what enumerated types do
for you.

Simple and reliable !!!

You haven't sold me on the 'reliable' part. The 'simple' part is OK,
but it's not much simpler than what can be done today so the relative
measure of 'simple' is pretty low in this case in my opinion. Having
to wonder about how exclusivity is guaranteed, how can I mess it up
and things like that don't excite me.

3. I expect Xilinx would be the first company to implement the new
keyword 'orif', because its fastest carry chain feature would be best
used in the situations without users' efforts to change its writing
patterns.

Gosh I hope not....implement the language standard not somebody's
extensions.

You may imagine 64-bit data bus would occupy a lot of space
and resources if not the best carry chains are referenced. And the
routine timing will be hugely saved and running frequency will hugely
boosted.

Got anything to back up those claims? The language extension that
you're proposing will do absolutely nothing to the final hardware,
there will be no savings of any kind. What you're proposing is (at
best) a designer productivity improvement (i.e. lines of working code
per unit of time). To suggest that a new language keyword would
result in better resource usage is suspect. Have you benchmarked
exactly how things get implemented today using functionally equivalent
logic? Boolean logic does not require language keywords beyond 'and',
'or' and 'not'. Designer productivity increases with higher level
abstractions but I'm not seeing much, if any, improvement to be gained
by 'orif'.

4. 'orif' name is very appropriate. It means if above conditional
equation is not met, or try this one, or try next, or try the
last, ... it meets the equation above in assembly.

'elsif' on an enumerated type signal does that as well and is just as
descriptive as 'orif'.

5. Most of programmers never use mutually exclusive property in their
designs and they fear the property would be violated some times.

Got any basis for that statement? Programmers? Doing VHDL? I'd
guess that they would catch on to either enumerated types or functions
pretty quickly though.

But
here are some hints the violation situation will never happen if it is
appropriate.

a. Data buses are always mutually exclusive !!! Does that even mean anything?

If two data conditions on a data bus may be active at the same cycle,
add minimum additional conditions to make them mutually exclusive.

And how do those conditions get satisfied and guaranteed? Hmmm...

7. Mutually exclusiveness is ubiquitout in logic design and I am very
sorry for VHDL without a special keyword to deal with it.

What is it about enumerated types in VHDL that you find so hard?

KJ

 

[Jim Lewis]

Weng,

Hi,
I open a new topics from previous one to try to stir another round to
introduce a new keyword 'orif'.

My conclusion from our numerous previous discussions
on this topic are that for simple cases it looks
intuitive and makes the syntax look deceptively
attractive, however, for more interesting conditions,
it becomes difficult if not impossible to identify the
mutually exclusive items and, hence, you will get
little to no benefit from it. So I was tickled to see
that SystemVerilog decided to implement something similar
to this, however, I would suspect that they do not give
you quite the flexibility that you want.

On the other hand, as I mentioned previously and Andy
pointed out in the thread you quoted (repeated below):
"For dynamic mutex inputs, verification is best
handled in an assertion. If a standardized one_hot() or zero_one_hot()
function could be created (to operate on an unconstrained vector of
booleans, for example), then synthesis could recognize their use in an
assertion, and make the appropriate optimizations automatically,
without affecting the syntax or structure of the language. The
assertion (or other code) could also control what happens when, in
fact, the conditions are not mutually exclusive (the same way the
language handles indices out of bounds, etc.). In other words, in
order to gain that level of control over what happens if mutex is not
true, you'd have to use the same amount of code for either solution,
and the latter solution does not require a change to the language."

I also note that some synthesis tools have started to support assertions
in synthesis. Synthesis support is a separate topic and is similar
whether it is an assertion or a built-in language feature.

For your code of the form:
If(E0 = '1') then
State_A <= E0_S;
Orif(E1 = '1') then
State_A <= E_S;
Orif(E2 = '1') then
State_A <= E2_S;

The assertion that would allow this code to be written with only elsif is:
assert zero_one_hot (E0, E1, E2) ;

I noted that in your code you mixed orif mixed with elsif (copied below),
was this intentional? One hand, these could convey exactly what I want
(because there are many cases like this), OTOH, it could be a mistake.
Hence the intent is ambiguous and during a design review, one would have
to pay particular attention to this and ask questions about your intent
and its validation. A copy of your code is below.

If(E0 = '1') then
State_A <= E0_S;
Orif(E1 = '1') then
State_A <= E_S;
Orif(E2 = '1') then
State_A <= E2_S;
elsIf(E3 = '1') then
State_A <= E3_S;
Orif(E4 = '1') then
State_A <= E4_S;
Orif(E5 = '1') then
State_A <= E5_S;
elsIf(E6 = '1') then

On the other hand, with assertions, the following assertions
allow the above code to be written using elsif. In addition,
in this case, it is very clear about which I want to be
mutually exclusive.
assert zero_one_hot (E0, E1, E2) ;
assert zero_one_hot (E3, E4, E5) ;

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;

You can also leave out the = '1' in VHDL-2006:
if E0 or E1 or E2 or E3 or E4 or E5 then

I also note that SystemVerilog added the keywords priority and
unique. The danger in adding new keywords is that they may
conflict with a name (signal, ...) already used in someone's design
and cause an old design to be a syntax error in the new language
revision. This generally does not please people and means they
have to add special handling for the file (compile flags).

What we need in the future revisions of the language is capability.
This does not necessarily mean adding new keywords.

> 7. Mutually exclusiveness is ubiquitout in logic design ...

I agree with this part. The language needs a capability to effectively
handle mutual exclusion.

The PSL extension brings us one_hot and zero_one_hot functions.
These functions are visible within a PSL assert statement (but not
a VHDL assert statement). As a result as long as you used a form
of assert that is compatible with PSL, you can do this with any
simulator or synthesis tool that supports Accellera VHDL-2006.
If the tool does not support it, you can file a bug and/or
enhancement against it to get the feature added.


If you wish to continue this discussion, please re-post (from 1 year
ago?) that show your more complex examples, identify the conditions
that you want to be mutually exclusive, and explain how you think
a tool should extract/determine those conditions.


Best,
Jim

 

[Weng Tianxiang]

Weng,

It seems to me that what you are trying to do is very similar
to SystemVerilog's "unique" and "priority" keywords. It is
not completely clear from your posts exactly what the semantics
of "orif" should be, but as I understand it you intend that
"orif" should have exactly the same behaviour as "elsif",
together with a mutual-exclusivity check so that it is an
error if more than one of the "if" conditions is true.
I agree that this is a desirable thing to be able to say.

I do not fully understand how your combinations of "orif"
and "elsif" are intended to work.

It is also desirable to be able to specify that *at least*
one of the conditions is true. And then you can combine
the "at-least-one" and "at-most-one" tests to guarantee
that there is EXACTLY one condition true. Note that
SystemVerilog got this wrong, in my opinion: "unique"
enforces exactly-one, and "priority" enforces at-least-one,
so there is no easy way to specify at-most-one.

It is easier in VHDL than Verilog, because the test
expressions cannot have side-effects.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
(e-mail address removed)://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

Hi Jonathan,
1. How 'elsif' and 'orif' work together?

See the following example:

If(E0 = '1') then
State_A <= E0_S;
Orif(E1 = '1') then
State_A <= E_S;
Orif(E2 = '1') then
State_A <= E2_S;

elsIf(E3 = '1') then
State_A <= E3_S;
Orif(E4 = '1') then
State_A <= E4_S;
Orif(E5 = '1') then
State_A <= E5_S;
elsIf(E6 = '1') then

'if', 'elsif' and 'else' play a role like brackets, putting together a
group of signals that are grouped with 'orif' between them to specify
mutually exclusiveness : there are two groups: (E0, E1, E2), (E3, E4,
E5) and signals in each group are mutually exclusive. Other grammar
meanings remain unchanged: It also means that if one of (E0, E1, E2)
is true, then 'if' statement is finished, otherwise try to test (E3,
E4, E5), like an usual 'if' statement.

The keyword 'orif' only adds the meaning that all signals in the group
are mutually exclusive, no more meaning is added. But it is enough for
compiler to do a smart job with the extra information.

For example, in the above example, two parallel carry chains can be
generated, then another LUT to put them together or more efficient LUT
allocations.

What I want is to transfer to a VHDL compiler the information that
there is mutually exclusive information about them and use them in
best interest of timing.

3. "It is also desirable to be able to specify that *at least*
one of the conditions is true. "

No such requirement is needed based on the fact that any 'if'
statement is complete: it means there is at least one hit, no more
than 2.
For example, the following example :
if(..) then
...
orif(...)
...
orif(...)
...
else
... <--- default hit
end if;

if(..) then
...
orif(...)
...
orif(...)
...
end if;

Above example is logically equivalent to the following one:
if(..) then
...
orif(...)
...
orif(...)
...
else
null; <--- default hit
end if;

It likes the following example with 'elsif'
if(..) then
...
elsif(...)
...
elsif(...)
...
else
null; <--- default hit
end if;

3. I am not fimiliar with Verilog, but from Marcus posting, I know
there is a definitive advantage of my method over Verilog's:
You have never to specify "at-least-one" and "at-most-one" tests. No.
'if' statement structure in sequential process has already null
statement as its default value as following examples show.

A2 : process(RESET, CLK)
begin
if(RESET = '1') then
State_A <= State_0_S;
elsif(CLK'event and CLK = '1') then
case State_A is
when State_0_S =>
if(A = '1') then
State_A <= State_1_S;
else
null;
end if;
...
...
end case;
end if;
end process;


A3 : process(RESET, CLK)
begin
if(RESET = '1') then
State_A <= State_0_S;
elsif(CLK'event and CLK = '1') then
case State_A is
when State_0_S =>
if(A = '1') then
State_A <= State_1_S;
end if;
...
...
end case;
end if;
end process;


Jonathan, I would like to address any concern you will rise.

Thank you.

Weng

 

[Jonathan Bromley]

(Restricting this to comp.arch.vhdl only)

1. How 'elsif' and 'orif' work together?

See the following example:

If(E0 = '1') then
State_A <= E0_S;
Orif(E1 = '1') then
State_A <= E_S;
Orif(E2 = '1') then
State_A <= E2_S;

elsIf(E3 = '1') then
State_A <= E3_S;
Orif(E4 = '1') then
State_A <= E4_S;
Orif(E5 = '1') then
State_A <= E5_S;
elsIf(E6 = '1') then

'if', 'elsif' and 'else' play a role like brackets, putting together a
group of signals that are grouped with 'orif' between them to specify
mutually exclusiveness : there are two groups: (E0, E1, E2), (E3, E4,
E5) and signals in each group are mutually exclusive. Other grammar
meanings remain unchanged: It also means that if one of (E0, E1, E2)
is true, then 'if' statement is finished, otherwise try to test (E3,
E4, E5), like an usual 'if' statement.

The keyword 'orif' only adds the meaning that all signals in the group
are mutually exclusive, no more meaning is added.

OK, so to try to put this a little more precisely:

'orif' has exactly the same execution semantics as 'elsif',
EXCEPT THAT
any group of branch tests, starting with if or elsif and
continuing through any number of orif with no intervening
elsif, are evaluated together and if more than one of those
tests evaluates to TRUE then it shall be an error.

Note that this mandates the evaluation of ALL tests in the
set before any decision is made, whereas regular VHDL
executes them one by one, only moving on to the next if
the current test is false.

Question: In the following example Tn are Boolean expressions,
and Sn are statement blocks.

if T1 S1
orif T2 S2
orif T3 S3 --- T1, T2, T3 are mutually exclusive
elsif T4 S4
orif T5 S5 --- T4, T5 are mutually exclusive
else S6

If (T1 OR T2 OR T3) is true, do we then also check T4/T5 for
mutual exclusivity? Both answers (yes, no) have potential
disadvantages.

There are some VERY tricky problems with language definition
if any of the Tn tests calls an impure function that may influence
the results of another Tn test - SystemVerilog has already had
trouble with that one.

I still don't understand how you intend to deal with the
practically-common "exactly one" requirement. A final else
doesn't do what I want, because it simply provides an execution
path when all the Tn are false; it does not provide me with a
check that exactly one of the Tn is true.

What I want is to transfer to a VHDL compiler the information that
there is mutually exclusive information about them and use them in
best interest of timing.

As I've already said, this is a worthy objective. Jim Lewis has
suggested it could be done with assertions. I suspect, though,
that a specialized language construct might be a more satisfactory
solution; the use of assertions means that a synthesis tool must
tie together two distinct language constructs, with a wide variety
of possible coding styles and the risk of very wide separation of
the two constructs (conditional and assertion). SystemVerilog
synthesis tools are gaining real practical benefit from the
"unique" and "priority" keywords today, but I know of no
synthesis tool that exploits explicit assertions to
improve its optimization.

3. I am not fimiliar with Verilog, but from Marcus posting, I know
there is a definitive advantage of my method over Verilog's:
You have never to specify "at-least-one" and "at-most-one" tests.

This is not a convincing point. SystemVerilog simply has two
new keywords that can be used as a prefix to 'if' or 'case'.
That is surely no worse than the need to remember a new
'orif' keyword. It's a difference of detail only, and at
present your approach is weaker because it has no way to
specify exactly-one or at-least-one among a set of tests.
(As Marcus and I have both said already, SystemVerilog
has probably got this slightly wrong - but it *does*
offer all the possibilities, which your 'orif' does not).

Keep provoking the community with good ideas - you're doing
a great job - but this one needs more work, I'm afraid.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
(e-mail address removed)
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
(e-mail address removed)
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[Andy]

I noted that in your code you mixed orif mixed with elsif (copied below),
was this intentional? One hand, these could convey exactly what I want
(because there are many cases like this), OTOH, it could be a mistake.
Hence the intent is ambiguous and during a design review, one would have
to pay particular attention to this and ask questions about your intent
and its validation. A copy of your code is below.

If(E0 = '1') then
State_A <= E0_S;
Orif(E1 = '1') then
State_A <= E_S;
Orif(E2 = '1') then
State_A <= E2_S;
elsIf(E3 = '1') then
State_A <= E3_S;
Orif(E4 = '1') then
State_A <= E4_S;
Orif(E5 = '1') then
State_A <= E5_S;
elsIf(E6 = '1') then

On the other hand, with assertions, the following assertions
allow the above code to be written using elsif. In addition,
in this case, it is very clear about which I want to be
mutually exclusive.
assert zero_one_hot (E0, E1, E2) ;
assert zero_one_hot (E3, E4, E5) ;

I would have (perhaps mistakenly?) interpreted the orif/elsif syntax
as:
also meaning:

assert zero_one_hot(E0, E1, E2, E4, E5);

My point (and Jim's) is that this is one very good reason why such a
seemingly simple language change is not a good idea when you look
under the hood.

Actually, would the correct syntax be:

assert zero_one_hot((e0, e1, e2, e4, e5)); -- one array argument

or does the psl zero_one_hot() function actually accept a variable
number of arguments?

I would really like to see one_hot() and zero_one_hot() as standard
vhdl (not just psl) functions, usable in an assert statement for this
purpose. The reason is that I don't see synthesis vendors using PSL at
any point in the future (there's just way too much there that would
never be relevant to synthesis). But they could easily parse simple
vhdl assertions with specific, standard functions to extract
meaningful information about the description.

As to the use of enumerated types, that works fine, as long as you
have access to the source of the signals, where you can re-create them
as an enumerated type. If they are primary (chip level) inputs, you do
not have a choice. And you cannot "translate" them into an enumerated
type, since the translation will incorporate priority logic of some
sort.

There are many cases where the tools could do a better job of
inferring mutual exclusivity:

enable := (others => '0');
for i in enable'range loop
if address = i then
enable(i) := '1';
end if;
end loop;

Most synthesis tools can figure out that enable is zero_one_hot.

Where the problem comes in is that if you want to use enable in the
next clock cycle (or later). After all, if you only needed to use it
immediately, you would dispense with the enable vector, and just put
the action that "enable" enables in the if-then statement directly.

But as soon as you want to store the enables for a clock cycle or
more, every synthesis tool I've seen fails to realize that enable is
still mutually exclusive. So far, the only solutions that I've seen
include manually coding an and-or tree (unreadable), coding it as tri-
state logic (and letting the tool convert to multiplexers; misleading,
and does not handle zero_hot), or coding it in the same clock cycle,
and using register retiming to spread it back out (not entirely
reliable, and not generally extensible past one clock cycle).


Andy

 

[Weng Tianxiang]

Weng,


My conclusion from our numerous previous discussions
on this topic are that for simple cases it looks
intuitive and makes the syntax look deceptively
attractive, however, for more interesting conditions,
it becomes difficult if not impossible to identify the
mutually exclusive items and, hence, you will get
little to no benefit from it. So I was tickled to see
that SystemVerilog decided to implement something similar
to this, however, I would suspect that they do not give
you quite the flexibility that you want.

On the other hand, as I mentioned previously and Andy
pointed out in the thread you quoted (repeated below):
"For dynamic mutex inputs, verification is best
handled in an assertion. If a standardized one_hot() or zero_one_hot()
function could be created (to operate on an unconstrained vector of
booleans, for example), then synthesis could recognize their use in an
assertion, and make the appropriate optimizations automatically,
without affecting the syntax or structure of the language. The
assertion (or other code) could also control what happens when, in
fact, the conditions are not mutually exclusive (the same way the
language handles indices out of bounds, etc.). In other words, in
order to gain that level of control over what happens if mutex is not
true, you'd have to use the same amount of code for either solution,
and the latter solution does not require a change to the language."

I also note that some synthesis tools have started to support assertions
in synthesis. Synthesis support is a separate topic and is similar
whether it is an assertion or a built-in language feature.

For your code of the form:
If(E0 = '1') then
State_A <= E0_S;
Orif(E1 = '1') then
State_A <= E_S;
Orif(E2 = '1') then
State_A <= E2_S;

The assertion that would allow this code to be written with only elsif is:
assert zero_one_hot (E0, E1, E2) ;

I noted that in your code you mixed orif mixed with elsif (copied below),
was this intentional? One hand, these could convey exactly what I want
(because there are many cases like this), OTOH, it could be a mistake.
Hence the intent is ambiguous and during a design review, one would have
to pay particular attention to this and ask questions about your intent
and its validation. A copy of your code is below.

If(E0 = '1') then
State_A <= E0_S;
Orif(E1 = '1') then
State_A <= E_S;
Orif(E2 = '1') then
State_A <= E2_S;
elsIf(E3 = '1') then
State_A <= E3_S;
Orif(E4 = '1') then
State_A <= E4_S;
Orif(E5 = '1') then
State_A <= E5_S;
elsIf(E6 = '1') then

On the other hand, with assertions, the following assertions
allow the above code to be written using elsif. In addition,
in this case, it is very clear about which I want to be
mutually exclusive.
assert zero_one_hot (E0, E1, E2) ;
assert zero_one_hot (E3, E4, E5) ;

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;

You can also leave out the = '1' in VHDL-2006:
if E0 or E1 or E2 or E3 or E4 or E5 then

I also note that SystemVerilog added the keywords priority and
unique. The danger in adding new keywords is that they may
conflict with a name (signal, ...) already used in someone's design
and cause an old design to be a syntax error in the new language
revision. This generally does not please people and means they
have to add special handling for the file (compile flags).

What we need in the future revisions of the language is capability.
This does not necessarily mean adding new keywords.

I agree with this part. The language needs a capability to effectively
handle mutual exclusion.

The PSL extension brings us one_hot and zero_one_hot functions.
These functions are visible within a PSL assert statement (but not
a VHDL assert statement). As a result as long as you used a form
of assert that is compatible with PSL, you can do this with any
simulator or synthesis tool that supports Accellera VHDL-2006.
If the tool does not support it, you can file a bug and/or
enhancement against it to get the feature added.

If you wish to continue this discussion, please re-post (from 1 year
ago?) that show your more complex examples, identify the conditions
that you want to be mutually exclusive, and explain how you think
a tool should extract/determine those conditions.

Best,
Jim

Hi Jim,
"I agree with this part. The language needs a capability to
effectively
handle mutual exclusion."

1. This is a step forward from my point of view.

2. We have to admit that there are many ways to do it.

3. My example is right and intend to do that. See my answer to
Jonathan Bromley.

4. Keyword 'orif' can be inserted in any places in a 'if' statement to
specify any group of conditions having mutually exclusiveness.

5. Your method using
assert zero_one_hot (E0, E1, E2) ;
assert zero_one_hot (E3, E4, E5) ;
is OK.

Here is an example that shows your method's drawback you have to
admit:
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;

You have to write 5 more statements than mine:

signal A1 : boolean;
signal A2 : boolean;
assert zero_one_hot (A1, A2) ;

A1 <= TWindowLoad_E0_L_H and nC_BE_R0(3) = '0';
A2 <= TWindowLoad_E0_H_H and nC_BE_R0(7) = '0';

if(A1) then
TWindow_3(10 downto 8) <= AD_R0(26 downto 24);

elsif(A2) then
TWindow_3(10 downto 8) <= AD_R0(58 downto 56);
end if;

The more signals are invovled, the more statements are added, and more
likely it is possible to be wrong or missing something.

6. The keyword 'orif' is defined to refer to carry chain structure in
FPGA to get essential timing advantages over other competing methods.

if(E0 = '1') then
OutBus(63 downto 0) <= Data0(63 downto 0);
orif(E1 = '1') then
OutBus(63 downto 0) <= Data1(63 downto 0);
orif(E2 = '1') then
OutBus(63 downto 0) <= Data2(63 downto 0);
end if;

Its implementation equation should look like this:
OutBus = E0*Data0 + E1*Data1 + E2*Data2 + OutBus;

Because 'else' and its null statement are defaulted.

Its carry chain bottom initial input data should be OutBus(i).

if(E0 = '1') then
OutBus(63 downto 0) <= Data0(63 downto 0);
orif(E1 = '1') then
OutBus(63 downto 0) <= Data1(63 downto 0);
orif(E2 = '1') then
OutBus(63 downto 0) <= Data2(63 downto 0);
else
OutBus(63 downto 0) <= Zero_64;
end if;

It is logically defined as the following:
if(E0 = '1' or E1 = '1' or E2 = '1') then
if(E0 = '1') then
OutBus(63 downto 0) <= Data0(63 downto 0);
orif(E1 = '1') then
OutBus(63 downto 0) <= Data1(63 downto 0);
orif(E2 = '1') then
OutBus(63 downto 0) <= Data2(63 downto 0);
end if;
else
OutBus(63 downto 0) <= Zero_64;
end if;

Its implementation equation should look like this:
OutBus = E0*Data0 + E1*Data1 + E2*Data2;

Its carry chain bottom initial input data should be '0'.

How efficient it is to refer to carry chain in FPGA.

Weng

 

[Jim Lewis]

Andy,

I would have (perhaps mistakenly?) interpreted the orif/elsif syntax
as:
also meaning:

assert zero_one_hot(E0, E1, E2, E4, E5);

My point (and Jim's) is that this is one very good reason why such a
seemingly simple language change is not a good idea when you look
under the hood.

Sadly he did clarify his intent in a further post and he did
mean to split the priority as I showed. I had an unfair advantage
as I have reviewed this with him in the past.

Actually, would the correct syntax be:

assert zero_one_hot((e0, e1, e2, e4, e5)); -- one array argument

or does the psl zero_one_hot() function actually accept a variable
number of arguments?

I would really like to see one_hot() and zero_one_hot() as standard
vhdl (not just psl) functions, usable in an assert statement for this
purpose. The reason is that I don't see synthesis vendors using PSL at
any point in the future (there's just way too much there that would
never be relevant to synthesis). But they could easily parse simple
vhdl assertions with specific, standard functions to extract
meaningful information about the description.

Probably a good idea. Technically speaking, PSL is part of VHDL and
synthesis tools tend to pick and choose what they implement, so they
could just implement this construct.

Cheers,
Jim

 

[Weng Tianxiang]

Weng,

I was almost starting to agree with you, until you said this...


This is the purest madness. If you want a language structure
that specifies a particular implementation, you have it already:
it's called a "primitive instance". I agree that a conditional
that is mutually-exclusive by design can readily be mapped to
specific hardware such as MUXCY or a tree of ORs, but the
precise mapping is NOT something we want in the language,
thanks very much. Tools must have the freedom to optimize
as they think best, and must compete (and succeed or fail)
on how effectively they do it.

Language constructs that have built-in assertions for
things that are otherwise hard to describe, such as
mutual exclusivity, are something that is well worth
exploring. Especially now that we have the partially-
successful SystemVerilog example to study, it should be
possible to come up with some interesting ideas. But
please don't blast a hole in your own argument by
demanding that the language construct should have a
one-to-one mapping to some specific piece of technology.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
(e-mail address removed)://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

Hi Jonathan,
All statement structures in VHDL are to refer to a hardware
structures.

A sequential process is to refer to registers.

If a combinational process doesn't get proper assignment, it would
refer to a latch.

A combinational signal in concurrent area refers to a combinational
signal.

Why can we refer a special language structure to a carry chain in FPGA
while it also gives a means to deal with real situation?

"Tools must have the freedom to optimize
as they think best, and must compete (and succeed or fail)
on how effectively they do it. "

In FPGA, it gets best timing with carry chain structure, why don't we
do it? Keyword 'orif' doesn't mean you cannot use other MUX/CASE
method to do it. But referring to a carry chain is the best way to do
things.

There are 4 considerations:
1. Easy to write;
2. Be concise in doing it;
3. Have wider range of usage;
4. Performance benefit.

Maybe 'mandated' word offends you. It should be changed to other
word.

Weng

 

[Mike Treseler]

enable := (others => '0');
for i in enable'range loop
if address = i then
enable(i) := '1';
end if;
end loop;

Most synthesis tools can figure out that enable is zero_one_hot.

Where the problem comes in is that if you want to use enable in the
next clock cycle (or later). After all, if you only needed to use it
immediately, you would dispense with the enable vector, and just put
the action that "enable" enables in the if-then statement directly.

But as soon as you want to store the enables for a clock cycle or
more, every synthesis tool I've seen fails to realize that enable is
still mutually exclusive.

I'll bite.
Why not describe the decode to match the way we encoded it?
Start on one end and break on the first active bit.

-- Mike Treseler

 

[Andy]

Intermediate signals/variables can be avoided by just simply using the
expressions in the call to zero_one_hot(); that's a non-issue.

There are many more uses of mutual exclusivity than carry chains, and
if mutual exclusivity's only specification is with "orif", some other
uses are more difficult to functionally describe. Consider a circuit
where, if accesses to an array are mutually exclusive, the array can
be implemented as a RAM, with a multiplexer on the input. Sure you
could code it that way, but I find it often easier to debug
descriptions that are functionally more concise, and let the tool
figure out the best implementation, with help (that does not detract
from the functionality by forcing it to be re-written) from assertions
if necessary.

A similar occurrence is when trying to determine if expensive
resources can be shared. Coding it such that mutual exclusivity is
explicit (with or without "orif") is often less functionally clear to
the reader, and therefore more likely to harbor functional errors.

Andy

 

[Colin Paul Gloster]

Jim,


|--------------------------------------------------------------------------|
|"Weng, |
|[..] |
| |
|[..] |
| |
|I noted that in your code you mixed orif mixed with elsif (copied below), |
|was this intentional? One hand, these could convey exactly what I want |
|(because there are many cases like this), OTOH, it could be a mistake. |
|Hence the intent is ambiguous and during a design review, one would have |
|to pay particular attention to this and ask questions about your intent |
|and its validation. A copy of your code is below. |
| |
|If(E0 = '1') then |
|State_A <= E0_S; |
|Orif(E1 = '1') then |
|State_A <= E_S; |
|Orif(E2 = '1') then |
|State_A <= E2_S; |
|elsIf(E3 = '1') then |
|State_A <= E3_S; |
|Orif(E4 = '1') then |
|State_A <= E4_S; |
|Orif(E5 = '1') then |
|State_A <= E5_S; |
|elsIf(E6 = '1') then |
|" |
|--------------------------------------------------------------------------|

Yes,

Weng really did intend to have both orif branches and elsif branches
in a single if statement (see
). I think the intention would be clearer with different
indentation. E.g.
If(E0 = '1') then
State_A <= E0_S;
Orif(E1 = '1') then
State_A <= E_S;
Orif(E2 = '1') then
State_A <= E2_S;

elsIf(E3 = '1') then
State_A <= E3_S;
Orif(E4 = '1') then
State_A <= E4_S;
Orif(E5 = '1') then
State_A <= E5_S;
elsIf(E6 = '1') then
--...

|--------------------------------------------------------------------------|
|"[..] |
| |
|[..] The danger in adding new keywords is that they may |
|conflict with a name (signal, ...) already used in someone's design |
|and cause an old design to be a syntax error in the new language |
|revision. This generally does not please people and means they |
|have to add special handling for the file (compile flags). |
| |
|[..]" |
|--------------------------------------------------------------------------|

A newly introduced reserved word would be guaranteed to not conflict
with old code by not being possible to misinterpret as a basic
identifier (basic_identifier ::= letter { [ underline ]
letter_or_digit), e.g. by starting with an underline or by containing
a percentage sign.

Best regards,
Colin Paul

 

[comp.arch.fpga]

Folks,

the functionality you are talking about is available in VHDL 2006 via
the use of PSL in assertions.

Essentially it is not about describing a function, but about
restricting the domain of that function.
This should not be mixed with the specification of the functions
behaviour, especially if you take
formal verification into account.

Kolja Sulimma

 

[Weng Tianxiang]

Jim,


|--------------------------------------------------------------------------­|
|"Weng, |
|[..] |
| |
|[..] |
| |
|I noted that in your code you mixed orif mixed with elsif (copied below), |
|was this intentional? One hand, these could convey exactly what I want |
|(because there are many cases like this), OTOH, it could be a mistake. |
|Hence the intent is ambiguous and during a design review, one would have |
|to pay particular attention to this and ask questions about your intent |
|and its validation. A copy of your code is below. |
| |
|If(E0 = '1') then |
|State_A <= E0_S; |
|Orif(E1 = '1') then |
|State_A <= E_S; |
|Orif(E2 = '1') then |
|State_A <= E2_S; |
|elsIf(E3 = '1') then |
|State_A <= E3_S; |
|Orif(E4 = '1') then |
|State_A <= E4_S; |
|Orif(E5 = '1') then |
|State_A <= E5_S; |
|elsIf(E6 = '1') then |
|" |
|--------------------------------------------------------------------------­|

Yes,

Weng really did intend to have both orif branches and elsif branches
in a single if statement (see). I think the intention would be clearer with different
indentation. E.g.
If(E0 = '1') then
State_A <= E0_S;
Orif(E1 = '1') then
State_A <= E_S;
Orif(E2 = '1') then
State_A <= E2_S;

elsIf(E3 = '1') then
State_A <= E3_S;
Orif(E4 = '1') then
State_A <= E4_S;
Orif(E5 = '1') then
State_A <= E5_S;
elsIf(E6 = '1') then
--...

|--------------------------------------------------------------------------­|
|"[..] |
| |
|[..] The danger in adding new keywords is that they may |
|conflict with a name (signal, ...) already used in someone's design |
|and cause an old design to be a syntax error in the new language |
|revision. This generally does not please people and means they |
|have to add special handling for the file (compile flags). |
| |
|[..]" |
|--------------------------------------------------------------------------­|

A newly introduced reserved word would be guaranteed to not conflict
with old code by not being possible to misinterpret as a basic
identifier (basic_identifier ::= letter { [ underline ]
letter_or_digit), e.g. by starting with an underline or by containing
a percentage sign.

Best regards,
Colin Paul

Hi Colin,
Thank you for your support.

You are the first big canon who gave full support behind the keyword
'orif' and gets full understanding of its meaning.

My fighting for 'orif' recognition is not for my personal purpose, it
is in the interest of HDL industry and academic world.

You help clear up 3 things:
1. Indent two separate mutually exclusive groups to avoid confusion.
I have never thought about it.

2. "Weng really did intend to have both orif branches and elsif
branches
in a single if statement "

I have really done it in 'orif' definition:
"Where keyword 'elsif' can be used in a VHDL code, there keyword
'orif' can be used.", but failed to mention that directly. It seems to
me that it is a reality and may never be mentioned specifically.

I thought that "if...elsif..." statement structure was created by IBM
in 1953 when designing Fortran language to meet software requirements:
sequential comparison, one after another.

In hardware world, HDL language must have a similar mainstream
language structure to meet the 0-1 out of N selections in parallel.
That was where keyword 'orif' came from.

In my experiences, 'orif' is much easier than zero_one_hot() to use in
practise in the same way as engineers rarely use single signal names
to replace equations in if() or elsif().

3. "A newly introduced reserved word would be guaranteed to not
conflict
with old code"

Jim's opinion is that if you introduce a new keyword 'orif', then even
though 'orif' doesn't conflict with 'elsif', but it certainly would
conflict with old signal name orif. This can never be avoided. 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.

I would like to add more information.
1. 'case' statement is a special case with keyword 'orif', in other
words, all 'case' statement can be written using keyword 'if...orif'
structure.

Example:

case two_bits is
when "00" =>
...
when "01" =>
...
when "10" =>
...
when others =>
...
end case;

if(two_bits = "00") then
...
orif(two_bits = "01") then
...
orif(two_bits = "10") then
...
else <-- equivalent to "when others =>"
...
end if;

2. Andy mentioned that he may be able to find something that is beyond
the capability of 'orif', but within capability of zero_one_hot().

Andy, you never have a chance to do so with signals.
Reason: you have to implement an assign statement to reflect their
mutually exclusive property, then you must use one of two conditional
branch statements: case statement or if statement that are within
'orif' range.

Mutually exclusiveness is not used for combinational signals.

I don't have any idea if mutually exclusive property applies to
variables.

3. As keyword 'orif' definition says, 'orif' only provides information
about mutually exclusive property among a group of conditions.
Compilers can do what they think is the best strategy as they want.
But for FPGA, the 'orif' perfectly refers to carry chain structure in
both Xilinx and Altera (I am not familiar with other FPGA products),
it is a wonderful thing, but should not be a burden or a blame, as
Jonathan indicated.

Weng

 

[Mike Treseler]

What is it about enumerated types in VHDL that you find so hard?

I agree with KJ.
Enumerated types and values cover
designs with mutual exclusion very well
and are easy to read and to testbench.

Synthesis does a good job of encoding and
decoding enumerated values.

How hard should I work and what
risks should I take to save a LUT
by enforcing and verifying my own encoding?

-- Mike Treseler

 

[Andy]

Jim,

On 2007-08-28, Jim Lewis <[email protected]> wrote:

|--------------------------------------------------------------------------­|
|"Weng, |
|[..] |
| |
|[..] |
| |
|I noted that in your code you mixed orif mixed with elsif (copied below), |
|was this intentional? One hand, these could convey exactly what I want |
|(because there are many cases like this), OTOH, it could be a mistake. |
|Hence the intent is ambiguous and during a design review, one would have |
|to pay particular attention to this and ask questions about your intent |
|and its validation. A copy of your code is below. |
| |
|If(E0 = '1') then |
|State_A <= E0_S; |
|Orif(E1 = '1') then |
|State_A <= E_S; |
|Orif(E2 = '1') then |
|State_A <= E2_S; |
|elsIf(E3 = '1') then |
|State_A <= E3_S; |
|Orif(E4 = '1') then |
|State_A <= E4_S; |
|Orif(E5 = '1') then |
|State_A <= E5_S; |
|elsIf(E6 = '1') then |
|" |
|--------------------------------------------------------------------------­|

Yes,

Weng really did intend to have both orif branches and elsif branches
in a single if statement (see). I think the intention would be clearer with different
indentation. E.g.
If(E0 = '1') then
State_A <= E0_S;
Orif(E1 = '1') then
State_A <= E_S;
Orif(E2 = '1') then
State_A <= E2_S;

elsIf(E3 = '1') then
State_A <= E3_S;
Orif(E4 = '1') then
State_A <= E4_S;
Orif(E5 = '1') then
State_A <= E5_S;
elsIf(E6 = '1') then
--...

|--------------------------------------------------------------------------­|
|"[..] |
| |
|[..] The danger in adding new keywords is that they may |
|conflict with a name (signal, ...) already used in someone's design |
|and cause an old design to be a syntax error in the new language |
|revision. This generally does not please people and means they |
|have to add special handling for the file (compile flags). |
| |
|[..]" |
|--------------------------------------------------------------------------­|

A newly introduced reserved word would be guaranteed to not conflict
with old code by not being possible to misinterpret as a basic
identifier (basic_identifier ::= letter { [ underline ]
letter_or_digit), e.g. by starting with an underline or by containing
a percentage sign.

Best regards,
Colin Paul

Hi Colin,
Thank you for your support.

You are the first big canon who gave full support behind the keyword
'orif' and gets full understanding of its meaning.

My fighting for 'orif' recognition is not for my personal purpose, it
is in the interest of HDL industry and academic world.

You help clear up 3 things:
1. Indent two separate mutually exclusive groups to avoid confusion.
I have never thought about it.

2. "Weng really did intend to have both orif branches and elsif
branches
in a single if statement "

I have really done it in 'orif' definition:
"Where keyword 'elsif' can be used in a VHDL code, there keyword
'orif' can be used.", but failed to mention that directly. It seems to
me that it is a reality and may never be mentioned specifically.

I thought that "if...elsif..." statement structure was created by IBM
in 1953 when designing Fortran language to meet software requirements:
sequential comparison, one after another.

In hardware world, HDL language must have a similar mainstream
language structure to meet the 0-1 out of N selections in parallel.
That was where keyword 'orif' came from.

In my experiences, 'orif' is much easier than zero_one_hot() to use in
practise in the same way as engineers rarely use single signal names
to replace equations in if() or elsif().

3. "A newly introduced reserved word would be guaranteed to not
conflict
with old code"

Jim's opinion is that if you introduce a new keyword 'orif', then even
though 'orif' doesn't conflict with 'elsif', but it certainly would
conflict with old signal name orif. This can never be avoided. 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.

I would like to add more information.
1. 'case' statement is a special case with keyword 'orif', in other
words, all 'case' statement can be written using keyword 'if...orif'
structure.

Example:

case two_bits is
when "00" =>
...
when "01" =>
...
when "10" =>
...
when others =>
...
end case;

if(two_bits = "00") then
...
orif(two_bits = "01") then
...
orif(two_bits = "10") then
...
else <-- equivalent to "when others =>"
...
end if;

2. Andy mentioned that he may be able to find something that is beyond
the capability of 'orif', but within capability of zero_one_hot().

Andy, you never have a chance to do so with signals.
Reason: you have to implement an assign statement to reflect their
mutually exclusive property, then you must use one of two conditional
branch statements: case statement or if statement that are within
'orif' range.

Mutually exclusiveness is not used for combinational signals.

I don't have any idea if mutually exclusive property applies to
variables.

3. As keyword 'orif' definition says, 'orif' only provides information
about mutually exclusive property among a group of conditions.
Compilers can do what they think is the best strategy as they want.
But for FPGA, the 'orif' perfectly refers to carry chain structure in
both Xilinx and Altera (I am not familiar with other FPGA products),
it is a wonderful thing, but should not be a burden or a blame, as
Jonathan indicated.

Weng

Weng,

The fact that orif must be indented from elsif, is a very poor way to
indicate functional structure of code. That should be the first key
that orif is a very weak bandaid on a problem that has much better
solutions that have repeatedly been suggested for a variety of
reasons.

Even your explanation of the indentation ("Indent two separate
mutually exclusive groups to avoid confusion") remains ambiguous: are
the groups mutually exclusive, or are the members of each group
mutually exclusive only amongst those group members, or both?
Indentation may look prettier (and help avoid missing an "elsif"), but
it adds nothing to the clarity of purpose.

"In my experiences, 'orif' is much easier than zero_one_hot() to use
in practise in the same way as engineers rarely use single signal
names to replace equations in if() or elsif()."

I've already told you that you do not need to use single signal names
with zero_one_hot() arguments anymore than you have to use them with
if/elsif/orif conditions; expressions can be used in both instances.
Nor are you limited to using expressions in either place; you can
assign a signal or variable, which will often be more readable in both
instances anyway. What "engineers rarely [or commonly] use" is not the
definition of good coding practice.

zero_one_hot() can always be prefixed with the standard package name
in which it is defined. Keywords, on the other hand cannot. I believe
that tricks like '_' and '%' on the front of new keywords are a
hideous hack, nevertheless befitting this whole orif concept.

Any synthesis tool that cannot figure out the code below (rewritten
from your example, but in standard vhdl with elsif) indicates mutually
exclusive conditions should be immediately uninstalled and returned to
the vendor for a full refund!

if(two_bits = "00") then
...
elsif(two_bits = "01") then
...
elsif(two_bits = "10") then
...
else <-- equivalent to "when others =>"
...
end if;

As for mutual exclusivity of combinatorial signals or variables, why
do you think mutual exclusivity should be limited to registers only?
Even in your own code examples you have demonstrated mutual
exclusivity of intermediate expressions, which are not registers.

I don't understand your reference to having "to implement an assign
statement to reflect their mutually exclusive property, then you must
use one of two conditional branch statements: case statement or if
statement that are within 'orif' range.

You are completely missing the point about using an assertion: the
assertion is completely independent of the functional code. It merely
provides additional information to a tool that may or may not use it,
but most importantly, it does not restrict you to a specific
functional coding method in order to provide that information.

Your statement: "3. As keyword 'orif' definition says, 'orif' only
provides information about mutually exclusive property among a group
of conditions. " is incorrect: it also provides the functional part,
and cannot be separated from it.

For example, how would you use orif in a loop to do the following (the
loop is necessary because the range of enable is arbitrary):

data <= (others => '0');
if read = '1' then
for i in enable'range loop
if enable(i) = '1' then
data <= input(i);
exit;
end if;
end loop;
assert zero_one_hot(enable);
end if;

The answer is: you couldn't! The use of the assertion, since it is
independent of the functional code, places no limitations on how you
code the functional part.

OTOH, you can choose to combine it with the functional code to easily
represent conditional mutual exclusivity (i.e. only if read = '1'), as
shown above.

OTOOH, if enable was always mutex, it could be indicated once with an
assertion, and any logic that uses it anywhere else could be optimized
because of the additional information.

Andy

 

[Weng Tianxiang]

On Aug 29, 3:13 am, Colin Paul Gloster <[email protected]>
wrote:

Jim,
|--------------------------------------------------------------------------­­|
|"Weng, |
|[..] |
| |
|[..] |
| |
|I noted that in your code you mixed orif mixed with elsif (copied below), |
|was this intentional? One hand, these could convey exactly what I want |
|(because there are many cases like this), OTOH, it could be a mistake. |
|Hence the intent is ambiguous and during a design review, one would have |
|to pay particular attention to this and ask questions about your intent |
|and its validation. A copy of your code is below. |
| |
|If(E0 = '1') then |
|State_A <= E0_S; |
|Orif(E1 = '1') then |
|State_A <= E_S; |
|Orif(E2 = '1') then |
|State_A <= E2_S; |
|elsIf(E3 = '1') then |
|State_A <= E3_S; |
|Orif(E4 = '1') then |
|State_A <= E4_S; |
|Orif(E5 = '1') then |
|State_A <= E5_S; |
|elsIf(E6 = '1') then |
|" |
|--------------------------------------------------------------------------­­|
Yes,
Weng really did intend to have both orif branches and elsif branches
in a single if statement (see). I think the intention would be clearer with different
indentation. E.g.
If(E0 = '1') then
State_A <= E0_S;
Orif(E1 = '1') then
State_A <= E_S;
Orif(E2 = '1') then
State_A <= E2_S;
elsIf(E3 = '1') then
State_A <= E3_S;
Orif(E4 = '1') then
State_A <= E4_S;
Orif(E5 = '1') then
State_A <= E5_S;
elsIf(E6 = '1') then
--...
|--------------------------------------------------------------------------­­|
|"[..] |
| |
|[..] The danger in adding new keywords is that they may |
|conflict with a name (signal, ...) already used in someone's design |
|and cause an old design to be a syntax error in the new language |
|revision. This generally does not please people and means they |
|have to add special handling for the file (compile flags). |
| |
|[..]" |
|--------------------------------------------------------------------------­­|
A newly introduced reserved word would be guaranteed to not conflict
with old code by not being possible to misinterpret as a basic
identifier (basic_identifier ::= letter { [ underline ]
letter_or_digit), e.g. by starting with an underline or by containing
a percentage sign.
Best regards,
Colin Paul

Hi Colin,
Thank you for your support.

You are the first big canon who gave full support behind the keyword
'orif' and gets full understanding of its meaning.

My fighting for 'orif' recognition is not for my personal purpose, it
is in the interest of HDL industry and academic world.

You help clear up 3 things:
1. Indent two separate mutually exclusive groups to avoid confusion.
I have never thought about it.

2. "Weng really did intend to have both orif branches and elsif
branches
in a single if statement "

I have really done it in 'orif' definition:
"Where keyword 'elsif' can be used in a VHDL code, there keyword
'orif' can be used.", but failed to mention that directly. It seems to
me that it is a reality and may never be mentioned specifically.

I thought that "if...elsif..." statement structure was created by IBM
in 1953 when designing Fortran language to meet software requirements:
sequential comparison, one after another.

In hardware world, HDL language must have a similar mainstream
language structure to meet the 0-1 out of N selections in parallel.
That was where keyword 'orif' came from.

In my experiences, 'orif' is much easier than zero_one_hot() to use in
practise in the same way as engineers rarely use single signal names
to replace equations in if() or elsif().

3. "A newly introduced reserved word would be guaranteed to not
conflict
with old code"

Jim's opinion is that if you introduce a new keyword 'orif', then even
though 'orif' doesn't conflict with 'elsif', but it certainly would
conflict with old signal name orif. This can never be avoided. 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.

I would like to add more information.
1. 'case' statement is a special case with keyword 'orif', in other
words, all 'case' statement can be written using keyword 'if...orif'
structure.

case two_bits is
when "00" =>
...
when "01" =>
...
when "10" =>
...
when others =>
...
end case;

if(two_bits = "00") then
...
orif(two_bits = "01") then
...
orif(two_bits = "10") then
...
else <-- equivalent to "when others =>"
...
end if;

2. Andy mentioned that he may be able to find something that is beyond
the capability of 'orif', but within capability of zero_one_hot().

Andy, you never have a chance to do so with signals.
Reason: you have to implement an assign statement to reflect their
mutually exclusive property, then you must use one of two conditional
branch statements: case statement or if statement that are within
'orif' range.

Mutually exclusiveness is not used for combinational signals.

I don't have any idea if mutually exclusive property applies to
variables.

3. As keyword 'orif' definition says, 'orif' only provides information
about mutually exclusive property among a group of conditions.
Compilers can do what they think is the best strategy as they want.
But for FPGA, the 'orif' perfectly refers to carry chain structure in
both Xilinx and Altera (I am not familiar with other FPGA products),
it is a wonderful thing, but should not be a burden or a blame, as
Jonathan indicated.

Weng

Weng,

The fact that orif must be indented from elsif, is a very poor way to
indicate functional structure of code. That should be the first key
that orif is a very weak bandaid on a problem that has much better
solutions that have repeatedly been suggested for a variety of
reasons.

Even your explanation of the indentation ("Indent two separate
mutually exclusive groups to avoid confusion") remains ambiguous: are
the groups mutually exclusive, or are the members of each group
mutually exclusive only amongst those group members, or both?
Indentation may look prettier (and help avoid missing an "elsif"), but
it adds nothing to the clarity of purpose.

"In my experiences, 'orif' is much easier than zero_one_hot() to use
in practise in the same way as engineers rarely use single signal
names to replace equations in if() or elsif()."

I've already told you that you do not need to use single signal names
with zero_one_hot() arguments anymore than you have to use them with
if/elsif/orif conditions; expressions can be used in both instances.
Nor are you limited to using expressions in either place; you can
assign a signal or variable, which will often be more readable in both
instances anyway. What "engineers rarely [or commonly] use" is not the
definition of good coding practice.

zero_one_hot() can always be prefixed with the standard package name
in which it is defined. Keywords, on the other hand cannot. I believe
that tricks like '_' and '%' on the front of new keywords are a
hideous hack, nevertheless befitting this whole orif concept.

Any synthesis tool that cannot figure out the code below (rewritten
from your example, but in standard vhdl with elsif) indicates mutually
exclusive conditions should be immediately uninstalled and returned to
the vendor for a full refund!

if(two_bits = "00") then
...
elsif(two_bits = "01") then
...
elsif(two_bits = "10") then
...
else <-- equivalent to "when others =>"
...
end if;

As for mutual exclusivity of combinatorial signals or variables, why
do you think mutual exclusivity should be limited to registers only?
Even in your own code examples you have demonstrated mutual
exclusivity of intermediate ...

read more »- Hide quoted text -

- Show quoted text -

Hi Andy and Jim,
I like to discuss the issue further with you.

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.

Keyword 'orif' has the same language grammar definition as keyword
'elsif' with one exception: conditional signal contained in leading
keywords 'if()' or 'elsif()' and conditional signals contained in the
subsequent and contiguous keyword 'orif()' at the same level in an
'if...elsif...end if' statement are mutually exclusive. Where keyword
'elsif' can be used in a VHDL code, there keyword 'orif' can be used.
'orif' and 'elsif' can be mixed at any levels of 'if...elsif...end if'
statements.

Here is a better example to show how powerful 'orif' is.

If(E0 = '1') then
If(E01 = '1') then
State_A <= E01_S;
orif(E02 = '1') then
State_A <= E02_S;
orif(E03 = '1') then
State_A <= E03_S;

elsIf(E04 = '1') then
State_A <= E04_S;
end if;
Orif(E1 = '1') then
State_A <= E1_S;
Orif(E2 = '1') then
State_A <= E2_S;

elsIf(E3 = '1') then
State_A <= E3_S;
Orif(E4 = '1') then
If(E41 = '1') then
State_A <= E41_S;
elsif(E42 = '1') then
State_A <= E42_S;
orif(E43 = '1') then
State_A <= E43_S;
orIf(E44 = '1') then
State_A <= E44_S;
end if;

Orif(E5 = '1') then
State_A <= E5_S;

elsIf(E6 = '1') then
...
else
...
end if;

Mutually exclusive groups: (E0, E1, E2), (E3, E4, E5), (E01, E02,
E03), (E42, E43, E44).

I would like to add a blank line to separate two groups in order not
to make a confusion with viewers of this post. Personnally I don't
think the blank line is needed if you are used to it.

I would like to tell you my experiences: when you are writing mutually
exclusive conditions, you don't know in advance that those group of
conditional signals that are mutually exclusive are written correctly,
and takes a long way to make them correct. You have to fine turn to
make them mutually exclusive finally.
The process is a slow learning one and you cannot write it immediately
without error. When zero_one_hot() method is used, you have two
choices: write them separately in its defnition area and its calling
area from start, or write them like writing a conventional
'if...eslif...end if' statement, then copy them and call them to
become 2 separate code after you are certain that they are right. I
know you have the experiences to write any 'if...eslif...end if'
statements. First of all, I don't believe you would like to write
'if...eslif...end if' statement in 2 separate parts, one for its
definition and assign statements, another is called in
'if...eslif...end if' statement. Then you can imagine same things and
more difficult things happening with the same situations as writing
'if...eslif...end if' statement.

I can imagine if both methods, Jim's and mine, are introduced into
VHDL standard, I can bet with you: 99.9999% of engineers who use
mutually exclusive method to speed up their designs would use my
method. My basis is nobody who write 'if...eslif...end if' statements
today uses 2 separate parts as Jim suggested for zero_one_hot() to
write 'if...eslif...end if' statements.

I have to point out the following code has error:

if(E0 = '1') then
OutBus(63 downto 0) <= Data0(63 downto 0);
orif(E1 = '1') then
OutBus(63 downto 0) <= Data1(63 downto 0);
orif(E2 = '1') then
OutBus(63 downto 0) <= Data2(63 downto 0);
end if;

Its implementation equation should look like this:
OutBus = E0*Data0 + E1*Data1 + E2*Data2 + OutBus;


The correct equation should look like this:
OutBus = E0*Data0 + E1*Data1 + E2*Data2 + (not (E0+E1+E2))*OutBus;


Here is Jim's equation that is wrong !
If(E0 = '1') then
State_A <= E0_S;
Orif(E1 = '1') then
State_A <= E_S;
Orif(E2 = '1') then
State_A <= E2_S;
elsIf(E3 = '1') then
State_A <= E3_S;
Orif(E4 = '1') then
State_A <= E4_S;
Orif(E5 = '1') then
State_A <= E5_S;
elsIf(E6 = '1') then

On the other hand, with assertions, the following assertions
allow the above code to be written using elsif. In addition,
in this case, it is very clear about which I want to be
mutually exclusive.
assert zero_one_hot (E0, E1, E2) ;
assert zero_one_hot (E3, E4, E5) ;


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.

Weng