I hate VHDL!!!

Hi Weng,

"Synthesis optimizations will clean it right up."

No ways! Compiler doesn't know they are mutually exclusive unless VHDL
or Verilog provides a mean programmer can use.
Click to expand...
For the statement below:

NextState <= stateX1 when BusAddress = 32-bit-Address1 else
stateX2 when BusAddress = 32-bit-Address2 else
...
Click to expand...
there is NO reason why a decent synthesis tool cannot see that they
are mutually exclusive: all comparisons compare against the same
input, BusAddress. It's extremely simple for a synthesis tool to
recognize this an act accordingly.
Long time ago (before you sent me your paper, which was, I think, 2
years ago), I did some tests on this and DC was able recognize this
mutual exclusiveness without problems.

In other words, for the most common case, there is enough information
for a synthesizer to do a good job.

The only case where your suggestion could have merit, is an example
like this:

Decode1 <= '1' when Addr = Addr1;
Decode2 <= '1' when Addr = Addr2;
Decode3 <= '1' when Addr = Addr3;
Decode4 <= '1' when Addr = Addr4;
Decode5 <= '1' when Addr = Addr5;

if Decode1='1' then
RdData <= Data1;
elsif Decode2='1' then
RdData <= Data2;
....

In this case, it's less likely that the synthesizer will recognize
that DecodeX is mutual exclusive. This is certainly the case if the
Decode signals are reclocked for whatever (timing?) reason.

My standard way to solve this is as follows:

v_RdData := (others => '0');
if Decode1='1' then
v_RdData := v_RdData or Data1;
elsif Decode2='1' then
v_RdData := v_RdData or Data2;
....
RdData <= v_RdData;

This solves 90% of the 5% of cases where a standard if-then-else tree
would give you trouble.
Your solution would be this:

if Decode1='1' then
RdData <= Data1;
orif Decode2='1' then
RdData <= Data2;
....

Yes, this could be a way to solve your problem, but, in my opinion,
it's not worth the trouble.

Not only would such a keyword be very confusing for beginners in
Verilog or VHDL, it only would introduce ambiguous behavior in the
language.

The way things are now, if you use the standard constructs, you can
reasonably be sure(*) that whatever your wrote will be synthesized
accordingly into gates and you can use formal equivalence check to
verify.

What if the designer using your new keyword makes a mistake and
conditions are NOT mutex? In that case, the simulator may give
different results for gatelevel simulation than for RTL simulations.
I'm sure there will be formal equivalence check consequences also.
In my opinion, you will open a can of worms that's just not worth
opening...

This is a Achilles heel for VHDL or Verilog.
Click to expand...
Given that his heel was the reason for his Achilles' death, this is a
slight exaggeration. Just like beginning of your rant. If you just
learned to moderate your tone a little bit, more people actually might
listen to what you really have to say. If, on the other hand, the
subject of this thread had the intention to have readers dismiss you
as a brainless troll (which you are not), you probably succeeded very
well...

Tom


(*) incomplete sensitivity lists may be an exception here, but a
synthesis tool can easily warn for those.
 
The only case where your suggestion could have merit, is an example
like this:

Decode1 <= '1' when Addr = Addr1;
Decode2 <= '1' when Addr = Addr2;
Decode3 <= '1' when Addr = Addr3;
Decode4 <= '1' when Addr = Addr4;
Decode5 <= '1' when Addr = Addr5;

if Decode1='1' then
RdData <= Data1;
elsif Decode2='1' then
RdData <= Data2;
...

In this case, it's less likely that the synthesizer will recognize
that DecodeX is mutual exclusive. This is certainly the case if the
Decode signals are reclocked for whatever (timing?) reason.
Click to expand...
In my PCI/PCI-X core and related designs, there are more than 70
places in one project I recognized there are mutually exclusive
situations. That is why I hate VHDL that doesn't provide a mean to
effectively express such situations.

Why I mentioned address comparison is because everyone uses it, but
not because it is the only place to use it.

For example, do you have counters in your design? see all of them and
their loading conditions: they must be mutually exclusive with loading
conditions!!! If you have 30 counters, there are 30 places where most
likely mutually exclusive situations happen!!!

My standard way to solve this is as follows:

v_RdData := (others => '0');
if Decode1='1' then
v_RdData := v_RdData or Data1;
elsif Decode2='1' then
v_RdData := v_RdData or Data2;
...
RdData <= v_RdData;
Click to expand...
I don't know if your method is valid for a state machine: two state
machine names can be "OR"ed?
If each time you are handling the situations like what you suggest,
what do you think?

