New keyword 'orif' and its implications

[Jim Lewis]

Weng,

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

You are taking the wrong approach. Your arguments are repetitive
and you keep thinking there is a win-lose situation.

At the risk of repeating myself:

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


To adopt any proposal into the language, this work must
be done. I am not sure anyone else feels passionate enough
about it to volunteer to do it. You feel passionate about
it. If you do the work and work out the issues, you may be
able to breathe some life into it - although I am not convinced
of its value unless you can show a compelling use case as I
do not know of one myself.

I would use the newsgroup to bounce your ideas off of - and
listen to the advice you get.


Bye,
Jim

 

[Weng Tianxiang]

On Aug 31, 6:01 pm, Jim Lewis <j...@synthworks.com> wrote:

Weng,

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

You are taking the wrong approach. Your arguments are repetitive
and you keep thinking there is a win-lose situation.

At the risk of repeating myself:

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

To adopt any proposal into the language, this work must
be done. I am not sure anyone else feels passionate enough
about it to volunteer to do it. You feel passionate about
it. If you do the work and work out the issues, you may be
able to breathe some life into it - although I am not convinced
of its value unless you can show a compelling use case as I
do not know of one myself.

I would use the newsgroup to bounce your ideas off of - and
listen to the advice you get.

Bye,
Jim

Jim,
1. I have quited my job since last October to devote my full energy to
develop other adventure personally. Since then I have been kept in pay
roll with full pay to do some maintenance work part time.

Today is my last pay day. My company was bought by another company
this week.

2. So I don't have time to do the job you asked now. First I have to
make money out of my current home project. If the project is finished
(expected to finished within 3-6 months from now), I will publish them
on this group to sell and stir another round of discussions. 'orif'
project is my amateur project only when I have time to do it.

3. I know nothing about PSL and just printed VHDL-1993 and VHDL-2002
today and started reading them. I have no interest to learn PSL. I am
more interested in algorithms and circuit development, not the VHDL
language. For my personal use, VHDL-1993 standard plus 'orif' is
enough. That I am pushing for 'orif' adoption is only for my personal
use. Now I don't need it as desperately as before.

4. I am not qualified in any sense to write the report. I would like
to have some big canon to co-sponsor the 'orif' work and I would like
to provide examples and drawings, but not full report, especially
English text part that is my weakest point. The reason is I am not a
good English writer, not a good persuader, even though many times I
have many creative ideas, but am not good at writing them
systematically and quickly. All ideas about 'orif' are on this topics,
I have no any ambition in my life to fight it forever.

5. With 'unique' keyword introduced in Verilog domain, the scientists
and engineers over there have demonstrated why they were. VHDL should
provide the same tool as 'unique' without doubt. Are specialists in
Verilog group so stupid that they created two new tools to do the same
things without a good reason? The reasons are plentiful, but none in
VHDL world shows full support of it. What a pity !

The reason is what I have presented in my posting: in-line programming
capability for a very important feature that was considered only after
2002.

Duplication of two fundamental tools is less a issue if they can
provide convenience, no matter your personal favors are. Now persons'
favor is more important than facts and become deciding factor.

6. 'orif' cannot provide more information than what members of a
mutually exclusive group are. Your method provides the message and
there is no more message to provide to VHDL compilers.

7. The only advantages of 'orif' are
a. in-line programming capability;
b. mixing 'elsif' and 'orif' language structure.

No more.

8. The advantage of 'orif' over 'unique' is that 'orif' can be
selectively used to replace 'elsif' at any place and at any levels in
a 'if' statement.

9. Sorry for using word 'fight' in previous posting. There is no
fight, just exchange ideas and I got a very special gift from the
discussions.

Thank you.

Weng

 

[comp.arch.fpga]

On 1 Sep., 02:13, Weng Tianxiang <wtx...@gmail.com> wrote:

Hi Kolja,
My opinion is when VHDL compilers get more information about mutually
exclusive information, what you can do, the VHDL compilers can do
better.
Yes. But mutual exclusiveness is only a small, special case of input

don't cares
(unreachable input combinations). The tools shoul dhave ways to
specify these,
not only mutual exclusiveness.
For example there might a vernier input that only has the valid
combinations
"0000", "0001", "0011", "0111", "1111". Mutual exclusiveness can not
provide this hint,
assertions can. Because of this the assertion based approach is
allready part of VHDL2006.
It is a very general approach, and of course there are special cases
for which a special
keyword makes live easier, but you still need to solve the general
case.
(Imaging how much simpler the design of a polynomial interpolation
would be, if VHDL had a
polynomial type and an interpolation keyword)

Because the formulation of these inputs sets can be a little
cumbersome, and because there
might be sequential depencies on these (and for a couple of other
reasons) PSL was included
as a way to specify assertion constraints.

The above equation would be implemented in Xilinx chip with carry
chain with initial input data to the carry chain being OutBus.
It will be synthesized to a gated or netlist. This is very the VHDL-

specific part ends.
The technology mapper will than select an appropriate implementation
for the or gate that
might be based on a carry chain implementation.

The
following enable equation would be eliminated from Jim's coding:
(E0 or E1 or E2 or E3 or E4 or E5) = '1'
Yes. The formulation is redundant, even without knowledge of the input

don't cares.

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 ...
But nothing else but that. That is not enough.

You are a doubtor of the technology,
How is that? I am the one that is telling you that your approach is to

limited and
does not utilize the power of logic synthesis to the possible extend.
Handling of
input don't cares is solved since the days of ATPG based synthesis.

As far as coding style goes: I prefer prefer to explicitly code that
the result is a don't care
for certain input conditions as to have this as an implicit side
effect of an operation.

Kolja Sulimma

P.S.: Here is another coding style, assuming the inputs and Es are in
arrays:

