New keyword 'orif' and its implications

On Sep 5, 12:16 pm, Andy <jonesa...@comcast.net> wrote:
"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
Click to expand...
Hi Andy,

Your code:
for i in enable(i) loop
if enable(i) = '1' then
output <= data(i);
exit;
end if;
end loop;
assert zero_one_hot(enable); <-- useless and wasting time in its
purpose

My code:
for i in enable(i) loop
if enable(i) = '1' then
output <= data(i);
exit;
end if;
end loop;

Why do you need to tell VHDL compiler that every element in enable is
mutually exclusive?

My coding has already told VHDL compiler that
1. all enable(i) are mutually exclusive;
2. You don't have to do anything, I have done it for you and please
take the rest.

If you really want to tell SIMULATOR the information, it has nothing
to do with orif. You may write any function following assertion
statement without any problem.

Target to transfer mutually exclusive information to VHDL compiler is
the pivotal point. VHDL compiler fails to do a better job because VHDL
language lacks elements concisely, relaibly, easily and safely to
transfer the mutually exclusive information to VHDL compiler, not to
SIMULATOR.

VHDL doesn't lack tools to transfer any information to SIMULATORS.
Assertion have already been there for the purpose since its birth.

Jim just unexpertly devised a mechanism that is almost useless in its
purpose.

I would like to thank for your discussion on this topics, because
through our discussions I realized that if one wants to transfer
mutually exclusive information to VHDL compiler, he must stick with
the 'if...end if' statement strucure. Before it, I failed to recognize
it. This is what I said you had given me as a gift.

Please declare who is the
wiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiner.

Weng
 
Weng,
Jim just unexpertly devised a mechanism that is almost
useless in its purpose.
What do you hope to accomplish by belittling other people?
Click to expand...
This is not going to help promote your thoughts.

Please note, I did not participate in the PSL effort, I simply
observed that PSL (with the Accellera VHDL-2006 integration)
provides a capability that seems to address a number of the
use cases you are implying you need.


I would like to thank for your discussion on this topics, because
through our discussions I realized that if one wants to transfer
mutually exclusive information to VHDL compiler, he must stick with
the 'if...end if' statement strucure. Before it, I failed to recognize
it. This is what I said you had given me as a gift.
Yet you have failed to demonstrate anything to anyone
Click to expand...
other than yourself.

Unfortunately, your ideas will not go anywhere unless someone
follows the steps I outlined previously. All proposals put
forward to the working group must go through these steps
of analysis of both the capability requested and the
proposed solution. At this point, I don't see anyone
as excited as yourself to handle this.


Please declare who is the
wiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiner.
Any volunteers :)
Click to expand...

Cheers,
Jim
 
Andy and Weng,
Andy's code:
for i in enable(i) loop
if enable(i) = '1' then
output <= data(i);
exit;
end if;
end loop;
assert zero_one_hot(enable); <-- useless and wasting time in its
purpose

Weng's code:
for i in enable(i) loop
if enable(i) = '1' then
output <= data(i);
exit;
end if;
end loop;
Click to expand...
I note that both of these have priority built into
the logic as the exit makes only the first enable set
take effect. Hence, without additional information (such as
the assertion), a synthesis tool will be obliged to create
the priority that is in the code.

If we really want mutually exclusive logic, then perhaps
a variable will do the trick. For give me if someone else
already suggested this as I have not re-read the threads.

process (enable, data)
variable vOutput : std_logic_vector(...) ;
begin
vOutput := (others => '0') ; -- assuming combinational logic
for i in enable'range loop
if enable(i) = '1' then
vOutput := data(i) or vOutput ;
end if;
end loop;
Output <= vOutput ;
end process ;

For those that like testing code on synthesis tools, I would
be curious to know how that plays the following (which is more
hardware implementation specific):

process (enable, data)
variable vOutput : std_logic_vector(...) ;
begin
vOutput := (others => '0') ; -- assuming combinational logic
for i in enable'range loop
vOutput := (data(i) and enable(i)) or vOutput ; -- vhdl-2006 "and"
end loop;
Output <= vOutput ;
end process ;


