Re: Wreal Proposals

I've been on this committee since the beginning (~1994), Cadence have
repeatedly damaged the language by forcing changes to align it with
their products rather than have it work properly, blocked other changes
and held it back at Accellera (using patent issues) rather than moving
it to the IEEE, and have failed to deliver on promised proposals like
back-annotation methodology.

So, from past experience I'd say Cadence doesn't want to discuss
alternative approaches for wreal because this is what has already been
rolled out to customers and they don't want it changed, a "yes" vote now
will probably lead to adoption as-is (or no change).

I recommend voting "no" and concentrating on merging with SV so that the
AMS team can tackle issues like analog assertions, power-management for
SoC, and user-defined types for RF modeling. Time wasted on issues like
this at the AMS committee could severely impact the schedule for
incorporating AMS into SV.

Kev.

On 03/19/2010 01:10 AM, Marq Kole wrote:
> Hi Kevin,
>
> As stated yesterday, I have heard nothing that indicates that accepting the proposal denies the progress on any alternative solutions. Not accepting the proposal could even endanger the standardization effort when it turns out we need to work around one or more of the patents mentioned in the LoA. Even if after technical debate we find that we cannot accept any suggested implementation part of the donation in the standard at least we are save from patent issues should that cover any of the technical alternatives we might pursue instead. In my view the proposal addresses a number of valid user issues that need to be addressed one way or another - this donation is at least a stake in the ground. That's why I would recommend voting "yes" to accepting the donation and move forward with the standardization effort.
>
> Cheers,
> Marq
>
> -----Original Message-----
> From: owner-verilog-ams@eda.org [mailto:owner-verilog-ams@eda.org] On Behalf Of Kevin Cameron
> Sent: Friday 19 March 2010 8:54
> Cc: Verilog-AMS LRM Committee
> Subject: Wreal Proposals
>
>
> The deprecation proposal that has been floating around in Mantiss is for
> the semantics of the current wreal not the syntax - the proposed change
> would not invalidate any existing code.
>
> Deprecation is not removal, it is the step before that where the
> functionality is supported but not recommended. I.e. going forward the
> recommend methodology would be to just use regular wires/disciplines and
> use V(<wire>) = <value> (in a digital context) rather than using the
> distinct wreal type. It will be clearer in the code what the intent is,
> e.g. if the wreal (as was) is the voltage level out of a power
> management block: "V(power_out) = 0.0" is easier to verify than
> "v_power_out = 0.0".
>
> The Mantiss proposal is simpler since it does not involve
> connect-modules to achieve plug-and-play.
>
> If you want to add resolved types with real values I would suggest using
> different names for the types e.g.: wreal_r. If you do that then it is
> easier to migrate to using a typedef'd version later in
> SystemVerilog(-AMS) than it is to deal with the macro-def approach.
>
> I would recommend voting "no" on accepting the Cadence proposal since
> lacks technical merit: increased complexity, untidy syntax and lack of
> forward compatibility.
>
> The Mantiss proposal has no associated patents.
>
> Kev.
>
>
>
>
>
>
>

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