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

Generally, I understand that both definitions (normalizing and not
normalizing the types) can theoretically work, and thus I'll not argue
too much if there is substantial opposition to my point of view. But I'm
interested to know what the arguments for normalizing the types are.

I can understand that due to historical reasons some simulators or other
software tools implemented their internal data structures in such a way
that only normalized types can be stored, and changing those data
structures would mean making major updates in tools' infrastructure,
leading to opposition to do such changes.

However, closing the eyes on historical reasons for a moment, I'm not
sure I understand what kind of negative effect storing the original,
non-normalized type information may have on tool's efficiency. After
all, you just need to let the expression object point to the object
storing the type information. If the type object is the "original" one,
you anyway have its definition somewhere, so this object doesn't consume
additional memory. Also, you anyway need to store the type information
of the expression somehow, and I don't think you could do that more
compactly than storing a pointer to the type object, even if the types
would be normalized. From performance point of view, following the
pointer to the type object and querying it in case of a need should be
fast enough for most practical needs. So it is not clear to me where the
supposed deficiency lies. 

Is there any other reason for considering using normalized types other
than unwillingness to change existing tool implementations (assuming
that some of them are currently implementing normalization of the
types)?

--Yulik.

-----Original Message-----
From: Gordon Vreugdenhil [mailto:gordonv@model.com] 
Sent: Thursday, October 18, 2007 4:05 PM
To: Feldman, Yulik
Cc: Bresticker, Shalom; 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

Feldman, Yulik wrote:
> 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. 

Yulik,

You are making a rather deep assumption here.  In my experience with
work on multiple simulator implementations, the opposite is in fact
true.
It is more efficient on several fronts to assume normalization
everywhere.  This has been Ok to do in Verilog and implementations
assume various aspects of a normalized model in fairly deep ways.

For those reasons, I will continue to have serious reservations
about this direction.

There may be some cases in which it is reasonable to require more
specific type information.  Steven has raised some of those.  But
requiring fully accurate information in various places is a
mine field and is a position for which you'll almost certainly find
substantial opposition.

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.