New keyword 'orif' and its implications

[Colin Paul Gloster]

|---------------------------------------------------------------------------------------------|
|> |
|> |
|> |
|> |
|> |
|> > On Aug 29, 3:13 am, Colin Paul Gloster <[email protected]> |
|> > wrote: |
|> |
|[..] |
|[..] |
|> |
|> > > [..] I think the intention would be clearer with different |
|> > > indentation. [..] |
|[..] |
|> > 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. |
|---------------------------------------------------------------------------------------------|

Hello Weng,

I neither provided support for nor opposed your proposal, I simply
tried to clarify for Jim whether the appearances of elsif were typos.

I am indifferent.

However, you clearly have not understood any of the responses so far
in this thread. At least three alternatives not needing a new language
were shown to you:
a synthesis tool worth using should be able to determine how to
efficiently implement a design;
a case statement;
and
one-hot encoding or something similar using PSL instead of an
attribute.

The PSL approach is the only one you have tried to respond to. If you
can not prove that what you want to achieve can not be achieved
well otherwise, then you will find it difficult to convince people who
do not want too many ways to achieve one thing.

Your lack of appreciation for how the case statement is relevant and
other things you have revealed to us indicate that your depth of
understanding of VHDL needs to improve and this is also not helping
people to take you seriously. Please read at least two good books with
decent VHDL content, e.g. at least one of those listed on
WWW.Ashenden.com.Au
, and read the books you choose twice each.

|---------------------------------------------------------------------------------------------|
|"> > My fighting for 'orif' recognition is not for my personal purpose, it |
|> > is in the interest of HDL industry and academic world." |
|[..] |
|> > 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. |
|---------------------------------------------------------------------------------------------|

I appreciate that you are genuinely being noble, but please understand
that you should not insist that orif must be implemented as a carry
chain. The designer writes in a HDL and the optimizer in the synthesis
tool finds an efficient way to implement something. Something from a
HDL might not always be represented the same way, depending on many
issues too complicated to explain here. Please understand this example
from Andy:
|---------------------------------------------------------------------------------------------|
|"> 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;" |
|---------------------------------------------------------------------------------------------|

No matter how you improve your proposal for orif, you can not refute
this point of Andy's.

Weng posted:

|---------------------------------------------------------------------------------------------|
|[..] |
|> |
|> > > |--------------------------------------------------------------------------­­| |
|> > > |"[..] | |
|> > > | | |
|> > > |[..] 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 |
|[..] |
|> > 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." |
|---------------------------------------------------------------------------------------------|

This can easily be avoided as I had already showed: it would be legal
and easy to have a reserved word (e.g. _orif) which could never had
been used as a basic_identifier.

|---------------------------------------------------------------------------------------------|
|" 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:
"[..]

4.2.2 Keywords
Keywords are reserved identifiers in PSL, so an HDL name that is a PSL
keyword cannot be referenced
directly, by its simple name, in an HDL expression used in a PSL
property. However, such an HDL name can
be referenced indirectly, using a hierarchical name or qualified name
as allowed by the underlying HDL.
The keywords used in PSL are shown in Table 1.
[..]
onehot0
[..]
5.2.3 Built-in functions
PSL defines a collection of built-in functions that detect typically
interesting conditions, or compute useful
values, as shown in Syntax 5-20.
Syntax 5-20.Built-in functions
HDL_or_PSL_Expression ::=
PSL_Expression
PSL_Expression ::=
Boolean -> Boolean
| Boolean <-> Boolean
Built_In_Function_Call ::=
prev (Any_Type [ , Number [ , Clock_Expression ]] )
[..]
| onehot0 ( BitVector )
[..]"

|---------------------------------------------------------------------------------------------|
|"> The fact that orif must be indented from elsif, is a very poor way to |
|> indicate functional structure of code. [..]" |
|---------------------------------------------------------------------------------------------|

Andy,

Your example
enable := (others => '0');
for i in enable'range loop
if address = i then
enable(i) := '1';
end if;
end loop;
from is
easier to read with indentation than
enable := (others => '0');
for i in enable'range loop if address = i then enable(i) := '1'; end if; end loop;
and is condemning evidence against neither FOR nor IF.

|---------------------------------------------------------------------------------------------|
|"[..] |
|> 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.

|---------------------------------------------------------------------------------------------|
|" Keywords, on the other hand cannot. I believe |
|> that tricks like '_' and '%' on the front of new keywords are a |
|> hideous hack, [..] |
|---------------------------------------------------------------------------------------------|

Actually _ would need to go to the front but % could go anywhere, not
that this would make you detest the ways in which new reserved words
can be added to VHDL (sorry to Verilog people reading this) with a
guarantee that old basic_identifiers will still be valid.

|---------------------------------------------------------------------------------------------|
|"[..] |
| |
|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. |
| |
|[..]" |
|---------------------------------------------------------------------------------------------|

Does the way that most reactions you have received are negative not
seem to indicate that maybe 99.9999% adoption of your proposal is
overly optimistic? It could be said that almost 99.9999% of people who
write in VHDL write the basic_identifier for detecting a clock edge
with "2 separate parts" even though a standard to use the
basic_identifier only once per detection was published alongside
VHDL93.

Regards,
Colin Paul

P.S. This thread is taking up a lot of time, I might not post denials
of mischaracterizations of me again until many days later as I need to
get other work done soon.

 

[comp.arch.fpga]

Weng Tianxiang <[email protected]> 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

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]

Weng,

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"?


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



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]

Weng,

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"?

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:

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]

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

 

[Andy]

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.

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...

read more »

Colin,

My comment regarding indentation, though poorly stated on my part, was
intended to support the traditional use of indentation, which is to
visually indicate subordinate execution/analysis of statements. Since
orif is not executed subordinately to elsif any more than additional
elsif's are, it should not be indented beyond elsif.

In my informal proposal to Jim, I suggested that zero_one_hot() (or
some standard function with that purpose) be defined in a VHDL-
standard package as a VHDL function (i.e. in addition to, or
independent of, a similar PSL function) so that it could be used with
the VHDL ASSERT statement. Thus, if it were defined in a standard
package, then the function name could be prefixed with the package
name to make it unique from any other identifier.

Andy

 

[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]

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 timestamped Thu, 30 Aug
2007 08:08:26 -0700, Jim Lewis <[email protected]> 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

 

[Torsten Landschoff]

[Narrowed to c.l.vhdl only]

Hi Weng,

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'.

Render me confused. If I assert a condition in VHDL, I would expect
the synthesizer to use that information to optimize the circuit (at
least if it has severity error, which is the default). When such an
assertion is declared, it can be assumed that the following code
relies on it anyway. Adding one more instance of "undefined behaviour"
should not matter.

However, I wonder if current synthesizers do some kind of validation
if the assertion can be violated ;-)

Greetings, Torsten

 

[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]

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]

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