output := (others =>'-'); -- this line allows the compiler to do the
optimization, most compilers DECIDE against it
for i in input'range loop
if e = (i=>'1', others=>'0') then output := intput(i);
end loop;



if you know the optimization and want to force it:
for i in input'range loop
if e(i) = '1' then output := output or intput(i);
end loop;

 

[Weng Tianxiang]

On Sep 1, 9:24 am, "comp.arch.fpga" <ksuli...@googlemail.com> wrote:

On 1 Sep., 02:13, Weng Tianxiang <wtx...@gmail.com> wrote:> Hi Kolja,
My opinion is when VHDL compilers get more information about mutually
exclusive information, what you can do, the VHDL compilers can do
better.

Yes. But mutual exclusiveness is only a small, special case of input
don't cares
(unreachable input combinations). The tools shoul dhave ways to
specify these,
not only mutual exclusiveness.
For example there might a vernier input that only has the valid
combinations
"0000", "0001", "0011", "0111", "1111". Mutual exclusiveness can not
provide this hint,
assertions can. Because of this the assertion based approach is
allready part of VHDL2006.
It is a very general approach, and of course there are special cases
for which a special
keyword makes live easier, but you still need to solve the general
case.
(Imaging how much simpler the design of a polynomial interpolation
would be, if VHDL had a
polynomial type and an interpolation keyword)

Because the formulation of these inputs sets can be a little
cumbersome, and because there
might be sequential depencies on these (and for a couple of other
reasons) PSL was included
as a way to specify assertion constraints.

The above equation would be implemented in Xilinx chip with carry
chain with initial input data to the carry chain being OutBus.

It will be synthesized to a gated or netlist. This is very the VHDL-
specific part ends.
The technology mapper will than select an appropriate implementation
for the or gate that
might be based on a carry chain implementation.

The
following enable equation would be eliminated from Jim's coding:
(E0 or E1 or E2 or E3 or E4 or E5) = '1'

Yes. The formulation is redundant, even without knowledge of the input
don't cares.

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

But nothing else but that. That is not enough.

You are a doubtor of the technology,

How is that? I am the one that is telling you that your approach is to
limited and
does not utilize the power of logic synthesis to the possible extend.
Handling of
input don't cares is solved since the days of ATPG based synthesis.

As far as coding style goes: I prefer prefer to explicitly code that
the result is a don't care
for certain input conditions as to have this as an implicit side
effect of an operation.

Kolja Sulimma

P.S.: Here is another coding style, assuming the inputs and Es are in
arrays:

output := (others =>'-'); -- this line allows the compiler to do the
optimization, most compilers DECIDE against it
for i in input'range loop
if e = (i=>'1', others=>'0') then output := intput(i);
end loop;

if you know the optimization and want to force it:
for i in input'range loop
if e(i) = '1' then output := output or intput(i);
end loop;

Hi Kolja,

The
following enable equation would be eliminated from Jim's coding:
(E0 or E1 or E2 or E3 or E4 or E5) = '1'

Yes. The formulation is redundant, even without knowledge of the
input
don't cares.

No, Jim's coding is the best coding we can do now. The equation is
never redundant !

-- 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 write his type of coding everywhere in my design. It is really not a
high level language, but a ASM language writing at flip-flop levels in
name of high level language.

But if 'orif' is a new keyword, the situation may change, at least
from paper and theory. There is no FPGA VHDL compiler today that can
generate better code than Jim's coding.

That is the reason:
What you can do, VHDL compiler can do it better if it gets all
information about mutual exclusiveness.

As far as "don't care" situation is concerned, VHDL compile ignores it
at all. It is not a VHDL problem, it is a compiler problem. You must
distinguish VHDL language problem from compiler capability problem.

Thank you.

Weng

 

[Weng Tianxiang]

On Aug 29, 3:13 am, Colin Paul Gloster <Colin_Paul_Glos...@ACM.org>
wrote:

Jim,

On 2007-08-28, Jim Lewis <j...@synthworks.com> 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 (seenews:1188325844.164564.136940@z24g2000prh.googlegroups.com
). 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,
I have difficulties to understand following segment you are talking
about the name conflicts.

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

I would like to know what Jim's name conflicting mechanism is.

1. Here I have an old file using the following statements:
assertion zero_one_hot(); -- the function was defined in an old file

Here I have another new file using the following statements:
assertion zero_one_hot(); -- try to refer to Jim's function.

Those two above files must be compiled together using 2006 version.
What happens?

No name conflicting?

2. Here is orif name conflicting.

Here I have an old file containing orif as a signal and has the
following statements.

Signal orif : std_logic;
....
If(orif = ...) then

Here I have an new file containing orif as a signal and has the
following statements.

Signal orif : std_logic;
....
If(orif = ...) then

When the old file is compiled by new 2006 version, what would happen
with above two statements? When the new file is compiled by new 2006
version, what would happen with above two statements?

How does 2006 version know that what it deals with is an old file or a
new file with your method?

Jim, here is my solution to your naming conflicting problem.

VERY SIMPLE AND COMPLETE !!!

If a 2006 version compiler uses file date to distinguish old file or
new file by reading their file generation year, before 2007 and after
2007, there is no any trouble to deal with new or old files and both
files can safely be compiled without error.

For 2006 compiler do the following things:
1. Read vhd file;
2. Read their last update date and get year number;
3. When year number <= 2006, orif is cleared in reserved word list;
When year number >= 2007, oris is in reserved word list.
4. If more accurate date is needed, it can add month and date to the
check list.

It doesn't need to add any extra characters before orif. I think
Verilog had used the same method as I suggested and it would guarantee
that there is no naming conflict.

Any comments?

Thank you.

Weng

 

[Weng Tianxiang]

Jim and Colin,
Here is a more flexible method that can avoid orif name conflicting
problem at any situations.

