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

 

 

-----Original Message-----
From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org] On
Behalf Of Steven Sharp
Sent: Tuesday, October 16, 2007 9:42 PM
To: gordonv@model.com; Feldman, Yulik
Cc: Brad.Pierce@synopsys.com; sv-bc@server.eda.org
Subject: RE: [sv-bc] confusion in determining the type of an self
determined binary expression during evalution of type operator

 

 

I don't agree about the type of a part select.  However, the example

you give here is not a part select.  It selects part of an object,

but "part select" is a technical term for a specific kind of select,

which you are not using here.

[Yulik] The problem here is that the LRM is very confusing on the
definition of the related terminology. I have tried to raise this issue
in the past, but it didn't get much attention. The end result is that I
and all my colleagues just use the "part select" term as a universal
term describing any kind of "select"/"slice"/"part select"/"bit
select"/"member select", even that we know that strictly speaking LRM
assigns some other mysterious meaning to this term. It looks that you're
using the term "select" for such a universal meaning; but I don't think
LRM clearly defines it as such either.

 

>There is one situation where the type may be normalized without any bad

>consequences, which is when a part select selects more than one element

>of an array, like in "a[6:5]".

 

This starts getting us into the area of true part selects (when it is

a vector) or slices (for arrays).  Here it sounds like you are more in

agreement with me (and Gord).  I would adjust your description slightly

though.  It is not the selection of more than one element that should

matter here; it is the use of the range (or part select) syntax, which

can select more than one element.  The slice "a[6:6]" only selects one

element, but it is still a slice.  

[Yulik] I agree

 

I agree that normalizing types that are strictly typed, such as classes

or unpacked structs, would cause problems.  However, I don't think that

the array cases from your examples are as bad as you suggest.  This is

because the assignment compatibility rules are based on "shape" rather

than exact bounds.  So the type information can be used to declare a

type that is compatible with the element, even if it is normalized.

The fact that the compatibility rules are based on "shape" actually

supports the argument that this is all that is retained about the

type of an array expression.

 

I haven't fully considered whether I think that things other than the

topmost dimension should be normalized.

[Yulik] See my previous reply in this thread; the rationale for keeping
the original type is to allow "selects" on arbitrary expressions,
without unnecessary complications

 

Steven Sharp

sharp@cadence.com

 

 

-- 

This message has been scanned for viruses and

dangerous content by MailScanner, and is

believed to be clean.

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