I have two other engineer's emails, one from IBM, another Lockheed
Martin, telling me other two methods to resolve the problem. That says
language needs something new to resolve the problem, even few
engineers saw it and need it. The fact is the more you recognize that
are mutually exclusive situations, faster speed and less resources you
can get. It's essential for my project to get 66MHz for PCI and 133MHz
for PCI-X while using FPGA.

This solves 90% of the 5% of cases where a standard if-then-else tree
would give you trouble.
Your solution would be this:

if Decode1='1' then
RdData <= Data1;
orif Decode2='1' then
RdData <= Data2;
...

The way things are now, if you use the standard constructs, you can
reasonably be sure(*) that whatever your wrote will be synthesized
accordingly into gates and you can use formal equivalence check to
verify.
Click to expand...
It has very clear definition of gates!!!
RdData <= (Decode1='1' and Data1) or (Decode2='1' and Data2) or
(Decode3='1' and Data3);
or
NextState <= (Decode1='1' and State1) or (Decode2='1' and State2) or
(Decode3='1' and State3);

What if the designer using your new keyword makes a mistake.
Click to expand...
Jim Lewis did a very good suggestion: add a debugging parameter:
"errels". if error happens, go to error handling in simulation.

Weng
 
In my PCI/PCI-X core and related designs, there are more than 70
places in one project I recognized there are mutually exclusive
situations. That is why I hate VHDL that doesn't provide a mean to
effectively express such situations.
Click to expand...
As I and you have shown, there is a way to do it. It's just not very
pretty. Which is good, since it's a dangerous construct. :)

For example, do you have counters in your design? see all of them and
their loading conditions: they must be mutually exclusive with loading
conditions!!! If you have 30 counters, there are 30 places where most
likely mutually exclusive situations happen!!!
Click to expand...
Counters are another place where you can very easily apply the OR
technique.

I don't know if your method is valid for a state machine: two state
machine names can be "OR"ed?
If each time you are handling the situations like what you suggest,
what do you think?
Click to expand...
If you declare the states of your statemachine as a vector instead of
an enum (which, admittedly, I don't really like), you can solve the
problem the same way.

Again, it's pretty way, but using
v_State := v_State or c_NextPhase;
instead of
State <= e_NextPhase;
isn't really the end of the world.

I have two other engineer's emails, one from IBM, another Lockheed
Martin, telling me other two methods to resolve the problem. That says
language needs something new to resolve the problem, even few
engineers saw it and need it.
Click to expand...
To me, that says that there are now at least 3 ways around it. :)

What if the designer using your new keyword makes a mistake.