If you are coding this in a clocked process, you can put guard on
the enable using the reduction form of or (from VHDL-2006) or replace
it with or_reduce from ieee.std_logic_misc (not a standard package and
hence not recommended by me):

process (Clk)
variable vOutput : std_logic_vector(...) ;
begin
if rising_edge(Clk) then
if OR( enable) = '1' then
vOutput := (others => '0') ; -- assuming combinational logic
for i in enable'range loop
vOutput := (data(i) and enable(i)) or vOutput ; -- vhdl-2006 "and"
end loop;
Output <= vOutput ;
end if ;
end if ;
end process ;


Cheers,
Jim
SynthWorks VHDL Training
 
On Wed, 05 Sep 2007 17:52:28 -0700, Weng Tianxiang <wtxwtx@gmail.com>
wrote:

On Sep 5, 12:16 pm, Andy <jonesa...@comcast.net> wrote:
"Conversely, there are several situations where
'orif' is not an option, but an assertion would be. "

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!

type data_t is array (enable'range) of std_logic_vector(output'range);
signal data: data_t; -- could be a port instead...
...
Andy

Hi Andy,

Your code:
for i in enable(i) loop
if enable(i) = '1' then
output <= data(i);
exit;
end if;
end loop;
assert zero_one_hot(enable); <-- useless and wasting time in its
purpose

My code:
for i in enable(i) loop
if enable(i) = '1' then
output <= data(i);
exit;
end if;
end loop;

Why do you need to tell VHDL compiler that every element in enable is
mutually exclusive?

My coding has already told VHDL compiler that
1. all enable(i) are mutually exclusive;
2. You don't have to do anything, I have done it for you and please
take the rest.
Click to expand...
Unfortunately, enable was accidentally set to "00010111"

Andy's code caught the problem before synthesis, so he fixed it.
Because his synthesis tool (the 2008 version) understood the assertion,
it was free to generate fast logic instead of following the priority.

Yours did not, and if your synthesis tool believed statement (1) above,
instead of following the priority built into the loop, it enabled four
drivers onto the "output" bus at once.

While you contemplate the smoking remains of your chip, you are invited
to explain how your comment "What assertion onehot0() can do, orif can
do better !" applies to this example.

- Brian
 
Weng,

To elaborate on what Jim and Brian have stated, In the loop, in order
for enable(n) to be considered, enable(n-1) must have been false. This
evaluation of enable(n-1) requires additional gates UNLESS there is
something else that tells the compiler (synthesis or simulation) that
the enable bits are mutually exclusive, and therefore that if
enable(n) is set, by definition enable(n-1) is not set.

It is interesting to note that the presence of the exit statement has
no effect on the synthesized gates IF enable is mutually exclusive.
However in the absence of both the exit statement and mutual
exclusivity, the last executed assignment to output wins, so enable(n)
is only used if enable(n+1) is not set, thus also requiring additional
gates.

Both of these explanations assume an index ordering of "to", not
"downto"; however, the behavior is similar (and the effect on
hardware the same) with "downto".

So, in fact your code DOES NOT demonstrate, nor optimize for, the
mutual exclusivity of the bits in enable. Contrary to your erroneous
statement, your code merely demonstrates your lack of understanding of
the significance of order of execution among sequential statements, a
fundamental concept in simulation and logic synthesis.

Jim's (and others') implementation using OR works well for data types
that support the OR operator: booleans, bits and vectors, but neither
integers, enumerated types nor other aggregate types, without a
conversion to/from an ORable data type, can use this method.

In addition, without the assertion, the (erroneous) lack of mutual
exclusivity upon which the solution depends would likely go unnoticed
in simulation. And while the ability of the simulator to use the
assertion has existed since the beginning, the ability of synthesis
tools to use the assertion (not to verify it, but to optimize
circuitry because of it) does not, to this day, exist.

Oh, and by the way, I AM THE WINNER! ;^)

Andy
 
