There was no requirement to call everything "interconnect" when we decided to allow both analog and digital use of wires in Verilog-AMS, and there was no reason to do it in SystemVerilog. Gord made some unwarranted and false assertions about how Verilog works, and made some bad conclusions about how to handle it.
The problem with "interconnect" is that it requires changes to how Verilog is used that creates an incompatibility between legacy code and new code. It seems unlikely to me that anyone is going to bother implementing and using it as currently proposed. We were careful with the design of Verilog-AMS that legacy code was reusable without modification.
I doubt it will be an obstacle AMS/SV integration because that doesn't seem to be any closer now than it was prior to SV-DC.
Kev.
On 10/24/2011 02:50 PM, Ian Wilson wrote:
> 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
>> 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
>>>> 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>
>>>>> Reply-To:<neil.korpusik@oracle.com>
>>>>> To: 'sv-ac@eda-stds.org'<sv-ac@eda-stds.org>, SV_BC List<sv-
>>>> bc@eda.org>,
>>>>> SV_EC List<sv-ec@eda.org>,<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.
-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Mon Oct 24 23:23:01 2011
This archive was generated by hypermail 2.1.8 : Mon Oct 24 2011 - 23:23:07 PDT