if and case cannot be considered equal

A

Amit

Guest
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.
 
On Wed, 1 Oct 2008 13:43:25 -0700 (PDT), Amit wrote:

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;
Not in VHDL, no.

If you use both Verilog and mind-altering
substances, you may be happy with this:

case (1'b1)
x > 10 : z <= z1;
x < 10 : z <= z2;
default: z <= z3;
endcase

--
Jonathan Bromley, Consultant

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

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
 
"Amit" <amit.kohan@gmail.com> wrote in message
news:29b62607-3d27-4092-afe5-74c57c3a93de@64g2000hsu.googlegroups.com...
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
 
On Oct 1, 8:32 pm, "KJ" <kkjenni...@sbcglobal.net> wrote:
"Amit" <amit.ko...@gmail.com> wrote in message

news:29b62607-3d27-4092-afe5-74c57c3a93de@64g2000hsu.googlegroups.com...



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
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
 
On Oct 1, 9:01 pm, kennheinr...@sympatico.ca wrote:
On Oct 1, 8:32 pm, "KJ" <kkjenni...@sbcglobal.net> wrote:



"Amit" <amit.ko...@gmail.com> wrote in message

news:29b62607-3d27-4092-afe5-74c57c3a93de@64g2000hsu.googlegroups.com...

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

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
 
On Oct 1, 4:59 pm, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:
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
 
On Oct 1, 3:43 pm, Amit <amit.ko...@gmail.com> wrote:
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
 
On Oct 1, 10:01 pm, kennheinr...@sympatico.ca wrote:
On Oct 1, 8:32 pm, "KJ" <kkjenni...@sbcglobal.net> wrote:

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
 
On Oct 2, 10:27 am, KJ <kkjenni...@sbcglobal.net> wrote:
On Oct 1, 10:01 pm, kennheinr...@sympatico.ca wrote:

On Oct 1, 8:32 pm, "KJ" <kkjenni...@sbcglobal.net> wrote:

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 ;)
LMAO!

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

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

Welcome to EDABoard.com

Sponsor

Back
Top