[sv-cc] meeting minutes for 05/01/2007

Minute for 5/1/2007

Rohit
Gord
Abi
Andrzej
Chas
Chuck
Jim
Bassam

naming issues (cont)
If the object has not been created yet via the HDL and thru the course
of the simulation, should that handle ever "come alive"?  JimV argues
that without context, it doesn't make sense to have a full name to an
object.  At the last face to face meeting, we decided to break things
differently:  a reference with a constant would be a variable or a
reg while a reference with an non-constant reference would be a
var select.

When the VPI implementation can, it should follow the defined behavior
as that of the HDL.  What about a class var member element reference
when the class var is NULL?

class foo;
   integer x;

...

foo classvar;
classvar.x

when classvar has not been new'ed yet.  This behavior is undefined.
If x is a static, then the LRM has defined that case, and it should
behave properly.  For names, you need to think of the latest topological
anchor, and then everything after it.

VPI and parameterized classes
Francoise thinks that we agreed that there should not be a way to
specify a name for a parameterized class.  It should remain tool
dependent.  Gord commented that there is a description in the LRM
for $typename, and there has been substantial debate on whether or
not it should provide authoritative type names.  Gord is not convinced
that it should provide an authoritative type name.  Francoise asked
why we would need to name these types.  Gord felt that there were issues
with this outside of VPI.  For example,

module m;
   parameter p2 = 1;
   class c #(parameter p = 1);
     static int i;
     task t;
       $display("%m %d, p);
     endtask
   logic [p2:0] y;
   endclass

c::t and c#(1)::t are defined to be equivalent.

c::x and c#(1)::x are the exact same object
while x#(20)::x would be a different object.

typedef c#(1) CL; does not cause a new type to come into existence,
rather it just gives a name to that type.

There is a family of types, then there are specializations that
are unique within a family.  That suggests a hierarchy within the
data model:  a family name then a type name.

Right now there is no way to iterate over all of the specializations
for a particular module instance.  Francoise thinks that it might
be useful, but it remains to be seen.  Gord thinks that customers
will want this.  Gord thinks that it is common user error to create
specializations when they did not intend to, so accessing the set
of specializations will be important.  Chas thinks this should be
doable since all the specializations should be known after elaboration.

parameterized classes only provide a means for creating specialized
class types, which come into existence when you actually use a unique
creating of a type.

Are there existing mantis items for these issues?

Still need to be able to handle

   class E extends c#(5);
   class F #(parameter p = 2) extends c#(p)
   class G #(p = 1) extends c

The extends is always relative to a type.
We should include a pretty extensive example, so that users of
the spec and have something more concrete to look at.  Need to
completely rework for parameterized classes.  For JimV's
proposal we only add to the data model, although we are changing
the meaning of some of the model.  JimV volunteers to try to
write up the proposal on how to do this.

Now, what should c.t return for %m?
$typename is described in section 19 somewhere.
$typename is not authoritative now, but might be in the future.
We could specify that the name is what $typename would return?
That would at least be useful, if not eventually authoritative.

VPI can be authoritative because we can give a name that is
unique for each type in a parameterization family.

Backwards compatibility discussion

Are we just giving the application developer a crutch on which
they can lean indefinitely?  If we do this, we can define all
non-compliant implementations to be a bug, instead of a partially
implemented solution.  It stratifies the steps for implementation.
The motivation to move forward is to support new SystemVerilog
constructs.

Abi tried to implement a solution that was library dependent,
but did not require a recompile, and she doesn't recommend
that solution.

This solution says that you can only have one application that
does not have to be recompiled.

We should do strict checking against the given version of the
specification, so that we can help avoid flavors of implementations.
Chuck and Jim checked with Steve Dovich about the legality of
putting something like this into the LRM, and he felt that it
was fine to do.

Interesting discussion on providing version neutral coding styles
to application developers.  There are issues with this, including
not being able to predict all use models, sophisticated users being
beyond this problem already, and coding styles having potential
issues themselves.

Andrzej pointed out that this will cause problems while debugging
because the default routine names would not be what was actually
being called.  Although this will cause some problems, Abi doesn't
think that this is a show stopper.  It is an annoyance but an
acceptable one.

Should we provide an expiration date for some versions that are
supported?  Yes, add a comment saying future versions of the spec
are likely to deprecate some or all of the compatibility modes.
Should we say something to the effect that not all vendors will
support all compatibility modes?  Not necessary, since it is the
way that it will be anyway.  Does protect vendors against customers
demanding that implementations support all of them.

Should this be an informative annex?  Abi doesn't care where it goes.
What is important is that all vendors support it.  We should ask
Steve Dovich to comment on where it should go.

Packed-Arrays of Packed Structs Proposal

Probably want to compare against 19.8 (in the merged doc) to see if
the definitions used for $dimensions would match what we would get
for some things like string and integer variables.

What are the remaining issues before a proposal can be put together?
Need a way to get to the struct in a packed array of structs.
Need to specify the properties and relations for the vpiPackedArrayVar
and vpiPackedArrayNet objects.  vpiSize is not defined for vpiStringVar.
Abi seems to recall that we discussed this and it should be the number
of bytes in the string.  Maybe we should create a vpiRangeSize that
will give the number of elements for the top most array element and
vpiSize would always give the number of bits for any given level.

vpiElement is a good label for the transition to the sub-array for
the packed array var.  Should the vpiArrayMember apply to these new
elements, and packed structs?  Abi would prefer a new property.
Chas would prefer to re-use the property.  Probably doesn't matter
much one way or another.

7.11.3 sum reduction.  This is an example of something that is not in
the VPI data model.


-- 
Charles Dawson
Senior Engineering Manager
NC-Verilog Team
Cadence Design Systems, Inc.
270 Billerica Road
Chelmsford, MA  01824
(978) 262 - 6273
chas@cadence.com


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