RE: Wreal Proposals

I'd third that.

There could be merit to Kevin's proposal and/or disagreements, but that shouldn't preclude the committee from considering ideas from the Cadence proposal as well. And due to the patent issue, any considerations from their proposal would require the committee's acceptance of it.

Since there doesn't seem to be any strings attached, I'm voting to accept the donation and continue with the discussions.

--Top Lertpanyavit

-----Original Message-----
From: owner-verilog-ams@eda.org [mailto:owner-verilog-ams@eda.org] On Behalf Of Bilhan, Haydar
Sent: Friday, March 19, 2010 8:26 AM
To: Verilog-AMS LRM Committee
Subject: RE: Wreal Proposals

I also agree with Marq's comments below.

Haydar Bilhan (Texas Instruments)

-----Original Message-----
From: owner-verilog-ams@eda.org [mailto:owner-verilog-ams@eda.org] On Behalf Of Marq Kole
Sent: Friday, March 19, 2010 3:10 AM
To: Kevin Cameron
Cc: Verilog-AMS LRM Committee
Subject: RE: Wreal Proposals

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.
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.