Jim Lewis did a very good suggestion: add a debugging parameter:
"errels". if error happens, go to error handling in simulation.
Click to expand...
Yes, this would partially solve the problem. Though you'd still get
undefined behavior in the real world.
This is especially true for state machines. It's often not easy to
prove that 2 signals are mutually exclusive and it could happen in a
rare boundary case for which you don't simulate since you don't expect
it in the first place.
If an orif-orelse statement were available in the language, I'd
probably use it to read data and, maybe, for the counter statement
(although that's already a boundary case). But there are easy ways
around it, so it's not really problem.

For state assignments, I'd *always* forbid the usage of these
keywords. It's just too dangerous to assign undefined statements...

Coming back to the training aspect: I have seen many bright engineers
who still make mistakes about where and how to use variables. As a
result, we generally avoid them for registers, even if it would speed
up simulations quite a bit. At least with variables, the synthesizer
will implement do exactly what has been simulated.
This is not the case of orif/orelse: when used by somebody who doesn't
have an in-depth understanding of the problem, you're guaranteed to
run into major trouble. Given the current costs of a silicon respin,
it's just too dangerous.

The orif/orelse andif/andelse keywords are an interesting concept, but
for me the problem it wants to solve isn't serious enough to hate the
language or to warrant adding them to the standard.

Tom Verbeure
 
1. I deeply believe that sooner or later the key words
"orif"/"orels"/"errels" will be introduced into VHDL.
2. I think the task is laid on Jim Lewis shoulder, he is my paper
reviewer, "errels" suggestor and member of VHDL committee. Now he is
fully qualified to do that. I will help him push the movements.
3.
< "The "orif"/"orels"/"errels" keywords are an interesting concept"
I am glad that your attitude changes from "brainless troll" to
"interesting concept".

It is just a tip of iceberg. Its power is far more than what you have
thought.
For example, all 5 methods(yours, my 2, engineer from IBM and Lockheed
Martin) fail when states of state machine are declared in enumerated
type(I never declare states as coded numbers to save time and energy
to elsewhere).
In general, the key words "orif"/"orels"/"errels" provide VHDL users
with very powerful tools to deliver any useful mutually exclusive
information well known to designers to VHDL compilers and it will
"immediately" reduce resource waste and increase final project speed
without big code change(change from "elsif" to "orif" delivers the
information to compiler) .

The following is an example:

If(A1) then // maybe if(A1 or A2 or A3) then
NextState <= state1;
orIf(A2) then // A1 will be excluded in final equation here
NextState <= state2;
orIf(A3) then // A1/A2 will be excluded in final equation here
NextState <= state3;
elsIf(A4) then // maybe elsif(A4 or A5 or A6) then
NextState <= state4;
orif(A5) then // A4 will be excluded in final equation here
NextState <= state5;
orIf(A6) then // A4/A5 will be excluded in final equation here
NextState <= state6;
elsIf(A7) then
NextState <= state7;
orIf(A8) then // A7 will be excluded in final equation here
NextState <= state8;
else
NextState <= state0;
end if;

It tell compilers that there are 3 groups of conditions that are
mutually exclusive:
A1/A2/A3;
A4/A5/A6;
A7/A8;

Further more logic saving can be achieved if you select common factor.
For example:
A1 <= B1 and C1;
A2 <= B1 and C2;
A3 <= B1 and C3;
"if(A1 or A2 or A3) then"
can be replaced by
"if(B1) then"

or
If(A1) then // maybe if(A1 or A2 or A3) then
Data <= Data1;
orif(A2) then // A1 will be excluded in final equation here
Data <= Data2;
orif(A3) then // A1/A2 will be excluded in final equation here
Data <= Data3;
elsif(A4) then // maybe elsif(A4 or A5 or A6) then
Data <= Data4;
orif(A5) then // A4 will be excluded in final equation here
Data <= Data5;
orif(A6) then // A4/A5 will be excluded in final equation here
Data <= Data6;
elsIf(A7) then
Data <= Data7;
orIf(A8) then // A7 will be excluded in final equation here
Data <= Data8;
else
Data <= Data0;
end if;

In another words, the power of 3 keywords is that
with any declaration to compiler that there are mutually exclusive
conditions, you get benefits in both speed and resources!!!

As we know, the most effective expression in VHDL is case statement.
The more case statement you use, the more efficient your design is.
Why? It indicates to compiler that there are mutually exclusive
relations. Case statement has a drawback: the case variable must be a
state machine name or it must have fixed number of bits. Again, why?
The reason is in a state machine, all states are mutually exclusive.
For a fixed number of bits, all different values are mutually
exclusive.
OK, now I would like to tell in real world there are far more
situations where there are mutually exclusive situations than 2 above
cases: not only within one state machine there are mutually exclusive
relations, there are possibilities that mutually exclusive relations
exist among a group of state machines if you can recognize them. In my
paper, I enumerated 11 cases where mutually exclusive relation may
exist. 3 years later I have accumulated more than that.

For example, let us refer to PCI transactions. If a PCI write
transaction is targeting at one of 4 spaces of a device, the 4 write
state machines in 4 different spaces are mutually exclusive: Only one
working state is permitted at any time among the 4 state machines.
This is why I suggest another two key words "machine" and "exclusive"
to declare which state machine is mutually exclusive with others.

Now VHDL standard become bottleneck, the code inefficiency source.
Why? it fails to provide users with a means to declare non-standard
mutually exclusive conditions that are ubiquitous.
 
Hi Weng,

A little question for you,

If you have this code :

if (C1) then
...
elsif (C2) then
...
endif

and if you know that C1 and C2 are mutually exclusive, why don't simply
write ? ;-)

if (C1) then
...
endif

if (C2) then
...
endif

If you reply me by 'if...then...elsif...then...else...endif', I give you
immediatly the solution:

process (...)
variable temp : type;
begin
temp := elsevalue;
if (C1) then
temp := C1value;
end if;
if (C2) then
temp := C2value;
end if;
...
S <= temp;
end process;

That give you the expected result, and you have no more relation between
C1 and C2.

I am agree, you continue to check the value of C1, but I am not sure
that you 'loose' the same among of time that with the 'elsif' structure.
Somewhere this method is equivalent to a case structure, if C1 and C2
have the same 'bit length' structure (i.e. can be express as a bus, and
give one value by condition).