Hi Brian,
1. Please write target answer's name, otherwise I may miss your
comments.

2. Before 2006, we didn't have 2006/2008 VHDL compilers available, did
you see any burning?

3. The following claim is irrelative to Andy's requirement:
"Andy's code caught the problem before synthesis, so he fixed it.
Because his synthesis tool (the 2008 version) understood the
assertion"

Andy wants me to use orif to transfer mutually exclusive information
to within loop, in this respect, no orif is needed and things are done
perfectly, because mutually exclusive Information has been clearly
transfered to within the loop by coding style.

I think it is the best explanation to your question:

Nothing is better than extra.

Whatever assertion onehot0() can do in terms of mutually exclusive
information tranfer mechanism, orif can do better, faster, safer and
more reliable !

The above sentence is too long to remember, the following sentence was
used and everyone involved knows its full meaning:
What assertion onehot0() can do, orif can do better.

I have to emphasize that onehot0() function is useful in general, but
useless in terms of its introduction purpose.

Weng
 
Andy,
Your following claim is false:
"...enable(n-1) must have been false.."

Only enable() is a static, a foolish case, the above situation would
happen and your assertion part plays a role for a VHDL compiler.

The static values may be all 0. So that no code would be generated for
the code segment. Are you serious enough to design a mechanims to deal
with the stupid case only?

It has nothing to do with mutually exclusive information.

Nothing is better than extra gabage.

Weng
 
Jim,
Sorry for any usage of inappropriate words.

Weng
 
On Sep 6, 10:30 am, Weng Tianxiang <wtx...@gmail.com> wrote:
Andy,
Your following claim is false:
"...enable(n-1) must have been false.."

Only enable() is a static, a foolish case, the above situation would
happen and your assertion part plays a role for a VHDL compiler.
Click to expand...
Enable() is NOT static! It is a dynamic signal/variable that is driven
from elsewhere.

Note that I said "in order for enable(n) to be considered". I did NOT
say "for enable(n) to be set"!
If enable(n-1) was set, then the loop would have exited before
evaluating enable(n). Therefore output gets data(n) only if enable(n)
= '1' AND enable(n-1) = '0' AND enable(n-2) = '0' AND... This
results in additional logic that is not necessary if it is known that
the enable bits are mutually exclusive.

If you don't believe me, compare the synthesis results of your code
with Jim's code (since the assertion in my code is not understood by
synthesis yet). Jim's code is the logical equivalent of what a
synthesis tool should implement for your code (or my code), if the
tool was aware of, and could optimize for, mutual exclusivity.

The static values may be all 0. So that no code would be generated for
the code segment. Are you serious enough to design a mechanims to deal
with the stupid case only?
Click to expand...
Since you ask, this function is intended for a clocked process, so
"doing nothing" means maintaining the previous value (i.e. a clock
enable), which is far from a "stupid case".

Andy
 
On Thu, 06 Sep 2007 07:53:25 -0700, Weng Tianxiang <wtxwtx@gmail.com>
wrote:

Hi Brian,
1. Please write target answer's name, otherwise I may miss your
comments.

2. Before 2006, we didn't have 2006/2008 VHDL compilers available, did
you see any burning?
Click to expand...
Back in the TTL days, yes.

3. The following claim is irrelative to Andy's requirement:
"Andy's code caught the problem before synthesis, so he fixed it.
Because his synthesis tool (the 2008 version) understood the
assertion"

Andy wants me to use orif to transfer mutually exclusive information
to within loop, in this respect, no orif is needed and things are done
perfectly, because mutually exclusive Information has been clearly
transfered to within the loop by coding style.
Click to expand...
it's exactly relevant because in his example, the ONLY mutually
exclusive information IS the assertion. In your counterexample I don't
see any such information, despite the fact that you are free to use
"orif".

Whatever assertion onehot0() can do in terms of mutually exclusive
information tranfer mechanism, orif can do better, faster, safer and
more reliable !
Click to expand...
This has still not been demonstrated for this example.

- Brian
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top