For 2006 compiler do the following things:
1. When being installed, VHDL 2006 compiler pops up a window to allow
clients to set a date after which all VHDL files will be compiled with
orif feature, then writes the date into VHDL initial file with item:
2006_orif_Starting_Date = 09/02/2007;
2. Read vhd file;
3. Read its last update date;
4. If the file date is after the date contained in
2006_orif_Starting_Date equation of VHDL.ini, orif is in reserved word
list, otherwise orif is cleared in reserved word list.

All trouble happens only at installation. If it is found later there
is need to change the effective date, users can modify the date
contained in 2006_orif_Starting_Date equation of the initial file.

Thank you.

Weng

 

[Colin Paul Gloster]

On 2007-09-03, Weng Tianxiang <wtxwtx@gmail.com> wrote:

|-----------------------------------------------------------------------------------------|
|"On Aug 29, 3:13 am, Colin Paul Gloster <Colin_Paul_Glos...@ACM.org> |
|wrote: |
|> Jim, |
|> |
|> On 2007-08-28, Jim Lewis <j...@synthworks.com> wrote: |
|> |
|[..] |
|> |--------------------------------------------------------------------------­| |
|> |"[..] | |
|> | | |
|> |[..] 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, |
|I have difficulties to understand following segment you are talking |
|about the name conflicts. |
| |
||[..] 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. |
| |
|I would like to know what Jim's name conflicting mechanism is. |
| |
|1. Here I have an old file using the following statements: |
|assertion zero_one_hot(); -- the function was defined in an old file |
| |
|Here I have another new file using the following statements: |
|assertion zero_one_hot(); -- try to refer to Jim's function. |
| |
|Those two above files must be compiled together using 2006 version. |
|What happens? |
| |
|No name conflicting?" |
|-----------------------------------------------------------------------------------------|

Weng,

Please reread
news:13ddnbc8cckdr7b@corp.supernews.com
in which it was confirmed that the function is not called zero_one_hot
but is called onehot0 and which has already been part of the PSL
standard for over a year
and please reread
news:slrnfddf2i.828.Colin_Paul_Gloster@mizar.iet.unipi.it
in which it is pointed out that the name conflict would appear only in
PSL (and that it would still be possible to use the name with a
conflict) unlike introducing your keyword which would affect not only
every PSL file which already had the name orif, but also every VHDL
file which already had the name orif.

|-----------------------------------------------------------------------------------------|
|"2. Here is orif name conflicting. |
| |
|Here I have an old file containing orif as a signal and has the |
|following statements. |
| |
|Signal orif : std_logic; |
|... |
|If(orif = ...) then" |
|-----------------------------------------------------------------------------------------|

An if statement does not need ( nor ) in this manner.

|-----------------------------------------------------------------------------------------|
|"Here I have an new file containing orif as a signal and has the |
|following statements. |
| |
|Signal orif : std_logic; |
|... |
|If(orif = ...) then |
| |
|When the old file is compiled by new 2006 version, what would happen |
|with above two statements?" |
|-----------------------------------------------------------------------------------------|

It would work (if you remove the parentheses).

|-----------------------------------------------------------------------------------------|
|" When the new file is compiled by new 2006 |
|version, what would happen with above two statements?" |
|-----------------------------------------------------------------------------------------|

The contents of the new file are identical to the contents of the old
file and the files will be treated identically.

|-----------------------------------------------------------------------------------------|
|"How does 2006 version know that what it deals with is an old file or a |
|new file with your method?" |
|-----------------------------------------------------------------------------------------|

It does not need to.

|-----------------------------------------------------------------------------------------|
|"Jim, here is my solution to your naming conflicting problem. |
| |
|VERY SIMPLE AND COMPLETE !!! |
| |
|If a 2006 version compiler uses file date to distinguish old file or |
|new file by reading their file generation year, before 2007 and after |
|2007, there is no any trouble to deal with new or old files and both |
|files can safely be compiled without error. |
| |
|[..]" |
|-----------------------------------------------------------------------------------------|

Not acceptable. Some people still code in VHDL87. Some people code in
VHDL93. Setting a tool switch can be used to choose the language. When
something was written (which could simply have been copied from a
VHDL87 book in 2010 or could have been a ten year old file whose time
stamp was changed because comments were reformatted) does not indicate
what it was written for.

Regards,
Colin Paul Gloster

 

[Weng Tianxiang]

On Sep 3, 5:31 am, Colin Paul Gloster <Colin_Paul_Glos...@ACM.org>
wrote:

On 2007-09-03, Weng Tianxiang <wtx...@gmail.com> wrote:

|--------------------------------------------------------------------------­---------------|
|"On Aug 29, 3:13 am, Colin Paul Gloster <Colin_Paul_Glos...@ACM.org> |
|wrote: |
|> Jim, |
|> |
|> On 2007-08-28, Jim Lewis <j...@synthworks.com> wrote: |
|> |
|[..] |
|> |--------------------------------------------------------------------------­­| |
|> |"[..] | |
|> | | |
|> |[..] 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, |
|I have difficulties to understand following segment you are talking |
|about the name conflicts. |
| |
||[..] 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. |
| |
|I would like to know what Jim's name conflicting mechanism is. |
| |
|1. Here I have an old file using the following statements: |
|assertion zero_one_hot(); -- the function was defined in an old file |
| |
|Here I have another new file using the following statements: |
|assertion zero_one_hot(); -- try to refer to Jim's function. |
| |
|Those two above files must be compiled together using 2006 version. |
|What happens? |
| |
|No name conflicting?" |
|--------------------------------------------------------------------------­---------------|

Weng,