That doesn't invalidate your idea, but you can seen that VHDL have the
possibility to implement this structure, and can give some information
on uncorrelation between signals (for compiler).
I seen one advantage with you notation; during the VHDL origin, people
want make a 'language' with more abstraction (than transistor and
logical gate). Your proposal continue this concept.

JaI

Weng Tianxiang wrote:

1. I deeply believe that sooner or later the key words
"orif"/"orels"/"errels" will be introduced into VHDL.
2. I think the task is laid on Jim Lewis shoulder, he is my paper
reviewer, "errels" suggestor and member of VHDL committee. Now he is
fully qualified to do that. I will help him push the movements.
3.
"The "orif"/"orels"/"errels" keywords are an interesting concept"
I am glad that your attitude changes from "brainless troll" to
"interesting concept".

It is just a tip of iceberg. Its power is far more than what you have
thought.
For example, all 5 methods(yours, my 2, engineer from IBM and Lockheed
Martin) fail when states of state machine are declared in enumerated
type(I never declare states as coded numbers to save time and energy
to elsewhere).
In general, the key words "orif"/"orels"/"errels" provide VHDL users
with very powerful tools to deliver any useful mutually exclusive
information well known to designers to VHDL compilers and it will
"immediately" reduce resource waste and increase final project speed
without big code change(change from "elsif" to "orif" delivers the
information to compiler) .

The following is an example:

If(A1) then // maybe if(A1 or A2 or A3) then
NextState <= state1;
orIf(A2) then // A1 will be excluded in final equation here
NextState <= state2;
orIf(A3) then // A1/A2 will be excluded in final equation here
NextState <= state3;
elsIf(A4) then // maybe elsif(A4 or A5 or A6) then
NextState <= state4;
orif(A5) then // A4 will be excluded in final equation here
NextState <= state5;
orIf(A6) then // A4/A5 will be excluded in final equation here
NextState <= state6;
elsIf(A7) then
NextState <= state7;
orIf(A8) then // A7 will be excluded in final equation here
NextState <= state8;
else
NextState <= state0;
end if;

It tell compilers that there are 3 groups of conditions that are
mutually exclusive:
A1/A2/A3;
A4/A5/A6;
A7/A8;

Further more logic saving can be achieved if you select common factor.
For example:
A1 <= B1 and C1;
A2 <= B1 and C2;
A3 <= B1 and C3;
"if(A1 or A2 or A3) then"
can be replaced by
"if(B1) then"

or
If(A1) then // maybe if(A1 or A2 or A3) then
Data <= Data1;
orif(A2) then // A1 will be excluded in final equation here
Data <= Data2;
orif(A3) then // A1/A2 will be excluded in final equation here
Data <= Data3;
elsif(A4) then // maybe elsif(A4 or A5 or A6) then
Data <= Data4;
orif(A5) then // A4 will be excluded in final equation here
Data <= Data5;
orif(A6) then // A4/A5 will be excluded in final equation here
Data <= Data6;
elsIf(A7) then
Data <= Data7;
orIf(A8) then // A7 will be excluded in final equation here
Data <= Data8;
else
Data <= Data0;
end if;

In another words, the power of 3 keywords is that
with any declaration to compiler that there are mutually exclusive
conditions, you get benefits in both speed and resources!!!

As we know, the most effective expression in VHDL is case statement.
The more case statement you use, the more efficient your design is.
Why? It indicates to compiler that there are mutually exclusive
relations. Case statement has a drawback: the case variable must be a
state machine name or it must have fixed number of bits. Again, why?
The reason is in a state machine, all states are mutually exclusive.
For a fixed number of bits, all different values are mutually
exclusive.
OK, now I would like to tell in real world there are far more
situations where there are mutually exclusive situations than 2 above
cases: not only within one state machine there are mutually exclusive
relations, there are possibilities that mutually exclusive relations
exist among a group of state machines if you can recognize them. In my
paper, I enumerated 11 cases where mutually exclusive relation may
exist. 3 years later I have accumulated more than that.

For example, let us refer to PCI transactions. If a PCI write
transaction is targeting at one of 4 spaces of a device, the 4 write
state machines in 4 different spaces are mutually exclusive: Only one
working state is permitted at any time among the 4 state machines.
This is why I suggest another two key words "machine" and "exclusive"
to declare which state machine is mutually exclusive with others.

