RE: [sv-bc] confusion in determining the type of an self determined binary expression during evalution of type operator

Yes, you're right. Maybe the example would be more persuading if I would
use a typedef:

typedef logic base_type [3:1];
base_type a [4:1];
base_type b;
logic c;
assign b = a[3];
assign c = b[i];

Anyway, probably this example by itself is not a strong enough argument
for not normalizing the types. Perhaps the other argument I mentioned,
to keep selects with more than one selection, like a[3][1], unambiguous
and similar in semantics with expressions like (a[3])[i], is a stronger
argument.

Another reason to keep the original type, is that if the type is
normalized, you're practically introducing a new type to the model. For
a software tool that means it should keep another object in memory, for
example. For a tool that performs logic transformations on the model and
writes the transformed model back into Verilog, the tool may need to
write declarations of these new types in the resulting Verilog (for
example, if the tool creates some temporary variables with these types),
not only making it larger, but also less readable, since the reader
would need to understand where these types are coming from. Also, for a
software developer developing that tool, it would more complex to debug
it, since s/he will need to keep track of what caused the creation of
this new type. These kinds of complexities may be avoided, if the
language just uses the original types in the types of part selects,
instead of artificially normalizing them.

--Yulik.

-----Original Message-----
From: Bresticker, Shalom 
Sent: Wednesday, October 17, 2007 12:33 PM
To: Feldman, Yulik
Cc: sv-bc@server.eda-stds.org
Subject: RE: [sv-bc] confusion in determining the type of an self
determined binary expression during evalution of type operator

Yulik, 

> Regarding the normalization of the array bounds, it is 
> important not to normalize the bounds only if the language is 
> extended to support selects on arbitrary expressions (which I 
> really hope will happen one day).
> Consider the following code:
> 
> logic a [4:1][3:1];
> logic b [3:1];
> logic c;
> assign b = a[3];
> assign c = b[i];
> 
> A software tool (or even a human person) may decide to 
> simplify the above code by replacing the reference to "b" 
> with the logic driving it
> ("a[3]"):
> 
> assign c = (a[3])[i];
> 
> The type of the expression in parenthesis should have the 
> bounds [3:1], not the normalized [2:0], otherwise the 
> selection will not work as expected. 

This seems to me to be a special case, where you could do that
substitution. It would be sufficient for b to be declared as 

logic b [2:0];  OR
logic b [5:3];  OR
logic b [1:3];

for this substitution not to work.

Shalom
---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

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