I hate VHDL!!!

[roller]

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

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

so, again you admit that it'd be the same than a case statement....as you
previously admitted that there was no logic change while another poster
showed that indeed there was a possible optimization (something like the
solution i gave in the first place)

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

no need to shout...

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.

no need, you didnt answer any of my previous questions on the
first place. And besides, i'll say it again, you ended up admitting that
your new keywords are identical to a "case", and also that there was no
logic
change.
In anycase, I agree with Tom (wallclimber)

> Weng

 

[E. Timothy Uy]

Instead of the USPTO, you could just click here for the abstracts and
links to Espacenet:

http://patents.oncloud8.com/?pns=6,556,042;6,505,337;6,466,052;6,323,682;6,191,610;6,144,220

Tim
patents.oncloud8.com

 

[Weng Tianxiang]

1. What I said is if "orif"/"ofels"/"errels" are adapted as new key
words in VHDL, it can let users use it and "IT WILL GENERATE LOGIC SO
EFFICIENT AND FAST THAT IT IS SIMILAR TO CASE STATEMENT".

Do you know "case" statement is the most efficient and fastest
statement in VHDL?

2. "there was no logic change."
It means the following:
If you write statements:
if(A1) then
NextState <= S1;
elsif(A2) then
NextState <= S2;
elsif(A3) then
NextState <= S2;
end if;

then it can be changed in the following way to add mutually exclusive
conditions:
if(A1) then
NextState <= S1;
orif(A2) then
NextState <= S2;
orif(A3) then
NextState <= S2;
end if;

That's it. "NO OTHER LOGIC CHANGE" and it will give you saving!!!

Weng

 

[Just an Illusion]

Hi Tom ;-),

if (C1) then (E1) elsif (C2) then (E2) else (E3) =>
C1.E1+!C1.C2.E2+!C1.!C2.E3
if (C2) then (E2) elsif (C1) then (E1) else (E3) => C2.E2
+!C2.C1.E1+!C1.!C2.E3

I think that both equation aren't totally equivalent

JaI

Wallclimber wrote:

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.



How is the logic equation different?

Tom

 

[Just an Illusion]

Hi Weng,

Weng Tianxiang wrote:

1. What I said is if "orif"/"ofels"/"errels" are adapted as new key
words in VHDL, it can let users use it and "IT WILL GENERATE LOGIC SO
EFFICIENT AND FAST THAT IT IS SIMILAR TO CASE STATEMENT".

As roller previously said, your don't need to shout (uppercase words are

equivalent to shout in news group).

In summary, you propose to extend usage of 'case' keyword.

If you be able to use a mechanism of bit masking (or 'don't care') for
case with vector condition, you have your expected result.

Do you know "case" statement is the most efficient and fastest
statement in VHDL?

*joke* This is not the combinatory statement : s <=a and b; :0)

2. "there was no logic change."
It means the following:
If you write statements:
if(A1) then
NextState <= S1;
elsif(A2) then
NextState <= S2;
elsif(A3) then
NextState <= S2;
end if;

then it can be changed in the following way to add mutually exclusive
conditions:
if(A1) then
NextState <= S1;
orif(A2) then
NextState <= S2;
orif(A3) then
NextState <= S2;
end if;

That's it. "NO OTHER LOGIC CHANGE" and it will give you saving!!!


The real problem is that some mutually exclusive conditions come from

higher level that your entity/architecture block. If you want really a
reusable block, that is not pre-synthesized, you must let the full chip
synthesis decide how optimize your full design. In lot of case, some
local optimization can hardest the global optimization.

Weng


JaI

 

[Weng Tianxiang]

Sorry roller, but while I agree that adding these keywords is a bad
idea, it *is* true there are optimization benefits to it.

"bad idea?", why? for beginners? I just use 30% of VHDL structures and
never pay attention to what I have never used.

It is not a little benefit. My experiences told me that when I was
failing the final running frequency, either 66MHz for PCI or 133MHz
for PCI-X, the only way that helps me is to try to use more case
statements to reduce number of levels in "if..elsif..elsif..endif"
structure.

"if..elsif..elsif..endif" structure is Fortran language's product. In
software, there is no impact on performance, everything must be
executed in serial order. But in hardware, its essence is concurrent
implementation.

