Re: [sv-cc] Food for thought

I am not sure if these are covered in Charles bullet items. If so,
then consider them as a strong second.

Add an acknowledgement of an instantiated and uninstantiated view
of the language semantics. The design data can usefully be processed
before elaboration, and much of the data model is inadequate for
uninstantiated data.

Eliminate overloading the handle type property to convey type
information. Objects should have a type relationship which return
"typedefinition" handles where the actual type can be accessed from
a property. This provides a real model for the type system which
is easier to extend without duplication of handle types across the
data model.

I will add more suggestions later as suppressed memories of tortured
development rise to the surface.

/sjd

> Last week I asked everyone to consider the straw poll action item
> which we have had open for a while. Here are some of my thoughts
> to get the ball rolling.
>
> I think it is not practical to replace the VPI data model with a new
> one which solves a bunch of problems, but if we were to I would want
> to fix the following (in no particular order):
>
> - Remove a whole bunch of redundant stuff that isn't used but was
> put in to match PLI 1.0 behavior. For example, on the nets
> diagram, we really don't need iterations on cont assign, prim term,
> path term, and tchk term. These are all covered by the load and
> driver iterations.
> - I would want to separate definition data and instance data. Create
> and instance object, and from it descend to a module, primitive, ...etc.
> - I would create a declarative object iteration from module, and
> get rid of all of the separate iterations on objects like nets, regs,
> ...etc.
> - I'd fix the typedef stuff so that it is separate from the type of
> a net/variable.
> - I'd fix the inconsistencies between nets and variables.
> - I'd introduce the concept of a reference to an object.
>
> If we extend this to the interface itself, I would also do the following:
>
> - Reconsider the lifetime of a VPI handle.
> - Clean up the return values for the routines so that they consistently
> return FALSE on success and non-FALSE on failure, or NULL if they
> are returning a pointer/handle.
> - Try to come up with more extensible data structures for routines
> like vpi_register_cb() and vpi_put_value()/vpi_get_value().
>
> Well, that is all I can think of off the top of my head. I don't know
> if we'll have much time to talk about this today, so if you also have
> ideas like these send them in an email.
>
> -Chas
>
>
> --
> Charles Dawson
> Senior Engineering Manager
> NC-Verilog Team
> Cadence Design Systems, Inc.
> 270 Billerica Road
> Chelmsford, MA 01824
> (978) 262 - 6273
> chas@cadence.com
Received on Wed Jan 12 14:33:46 2005