RE: [sv-bc] types for "inside" operands

Gord,

I intended something like this --

Because

    (1'b1 + 1'b1) > 2'b01

then

    ! (1'b1 inside {[(1'b1 + 1'b1) : 2'b01]})

even though

    1'b1 == 2'b01

This follows from "If the bound to the left of the colon is greater than
the bound to the right, the range is empty and contains no values."

-- Brad

-----Original Message-----
From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Brad
Pierce
Sent: Wednesday, January 30, 2008 8:16 AM
To: SV_EC List; SV_BC List
Subject: RE: [sv-bc] types for "inside" operands

Gord,

Also, as I wrote in 

     http://www.eda-stds.org/svdb/view.php?id=1805

because in Verilog the following comparisons are true 

          -3 > 3'b100 
          (1'b1 + 1'b1) > 2'b01 * {1'b1 + 1'b1} 

either of the following value ranges, considered as one of the items in
the right operand of an inside operator, would be empty and contain no
values -- 

          [ -3 : 3'b100 ] 
          [ 1'b1 + 1'b1 : 2'b01 * {1'b1 + 1'b1} ] 

-- Brad

-----Original Message-----
From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of
Gordon Vreugdenhil
Sent: Wednesday, January 30, 2008 7:54 AM
To: SV_EC List; SV_BC List
Subject: [sv-bc] types for "inside" operands


Earlier discussions regarding the semantics for "inside" with respect to
reals implies that typing of expressions in an "inside" is similar to a
complex conditional.  So, for example, consider the following:
     reg signed [3:0] r = 1;
     reg [3:0] r2;
     ...
        if (r inside [ -1 : r2 ]) ...

If this is equivalent to:
     r >= -1 && r <= r2
then the condition is false for all values of r2 since the unsignedness
of "r2" contaminates the entire condition and all comparisons are done
as 32 bit unsigned comparisons.  So
-1 is a very large unsigned 32 bit value and the range is empty for any
value of r2 (since it is width extended in an unsigned manner).

In the context of a "case (...) inside", I further assume that the type
of all expressions (terms of each set and the case
expression) have their types unified prior to any comparisons being
done.

I think this is consistent with Steven's comments in Mantis 1805 but
want to make sure that this matches everyone's expectations since, once
again, the Verilog semantics here can be very surprising to users.

Gord.
--
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com


--
This message has been scanned for viruses and dangerous content by
MailScanner, and is believed to be clean.


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.