Now VHDL standard become bottleneck, the code inefficiency source.
Why? it fails to provide users with a means to declare non-standard
mutually exclusive conditions that are ubiquitous.
Click to expand...
 
Just an Illusion a écrit:

and if you know that C1 and C2 are mutually exclusive, why don't simply
write ? ;-)

if (C1) then
...
endif

if (C2) then
...
endif

If you reply me by 'if...then...elsif...then...else...endif', I give you
immediatly the solution:

process (...)
variable temp : type;
begin
temp := elsevalue;
if (C1) then
temp := C1value;
end if;
if (C2) then
temp := C2value;
end if;
...
S <= temp;
end process;
Click to expand...
I don't see much difference between all these solutions.
Your first example is equivalent to an if ... elsif ... else ... end if;
structure, only you write it with the least priority first.
The second example is exactly the same. The use of a variable doesn't
change anything.
What would happen if CI and C2 were both true? You know it won't happen
but the tools don't so they take the case into account.
--
____ _ __ ___
| _ \_)/ _|/ _ \ Adresse de retour invalide: retirez le -
| | | | | (_| |_| | Invalid return address: remove the -
|_| |_|_|\__|\___/
 
Hi!

Nicolas Matringe wrote:
Just an Illusion a écrit:

and if you know that C1 and C2 are mutually exclusive, why don't
simply write ? ;-)

if (C1) then
...
endif

if (C2) then
...
endif
Click to expand...
Because it will most likely produce a chain of 2:1 muxes.

if ... elsif ... else ... end if, on the other hand, may produce an n:1
mux but with probably more complex control logic.

[...]
What would happen if CI and C2 were both true? You know it won't happen
but the tools don't so they take the case into account.
Click to expand...
The IMHO best solution is a case statement:

-- assuming something like std_logic here...
constant x : some_vector := C1 & C2;

case x is
when "00" =>
temp := elsevalue;
when "10" =>
temp := C1value;
when "01" =>
temp := C2value;
when others => -- don't care
temp := (others => 'X');
end case

It's not exactly the same as the proposed "orif/orels" statements, but
serves the same purpose.

Conclusion: There's no need to put even more bloat into VHDL.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
 
You are right, but I never said they are different.

In my case, if I want be sure that no ambiguity exist for the tools, I
write the logical function.

I am agree too that supplementary logic add some compile time, and
generate some unused code.

But could you explain me how you translate your 'external' exclusive
constraint on silicium ?

JaI

Nicolas Matringe wrote:

Just an Illusion a écrit:

and if you know that C1 and C2 are mutually exclusive, why don't
simply write ? ;-)

if (C1) then
...
endif

if (C2) then
...
endif

If you reply me by 'if...then...elsif...then...else...endif', I give
you immediatly the solution:

process (...)
variable temp : type;
begin
temp := elsevalue;
if (C1) then
temp := C1value;
end if;
if (C2) then
temp := C2value;
end if;
...
S <= temp;
end process;


I don't see much difference between all these solutions.
Your first example is equivalent to an if ... elsif ... else ... end
if; structure, only you write it with the least priority first.
The second example is exactly the same. The use of a variable doesn't
change anything.
What would happen if CI and C2 were both true? You know it won't
happen but the tools don't so they take the case into account.
Click to expand...
 
Just an Illusion a écrit:
But could you explain me how you translate your 'external' exclusive
constraint on silicium ?
Click to expand...
No, and I'm still wondering about it too :eek:)

