RE: Fwd: [sv-dc] Results from the most recent Champions email vote

Ian,

In SystemVerilog, wire is no longer predefined as of type logic. For the new revision, Mantis 3398 adds user-defined types and resolution functions to nets.

Shalom

From: owner-verilog-ams@eda.org [mailto:owner-verilog-ams@eda.org] On Behalf Of Ian Wilson
Sent: Monday, October 24, 2011 11:51 PM
To: Dave Miller
Cc: Little Scott-B11206; verilog-ams@eda.org
Subject: Re: Fwd: [sv-dc] Results from the most recent Champions email vote

For reference, here is my viewpoint on generic interconnect and
its impact on AMS:

The only candidate in existing {System}Verilog for a typeless interconnect is wire.
However, this is predfined as being of type logic, so would be incompatible on some
level with user-defined types (which would be the mechanism for providing portable
behavior similar to wreal). Hence the proposal to introduce 'interconnect' as a type.

From an AMS viewpoint, interconnect (whether wire or something) doesn't have
any behavior except possibly to contribute discipline information, so other than
complicating the elaboration process, and adding syntax, it doesn't seem that
interconnect as currently proposed will be a major problem for AMS/SV integration.

--ian

----------------------------------

Ian M Wilson

Architect

Berkeley Design Automation

Office: 408-496-6600 x238

Cell: 714-272-7040

ian.wilson@berkeley-da.com<mailto:ian.wilson@berkeley-da.com>

http://www.berkeley-da.com

----------------------------------

True SPICE accuracy, 5X-20X faster

Don't Be Left Behind!

----------------------------------

Nothing to do with wreal (that is user defined nettype), my mistake.
Generic interconnect is related to how we handle pass through mechanics in Verilog-AMS.

Currently it is undocumented and undefined, but implementations piggy back on "wire".
We need to fix this in SV-AMS anyway.
The generic interconnect proposal does that work for us and should be fully compatible with Verilog-AMS when the time comes.

So no - defiantly no divergence, more a convergence by introducing a defined and documented construct to handle this issue in both languages.

Whether the old "wire" method (existing models) will be able to be used in a SV-AMS world, we really can't tell at this stage, but that is not SV's concern. That is more a backward compatibility question we have to address, and backward's compatibility is not always a good thing.

Cheers..
Dave

On 10/24/2011 11:24 AM, Little Scott-B11206 wrote:

Hi Dave:

1. Brad Pierce is a member of the Champions committee from SNPS.

2. If Verilog-AMS wants to comment on their perspective about whether this proposal creates a divergence between SV and Verilog-AMS that would likely be a good thing. My guess is that Brad is simply curious what effect the interconnect will have on the Verilog-AMS/SV merger. I would expect he doesn't want SV-DC to do something that would significantly complicate the merger. I haven't heard any concerns from SNPS, so I don't believe the question comes from anyone at SNPS other than Brad.

I read the feedback, and I was going to prepare a response in the next couple of days. I would send out that response to the SV-DC reflector to iterate on the wording a bit prior to sending it along to Brad. If Verilog-AMS would like to be included and make it a joint response to Brad that would be fine. Your thoughts?

I think that a bit of explanation about how SV-DC& Verilog-AMS are interacting would also be useful.

Thanks,
Scott

-----Original Message-----
From: Miller Dave-A17239
Sent: Monday, October 24, 2011 10:11 AM
To: Little Scott-B11206
Cc: Chandrasekaran Srikanth-A12788; ian.wilson@berkeley-da.com<mailto:ian.wilson@berkeley-da.com>
Subject: Re: Fwd: [sv-dc] Results from the most recent Champions email
vote

Sorry meant to also include Ian in response.

On 10/24/2011 10:08 AM, Dave Miller wrote:

-------- Original Message --------
Subject: [sv-dc] Results from the most recent Champions email vote
Date: Sat, 22 Oct 2011 19:52:03 -0700
From: Neil Korpusik<neil.korpusik@oracle.com><mailto:neil.korpusik@oracle.com>
Reply-To:<neil.korpusik@oracle.com><mailto:neil.korpusik@oracle.com>
To: 'sv-ac@eda-stds.org<mailto:sv-ac@eda-stds.org>'<sv-ac@eda-stds.org><mailto:sv-ac@eda-stds.org>, SV_BC List<sv-
bc@eda.org<mailto:bc@eda.org>>,

SV_EC List<sv-ec@eda.org><mailto:sv-ec@eda.org>,<sv-dc@eda.org><mailto:sv-dc@eda.org>

The proposal was opposed by the Champions in the email vote which
ended

October 17, 2011.

....
3724 SV-DC Allow generic interconnect for "typeless" connections

Scott, I saw this, as well as the comment in the Mantis:
<QUOTE>
Opposed:
Brad
Before approving, I'd like to hear the official position of SV-DC
about

whether this is a divergence away from Verilog-AMS, and if so, why
that

divergence is considered necessary.
</QUOTE>

1. Who is Brad?

2. Is there anything that we (Verilog-AMS) can do to help here? Is
the

divergence regarding wreal vs generic interconnect?
Is it simply a matter of pointing out that the two groups work
closely

together, and that Verilog-AMS (Ian) is directly involved with the
proposal to

ensure that the SV proposal will play nice with AMS in the future?

Of course any technical person must understand that there will always
be a

little bit of give and take when two languages like this are merged
together.

--
==============================================
-- David Miller
-- Design Technology (Austin)
-- Freescale Semiconductor
-- Ph : 512 996-7377 Fax: x7755
==============================================
--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.
---------------------------------------------------------------------
Intel Israel (74) Limited
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.