[sv-bc] FW: [sv-ec] Mantis Items 3075-3081

-----Original Message-----
From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of Gordon Vreugdenhil
Sent: Thursday, October 28, 2010 8:38 PM
To: Daniel Schostak
Cc: sv-ec@eda.org
Subject: Re: [sv-ec] Mantis Items 3075-3081

Daniel, here are some comments on $typename.

FIrst, note the following from 20.6.1:

When called with an expression as its argument, $typename returns a
string that represents the self-determined type result of the expression.
The expression's return type is determined during elaboration, but
never evaluated.

This is specifically worded in that way so that one doesn't have to worry
about the legality of the expression value in terms of determining the type.
That conflicts with what you are requesting (that the actual object be
used for a class) and in fact can be problematic even in terms of what
to do with NULL references and/or intermediate terms that might be
NULL.

Here is an example:
class C;
endclass
C myc = null;
initial $display($typename(c));

Now one could define the semantics of $typename with all sorts of special
caveats, but would we do that only for classes? What about for
untyped mailbox items? Null virtual interface references? Part of the
problem is that you can "get to" a class handle via any kind of combination
of these and you'd have to be very careful about expression versus type
semantics.

Then there are all sorts of issues and holes in the $typename definition
itself.

For example, imagine you have:
---- file1.sv -----
class C;
endclass
module child;
C c;
endmodule

---- file2.sv -----
class C;
endclass
module top;
C c;
child c2();
initial $display("%s %s", $typename(c2.c), $typename(c));
endmodule

Since there are two distinct (identically named) types in two different
compilation units, you'd want to have the compilation unit names
as part of the class name, but then you'd have to come up with rules for
naming the compilation units that everyone would agree on.

Similarly with parameterized classes, the exact nature of what
constitutes the "type" includes the type and value of each
parameter; given the existing descriptions in $typename, that
might involve very problematic "recursive" structural descriptions of
each type or type/value.

Things get really messy once you get into realistic situations in very
large design environments -- you can get into library naming issues
that are going vary widely depending on vendor approaches and
could even involve mixed language and other kinds of very difficult
issues.

So it depends on what you are really after.

If you only care about the simple cases in trivial environments, I think
we can likely figure out reasonable rules, But if you really want to
have something that you can rely on over a wide body of user design
management styles, tools, pli interactions, etc, etc, I think that you
are unlikely to reach a degree of consensus that will work.

Gord.

On 10/25/2010 11:03 AM, Daniel Schostak wrote:
> [...]
> Mantis Item 3076 (standardization of $typename):
> ------------------------------------------------
>
> > From the discussion in the meeting on Sep 27 2010, this may be problematic to get any agreement on. However, I will try suggesting a minimum level of information for classes (which is the area I was trying to get some agreement on). I would suggest at the most basic level $typename should return the name of the class referenced by an object handle (if the object handle was a base class object handle and the class instance was a derived class the name of the derived class would be returned). I think this would facilitate creating messages for unexpected failure cases in class based testbenches so that you may have an idea of what has gone wrong before you rerun the failure with the debug features of whatever tool you are using enabled.
>
> [...]
> From, Daniel Schostak.
>
> -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
>

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