"if..orif..orif..endif" structure provides a similar, but excellent
structure to supplement "if..elsif..elsif..endif" structure: either in
serial implementation area or in concurrent implementation area.

Weng

 

[Just an Illusion]

Hi Weng,

Weng Tianxiang wrote:

...

"if..elsif..elsif..endif" structure is Fortran language's product. In
software, there is no impact on performance, everything must be
executed in serial order.

Do you know that the vhdl origin is ada, not fortran

But in hardware, its essence is concurrent implementation.

I am not agree with you about this point, 'case' is the concurrent

implementation 'spirit'; 'if' defined a policy of priority then you
expected than you found a mux cascade at the end.

"if..orif..orif..endif" structure provides a similar, but excellent
structure to supplement "if..elsif..elsif..endif" structure: either in
serial implementation area or in concurrent implementation area.


An other remark, you haven't any 'serial' implementation area, but

'sequential' ;-)

And neither 'if' nor 'case' can be define into a concurrent statement
area. They are typically sequential statement (must be embedded into a
process statement part, that is a sequential statement). It is not
because process executions are concurrent, than there 'code' is
concurrent too.

Weng


Rgrds,

JaI

 

[Weng Tianxiang]

I would like to show you with real code in my PCI-CORE why it is very
important to introduce "if..orif..endif" keywords into VHDL to clear
any confusions about mutual exclusive conditions.

This is very common equations in PCI core design.
A register of 5-bits at my PCI configuration space address 0x07 is
targeted by PCI host to write new data into it. When PCI bus is 32-bit
width, the write data is in low 32-bit PCI bus, if PCI bus is 64-bit
width, the write data is in high 32-bit PCI bus. There is another
internal clear signal to initialize the register.
if(DIMMNumberClear) then
DIMMNumber(4 downto 0) <= (others=>'0');