Please rereadnews:13ddnbc8cckdr7b@corp.supernews.com
in which it was confirmed that the function is not called zero_one_hot
but is called onehot0 and which has already been part of the PSL
standard for over a year
and please rereadnews:slrnfddf2i.828.Colin_Paul_Gloster@mizar.iet.unipi.it
in which it is pointed out that the name conflict would appear only in
PSL (and that it would still be possible to use the name with a
conflict) unlike introducing your keyword which would affect not only
every PSL file which already had the name orif, but also every VHDL
file which already had the name orif.

|--------------------------------------------------------------------------­---------------|
|"2. Here is orif name conflicting. |
| |
|Here I have an old file containing orif as a signal and has the |
|following statements. |
| |
|Signal orif : std_logic; |
|... |
|If(orif = ...) then" |
|--------------------------------------------------------------------------­---------------|

An if statement does not need ( nor ) in this manner.

|--------------------------------------------------------------------------­---------------|
|"Here I have an new file containing orif as a signal and has the |
|following statements. |
| |
|Signal orif : std_logic; |
|... |
|If(orif = ...) then |
| |
|When the old file is compiled by new 2006 version, what would happen |
|with above two statements?" |
|--------------------------------------------------------------------------­---------------|

It would work (if you remove the parentheses).

|--------------------------------------------------------------------------­---------------|
|" When the new file is compiled by new 2006 |
|version, what would happen with above two statements?" |
|--------------------------------------------------------------------------­---------------|

The contents of the new file are identical to the contents of the old
file and the files will be treated identically.

|--------------------------------------------------------------------------­---------------|
|"How does 2006 version know that what it deals with is an old file or a |
|new file with your method?" |
|--------------------------------------------------------------------------­---------------|

It does not need to.

|--------------------------------------------------------------------------­---------------|
|"Jim, here is my solution to your naming conflicting problem. |
| |
|VERY SIMPLE AND COMPLETE !!! |
| |
|If a 2006 version compiler uses file date to distinguish old file or |
|new file by reading their file generation year, before 2007 and after |
|2007, there is no any trouble to deal with new or old files and both |
|files can safely be compiled without error. |
| |
|[..]" |
|--------------------------------------------------------------------------­---------------|

Not acceptable. Some people still code in VHDL87. Some people code in
VHDL93. Setting a tool switch can be used to choose the language. When
something was written (which could simply have been copied from a
VHDL87 book in 2010 or could have been a ten year old file whose time
stamp was changed because comments were reformatted) does not indicate
what it was written for.

Regards,
Colin Paul Gloster

Hi Colin,
OK, I accept your following explanation:

Not acceptable. Some people still code in VHDL87. Some people code in
VHDL93. Setting a tool switch can be used to choose the language.
When
something was written (which could simply have been copied from a
VHDL87 book in 2010 or could have been a ten year old file whose time
stamp was changed because comments were reformatted) does not
indicate
what it was written for.

With compiler switch for different versions, why is there still orif
name conflicting problem?

For 2006 version, keyword orif can be safely used, for old one, there
is no keyword orif.

Thank you.

Weng

 

[Weng Tianxiang]

Hi Colin,
I finally got the right answers and realized that orif is used in 2006
version for other usage.

Jim's always suggested that orif would conflict with OLD files. With
version switches you mentioned, the Jim's claim has not been true
since the beginning.

Now it seems to me that any new keywords can be used in a new version
if there are version switches and the names are not conflicted within
the new versions.

Can we use new keyword OIF or _ORIF for the mutually exclusive
purpose?

OIF is better than _ORIF as a keyword. The fewer letters, the better.

How the new keyword is spelled is not essential, but it is essential
to introduce a new keyword to provide in-line programming capability.

Do you have any reservations about the introduction of new keyword for
the purpose? Why?

Thank you.

Weng

 

[Weng Tianxiang]

Hi Andy,
1. I have a better solution to your complain:
"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. "

The better method to distinguish orif from elsif and that will
ultimately fend off any future tough questions about it is to put the
two keywords in two keyword listing tables in text editor's file and
they will be shown in two different colors, one RED, another PINK, as
TextPad, Emac, or any text editors do without conventional indent
practise change. It is a trivial thing, but exaggerated to a
disadvantage and failure at a strategic level.

2. I disagree with your following comment:

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); <-- useless and just waisting time !!!
end if;
end process;


With your above coding, it seems to me that you don't have a deep
insight why VHDL needs a mechanism to transfer mutually exclusive
information to VHDL compiler, neither does Jim.

With your coding, it doesn't need to provide the information the
assertion provides. It is a well known popular practise before
introducing mutually exclusiveness.

VHDL COMPILERS NEED MUTUALLY EXCLUSIVE INFORMATION IN ORDER TO KEEP
'IF...END IF' STATEMENT STRUCTURE UNIQUITOUS AND MAKE IT POSSIBLE
WRITING HARDWARE IS JUST LIKE WRITING SOFTWARE C (all if statement
when writing software).

We provide EXTRA mutually exclusive information to VHDL compiler and
let the compiler do better job with the "if...end if" statement
structure than what you and we have traditionally done. Because
"if...end if" statements are the simplest and unified way to express
logic ideas. Any advantages current hardware writing style (shown as
in your code) would dissapear and become unnecessary if mutually
exclusive information is given.

Why the above statement is waistful? You have already written the code
with the knowledge how it behaves and adding the assertion statement
just let simulator waisting time to do what you and I never do it
before. No assertion statement in your code works well and nobody adds
the assertion statements to confirm it now.

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

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


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


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


4. If you keep writing your coding style, you never need assertion
functions. If you write assertion function to declare a group of
signals are mutually exclusive, you must stick with the 'if' statement
structure to get its function working. Otherwise writing assertion,
like your code does, is just waisting time.

5. orif or other similar spelling OIF, _ORIF, is not replacable with
assertion function.

6, My another keyword method: Exclusive(or other name, no problem).

