New keyword 'orif' and its implications

[Michael Jørgensen]

<BEGIN QUOTE>
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;
<END QUOTE>


I think perhaps the above example is a bit too simple. In my designs I have
an external CPU accessing various tables inside the FPGA. The address
decoding leads to a number of mutually exclusive conditions, but the
synthesis tool does not recognize them as such.

The following example shows what I mean (see code at end of post).
Basically, it is just 4-input 4-output LUT, but when synthesizing I end up
with a long chain of MUX'es.

I would like the output signal in the code below to be synthesized as a
single 8-to-1 multiplexer (i.e. in parallel), and not as seven 2-to-1
multiplexers chained together in series.

Others have suggested using enumerated types, but I can't see how that
helps. This will just lead to a chain of if-statements in the address
decoding, instead of in the output multiplexing.

So either I'm missing something fundamental in VHDL (quite likely, since I'm
still new in this field), or the language has a limitation that is causing
problems for me.

-Michael.


<BEGIN CODE EXAMPLE>

library ieee;
use ieee.std_logic_1164.all;

package p_test_decode is
subtype t_data is std_logic_vector(3 downto 0);
subtype t_addr is std_logic_vector(3 downto 0);
end p_test_decode;

library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
use work.p_test_decode.all;

entity test_decode is
port (
Addr_IN : in t_addr;
D_OUT : out t_data
);
end entity test_decode;

architecture rtl of test_decode is
signal reg_hit : std_logic_vector(7 downto 0);
type t_decode is array(7 downto 0) of t_addr;
constant addr : t_decode := ("0001", "0010", "0110", "0101", "1001",
"1000", "1010", "1101"); -- Just a random selection of bit patterns
type t_val is array(7 downto 0) of t_data;
constant val : t_val := ("1010", "1011", "1100", "0100", "1001", "0011",
"0001", "0000"); -- Just another random selection of bit patterns
begin
hit: for i in 0 to 7 generate
reg_hit(i) <= '1' when Addr_in = addr(i) else '0';
end generate;

-- reg_hit is essentially a one-hot representation of the result of the
address decoding.

-- I want D_OUT to be an 8-to-1 multiplexer; not seven 2-to-1
multiplexers.

D_OUT <= val(0) when reg_hit(0) = '1' else
val(1) when reg_hit(1) = '1' else
val(2) when reg_hit(2) = '1' else
val(3) when reg_hit(3) = '1' else
val(4) when reg_hit(4) = '1' else
val(5) when reg_hit(5) = '1' else
val(6) when reg_hit(6) = '1' else
val(7) when reg_hit(7) = '1' else
(others => 'X');

end architecture rtl;

<END CODE EXAMPLE>

 

[Andy]

Adam, [sic]

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

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

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

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

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

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

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

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

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

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

I can tell.

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

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

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

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

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

Andy

 

[Weng Tianxiang]

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

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

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

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

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

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

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

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

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

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

I can tell.

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

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

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

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

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

Andy

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

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

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

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

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

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

Thank you.

Weng

 

[Weng Tianxiang]

Weng, take a step back.

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

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

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

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

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

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

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

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

Kolja Sulimma

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

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

You are the one of second group.

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

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

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

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


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


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


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


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


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

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

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

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

Thank you.

Weng

 

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

Weng,


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]

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;

 

[KJ]

<BEGIN QUOTE>
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;
<END QUOTE>


I think perhaps the above example is a bit too simple. In my designs I
have an external CPU accessing various tables inside the FPGA. The address
decoding leads to a number of mutually exclusive conditions, but the
synthesis tool does not recognize them as such.

The following example shows what I mean (see code at end of post).
Basically, it is just 4-input 4-output LUT, but when synthesizing I end up
with a long chain of MUX'es.

When I synthesized it with Quartus I got 4 LUTs for the total usage, one to
compute each of the four bits of D_OUT. The input to each of the four LUTs
are the four address inputs Addr_IN(3:0). The intermediate signal
'reg_hit(3:0)' was optomized out, the logic path for all four outputs
consisted of a single LUT delay. There was no cascading of LUTs or
anything. Bottom line is that the synthesized result is exactly what I
would have expected.

