Re: Cadence wreal proposal donation result

The Mentor Graphics proposal isn't really complimentary, it provides an
alternative (and in my opinion superior) mechanism for how to do
resolved signals with user-defined driver types. As an approach it isn't
limited to real valued types, it can be used for more complex types (as
needed for event-driven RF), and it allows user definition of the
resolution function, so it is not limited to those defined in the
Cadence offering.

If you want an interim solution, the "best" option (in my opinion) would
be to add the different wreal/resolved types as built-ins with different
names such that they can be replaced by user-defined types (or
system-defined in optional includes) at a later date. I don't think the
resolution scheme specification belongs in the disciplines or as pragmas
(`def..), discplines define physical domains (e.g. electrical) which
determines what can be connected to a net and shouldn't be used for
sub-classing simulation driver types. I.e. drivers with the same
discipline can be connected to the same net (single simulation node),
the actual type of the driver is an orthogonal concept (logic, real,
continuous or user-defined), not all tools need to understand the driver
types.

The wreal/connect-module issue needs to be addressed in the context of
handling multi-driver multi-type resolution. This has been considered by
the committee before, the general scheme for cross-type resolution is:

    convert all drivers of a net to the same type (preferably with no
loss of accuracy)
    resolve drivers to get the net value
    convert net value to type of receivers (can be lossy)

For a mixed logic/continuous net this means doing the auto insertion of
the D2As, resolving using the analog solver and converting back with
A2Ds. There is a bunch of work that needs to be done on how to
generalize the syntax/semantics so that mixing just (say) "real" and
"logic" works (or at least has a defined behavior), and that mixing
those with user-defined types works in discrete simulation as well as
mixed with continuous drivers. Also, "connect modules" are used rather
than "connect functions" because the D2A conversion has persistent
state, in the case of discrete/discrete driver conversion that is not
always required so functions will do. The extra work needed involves
defining syntax for:

    Type ranking for accuracy (e.g. real over bool)
    Connect modules for user-defined types
    Type conversion functions (for user-defined types)

The Mentor Graphics proposal doesn't conflict with doing any of that,
the Cadence proposal does.

Kev.

PS: 'absdelta' is an orthogonal feature, and I don't have any particular
issue with it.

On 04/07/2010 06:11 AM, Sri Chandra wrote:
> Kevin,
>
> In my opinion, I thought Mentor proposal was complimentary to what is
> being considered as part of the Cadence wreal donation, and addresses
> some of the aspects of the wreal issues that are being discussed.
>
> Infact we had scheduled to discuss the Cadence proposal as part of
> last week's call, however Ken is on vacation and hence we have
> scheduled it for next week.
>
> Regards,
> Sri
>
>
>
> On 4/7/2010 1:56 PM, Kevin Cameron wrote:
>>
>> Given that the proposal from Mentor Graphics is a superior solution for
>> the resolved real signal type, but depends on syntax that is SV rather
>> than Verilog-AMS (classes etc.), and also extends SV, I say (again) this
>> whole issue should be left for when SV and Verilog-AMS are merged.
>>
>> If not: does the Mentor Graphics document need to be formally
>> donated/accepted before official consideration?
>>
>> Kev.
>>
>> On 04/06/2010 08:57 AM, Sri Chandra wrote:
>>> Hi all,
>>>
>>> The closing date for voting on this proposal from the Accellera active
>>> members was 19th March 2010.
>>>
>>> We got 7 yes votes for accepting the donation from Accellera
>>> members and 1 ambiguous vote, and with this the wreal donation from
>>> Cadence is considered accepted.
>>>
>>> Once again this is not a vote on its inclusion in the actual standard,
>>> this will be done as per the usual technical committee language
>>> development process to address any and all open issues/requirements
>>> that are not addressed in the proposal. As part of this donation,
>>> Cadence has also provided patent licensing (if any, pending or
>>> approved) used in the donation to Accellera, and Cadence will not
>>> enforce any patent claims for users of this donation. A letter of
>>> assurance has also been signed by Cadence that no further patenting
>>> will be done, and the implementers have the same patent protection.
>>>
>>> Regards,
>>> Sri
>>>
>>>
>>
>>
>
>

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