Here is an example how Exclusive is used:

signal A : unsigned(5 downto 0) ; -- to store mutually exclusive data

Exclusive : (A); -- it indicates that signal A of its bits is mutually
exclusive.

Exclusive : (StateRead, StateWrite); -- indicate two state machines
are mutually exclusive with their intial states being common. This
function extends mutually exclusive funtion to more than 2 state
machines.

If you need, I can send my paper to you: "HDL Code Inefficiency
Sources and Its Solutions".

Jim,

I am going to publish 6 articles in a batch within next 6 months in
one of three forms: websites, patent applications or international
conferences. One of them has a very good example how 'orif' is used, a
brand new usage. No special report to you is under consideration until
you are pursuaded in advance. You may have to wait for next 6 months
to get the files.

Weng

 

[KJ]

"Weng Tianxiang" <wtxwtx@gmail.com> wrote in message
news:1188844272.492602.110170@k79g2000hse.googlegroups.com...
<snip>

The better method to distinguish orif from elsif and that will
ultimately fend off any future tough questions about it is to put the
two keywords in two keyword listing tables in text editor's file and
they will be shown in two different colors, one RED, another PINK, as
TextPad, Emac, or any text editors do without conventional indent
practise change. It is a trivial thing, but exaggerated to a
disadvantage and failure at a strategic level.

Wow....now you're suggesting color coding as a method to handle your
ambiguities?

<snip>

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); <-- useless and just waisting time !!!
end if;
end process;


With your above coding, it seems to me that you don't have a deep
insight why VHDL needs a mechanism to transfer mutually exclusive
information to VHDL compiler, neither does Jim.

You haven't demonstrated your insight either...but that's my opinion.

With your coding, it doesn't need to provide the information the
assertion provides. It is a well known popular practise before
introducing mutually exclusiveness.
I agree..almost. Sometimes you'll put in these assertions to check the code

you just wrote not so much as a check on what you've just written but as a
check down the road when the code gets modified for whatever reason and the
modifier is maybe unaware of why their change will cause a problem down the
road. A well crafted 'report' after the 'assert' will explain why it is
important and more importantly it will be in 'live code' that actually gets
checked, not in a comment where it is not.

In any case, the assert that was added can be considered a simulation time
waster or info from a maintability standpoint.

Andy's code does not assume mutual exclusiveness it is a priority encoding
to produce outbus.

VHDL COMPILERS NEED MUTUALLY EXCLUSIVE INFORMATION IN ORDER TO KEEP
'IF...END IF' STATEMENT STRUCTURE UNIQUITOUS AND MAKE IT POSSIBLE
WRITING HARDWARE IS JUST LIKE WRITING SOFTWARE C (all if statement
when writing software).

That's your 2 cents about what you think compilers need. Do you have ANY
references or evidence to back up that claim? If not, stop shouting it.

We provide EXTRA mutually exclusive information to VHDL compiler and
let the compiler do better job with the "if...end if" statement
structure than what you and we have traditionally done. Because
"if...end if" statements are the simplest and unified way to express
logic ideas. Any advantages current hardware writing style (shown as
in your code) would dissapear and become unnecessary if mutually
exclusive information is given.

Personally I prefer enumerated types to express mutual exclusiveness where
appropriate and sum of products formation (as shown in Jim's example that
you've posted below a bit) where there are things that 'should' be mutually
exclusive but can not be formally shown to be. There are other constructs
besides the 'if' statement that are quite understandable; your assertion
that 'if...endif' is the 'simplest and unified way' represents your opinion
not some grand truth. The fact that you think that it needs to be augmented
with a new 'orif' keyword suggests that the 'if' statement is not quite so
unified after all.

Why the above statement is waistful? You have already written the code
with the knowledge how it behaves and adding the assertion statement
just let simulator waisting time to do what you and I never do it
before. No assertion statement in your code works well and nobody adds
the assertion statements to confirm it now.

I agree, but as mentioned before, the assert statement with a descriptive
report allows for passing of obscure design information from one design time
to another...sort of a 'heads up' for the designer picking up the code 1
year down the road.

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

And they generally do. Looking at the technology map view of synthesized
code is generally enlightening. In any case, your opinioin has not yet been
substantiated in fact with anything you've posted so far.

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

What do you mean my 'two levels' or 'three levels' of mutual exclusiveness?

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


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

I don't think so, unless you assume the various 'E' are one hot encoded.

Had Jim made that assumption he would have written it without the "if (E0 or
E1 or E2 or E3 or E4 or E5) = '1'" as well I'm sure. In any case, as
written, Jim's handles the case where none of the 'E' happen to be set.
Whether or not this is appropriate depends on what assumptions there are
with 'E'; personally I would think that the condition where none is set is
probably the more common case when bringing together various external
signals and trying to say that they are in some sense mutually exclusive.

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.

But you've presented nothing to indicate that 'orif' would map to anything
different. In fact, you can not. The rules of boolean logic require only
'and', 'or' and 'not', they do not require 'orif'. You claim (but present
no evidence) that the new 'orif' keyword could in some cases present some
resource or timing improvement but you have no basis for that claim and
nothing at all to back it up. Looking at source code examples and
suggesting that it would improve anything is naive at best.