--
____ _ __ ___
| _ \_)/ _|/ _ \ Adresse de retour invalide: retirez le -
| | | | | (_| |_| | Invalid return address: remove the -
|_| |_|_|\__|\___/
 
process (...)
variable temp : type;
begin
temp := elsevalue;
if (C1) then
temp := C1value;
end if;
if (C2) then
temp := C2value;
end if;
...
S <= temp;
end process;

That give you the expected result, and you have no more relation between
C1 and C2.
Click to expand...
Sorry, but that's not true.

Your examples is equivalent to

if (C2) then
S <= C2value;
elsif (C1) then
S <= C1value;
else
S <= elsevalue;
end if;

You have only reversed the priority.

Tom Verbeure
 
"Weng Tianxiang" <wtx@umem.com> escribió en el mensaje
news:511e4538.0406100904.1449fa93@posting.google.com...
<snip>


This is why I suggest another two key words "machine" and "exclusive"
to declare which state machine is mutually exclusive with others.
Click to expand...
oh please!, how many keywords do you want to add? maybe you could write your
own language and then write the parser you talked about in this thread, and
then you'd be happy?!
in your OP you mentioned:

if(BusAddress = 32-bit-Address1) then
NextState <= stateX1;
elsif(BusAddress = 32-bit-Address2) then
NextState <= stateX2;

elsif(BusAddress = 32-bit-Address3) then
NextState <= stateX3;
end if;

Did you notice that in goto stateX3 statement it contains two other
unnecessary comparisons:
BusAddress = 32-bit-Address1
BusAddress = 32-bit-Address2

It just wastes resources!!!



now, you could use one-hot state machine encoding like:

signal NextState : std_logic_vector(2 downto 0);

and then you assign:

NextState(0) <= '1' when (BusAddress = 32-bit-Address1) else '0';
NextState(1) <= '1' when (BusAddress = 32-bit-Address2) else '0';
NextState(2) <= '1' when (BusAddress = 32-bit-Address3) else '0';

but it still need the comparisons to take place in parallel(and be really
sure that they are exclusive!!), and there's no other way to do it! cause
even if the conditions are mutually exclusive, you still have to check if
they are met! so you need a comparator for EACH condition (or you could
"develop" -like unrolling a loop- the comparisons by writing 3 logic
functions in the form of and-or terms of the input BusAddress and then use
one-hot state machino coding)

instead of hearing your attacks to VHDL and your new keyword proposals, i'd
like to know if you have actually thought thru how this whole "mutual
exclusive" thing could be implemented in real hardware, as it'd be far more
interesting than your "i hate vhdl" thingy...


Now VHDL standard become bottleneck, the code inefficiency source.
Why? it fails to provide users with a means to declare non-standard
mutually exclusive conditions that are ubiquitous.
Click to expand...
 
instead of hearing your attacks to VHDL and your new keyword proposals, i'd
like to know if you have actually thought thru how this whole "mutual
exclusive" thing could be implemented in real hardware, as it'd be far more
interesting
Click to expand...
If you are interested in latest technique of how Xilinx implements
multiplex, go to U.S. Patent and Trademark Office website and the
following is their patent number and title:
6,556,042 FPGA with improved structure for implementing large
multiplexers
6,505,337 Method for implementing large multiplexers with FPGA lookup
tables
6,466,052 Implementing wide multiplexers in an FPGA using a
horizontal chain structure
6,323,682 FPGA architecture with wide function multiplexers
6,191,610 Method for implementing large multiplexers with FPGA lookup
tables
6,144,220 FPGA Architecture using multiplexers that incorporate a
logic gate
....

Reading the latest one is enough for a junior engineer.

They will tells you that
1. Multiplexer is implemented very efficient from hardware level of
FPGA, not mention ASIC;
2. Minimum levels of paths and minimum path delay if multiplexer is
used.

The patents specifies every details you want to know and they want to
protect and the methods are very genius.

Why mutually exclusive conditions are very important is each time a
new mutually exclusive condition is told to VHDL compiler, you
immediately get benefits in term of speed and resources saving without
any logic change.

Do you think it is the better & concise way to express it:

if(A) then
NextState <= State1;
orif(B) then
NextState <= State1;
orif(B) then
NextState <= State1;
end if;

Weng
 
"Weng Tianxiang" <wtx@umem.com> escribió en el mensaje
news:511e4538.0406111621.3ab1f48f@posting.google.com...

<snip>

Why mutually exclusive conditions are very important is each time a
new mutually exclusive condition is told to VHDL compiler, you
immediately get benefits in term of speed and resources saving without
any logic change.
Click to expand...
ok, so you admit that in real hardware there's no logic change?
and that the benefits will only be in simulation time?
and so the simulator, instead of simulating the real behaviour of the
hardware, by simulating all the conditions, it'd simulate only one, and so,
you get an super terrific amazing speedup?!
in anycase, how would you implement the mutual exclusive condition test in
software (the simulator will have to do it)?, please, i just woke up so i
may be forgetting something, but IMHO i still think that you need to perform
all the comparisons to check if they are actually met!, so where would the
speedup be?

Do you think it is the better & concise way to express it:

if(A) then
NextState <= State1;
orif(B) then
NextState <= State1;
orif(B) then
NextState <= State1;
end if;

Weng
Click to expand...
assuming the previous code was correct (cause it isnt, you have two B tests
and always assign the same value...)
how's that better than "elsif"?
 
Hi Wallclimber

Wallclimber wrote:

process (...)
variable temp : type;
begin
temp := elsevalue;
if (C1) then
temp := C1value;
end if;
if (C2) then
temp := C2value;
end if;
...
S <= temp;
end process;

That give you the expected result, and you have no more relation between
C1 and C2.



Sorry, but that's not true.


You are right.
Click to expand...

Your examples is equivalent to

if (C2) then
S <= C2value;
elsif (C1) then
S <= C1value;
else
S <= elsevalue;
end if;

You have only reversed the priority.


But here you are not totally right.
Click to expand...
I haven't only change priority, but the logical equation too.

Tom Verbeure
Click to expand...
 
Hi Wallclimber,

My objective is _not_ to give a circuit that give equation of exclusive
signals based on usage of 'if..then..else' structure; it is impossible.
But show that you can _visually_ help designer to identify them.

The structure 'if..then..else' and his extension 'if..then..elsif..else'
are equivalent to logical equation (read lrm, section 8.7):

A1.B1 + !A1.A2.B2 + !A1.!A2.B3

where :

if (A1) then (B1) elsif (A2) then (B2) else (B3)

If A1 and A2 are mutually exclusive, you can simplify the equation to
A1.B1 + A2.B2 + !A1.!A2.B3

_But_ A1.B1 + A2.B2 + !A1.!A2.B3 <> A1.B1 + !A1.A2.B2 + !A1.!A2.B3,
except if A1 and A2 are mutually exclusive

Conclusion: 'if..then..elseif..else' can modelize the equation A1.B1 +
A2.B2 + !A1.!A2.B3, but it cover more than this.
If you want modelize _exactly_ the equation A1.B1 + A2.B2 + !A1.!A2.B3,
don't use 'elsif' structure. It's not a problem on the vhdl, but a
problem of logic ;-)