Since you synthesized it and ended up with "a long chain of MUX'es" perhaps
you should take Andy's suggestion regarding such a synthesis tool which is
that it "should be immediately uninstalled and returned to the vendor for a
full refund!".

I would like the output signal in the code below to be synthesized as a
single 8-to-1 multiplexer (i.e. in parallel), and not as seven 2-to-1
multiplexers chained together in series.

I'm not sure how the 8->1 mux fits into the example you posted, but perhaps
you should ponder a bit on how to implement an 8->1 mux given logic
primitives that take 4 to 6 inputs only (i.e. various FPGAs). CPLDs have
much wider inputs to the logic array, but FPGAs with their LUTs don't so
maybe what you're seeing when you talk about long chains of muxes is simply
because the FPGA LUT with it's 4-6 inputs simply cannot implement an 8->1
mux in a single level of logic. Again though, the 8->1 mux you're speaking
of must be something other than for the code you posted.

Others have suggested using enumerated types, but I can't see how that
helps. This will just lead to a chain of if-statements in the address
decoding, instead of in the output multiplexing.

Enumerated types wouldn't help in the synthesis in this particular example,
but what it can help with is readability. D_OUT(0), D_OUT(1), etc. is
probably less descriptive then D_OUT(Ram), D_OUT(Flash), etc. The mutual
exclusivity of the bits of the signal 'reg_hit' in your example was
correctly handled as it should be by Quartus.

So either I'm missing something fundamental in VHDL (quite likely, since
I'm still new in this field), or the language has a limitation that is
causing problems for me.

I don't think it's a language limitation that is causing whatever problems
you're seeing. Given the synthesis results that you got (the long chain of
mux) suggests that the problems are caused by your synthesis tool.

KJ

 

[Weng Tianxiang]

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.


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.


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


But nothing else but that. That is not enough.


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

 

[comp.arch.fpga]

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

Finally you get my point. There is no need to change the language, you
only
need to change the compiler to support the existing language features:
- interpretation of assertions to deduce reachability don't cares.
- honoring output observability don't cares coded as '-' during
optimization

Again: The existing language features can do a lot more than mutual
exclusiveness.
You only need compilers that use them. Adding a keyword for a special
case to the
language will only delay adoption of the general case.

Kolja Sulimma

 

[Weng Tianxiang]

Finally you get my point. There is no need to change the language, you
only
need to change the compiler to support the existing language features:
- interpretation of assertions to deduce reachability don't cares.
- honoring output observability don't cares coded as '-' during
optimization

Again: The existing language features can do a lot more than mutual
exclusiveness.
You only need compilers that use them. Adding a keyword for a special
case to the
language will only delay adoption of the general case.

Kolja Sulimma

Hi Kolja,
"at all. It is not a VHDL problem, it is a compiler problem. You must
distinguish VHDL language problem from compiler capability problem. "

In above sentence, what I had refered to is the case of 'dont' care'
you mentioned in your example, not the 'orif' case.

Verilog introduction of 'unique' and other related functions has
showed that mutually exclusiveness in HDL needed to be added and
improved.

Weng

 

[Weng Tianxiang]

Jim,


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

Yes,

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

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

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

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

Best regards,
Colin Paul

Hi Colin,
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

 

[Michael Jørgensen]

[snip]

I don't think it's a language limitation that is causing whatever problems
you're seeing. Given the synthesis results that you got (the long chain
of mux) suggests that the problems are caused by your synthesis tool.

KJ

Thanks for your comments.