The only claim you could possibly make is that 'orif' is a productivity
enhancer perhaps because it is fewer lines of code (but by perusing Andy,
Jim and your code it would seem that 'orif' is the longest) or because it is
less error prone in use (doesn't appear to be).

In case you're interested, Andy's version consumes 9 logic elements and has
four levels of logic; Jim's version consumes 6 logic elements and has three
levels of logic. The difference comes about because Jim's version take full
advantage of the supposed knowledge that the data inputs are all mutually
exclusive whereas Andy's makes no such assumption. These were benchmarked
using Quartus targetting a Cyclone II which has 4 input LUTs as the logic
primitive. Code I used posted at the end of this posting.

5. orif or other similar spelling OIF, _ORIF, is not replacable with
assertion function.

Actually that's a good thing about 'orif'. Logic should be described by
logic functions not assertions. Those that are proposing using assertions
to drive the synthesized code in some fashion are barking up a bad
tree....what happens when the supposedly impossible happens and the asserted
condition is no longer met? What will the synthesized result produce? It
better be what is described in the logic description which therefore implies
that the asserted statements really should be ignored during synthesis for
the purposes of optomizing any logic functions.

6, My another keyword method: Exclusive(or other name, no problem).

Here is an example how Exclusive is used:

signal A : unsigned(5 downto 0) ; -- to store mutually exclusive data

Exclusive : (A); -- it indicates that signal A of its bits is mutually
exclusive.
What guarantees the exclusiveness? The engineer's code of honor? If it is

reeeeeally mutually exclusive it could be described by an enumerated type.

Exclusive : (StateRead, StateWrite); -- indicate two state machines
are mutually exclusive with their intial states being common. This
function extends mutually exclusive funtion to more than 2 state
machines.

Kind of looks like an enumerated type definition too....hmmm

If you need, I can send my paper to you: "HDL Code Inefficiency
Sources and Its Solutions".

Jim,

I am going to publish 6 articles in a batch within next 6 months in
one of three forms: websites, patent applications or international
conferences. One of them has a very good example how 'orif' is used, a
brand new usage. No special report to you is under consideration until
you are pursuaded in advance. You may have to wait for next 6 months
to get the files.

Hopefully you'll present actual results to back up your so far baseless

claims, it would make for a much stronger case for 'orif'. Good luck with
your work.

KJ

Jim and Andy's versions implemented below. Uncomment out the one you'd like
to synthesize with. By the way, Jim, Andy and Weng's code as presented in
this thread are all flawed and not compilable. In some cases, 'outbus' is
treated as a vector, in others it is treated as a single bit. I modified
each so that 'outbus' is a single bit which appears to be the real intent
here....apologies if it's not.

--------- CODE USED TO IMPLEMENT ANDY AND JIM'S VERSION ----------
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;

entity test is
port (
clk: in std_ulogic;
reset: in std_ulogic;
e: in std_ulogic_vector(7 downto 0);
data: in std_ulogic_vector(7 downto 0);
outbus: out std_ulogic);
end entity test;

architecture rtl of test is
begin
-- Andy's code
-- process (reset, clk) is
-- begin
-- if reset = '1' then
-- outbus <= '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); -- useless and just waisting time !!!
-- end if;
-- end process;

-- It is Jim's coding
OutBusA : process(RESET, CLK)
begin
if(RESET = '1') then
OutBus <= '0';
elsif rising_edge(CLK) then
if (E(0) or E(1) or E(2) or E(3) or E(4) or E(5)) = '1' then
OutBus <=
(E(0) and Data(0)) or (E(1) and Data(1)) or (E(2) and Data(2)) or
(E(3) and Data(3)) or (E(4) and Data(4)) or (E(5) and Data(5)) ;
end if ;
end if ;
end process;

end architecture rtl;
--------- END CODE USED TO IMPLEMENT ANDY AND JIM'S VERSION ----------

 

[Andy]

P.S.: Here is another coding style, assuming the inputs and Es are in
arrays:

output := (others =>'-'); -- this line allows the compiler to do the
optimization, most compilers DECIDE against it
for i in input'range loop
if e = (i=>'1', others=>'0') then output := intput(i);
end loop;

if you know the optimization and want to force it:
for i in input'range loop
if e(i) = '1' then output := output or intput(i);
end loop;

In the (Jim's?) original example, the output was unchanged if no
enable bits were set. Therefore the additional check on e1 or e2 or
e3... is necessary to make sure that only if any enable bit is set
does the output get a new value.

An initial assignment to (others => '-') only takes care of the case
if no enables are set. The order of execution of the loop provides
priority coding, in that the rightmost bit of enable that is set will
win (in the first example), no matter how many are set.

Andy

 

[Andy]

On Aug 31, 9:16 pm, Weng Tianxiang <wtx...@gmail.com> wrote:

3. I know nothing about PSL and just printed VHDL-1993 and VHDL-2002
today and started reading them. I have no interest to learn PSL. I am
more interested in algorithms and circuit development, not the VHDL
language. For my personal use, VHDL-1993 standard plus 'orif' is
enough. That I am pushing for 'orif' adoption is only for my personal
use. Now I don't need it as desperately as before.

So you are not interested in what VHDL already has, you just want to
blindly add duplicative, invasive new features to the language so that
you don't have to learn these existing, more powerful methods?

This is not a language issue. The language already supports
communicating mutual exclusivity and many more powerful notions.
Existing synthesis tools do not use the information; that is the
problem. It would help them if there was "a standard way" to
communicate this to them (which is possible within the existing
language). Just like there is a standard way to communicate a
synchronous process that implies flip flops: there are lots of ways to
describe that behavior in VHDL, but only certain ones are universally
accepted by synthesis tools.

Andy

 

[Weng Tianxiang]

On Sep 4, 6:41 am, Andy <jonesa...@comcast.net> wrote:

On Aug 31, 9:16 pm, Weng Tianxiang <wtx...@gmail.com> wrote:

3. I know nothing about PSL and just printed VHDL-1993 and VHDL-2002
today and started reading them. I have no interest to learn PSL. I am
more interested in algorithms and circuit development, not the VHDL
language. For my personal use, VHDL-1993 standard plus 'orif' is
enough. That I am pushing for 'orif' adoption is only for my personal
use. Now I don't need it as desperately as before.

So you are not interested in what VHDL already has, you just want to
blindly add duplicative, invasive new features to the language so that
you don't have to learn these existing, more powerful methods?

This is not a language issue. The language already supports
communicating mutual exclusivity and many more powerful notions.
Existing synthesis tools do not use the information; that is the
problem. It would help them if there was "a standard way" to
communicate this to them (which is possible within the existing
language). Just like there is a standard way to communicate a
synchronous process that implies flip flops: there are lots of ways to
describe that behavior in VHDL, but only certain ones are universally
accepted by synthesis tools.

Andy

Hi Andy,
I accept your advice and will learn PSL

I have ordered one of 3 books Colin suggested, and found that they
don't contain PSL. I will print VHDL-2006 today.

Are you sure that Jim's assertion method in communicating mutually
exclusivity to VHDL compiler is good enough without need for 'orif'
introduction?

1. As I described before, if you use Jim's method and want to get the
information to compiler, you must insist the 'if...end if' structure
to get the benefits, otherwise it is useless, meaningless and wasting
time.

2. When you use 'if...end if' structure, 'orif' is the best choice, no
question! You can add the information line by line at any levels as
you want.

3. My goal is to make writing VHDL for a hardware engineer as easy as
writing C for a software engineer using 'if...end if' structure with
mixing 'elsif' and 'orif'.

Thank you.

Weng

 

[Andy]

KJ,

Thanks for pointing out that my example, without the assertion,
assumes priority encoding, and not mutual exclusivity. This is often
forgotten in sequential code.

The only problem with enumerated types is that they are not applicable
to an arbitrary (i.e. parameterizable) number of values. So a uniform
way of encoding a arbitrary length vector as enumerated values does
not exist. However, one could choose binary encoding of a one hot
value as an alternative. The trick is doing binary encoding in a way
that takes advantage of mutual exclusivity. It can be done, but I have
not experimented to find out if the encode/decode is able to be
optimized out.

output <= data(to_integer(unsigned(one_hot_encode(e))));

Where one_hot_encode() is a function that optimally (without priority)
converts a one_hot slv to a smaller, binary value slv.

Additional code is needed to handle the zero_hot case.

If one was willing to assume that vector lengths could be limited to
2**31 bits, then one_hot_encode() could return an integer, making its
use a little simpler:

output <- data(one_hot_encode(e));

The optimal coding of one_hot_encode() is left as an excercise for the
user. ;^)

BTW, I assumed "data" was an array of std_logic_vector in my example;
so my version worked as was with the appropriate declaration.

Andy

 

[Andy]

Weng,

First you don't like using additional signals (one signal per
conditional expression), and using the same signal in the condition as
the assertion. So I demonstrate that additional signals are not
necessary. I never said that using duplicate expressions to avoid
additional signals/variables was a good idea, I just showed you how
you could use them to avoid your dreaded extra signals (which, by the
way, is almost always more self-documenting than the expression, even
if it is not used in more than one place).