JaI

Wallclimber wrote:

process (...)
variable temp : type;
begin
temp := elsevalue;
if (C1) then
temp := C1value;
end if;
if (C2) then
temp := C2value;
end if;
...
S <= temp;
end process;

That give you the expected result, and you have no more relation between
C1 and C2.



Sorry, but that's not true.

Your examples is equivalent to

if (C2) then
S <= C2value;
elsif (C1) then
S <= C1value;
else
S <= elsevalue;
end if;

You have only reversed the priority.

Tom Verbeure
Click to expand...
 
ok, so you admit that in real hardware there's no logic change?
and that the benefits will only be in simulation time?
Click to expand...
Sorry roller, but while I agree that adding these keywords is a bad
idea, it *is* true there are optimization benefits to it. His example
with the addresses comparators is a bad example. For a better one,
look at one of my previous postings.

and so the simulator, instead of simulating the real behaviour of the
hardware, by simulating all the conditions, it'd simulate only one, and so,
you get an super terrific amazing speedup?!
Click to expand...
No, this is not what it's about.


Do you think it is the better & concise way to express it:

if(A) then
NextState <= State1;
orif(B) then
NextState <= State2;
orif(C) then
NextState <= State3;
end if;

Weng

assuming the previous code was correct (cause it isnt, you have two B tests
and always assign the same value...)
how's that better than "elsif"?
Click to expand...
(I changed 'B' to 'C' and '1' to '2' and '3' in the example above.)

When you use elsif, you give the A case a higher priority than the B
case, which has a higher priority than the C case. In term of
hardware, this gives you cascaded multiplexers for each State
assignement. If you guarantee that A, B and C are mutually exclusive,
than you can optimize this to a flat and-or tree. The second solution
is more hardware efficient and had a shorter critical path.

Tom
 
Hi JaI,

Hi Wallclimber,
Click to expand...
You can say 'Tom'. If anybody knows how to change the name associated
with a Google Groups account, let me know! :)

My objective is _not_ to give a circuit that give equation of exclusive
signals based on usage of 'if..then..else' structure; it is impossible.
But show that you can _visually_ help designer to identify them.

The structure 'if..then..else' and his extension 'if..then..elsif..else'
are equivalent to logical equation (read lrm, section 8.7):
Click to expand...
I'm afraid section 8.7 doesn't talk about logic implementation...

A1.B1 + !A1.A2.B2 + !A1.!A2.B3
where :
if (A1) then (B1) elsif (A2) then (B2) else (B3)
Click to expand...
Agreed.

If A1 and A2 are mutually exclusive, you can simplify the equation to
A1.B1 + A2.B2 + !A1.!A2.B3
Click to expand...
Agreed.