elsif(CSRAD_R0_L_DIMMNumber_H and nC_BE_R0(3 downto 0) = "0111") then
if(AD_R0(28) = '1) then
DIMMNumber(4 downto 0) <= "10000";
else
DIMMNumber(4 downto 0) <= AD_R0(28 downto 24);
end if;

elsif(CSRAD_R0_H_DIMMNumber_H and nC_BE_R0(7 downto 4) = "0111") then
if(AD_R0(60) = '1') then
DIMMNumber(4 downto 0) <= "10000";
else
DIMMNumber(4 downto 0) <= AD_R0(60 downto 56);
end if;
end if;

3 levels in the 'if..elsif..endif'.

First level has highest order to clear.

Second and 3rd are mutually exclusive.
Because PCI-bus is either 32-bit width or 64-bit width.
If you choose any other current legal writing to get its performance
benefit, you would destroy the simplicity of above equations, but if
you don't, you have to pay penalty to the priority tree inherited in
'if..elsif..endif'.

If "if..orif..endif" keywords is introduced into VHDL, how nice it
fits into the situations!

if(DIMMNumberClear) then
DIMMNumber(4 downto 0) <= (others=>'0');

elsif(CSRAD_R0_L_DIMMNumber_H and nC_BE_R0(3 downto 0) = "0111") then
if(AD_R0(28) = '1) then
DIMMNumber(4 downto 0) <= "10000";
else
DIMMNumber(4 downto 0) <= AD_R0(28 downto 24);
end if;

orif(CSRAD_R0_H_DIMMNumber_H and nC_BE_R0(7 downto 4) = "0111") then
if(AD_R0(60) = '1') then
DIMMNumber(4 downto 0) <= "10000";
else
DIMMNumber(4 downto 0) <= AD_R0(60 downto 56);
end if;
end if

1. Mutually exclusive case is easy to recognize if you pay attention
to it;
2. No any "critical boundary" exist!
3. No any confusion about simulations!
4. Not danger at all!

Any comments special to the above example are welcome.

Weng

 

[Mike Treseler]

Weng Tianxiang wrote:

I would like to show you with real code in my PCI-CORE why it is very
important to introduce "if..orif..endif" keywords into VHDL to clear
any confusions about mutual exclusive conditions.

Any comments special to the above example are welcome.

see:
http://groups.google.com/groups?q=overlapping+cases+priority+hinze

-- Mike Treseler

 

[roller]

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

I would like to show you with real code in my PCI-CORE why it is very
important to introduce "if..orif..endif" keywords into VHDL to clear
any confusions about mutual exclusive conditions.

right, cause you're the only one who actually need it...

snip

Any comments special to the above example are welcome.

Weng

yes, it's never late to learn...
i cant believe this issue is still being discussed while several solutions
were showed to be feasible...

 

[roller]

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

Sorry roller, but while I agree that adding these keywords is a bad
idea, it *is* true there are optimization benefits to it.

"bad idea?", why? for beginners? I just use 30% of VHDL structures and
never pay attention to what I have never used.

and maybe you should...because "case" didnt seem to fit in your 30%

It is not a little benefit. My experiences told me that when I was
failing the final running frequency, either 66MHz for PCI or 133MHz
for PCI-X, the only way that helps me is to try to use more case
statements to reduce number of levels in "if..elsif..elsif..endif"
structure.

"if..elsif..elsif..endif" structure is Fortran language's product.

man, VHDL comes from ADA...and the need for "if...endif" is to give
priority, whether Fortran, C and every other language uses it or not is not
the issue here.

In software, there is no impact on performance, everything must be
executed in serial order. But in hardware, its essence is concurrent
implementation.

and it was showed that could be achieved without new keywords...

"if..orif..orif..endif" structure provides a similar, but excellent
structure to supplement "if..elsif..elsif..endif" structure: either in
serial implementation area or in concurrent implementation area.

whatever man

> Weng

 

[roller]

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

1. What I said is if "orif"/"ofels"/"errels" are adapted as new key
words in VHDL, it can let users use it and "IT WILL GENERATE LOGIC SO
EFFICIENT AND FAST THAT IT IS SIMILAR TO CASE STATEMENT".

Do you know "case" statement is the most efficient and fastest
statement in VHDL?

2. "there was no logic change."
It means the following:
If you write statements:
if(A1) then
NextState <= S1;
elsif(A2) then
NextState <= S2;
elsif(A3) then
NextState <= S2;
end if;

then it can be changed in the following way to add mutually exclusive
conditions:
if(A1) then
NextState <= S1;
orif(A2) then
NextState <= S2;
orif(A3) then
NextState <= S2;
end if;

That's it. "NO OTHER LOGIC CHANGE" and it will give you saving!!!

Weng

whatever you say dude

 

[Just an Illusion]

Hi Weng,

I am definitively not a pci designer expert but I have a question for
you: could you change dynamically the size of the pci bus ?

Otherwise I think that you can parametrize some part of the design below.

if (DIMMNumberClear) then
DIMMNumber(4 downto 0) <= (others=>'0');
elsif (update_condition) then
if (AD_R0(28+n*32) = '1') then
DIMMNumber (4 downto 0) <= "10000";
else
DIMMNumber (4 downto 0) <= AD_R0(28+n*32 downto 24+n*32);
endif;
endif;

Now you need only something to calculate value of 'n' and the
'update_condition'

As you can read, you don't need any more some exclusive keyword, because
in equations it is clearly not possible to have 'n' with simultaneous
different values.

Bye,
JaI

Weng Tianxiang wrote:

I would like to show you with real code in my PCI-CORE why it is very
important to introduce "if..orif..endif" keywords into VHDL to clear
any confusions about mutual exclusive conditions.

This is very common equations in PCI core design.
A register of 5-bits at my PCI configuration space address 0x07 is
targeted by PCI host to write new data into it. When PCI bus is 32-bit
width, the write data is in low 32-bit PCI bus, if PCI bus is 64-bit
width, the write data is in high 32-bit PCI bus. There is another
internal clear signal to initialize the register.
if(DIMMNumberClear) then
DIMMNumber(4 downto 0) <= (others=>'0');

elsif(CSRAD_R0_L_DIMMNumber_H and nC_BE_R0(3 downto 0) = "0111") then
if(AD_R0(28) = '1) then
DIMMNumber(4 downto 0) <= "10000";
else
DIMMNumber(4 downto 0) <= AD_R0(28 downto 24);
end if;

elsif(CSRAD_R0_H_DIMMNumber_H and nC_BE_R0(7 downto 4) = "0111") then
if(AD_R0(60) = '1') then
DIMMNumber(4 downto 0) <= "10000";
else
DIMMNumber(4 downto 0) <= AD_R0(60 downto 56);
end if;
end if;

3 levels in the 'if..elsif..endif'.

First level has highest order to clear.

Second and 3rd are mutually exclusive.
Because PCI-bus is either 32-bit width or 64-bit width.
If you choose any other current legal writing to get its performance
benefit, you would destroy the simplicity of above equations, but if
you don't, you have to pay penalty to the priority tree inherited in
'if..elsif..endif'.

If "if..orif..endif" keywords is introduced into VHDL, how nice it
fits into the situations!

if(DIMMNumberClear) then
DIMMNumber(4 downto 0) <= (others=>'0');

elsif(CSRAD_R0_L_DIMMNumber_H and nC_BE_R0(3 downto 0) = "0111") then
if(AD_R0(28) = '1) then
DIMMNumber(4 downto 0) <= "10000";
else
DIMMNumber(4 downto 0) <= AD_R0(28 downto 24);
end if;

orif(CSRAD_R0_H_DIMMNumber_H and nC_BE_R0(7 downto 4) = "0111") then
if(AD_R0(60) = '1') then
DIMMNumber(4 downto 0) <= "10000";
else
DIMMNumber(4 downto 0) <= AD_R0(60 downto 56);
end if;
end if

1. Mutually exclusive case is easy to recognize if you pay attention
to it;
2. No any "critical boundary" exist!
3. No any confusion about simulations!
4. Not danger at all!

Any comments special to the above example are welcome.

Weng

 

[Uncle Noah]

"roller" <trash_nospam@hotmail.com> wrote in message news:<cb1g6q$24ho$1@avanie.enst.fr>...

"Weng Tianxiang" <wtx@umem.com> escribió en el mensaje
news:511e4538.0406181434.3f57396f@posting.google.com...
I would like to show you with real code in my PCI-CORE why it is very
important to introduce "if..orif..endif" keywords into VHDL to clear
any confusions about mutual exclusive conditions.

Weng...

OK, we got the point... you certainly are unaware of VHDL.
So WHY don't you code your PCI component in Verilog? And leave us in peace?
You are obviously a Verilog-berserk.

It is sad yet very offensive, that so many people are arguing over such tiny issue.

To my experience, in almost ALL occasions, languages suffice, people don't...

regards

Uncle Noah a.k.a. "The G.B. Man"
P.S.: Many useful people shouldn't get wasted in this thread...

 

[Just an Illusion]

Hi Weng,

This morning I have just realized that perhaps you have a bad analyze
your true problem.

In your example, you said that condition 2 and 3 are mutually exclusive,
but that not fully true.

Let me rewrite your code with more symbolic notation:

if (Cond_1) then
DIMMNumber (4 downto 0) <= (others => '0');

elsif (Cond_2) then
if(AD_R0(28) = '1) then
DIMMNumber(4 downto 0) <= "10000";
else
DIMMNumber(4 downto 0) <= AD_R0(28 downto 24);
end if;

elsif (Cond_3) then
if(AD_R0(60) = '1) then
DIMMNumber(4 downto 0) <= "10000";
else
DIMMNumber(4 downto 0) <= AD_R0(60 downto 58);
end if;

end if;

What this structure must give you in synthesis ?
-> a 5-bit register with 3 asynchronous load conditions (Cond_1, Cond_2
and Cond_3)

Why a register ? because you haven't define all cases.

You said: Cond_2 implicate !Cond_3, and Cond_3 implicate !Cond_2, but
you can have !Cond_3 and !Cond_2.
To be really mutually exclusive (xor logique function), you must have at
least Cond_2 or Cond_3.

That is not what you have modelized (with or without your orif
structure). Your 'orif' function is equivalent to logic implication (A
-> B), which are equivalent to logical function !A+B (not A or B).

Try to write your control part like this, and perhaps that can solve
your situation.

JaI


Weng Tianxiang wrote:

I would like to show you with real code in my PCI-CORE why it is very
important to introduce "if..orif..endif" keywords into VHDL to clear
any confusions about mutual exclusive conditions.

This is very common equations in PCI core design.
A register of 5-bits at my PCI configuration space address 0x07 is
targeted by PCI host to write new data into it. When PCI bus is 32-bit
width, the write data is in low 32-bit PCI bus, if PCI bus is 64-bit
width, the write data is in high 32-bit PCI bus. There is another
internal clear signal to initialize the register.
if(DIMMNumberClear) then
DIMMNumber(4 downto 0) <= (others=>'0');

elsif(CSRAD_R0_L_DIMMNumber_H and nC_BE_R0(3 downto 0) = "0111") then
if(AD_R0(28) = '1) then
DIMMNumber(4 downto 0) <= "10000";
else
DIMMNumber(4 downto 0) <= AD_R0(28 downto 24);
end if;

elsif(CSRAD_R0_H_DIMMNumber_H and nC_BE_R0(7 downto 4) = "0111") then
if(AD_R0(60) = '1') then
DIMMNumber(4 downto 0) <= "10000";
else
DIMMNumber(4 downto 0) <= AD_R0(60 downto 56);
end if;
end if;

3 levels in the 'if..elsif..endif'.

First level has highest order to clear.

Second and 3rd are mutually exclusive.
Because PCI-bus is either 32-bit width or 64-bit width.
If you choose any other current legal writing to get its performance
benefit, you would destroy the simplicity of above equations, but if
you don't, you have to pay penalty to the priority tree inherited in
'if..elsif..endif'.

If "if..orif..endif" keywords is introduced into VHDL, how nice it
fits into the situations!

if(DIMMNumberClear) then
DIMMNumber(4 downto 0) <= (others=>'0');

elsif(CSRAD_R0_L_DIMMNumber_H and nC_BE_R0(3 downto 0) = "0111") then
if(AD_R0(28) = '1) then
DIMMNumber(4 downto 0) <= "10000";
else
DIMMNumber(4 downto 0) <= AD_R0(28 downto 24);
end if;

orif(CSRAD_R0_H_DIMMNumber_H and nC_BE_R0(7 downto 4) = "0111") then
if(AD_R0(60) = '1') then
DIMMNumber(4 downto 0) <= "10000";
else
DIMMNumber(4 downto 0) <= AD_R0(60 downto 56);
end if;
end if

1. Mutually exclusive case is easy to recognize if you pay attention
to it;
2. No any "critical boundary" exist!
3. No any confusion about simulations!
4. Not danger at all!

Any comments special to the above example are welcome.

Weng

 

[Jim Lewis]

Weng,
Ironic, I go on vacation and the rant goes on and on
and on. I wanted to comment on a couple of things.

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.

Upon two years of reflection, I think there is a more consise
way to express what you want without the down side and
perhaps gain even more flexability:

assert onehot(A1, A2, A3) report "failed" severity failure ;
assert onehot(A4, A5, A6) report "failed" severity failure ;
assert onehot(A7, A8) report "failed" severity failure ;

-- New condition
assert onehot(A1, A7) report "failed" severity failure ;

process( ...)
begin
....
If(A1) then
NextState <= state1;
elsIf(A2) then
NextState <= state2;
....
elsIf(A8) then
NextState <= state8;
else
NextState <= state0;
end if;
....
end process ;

I like this as it is easy to express the error conditions.
Synthesizing assertions is a task for 1076.6 and would not
require any language change.

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.

Your suggestion of adding keywords needed to be
mulled over. At the end of the day, it was determined
not to be the best answer - too much complexity,
too much chance for error, and there is a better
method (illustrated above).

It would be really helpful if you would desist from
being so insulting. While I don't agree with brainless
troll, you are definitely acting like a troll.

if(DIMMNumberClear) then
DIMMNumber(4 downto 0) <= (others=>'0');

elsif(CSRAD_R0_L_DIMMNumber_H and nC_BE_R0(3 downto 0) = "0111") then
if(AD_R0(28) = '1) then
DIMMNumber(4 downto 0) <= "10000";
else
DIMMNumber(4 downto 0) <= AD_R0(28 downto 24);
end if;

orif(CSRAD_R0_H_DIMMNumber_H and nC_BE_R0(7 downto 4) = "0111") then
if(AD_R0(60) = '1') then
DIMMNumber(4 downto 0) <= "10000";
else
DIMMNumber(4 downto 0) <= AD_R0(60 downto 56);
end if;
end if;

I am not sure an algorithm can extract what is mutually exclusive
above. Perhaps you ment:

assert onehot(CSRAD_R0_L_DIMMNumber_H, CSRAD_R0_H_DIMMNumber_H) ... ;

Note your code also includes fields of nC_BE_RO.



Regards,
Jim
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training mailto:Jim@SynthWorks.com
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787

Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 

[Jim Lewis]

Weng,

In the last example, you have to declare every equation in 'if'
condition as a signal,
Yes.

You realize that your expression had an error right?
Show me a correct example that has mutual exclusion
and uses an equation.

and then to add assert onehot() statements at the file beginning.
I was using assert as a concurrent statement, so it can go anywhere

in the concurrent code region of the architecture.

Do you really think 'assert' is better than 'orif'?
Yes. Read on.

'if..elsif..endif' is the most beautiful and commonly used expression.
I agree.

'if..orif..endif' does the same things as beautiful and
concise as 'if..elsif..endif'.
Lets see. Here is a simple example:

Ex1 : process
begin
wait until Clk='1' ;
if ASel = '1' then
Y <= A ;
orif BSel = '1' then
Y <= B ;
orif CSel = '1' then
Y <= C ;
orif DSel = '1' then
Y <= D;

-- covers error conditions. eg: ASel = 1 and BSel = 1
errels
report "error" ;
Y <= '-' ; --

-- covers all other conditions and not required
-- else
-- Y <= Y ;
end if ;
end process ;


The following is more expressive than above. In this
example I don't think either is more concise than the
other.

assert onehot(ASel & BSel & CSel & DSel) ... ;

Ex2 : process
begin
wait until Clk='1' ;
if ASel = '1' then
Y <= A ;
elsif BSel = '1' then
Y <= B ;
elsif CSel = '1' then
Y <= C ;
elsif DSel = '1' then
Y <= D;
end if ;
end process ;

'Dangerous' is a word what belongs to a novice designer. Your statements:
assert onehot(A1, A2, A3) report "failed" severity failure ;
has the same level of 'danger' as 'orif' if there were a 'danger'.
I really don't know how the level of 'danger' is reduced by using
'assert' statement!
Which one do you think is more readable? With orif you really

need to pay attention to orif vs. elsif. With assert onehot,
look at the signals in the expression.

I think your mistake below clearly illustrates another
danger of orif. See the statemachine example for another.
With assert onehot, you easily see exactly what you are
getting.

Perhaps you meant:
assert onehot(CSRAD_R0_L_DIMMNumber_H, CSRAD_R0_H_DIMMNumber_H) ... ;

You are right.


Note your code also includes fields of nC_BE_RO.

('AND' nC_BE_RO) has no any effect on the mutually exclusive relations of above two conditions.

Your orif statement says one equation is mutually
exclusive from the other. Since you are using different
fields of nC_BE_RO, it will be considered by the synthesis
tool as being part of the mutually exclusion. Hence,
I am not convinced you will realize any hardware savings in
your example.

'if..orif..endif' has the same effect that 'assert' method cannot have.
Likewise assert has capability that if..orif..endif cannot express.

General claims of validity do nothing, show me a relevant example.

assert has another problem: when two state machines are mutually
exclusive, do you have a means to declare they are mutually
exclusive?
First it is states that are mutually exclusive not the entire

statemachine itself.

assert onehot(SM1=READ_STATE, SM2=WRITE_STATE) ... ;

If you have a sizable amount of logic, how many times are
you going to express mutual exclusion with orif? Perhaps
you should work through the logic in your statemachine
example.

Lets suppose you have specified a particular multiple
times due to different branches in a statemachine.
What happens if you have specified two conditions to
be mutually exclusive in one branch with orif, but
accidentally use elsif in another branch?
How will you detect your error? You will need a good
lint tool.

To really understand what is needed one must look at the details.
If you only consider code snippets, you will end up with a
less desirable implementation.

Your questions are convincing me even more that assert onehot
is the better solution.

You are the only person so far I have met who recognized the problem.
I don't think this is the case. I noted several who

agree there is a problem, but disagree with your solution.
Others tune out due to your approach. Starting a question
by insulting people (standards groups) generally causes
them to ignore you.

Regards,
Jim
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training mailto:Jim@SynthWorks.com
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787

Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 

[Weng Tianxiang]

Jim,

You realize that your expression had an error right?

Now let us first resolve this problem: Your claim is wrong.

My situation is:
CSRAD_R0_L_DIMMNumber_H and CSRAD_R0_H_DIMMNumber_H are mutually
exclusive derived from their physical conditions: 32-bit width PCI bus
and 64-bit width PCI bus(it cannot be modified as Just ... wrongly
indicated), so
1. (CSRAD_R0_L_DIMMNumber_H and (..))
2. (CSRAD_R0_H_DIMMNumber_H and (..))
are mutually exclusive.

The following is an excerpt from my paper:
Rule 4: Signals are mutually exclusive if their time marks are
mutually exclusive.
Example:
SignalA <= (AState = A1_S and (…)) (2)
or (AState = A2_S and (…));
SignalB <= (AState = A3_S and (…)) (3)
or (AState = A4_S and (…));
SignalA and SignalB are mutually exclusive, no matter how complex the
logic in (…) is.

Its extension is:
if two signals are mutually exclusive based on whatever reasons, the
derivative signals: A1, B1 are mutually exclusive:
A1 <= A and (..);
B1 <= B and (..);

That is what my equation says. (if..orif..endif).

Jim, if you recognized your wrong claim, I can go with your next
question.

Weng

 

[Jim Lewis]

Weng,
See below.

You realize that your expression had an error right?

Now let us first resolve this problem: Your claim is wrong.

My situation is:
CSRAD_R0_L_DIMMNumber_H and CSRAD_R0_H_DIMMNumber_H are mutually
exclusive derived from their physical conditions: 32-bit width PCI bus
and 64-bit width PCI bus(it cannot be modified as Just ... wrongly
indicated), so
1. (CSRAD_R0_L_DIMMNumber_H and (..))
2. (CSRAD_R0_H_DIMMNumber_H and (..))
are mutually exclusive.

Your full code is shown below. I agree that the entire
expression in 1 is mutually exclusive from the entire
expression in 2, however, this is all that can be
concluded from the orif in the code below.

To be fair, this is the code you showed:

if(DIMMNumberClear) then
DIMMNumber(4 downto 0) <= (others=>'0');

elsif(CSRAD_R0_L_DIMMNumber_H and nC_BE_R0(3 downto 0) = "0111") then
if(AD_R0(28) = '1) then
DIMMNumber(4 downto 0) <= "10000";
else
DIMMNumber(4 downto 0) <= AD_R0(28 downto 24);
end if;

orif(CSRAD_R0_H_DIMMNumber_H and nC_BE_R0(7 downto 4) = "0111") then
if(AD_R0(60) = '1') then
DIMMNumber(4 downto 0) <= "10000";
else
DIMMNumber(4 downto 0) <= AD_R0(60 downto 56);
end if;
end if;

If there is additional logic in this logic
block (entity/architecture) that independently
shows that CSRAD_R0_L_DIMMNumber_H is mutually exclusive
from CSRAD_R0_L_DIMMNumber_H, then you probably don't
need the orif statement. If there is additional
logic this is the first you have mentioned it in your
argument.

The following is an excerpt from my paper:
Rule 4: Signals are mutually exclusive if their time marks are
mutually exclusive.
Example:
SignalA <= (AState = A1_S and (…)) (2)
or (AState = A2_S and (…));
SignalB <= (AState = A3_S and (…)) (3)
or (AState = A4_S and (…));
SignalA and SignalB are mutually exclusive, no matter how complex the
logic in (…) is.

I agree with this. It is possible that a synthesis tool
could derive that these two signals are mutually exclusive.
I don't know if they currently do this. I would
not want to have to specify that this is onehot. I would not
be surprised if I had to. I expect to have to use onehot
when signals come from another block or some condition
exists that is not easy to derive.

Its extension is:
if two signals are mutually exclusive based on whatever reasons, the
derivative signals: A1, B1 are mutually exclusive:
A1 <= A and (..);
B1 <= B and (..);

That is what my equation says. (if..orif..endif).

What does orif say? It says that the one entire expression
is mutually exclusive from the other. Hence it says that
A1 is mutually exclusive form B1. You cannot conclude that
A and B are mutually exclusive.

On the other hand, if rather than orif you use:
assert onehot (A, B) ... ;

Then you are saying that A and B are mutually exclusive and
you can deduce/derive that A1 and B1 are also mutually
exclusive.

Again any additional logic that you have not shown or explained
previously will change the validity of my claim, however,
please note, I only have a limited amount of ESP.

The only thing your current examples have done is
convince me that assert onehot is a better solution
than orif. Do you have anything else?

Cheers,
Jim

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training mailto:Jim@SynthWorks.com
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787

Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 

[Just an Illusion]

Hi Weng

Weng Tianxiang wrote:

Jim,


You realize that your expression had an error right?



Now let us first resolve this problem: Your claim is wrong.

My situation is:
CSRAD_R0_L_DIMMNumber_H and CSRAD_R0_H_DIMMNumber_H are mutually
exclusive derived from their physical conditions: 32-bit width PCI bus
and 64-bit width PCI bus(it cannot be modified as Just ... wrongly
indicated), so
1. (CSRAD_R0_L_DIMMNumber_H and (..))
2. (CSRAD_R0_H_DIMMNumber_H and (..))
are mutually exclusive.


Question for you: You said that your 2 above conditions are mutually

because CSRAD_R0_L_DIMMNumber_H and CSRAD_R0_H_DIMMNumber_H are mutually
exclusive, right ?

If I take the following example:
A1 <= A and B;
A2 <= C and B;

with A and C mutually exclusive. How could you pretend that A1 and A2
are mutually exclusive ?
Mutual exclusive is these both signals are never equal. It is express in
logic by the xor function (exclusive or).

I supposed that Just... is me, you can short my alias by JaI (as my
signature) ;-)

I *never* said that you must modified your code with my way. It is only
a proposal, based on fact that you have some part of your code which is
equivalent, except that you have an offset in one case and not in the
other one.

With this new information about CSRAD_R0_L_DIMMNumber_H and
CSRAD_R0_H_DIMMNumber_H mutual exclusive.
Why don't write your example with case:


if(DIMMNumberClear) then
DIMMNumber(4 downto 0) <= (others=>'0');

else
case PCI_TYPE is
when CSRAD_R0_L_DIMMNumber_H =>
if (nC_BE_R0(3 downto 0) = "0111") then
if(AD_R0(28) = '1) then
DIMMNumber(4 downto 0) <= "10000";
else
DIMMNumber(4 downto 0) <= AD_R0(28 downto 24);
end if;
end if;
when CSRAD_R0_H_DIMMNumber_H =>
if (nC_BE_R0(7 downto 4) = "0111") then
if(AD_R0(60) = '1') then
DIMMNumber(4 downto 0) <= "10000";
else
DIMMNumber(4 downto 0) <= AD_R0(60 downto 56);
end if;
end if;
when others => null;
end case;
end if;

In that case, CSRAD_R0_L_DIMMNumber_H and CSRAD_R0_H_DIMMNumber_H are
clearly exclusive.

If I rewrite my proposal, you can have something as:

type PCI_TYPE is (BAD_TYPE,PCI_32, PCI_64);

signal my_pci_type : PCI_TYPE;
signal bad_pci_type : std_logic;
signal n : integer;
....

-- I have convert CSRAD_R0_L_DIMMNumber_H and CSRAD_R0_H_DIMMNumber_H
-- according to 1076.3-1997.

process (CSRAD_R0_L_DIMMNumber_H, CSRAD_R0_H_DIMMNumber_H)
variable tmp_type : std_logic_vector (1 downto 0);
begin
tmp_type := CSRAD_R0_L_DIMMNumber_H & CSRAD_R0_H_DIMMNumber_H;

case tmp_type is
when "10" => my_pci_type <= PCI_32;
when "01" => my_pci_type <= PCI_64;
when others => my_pci_type <= BAD_TYPE;
end process;

process (my_pci_type)
begin
case my_pci_type is
when PCI_32 =>
n <= 0;
bad_pci_type <= '0';
when PCI_64 =>
n <=1;
bad_pci_type <= '0';
when others =>
n <=0;
bad_pci_type <= '1';
end case;
end process;

process (DIMMNumberClear, nC_BE_R0, n, bad_pci_type)
begin
if (DIMMNumberClear) then
DIMMNumber(4 downto 0) <= (others=>'0');
elsif (bad_pci_type = '0') then
if (AD_R0(28+n*32) = '1') then
DIMMNumber (4 downto 0) <= "10000";
else
DIMMNumber (4 downto 0) <= AD_R0(28+n*32 downto 24+n*32);
endif;
endif;
end process;

snip
Weng


JaI