[sv-dc] Re: A proposal on UDT and resolution functions

Thanks for the comments Arturo.

In general, my goal with the current proposal was to get a good
start for making further progress. We really just needed to get
some sort of baseline established. Personally, I haven't given up on
the late binding and/or per-net overrides. That isn't permitted by
the current proposal, but I think that there are pretty reasonable
avenues for getting there. One of the reasons that I am prepared
at this point to move forward without the late binding aspects is that
there wasn't strong user interest in committee discussions. Once
we start discussing "generic interconnect" and similar, it may
end up that we need most of what I had originally proposed on
that front so it may end up falling out again from other work.

Gord.

On 3/9/2011 12:30 AM, Arturo Salz wrote:
>
> A couple of quick points regarding this proposal:
>
> ·The nettype declaration is not a scope, which is good. The syntax
> combines the nettype declaration with a compact way for tightly
> binding the resolution function to the nettype, which is also a nice
> feature.
>
> ·The relationship between a resolution function and a nettype is
> one-to-one. Therefore, users must create a distinct nettype for each
> datatype/resolution-function pair. This is inconsistent with one of
> the key requirements of Mentor's earlier proposal: the ability to do
> late binding of resolution functions. A key difference between this
> proposal and Mentor's earlier one is that the latter provides for a
> generic (or typeless) signal that specifies connectivity without any
> behavior - the semantics of the signal can be specified separately.
> This is something we'll need to discuss.
>
> ·The nettype declaration can optionally specify a resolution function
> binding using the function name. But the function must be declared
> separately -- presumably an unrelated external function declared in
> some scope or package (or class ?) . I believe that allowing the
> resolution function declaration to be part of the nettype declaration
> would facilitate these declarations, help contain all nettype
> information, and improve the quality of the resolution checks
> performed by the compiler. For example, we could enhance the syntax to
> allow the following:
>
> *typedef**struct* { ... } T; // user-defined datatype T
>
> *nettype*T wT *with* *function* T Tsum(input T driver[]);
>
> **Tsum = 0;
>
> *foreach* (driver[i]) Tsum += driver[i];
>
> *endfunction*
>
> In fact, the function return type (and possibly even the function
> name) could be omitted since they are implicitly known, allowing for
> something like:
>
> *nettype*T wT *with* *function* Tsum(input T driver[]); ... endfunction
>
> ·The proposal also implies that a class method could be used as a
> resolution function. I don't believe that is such a good idea -- at
> any rate, only a static method could be used as a resolution function.
>
> ·The binding of a resolution function to a nettype is optional, hence,
> it allows creation of unresolved nettypes that can only have a single
> driver. I frankly don't see any use for these unresolved nettypes
> since they have the exact same semantics as a variable port of that
> same datatype. Mentor's proposal did not require binding of the
> resolution function with the nettype declaration in order to allow for
> late binding, which is a feature that this proposal does not
> incorporate. And, if that's the case then unresolved nettypes seem
> redundant.
>
> ·The proposal does not include a mechanism for specifying generic
> (parameterized) nettypes. Presumably the datatype could be
> parameterized (perhaps in a compilation unit or module), but then the
> nettype would be applicable only on fully specialized datatypes.
>
> ·The proposal does not provide a mechanism for overriding the
> resolution function on a per-net basis. Something that was discussed
> but never settled. This proposal seems to close the door on such an
> enhancement.
>
> ·The proposal does not state that nettypes are atomically driven -- in
> fact, the wording "Any change in value to one of the fields of the
> data type associated with a nettype (the drivers)" implies that only
> some fields may be written by a driver. This may be an unintended
> conclusion, but we should nonetheless be specific about it. Likewise,
> I believe that we need to specify that execution of a resolution
> function is atomic.
>
> Arturo
>
> *From:*owner-sv-dc@eda.org [mailto:owner-sv-dc@eda.org] *On Behalf Of
> *Abhi Kolpekwar
> *Sent:* Tuesday, March 08, 2011 6:37 PM
> *To:* sv-dc@eda.org
> *Cc:* Gordon Vreugdenhil; Shekar Chetput
> *Subject:* [sv-dc] A proposal on UDT and resolution functions
>
> Hi All,
>
> Attached is a joint proposal by Cadence and Mentor on UDTs and
> resolution functions. While we are in agreement in most cases, there
> are still some open issues that need to be cleared out in the committee.
>
> We look forward to our discussions in tomorrow's meeting.
>
> Thanks,
>
> Abhi
>
> http://www.cadence.com/mail/footer_gray_640.gif
>
> http://www.cadence.com/mail/footer_logocdns1.gif
>
>
>
> *Abhi Kolpekwar*| Initiatives Architect
>
> P: 5124652260 www.cadence.com <http://www.cadence.com>
> abhijeet@cadence.com <mailto:abhijeet@cadence.com>
>
> http://www.cadence.com/mail/footer_gray_640.gif
>
>
>
>
> --
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean.
>

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