if and case cannot be considered equal

[Amit]

hi group,

is it possible to use CASE STATEMENT for such a condition as:


if (X > 10) then
z <= z1;
elsif (x < 10) then
z <= z2;
else
z <= z3;
end if;

as far as I know we cannot do :

case x is
when > 10 =>
z <= z1;
and ...


any idea?


cheers.

 

[KJ]

hi group,

is it possible to use CASE STATEMENT for such a condition as:


if (X > 10) then
z <= z1;
elsif (x < 10) then
z <= z2;
else
z <= z3;
end if;

as far as I know we cannot do :

case x is
when > 10 =>
z <= z1;
and ...


any idea?

process(...)
function Classify(V: integer) return boolean is
begin
if (V > 10) then
return TRUE;
else
return FALSE;
end if;
end function Classify;
variable Testit: boolean
begin
Testit := Classify(x);
case Testit is
when TRUE => ...
when FALSE => ...
end case;

If you have other conditions you want as well (i.e. x> 20, x = 314, etc.)
then instead of using a variable and function that returns a boolean you can
use either an enumerated type or an integer where the different values
returned from the function would define the different classifications of
'x'.

Kevin Jennings

 

[kennheinrich]

process(...)
function Classify(V: integer) return boolean is
begin
if (V > 10) then
return TRUE;
else
return FALSE;
end if;
end function Classify;
variable Testit: boolean
begin
Testit := Classify(x);
case Testit is
when TRUE => ...
when FALSE => ...
end case;

If you have other conditions you want as well (i.e. x> 20, x = 314, etc.)
then instead of using a variable and function that returns a boolean you can
use either an enumerated type or an integer where the different values
returned from the function would define the different classifications of
'x'.

Kevin Jennings

Agreed, this has the intended benefit of making the choice of the
condition directly linked to the predicate (x>10). However, it breaks
the textual readability: if I renamed "Classify" to "GreaterThanSix" I
could really mess you up If I renamed "Classify" to
"TestAgainst10" it would be readable, but what if I changed the test
condition to (x>7)?

The case statement choice will also accept a discrete range. For this
particular predicate (a simple cut in the linear order), you could try

case x is
when 11 to integer'high =>
z <= z1;
when integer'low to 9 =>
z <= z2;
when others =>
z <= z3;
end case;

It's still not as readable, but it might be an acceptable compromise.

- Kenn

 

[Andy]

Agreed, this has the intended benefit of making the choice of the
condition directly linked to the predicate (x>10). However, it breaks
the textual readability: if I renamed "Classify" to "GreaterThanSix" I
could really mess you up If I renamed "Classify" to
"TestAgainst10" it would be readable, but what if I changed the test
condition to (x>7)?

The case statement choice will also accept a discrete range. For this
particular predicate (a simple cut in the linear order), you could try

case x is
  when 11 to integer'high =>
    z <= z1;
  when integer'low to 9 =>
    z <= z2;
  when others =>
    z <= z3;
end case;

It's still not as readable, but it might be an acceptable compromise.

 - Kenn

Be sure to use the appropriate subtype of X; I doubt it is the full
integer range.

i.e. "x_type'high"

Andy

 

[Andy]

If you use both Verilog and mind-altering
substances...

Isn't that sort of redundant? ;^)

Sorry, just couldn't let that one go without a jab!

Andy

 

[Andy]

hi group,

is it possible to use CASE STATEMENT for such a condition as:

if (X > 10) then
   z <= z1;
elsif (x < 10) then
   z <= z2;
else
   z <= z3;
end if;

as far as I know we cannot do :

case x is
   when > 10 =>
        z <= z1;
and ...

any idea?

cheers.

I'm curious about the subject line: They are BY DEFINITION not equal.
'If' statements may have completely independent conditions, whereas a
vhdl case statement must have an exhaustive list of and mutually
exclusive conditions, verifiable by the compiler. There are short-hand
notations for the list(s), as has been shown.

Andy

 

[KJ]

Agreed, this has the intended benefit of making the choice of the
condition directly linked to the predicate (x>10). However, it breaks
the textual readability: if I renamed "Classify" to "GreaterThanSix" I
could really mess you up

OK, but if I got rid of all carriage returns in your source code it
could really mess YOU up too

If I renamed "Classify" to
"TestAgainst10" it would be readable, but what if I changed the test
condition to (x>7)?

But that's why I called the function 'Classify' since you're taking
some input and putting it into one of several different buckets or
classifications. Looking again at the OP though, I really needed
three buckets not two so using 'boolean' as a proxy wasn't a good
choice, should've just used integer range 0 to 2 (or more likely a
previously defined subtype).

In any case, the readability measure is likely directly related to
whether the reader chooses to see the various comparisons as a
classification of the input 'x' or not.

The case statement choice will also accept a discrete range. For this
particular predicate (a simple cut in the linear order), you could try

case x is
  when 11 to integer'high =>
    z <= z1;
  when integer'low to 9 =>
    z <= z2;
  when others =>
    z <= z3;
end case;

Good point and an often forgotten one.

It's still not as readable, but it might be an acceptable compromise.

In the more general case it might not end up being as readable but for
the specific case posted the use of ranges as you've done is certainly
no compromise...and less coding to boot.

Kevin Jennings

 

[kennheinrich]

OK, but if I got rid of all carriage returns in your source code it
could really mess YOU up too

LMAO!


But that's why I called the function 'Classify' since you're taking
some input and putting it into one of several different buckets or
classifications.  Looking again at the OP though, I really needed
three buckets not two so using 'boolean' as a proxy wasn't a good
choice, should've just used integer range 0 to 2 (or more likely a
previously defined subtype).

Agreed. In some languages (I'm thinking SML might be one), part of the
predefined standard library code is a structure with an enum defined
exactly for this kind of comparison application: (LESS, EQ, GREATER).
Whereas general "C" usage would use (<0, 0, and >0) in the comparison
function that enables, say, quicksort. But again, this is going well
above the typical use case of your vanilla VHDL code grunt. We're just
apple-polishing at this point ;-)

In any case, the readability measure is likely directly related to
whether the reader chooses to see the various comparisons as a
classification of the input 'x' or not.



Good point and an often forgotten one.


In the more general case it might not end up being as readable but for
the specific case posted the use of ranges as you've done is certainly
no compromise...and less coding to boot.

The reality is that one man's elegant and maintainable code is another
man's nightmare, because he just can't see the world in the same way
as the first man did. I think that's exactly why I was less fond of
"Classify": just because I didn't see the problem in the same way as
you did. Now that I think about it I a little more, I can see why it
makes good sense, too.

Readability is unfortunately somewhat subjective. But I think most of
the "good guys" can tell the dross from the good code anyway.

- Kenn