It really isn't hard to use arrays and loops if you think about it.

Most data bus driving circuits are based on decoding some sort of
address with qualifiers (read_enable, etc.). Therefore I have as
inputs either the address and enable, or I pre-decode (for timing
reasons) the address into an array of strobes. Thus there are not
separate lines for assigning array elements with individual signals,
because I avoid the individual signals in the first place. Even if
there are individual signals, they are often passed in on ports.
Rather than have individual ports for the individual signals, I have
an array port, with the signals bound to elements of the array port in
the instantiation. No more code required to use an array than
individual signals, and even less code in the entity declaration.

I used to design fpgas with a big, centralized address decode module.
That leads to lots of individual signals. Now I distribute the address
and enables to individual modules, along with a generic for base
address, etc. and let each module decode its own enables and determine
when to drive the data bus with what. I also use a lot of tri-state
logic that gets converted to multiplexers automatically, simply
because it lets me decentralize the data bus loading. This also has
the added benefit that the synthesis tool automatically assumes that
the tri-state enables are mutually exclusive (otherwise the simulation
would not have worked anyway), and optimizes the multiplexers
automatically.

You have to think about avoiding the individual signals in the first
place, not just how to convert them into arrays.

Andy

 

[Andy]

Are you sure that Jim's assertion method in communicating mutually
exclusivity to VHDL compiler is good enough without need for 'orif'
introduction?

It depends on the definition of "good enough", but there is not a
single situation where an assertion could not reasonably be used, but
where 'orif' could be. Conversely, there are several situations where
'orif' is not an option, but an assertion would be.

1. As I described before, if you use Jim's method and want to get the
information to compiler, you must insist the 'if...end if' structure
to get the benefits, otherwise it is useless, meaningless and wasting
time.

Not necessarily. There are many mutual exclusivity situations that
might even span different processes. Consider two processes that both
use multipliers. If both processes' uses of their multipliers are
enabled by specific conditions that can be shown to be mutually
exclusive, the synthesis tool has enough information to enable them to
share one multiplier. Of course whether or not current synthesis
tools share resources across processes is beyond the scope of this
argument.

Another example is two state machines that are never both in a state
that uses a multiplier (or some other expensive, shareable resource).

Both of these situations are certainly possible with if-then code
structures, but they don't have to be, and can still take advantage of
an assertion to verify and communicate the mutual exclusivity.

2. When you use 'if...end if' structure, 'orif' is the best choice, no
question! You can add the information line by line at any levels as
you want.

'Orif' is only an option if you can code the function in an if-ELSIF
structure, which cannot be done for a parameterized loop of if-then
structures.

3. My goal is to make writing VHDL for a hardware engineer as easy as
writing C for a software engineer using 'if...end if' structure with
mixing 'elsif' and 'orif'.

Ouch! Then just use verilog; it is already as "easy to use as C" (and
to get into trouble with). ;^)