_But_ A1.B1 + A2.B2 + !A1.!A2.B3 <> A1.B1 + !A1.A2.B2 + !A1.!A2.B3,
except if A1 and A2 are mutually exclusive

Conclusion: 'if..then..elseif..else' can modelize the equation A1.B1 +
A2.B2 + !A1.!A2.B3, but it cover more than this.
Click to expand...
Hmmm. Highly depends on how you define "... can modelize this ...".
For me, this works both ways. A formal equivalence check between RTL
and gatelevel would flag it as not equivalent. At the end of the day,
that's the only thing that counts.

If you want modelize _exactly_ the equation A1.B1 + A2.B2 + !A1.!A2.B3,
don't use 'elsif' structure.
Click to expand...
Well, you can work around it:

v_C := '0';
if A1 then v_C := C or B1;
elsif A2 then v_C := C or B2;
else v_C := C or B3;
end if;
C <= v_C;

It's not a problem on the vhdl, but a
problem of logic ;-)
Click to expand...
I'm afraid that I'm not really sure what point you wanted to make. :)

Tom
 
Your examples is equivalent to

if (C2) then
S <= C2value;
elsif (C1) then
S <= C1value;
else
S <= elsevalue;
end if;

You have only reversed the priority.


But here you are not totally right.
I haven't only change priority, but the logical equation too.
Click to expand...
How is the logic equation different?

Tom
 
'if..elsif..elseif..endif' generates following equation:
A1.B1 + !A1.A2.B2 + !A1.!A2.A3.B3

If A1, A2 and A3 are mutually exclusive, and my suggestion is used:
'if..ORIF..ORIF..endif'
you will get the equation:
A1.B1 + A2.B2 + A3.B3
Same equation as if a "case" statement were used.

1. You tell compiler to generate statements like "case" statement.
2. More items means long route, longer delay and decreased running
frequency.

The speed-up and resource saving is the FPGA chip final result, not
simulation!
I have never mentioned simulation saving.

When you don't fully understand a situation, you may feel it
"dangerous", "can of worm", "Pandora's box". But when you understand
it, it will makes your chip run faster and with confidence and without
any new simulation burden if and only if VHDL provides a means to do
that!

A CONCLUSION OF MUTUALLY EXCLUSIVE CONDITIONS IS NOT BASED ON THEIR
CONDITION VALUES, BUT ON PHYSICAL CONDITIONS!!!

You are sleeping, you cannot be eating. And you are eating, you cannot
be sleeping;
You are at home, you cannot be at theater, you are at theater, you
cannot be at home;
You are dead, you cannot be alive, you are alive, you cannot be dead;
You are 20 years old, you cannot be 40 years old, you are 40 years
old, you cannot be 20 years old;
A true $20 note cannot be false, a false $20 note cannot be true;

But "You are a son, you cannot be a father, you are a father, you
cannot be a son" is wrong!!! You don't have to do simulations, no, not
a second, to prove if they are mutually exclusive.

So there is no confusion at all and there is never a "rare" "critical"
boundary condition to be tested!!!

If you can provide me with an example, I will tell you where you are
wrong.

Weng
 
"Wallclimber" <hombre@gmail.com> escribió en el mensaje
news:f7896340.0406140720.622402a2@posting.google.com...
ok, so you admit that in real hardware there's no logic change?
and that the benefits will only be in simulation time?

Sorry roller, but while I agree that adding these keywords is a bad
idea, it *is* true there are optimization benefits to it. His example
with the addresses comparators is a bad example. For a better one,
look at one of my previous postings.

and so the simulator, instead of simulating the real behaviour of the
hardware, by simulating all the conditions, it'd simulate only one, and
so,
you get an super terrific amazing speedup?!

No, this is not what it's about.
Click to expand...
well, the OP wasnt clear about it then :)

Do you think it is the better & concise way to express it:

if(A) then
NextState <= State1;
orif(B) then
NextState <= State2;
orif(C) then
NextState <= State3;
end if;

Weng

assuming the previous code was correct (cause it isnt, you have two B
tests
and always assign the same value...)
how's that better than "elsif"?

(I changed 'B' to 'C' and '1' to '2' and '3' in the example above.)

When you use elsif, you give the A case a higher priority than the B
case, which has a higher priority than the C case. In term of
hardware, this gives you cascaded multiplexers for each State
assignement. If you guarantee that A, B and C are mutually exclusive,
than you can optimize this to a flat and-or tree. The second solution
is more hardware efficient and had a shorter critical path.

Tom
Click to expand...
so, it's something like the example i posted, ok then.
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top