I entered this thread because I thought I recognized a problem I was having
myself, i.e. that the synthesis tool (I'm using Quartus) did not properly
utilize mutually explusiveness. Well, I was mistaken. Let me explain.

The small example in my previous post was created to describe my problem.
However, I was making the mistake of looking in the RTL viewer. Using my
example, there is indeed a chain of MUX's clearly seen in the RTL view.
However, I then checked the equation file, and that consists essentially of
four parallel ALUTs, just as you described.

That surprised me: I thought the RTL viewer was essentially a graphical
representation of the equation file, but that is clearly not the case. It
only represents something that is logically equivalent. I'm glad to have
found that out.

I tried a more complicated example where the output was to be multiplexed
from four different RAMS. Again, the selection was done in a single ALUT for
each output bit.

So it seems that Quartus is actually doing a very good job at optimizing the
design, contrary to my initial claim.

My conclusion is therefore that the problem I aluded too is non-existent.

Going back to the OP, this leads me to ask, what is actually the problem
that Weng is trying to solve?

-Michael.

 

[Colin Paul Gloster]

|-----------------------------------------------------------------------------------------|
|"On Aug 29, 3:13 am, Colin Paul Gloster <[email protected]> |
|wrote: |
|> Jim, |
|> |
|> |
|[..] |
|> |--------------------------------------------------------------------------­| |
|> |"[..] | |
|> | | |
|> |[..] 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
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
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

 

[Jonathan Bromley]

Going back to the OP, this leads me to ask, what is actually the problem
that Weng is trying to solve?

The issue is well-known, and has numerous prior-art solutions
(I'll come back to them): There are many, many designs in which
the designer has private knowledge of the set of values that may
legally appear on a group of signals. If the designer cannot
express that knowledge to the synthesis tool, he will get
inferior logic optimization. If the designer cannot express
that knowledge to the simulator, he runs the risk of failing
to detect certain errors that put illegal values on to the
signals.

Here's a very simple example, for which no new solution is
needed. Suppose I wish to make an electronic die that
displays (using seven LEDs) the usual pattern of one to
six spots. My display has four "segments" made from
seven lamps:

A B
C D C 1->D, 2->A, 3->AD, 4->AB, 5->ABD, 6->ABC
B A

Now I run a binary counter over the values 1,2,3,4,5,6
to generate the values. I need a decoder:

signal count: unsigned(2 downto 0);
signal lamps: std_logic_vector(0 to 3); --- 0=A,1=B, 2=C, 3=D
...
case count is -----lamps ABCD
when "001" => lamps <= "0001";
when ....
when "110" => lamps <= "1110";
when others=> lamps <= "----";
end case;

This is a simple and effective style that allows the synth tool
full scope for optimization, and in simulation makes it very clear
to you if you mistakenly put a bad value on "count". You could
even add a simulation-only error diagnostic (assertion) in the
"others" branch. I have been able to write code that captures
my hidden design knowledge both for simulation and for synthesis.
If, in the real hardware, the count should go to 0 or 7 then I
will get some goofy pattern on the LEDs; but I don't care,
because my simulations convinced me that this will never happen.

In more complicated situations, and particularly in situations
where different signals need to be tested to choose different
branches of a conditional, it can be very difficult indeed to
capture this kind of design knowledge in the code.

Assertions provide a clear and appropriate way to expose
such design-specific knowledge to a simulator ("I promise
that signals P and Q will never be true together; I promise
that if signal P is true then exactly one of signals
R and S will also be true") but no synthesis tool that
I'm aware of can make use of this kind of information to
improve its optimizations.

Synthesis pragmas or directives, notably the full_case
and parallel_case pragmas supported by all serious Verilog
synthesis tools, provide a convenient way to flag to a
synthesis tool that certain conditions will always hold
(full_case specifies that at least one branch of a
conditional will be taken and therefore the tool does
not need to consider any other possibilities; parallel_case
specifies that no more than one branch of a conditional
will be taken, so the tool can assume mutual exclusivity).
Unfortunately, simulators completely ignore such directives
and therefore we not only risk missing important error
conditions, but also we may get mismatches between simulation
and synthesis behaviour. Most VHDL designers would rightly
choke on their coffee at such a thought.

Consequently, many people have sought some way to express
such kinds of design intent within the language itself.
Assertions are the obvious candidate, but are probably
too open-ended to be tractable for synthesis: for example,
an assertion in one part of a design might enforce
mutual exclusivity on a conditional in quite another
part of the design and it is unreasonable to expect
synthesis tools to be able to handle that sort of thing.
SystemVerilog has taken the approach of adding some new
language keywords ("unique" and "priority") that can
be used to modify the conditional statements "case"
and "if"; simulators recognise these keywords as a
special assertion, and synthesis tools recognise them
as licence to perform certain optimizations. Everyone
is happy. We get better logic, and no sim/synth mismatch.

There is absolutely no point in trying to apply anything
like full_case and parallel_case to VHDL case statements,
since they are inherently full and parallel by the language
definition. However, there *may* be some mileage in
chasing that goal for the "if" statement. That's what
Weng's "orif" keyword aims to do. I, and many others,
think it's an idea that has merit but is too flawed and
limited to be worthy of inclusion in the language.

It is *always* possible to get the desired behaviour
by writing sufficiently contorted VHDL. There is,
however, much to be said for providing a language-based
mechanism to solve these important and common problems.
Some posters to this thread have argued that enumeration
types do all they need; I totally disagree, because
enumerations specify mutual exclusivity only in cases
where the mutual exclusivity can trivially be shown
to hold statically.

The practical reality, today, is that all the common
examples of this problem (notably, many variations on
the one-hot-coded theme) have perfectly viable solutions
in standard VHDL. Consequently, language support is not
high on the list of priorities for the people that matter.
I lack the will and the stamina to try to change that
situation, so I'll now shut up even though I think I
may have some better ideas
--
Jonathan Bromley, Consultant

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

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

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

 

[Weng Tianxiang]

|--------------------------------------------------------------------------­---------------|
|"On Aug 29, 3:13 am, Colin Paul Gloster <[email protected]> |
|wrote: |
|> Jim, |
|> |
|> |
|[..] |
|> |--------------------------------------------------------------------------­­| |
|> |"[..] | |
|> | | |
|> |[..] 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 rereadin 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 rereadin 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

 

[KJ]

The issue is well-known, and has numerous prior-art solutions
(I'll come back to them): There are many, many designs in which
the designer has private knowledge of the set of values that may
legally appear on a group of signals. If the designer cannot
express that knowledge to the synthesis tool, he will get
inferior logic optimization. If the designer cannot express
that knowledge to the simulator, he runs the risk of failing
to detect certain errors that put illegal values on to the
signals.

Here's a very simple example, for which no new solution is
needed.

<snip>
You did kind of the bait and switch on this one without really addressing
the question posed....what is the problem that Weng is trying to solve?

In more complicated situations, and particularly in situations
where different signals need to be tested to choose different
branches of a conditional, it can be very difficult indeed to
capture this kind of design knowledge in the code.

Ummm.....like what? Certainly not Weng's outbus example. That one is best
coded by writing it in a sum of products form, but Weng dismisses that as
being the equivalent of assembler whereas the 'orif' is a high level
construct which is completely wrong. Other cases that have been brought up
can be handled by properly reformulating the problem using enumerated types.

From what I can tell, the only problem that 'orif' solves is how to
structure something into an 'if' statement instead of using other clearly
understandable statements that are already part of the language. Much like
the person who owns a hammer sees every problem as a nail, Weng sees the
'if' statement as his hammer but finds it somewhat deficient in that he
needs a modified one (one with an 'orif') to tackle a problem that has no
nail.

Assertions provide a clear and appropriate way to expose
such design-specific knowledge to a simulator ("I promise
that signals P and Q will never be true together; I promise
that if signal P is true then exactly one of signals
R and S will also be true") but no synthesis tool that
I'm aware of can make use of this kind of information to
improve its optimizations.

If you already have the complete logic description (which is encoded in all
of the 'non-assert' statements) the synthesis tool will not really have much
use for these unverifiable asserts that purport to give this supposedly
'higher level' information. Just what should happen if the logic
description says one thing but the assertion claim another...and the
supposedly impossible thing happens (i.e. the 'assert' fires)? The
synthesis tool generated logic will have no way to flag this and, I'm
guessing, is free to implement this case however it wants to independent of
the logic description....I think I'll pass on such a tool, the supposedly
'impossible' happens, 'specially as code gets reused in new applications.

It is *always* possible to get the desired behaviour
by writing sufficiently contorted VHDL.

Many times with uncontorted code as well....like the sum of products
solution to the outbus example.

There is,
however, much to be said for providing a language-based
mechanism to solve these important and common problems.
Some posters to this thread have argued that enumeration
types do all they need; I totally disagree, because
enumerations specify mutual exclusivity only in cases
where the mutual exclusivity can trivially be shown
to hold statically.

So we agree that the enumeration type solves the one class of mutual
exclusiveness. But I'm still waiting for the example of this 'common'
problem for which 'orif' is the solution.

KJ

 

[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