Date: Wed Mar 09 2011 - 00:30:25 PST
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
[cid:image002.gif@01CBDDE7.FE265520]
Abhi Kolpekwar | Initiatives Architect
P: 5124652260 www.cadence.com<http://www.cadence.com> abhijeet@cadence.com<mailto:abhijeet@cadence.com>
-- This message has been scanned for viruses and dangerous content by MailScanner<http://www.mailscanner.info/>, and is believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
