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

From: Feldman, Yulik <yulik.feldman_at_.....>
Date: Tue Oct 16 2007 - 08:29:39 PDT
I'm afraid if we go into detailed discussion right now, we would need a
separate thread for that :) I'll just mention what I think about it.

As a thumb rule, I think that the type of part select should be the same
as the type of the data selected by it. I.e., if we have "bit [2:1] a
[7:5][4:3];", the type of "a[5]" should be "bit [2:1] (imaginary
placeholder) [4:3]", without further normalization. 

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]". In this case, the topmost array type
(corresponding to the range of selected elements of the array) may be
normalized, while the type of the elements of this array should still be
left in their original form (I believe). I.e, the type of "a[6:5]" can
be either the partly normalized to "bit [2:1] (placeholder) [1:0][4:3]"
or be left in a more-or-less "original" form like "bit [2:1]
(placeholder) [6:5][4:3]". I do agree that normalizing the top-most
array for part selects selecting more than one element of an array may
be preferable over not normalizing it, though I'm not sure it really
matters for tool's performance.

If we simplify the above example and look on a simple one-dimensional
packed array, like "bit [7:5] b;", then, if we normalize the topmost
array, the type of "b[6:5]" will be "bit [1:0] b;". So, unless you think
that the whole type should normalized, and not only that of the topmost
array, we may be still thinking the same. If you believe everything
should be normalized, then we indeed have a disagreement, and we will
have to discuss it. In my eyes, normalizing all types, in whatever way,
would make this type information mostly, if not completely, useless.

--Yulik.

-----Original Message-----
From: Gordon Vreugdenhil [mailto:gordonv@model.com] 
Sent: Tuesday, October 16, 2007 4:12 PM
To: Feldman, Yulik
Cc: Brad Pierce; 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



Feldman, Yulik wrote:
> I didn't imply that it has a self-determined type. I just gave
examples
> of expression kinds that may have a complex data type, self-determined
> or context-determined.

Yulik, I believe that you are suggesting that a (part)select should not
necessarily be normalized but should carry its range information
around (more like VHDL).  I would almost certainly object to that
approach as a general requirement.

The reason for the objection is that there is no Verilog precedent
for needing that information in general and adding such a requirement
would definitely have an impact on simulation performance.  Given the
limited  contexts in which the information is used, it would be better
to assume normalization everywhere other than a very few specific
circumstances.

I know that various people have talked about wanting to have selects
on general expressions and that this position impacts that.

If someone wants to try to write up a full description of normalization
rules and/or un-normalized cases, I'd certainly review it, but I'm
likely going to be wary of any deep requirement regarding
non-normalized expressions.

Gord.

-- 
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com
---------------------------------------------------------------------
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.
Received on Tue Oct 16 08:30:32 2007

This archive was generated by hypermail 2.1.8 : Tue Oct 16 2007 - 08:30:47 PDT