The way I see it is thus: The barrier to new syntactical changes in
VHDL, particularly those that affect the synthesizable subset of VHDL,
should be quite high because of the problems that occur until every
tool in the chain can even read the new syntax. Therefore, syntactical
changes should only be made to allow functionality that cannot be
reasonably supported within the existing syntax. Of course, that
depends on the definition of "reasonably", but I just don't think
'orif' exceeds the barrier.

Thanks,

Andy

 

[Weng Tianxiang]

On Sep 5, 9:19 am, Andy <jonesa...@comcast.net> wrote:

Are you sure that Jim's assertion method in communicating mutually
exclusivity to VHDL compiler is good enough without need for 'orif'
introduction?

It depends on the definition of "good enough", but there is not a
single situation where an assertion could not reasonably be used, but
where 'orif' could be. Conversely, there are several situations where
'orif' is not an option, but an assertion would be.



1. As I described before, if you use Jim's method and want to get the
information to compiler, you must insist the 'if...end if' structure
to get the benefits, otherwise it is useless, meaningless and wasting
time.

Not necessarily. There are many mutual exclusivity situations that
might even span different processes. Consider two processes that both
use multipliers. If both processes' uses of their multipliers are
enabled by specific conditions that can be shown to be mutually
exclusive, the synthesis tool has enough information to enable them to
share one multiplier. Of course whether or not current synthesis
tools share resources across processes is beyond the scope of this
argument.

Another example is two state machines that are never both in a state
that uses a multiplier (or some other expensive, shareable resource).

Both of these situations are certainly possible with if-then code
structures, but they don't have to be, and can still take advantage of
an assertion to verify and communicate the mutual exclusivity.



2. When you use 'if...end if' structure, 'orif' is the best choice, no
question! You can add the information line by line at any levels as
you want.

'Orif' is only an option if you can code the function in an if-ELSIF
structure, which cannot be done for a parameterized loop of if-then
structures.



3. My goal is to make writing VHDL for a hardware engineer as easy as
writing C for a software engineer using 'if...end if' structure with
mixing 'elsif' and 'orif'.

Ouch! Then just use verilog; it is already as "easy to use as C" (and
to get into trouble with). ;^)

The way I see it is thus: The barrier to new syntactical changes in
VHDL, particularly those that affect the synthesizable subset of VHDL,
should be quite high because of the problems that occur until every
tool in the chain can even read the new syntax. Therefore, syntactical
changes should only be made to allow functionality that cannot be
reasonably supported within the existing syntax. Of course, that
depends on the definition of "reasonably", but I just don't think
'orif' exceeds the barrier.

Thanks,

Andy

Hi Andy,
"Conversely, there are several situations where
'orif' is not an option, but an assertion would be. "

NEVER !

If you have an example to support your opinion, I would recall my
propose forever.

Weng

 

[Andy]

On Sep 5, 12:41 pm, Weng Tianxiang <wtx...@gmail.com> wrote:

Hi Andy,
Now it is clear to me, if not to you,

What assertion onehot0() can do, orif can do better !

"You can NEVER use a parameterized loop of if-then structures"

It is wrong now after our long discussions.

Whenever you write a loop and try to transfer mutually exclusive
information into it, you must remember that you must clearly write
'if..elsif..." structure, then each elsif is a perfect candatate to be
replaced within your loop.

Weng,

Neither of your statements is true.

With 'orif' you must have all of your mutually exclusive (orif)
conditions in a single if-orif tree. 'orif' statements in different if-
orif trees have no context relative to each other, and therefore
cannot indicate mutual exclusivity. For example:

if a = '1 then
z <= x;
orif b = '1' then -- a and b are mutex
z <= y;
end if;

if c = '1' then
g <= e;
orif d = '1' then -- c and d are mutex
g <= f;
end if;

Note that the above does not indicate that a and c are mutex, nor
would you want it to, because then how would you code it such that a
and c are NOT mutex, but both are executed (so you could not use
elsif). For practical reasons, the scope of the mutual exclusivity
must be limited to the same if- or elsif- tree.

You can only unroll a loop of if-then statements into a single if-orif
tree if you know the number of choices when you write it. Otherwise,
you must use a loop with an if-then statement, using a parameter to
determine the number of loop iterations. The if-then statement in the
loop unrolls during synthesis to become separate if-then statements,
so even if there was an orif in the loop's if-then statement, it would
be meaningless between the separate, unrolled if-then statements. The
parameter to control loop iterations may be related to a generic, or
to the size of an unconstrained array port, so you could not possibly
know it ahead of time and manually transform the loop into an if-orif
tree.

REMEMBER: if you want to use assertion onehot0() to transfer mutually
exclusive information, all signals in onehot() entries must be used
after keywords if and elsif. Other coding short cut would leave the
information useless and wastful.

An example of using an assertion without an associated if-then
statement:

Case state_a is
....
when multiply_a =>
x <= y * z;
....
end case.
....
case state_b is
....
when multiply_b =>
a <= b * c;
....
end case;
....
assert zero_one_hot((state_a=multiply_a, state_b=multiply_b));

The assertion could tell the synthesis tool that only one physical
multiplier is needed.

Andy

 

[Andy]

"Conversely, there are several situations where
'orif' is not an option, but an assertion would be. "

NEVER !

If you have an example to support your opinion, I would recall my
propose forever.

Weng,

If you can re-write the following with an if-orif tree to indicate
that every element in enable is mutually exclusive, then you win!

BTW, the range of enable is unknown, but somewhere within the range of
integer'low to integer'high, if that helps.

type data_t is array (enable'range) of std_logic_vector(output'range);
signal data: data_t; -- could be a port instead...
....
for i in enable(i) loop
if enable(i) = '1' then
output <= data(i);
exit;
end if;
end loop;
assert zero_one_hot(enable);

Andy