RE: V-AMS DevModeling meeting April 6, new proposal doc

David,

The other problem we have is that analog is analog and digital is
digital. The requirements for Verilog were done without any analog in mind
and for System Verilog it got no better. So while we can and should try
to unify these it won't be easy, especially if the position is that
Verilog-AMS which is in production at hundreds of mixed signal design
houses (Verilog-A is in production at thousands of customers) are told they
have to scrape what works and make analog fit into a digital design solution.

I think our current efforts including the device modeling subcommittee
efforts is to look at what is in System Verilog (or Verilog 2K) and
leverage what makes sense but not to burden our users with something they
would never get that as Geoffrey stated would kill the language or stop
adoption. We will try to sync up but some areas where unification could
have occurred probably won't and we will end up with a less than optimal
language, but it will work and users will be productive.

Jon

At 05:05 PM 4/5/2004, David W. Smith wrote:
>Sri,
>Thank you for the clear and thoughtful response. It does help to clarify
>the situation. I sympathize with the need to have SV
>experts participate on the development of AMS extensions to SystemVerilog.
>I will continue to lobby for that from within Synopsys
>and also with committee members.
>
>Regards
>David
>
>David W. Smith
>Synopsys Scientist
>
>Synopsys, Inc.
>Synopsys Technology Park
>2025 NW Cornelius Pass Road
>Hillsboro, OR 97124
>
>Voice: 503.547.6467
>Main: 503.547.6000
>FAX: 503.547.6906
>Email: david.smith@synopsys.com
>http://www.synopsys.com
>
>
>-----Original Message-----
>From: Chandrasekaran Srikanth-A12788
>[mailto:Srikanth.Chandrasekaran@motorola.com]
>Sent: Monday, April 05, 2004 4:58 PM
>To: 'David W. Smith'; 'Geoffrey.Coram'; 'David W. Smith'
>Cc: 'Kevin Cameron'; 'Verilog-A Reflector'; 'verilog-ams-devmod@eda.org'
>Subject: RE: V-AMS DevModeling meeting April 6, new proposal doc
>
>David,
>
>The intention of the Verilog-AMS committee is certainly to move towards
>unification of the VerilogAMS language in its current form
>with the SystemVerilog language. However, as I have told on numerous
>occasions in the past, this can possibly happen only if one of
>two things happen
>
>1. Either some of the volunteers from the SystemVerilog committee
>participate in the VerilogAMS work. There is very little bandwidth
>(and exposure) for the current committee members with respect to the SV
>language and also the developments and enhancements
>happening on the digital language. So it would make this much more
>smoother and easier if a identified group of people from your
>committee (along with couple of analog guys) take up this thread of work
>independently to other enhancements that we need to do in
>the pure analog aspects of the language.
>
>2. The second option would be to run VerilogAMS committee as part of the
>SystemVerilog committee. Once again, this will not solve
>the problem if there are no digital volunteers in working with the analog
>guys in merging the two languages. From what I understand,
>this is not going to be no small task, and I havent even thought of the
>compatibility issues with currently existing models and
>designers who use VerilogA/VerilogAMS in its current form. The number of
>users (atleast within Motorola) using the VerilogA language
>is quite high. I agree that moving towards SV we might have to bite the
>bullet on certain aspects of compatibility, keywords etc. I
>also agree that we are moving towards an unified language, and it is in
>the best interests of everybody to migrate the mixed signal
>language with systemVerilog. I am definitely for it.
>
>With regards to the current status of the language - there are 3
>independent things happening:
>
>1. There are lot of loopholes, open issues, missing features in the
>VerilogAMS language as it exists today - IC analysis for mixed
>signal, DC Sweep, wanting to write table_models, ambiguities between the
>different sections of the LRM etc etc. These need to be
>definitely addressed so that people wanting who are currently writing
>models in VerilogAMS with the current language standards are
>able to read, understand, interpret the LRM in an uniform way.
>
>2. The Syntax (BNF) as it exists in 2.1 is erroneous in a few places and
>not a complete formal implementation grammer. There are
>mistakes, and in some places no definitions and hence vendors make their
>own assumptions and choices on what it should mean
>syntax-wise, sematically and also behaviourally. This is not a good
>situation. To top that it refers to 1995 standard which is
>obsolete. An year+ ago we had a discussion to move towards SV, but there
>were no digital volunteers (SV volunteers) wanting to work
>with us (and probably vice-versa) to merge it with SV. This has been
>raised at the board level, and Vassilios assured that once your
>current version is approved there would be some people from your committee
>working with us to take the AMS language to SV. Until
>then we still needed to address the problems with BNF and hence migrated
>with 2001 standard, which I am given to believe is a step
>in the right direction for merging the language with SystemVerilog
>
>3. Work on the extension of the VerilogAMS language in its current form
>with additional capabilities to support designers writing
>compact models. There seems to be a fair number of users who want to write
>these models in VerilogA and want to see capabilities
>added to the language to facilitate them as soon as possible. These
>community, which is a subcommittee of VerilogAMS, is a pure
>analog group as I understand and I don't think should have the
>focus/responsibility of the issues with the digital language, SV vs
>2001 etc. This is a responsibility of the main VerilogAMS group and the SV
>development group. However all these extensions proposed
>for compact models will be integrated in the enhanced BNF by the main
>committee, that I have mentioned in point #2.
>
>Regards,
>Sri
>
>
>
> > -----Original Message-----
> > From: owner-verilog-ams@eda.org
> > [mailto:owner-verilog-ams@eda.org] On Behalf Of David W. Smith
> > Sent: Tuesday, April 06, 2004 4:09 AM
> > To: 'Geoffrey.Coram'; 'David W. Smith'
> > Cc: 'Kevin Cameron'; 'Verilog-A Reflector'; verilog-ams-devmod@eda.org
> > Subject: RE: V-AMS DevModeling meeting April 6, new proposal doc
> >
> >
> > I guess I am somewhat confused. When you have
> > SystemVerilog-AMS (which is what I have been told by
> > Vassilios you are working on and
> > what the board has approved as the next version) then you
> > have all of the keywords in SV. I do not understand the
> > comment of merging
> > in pieces. SV is an approved and completed standard. Why in pieces?
> >
> > Regards
> > David
> >
> >
> > -----Original Message-----
> > From: owner-verilog-ams@eda.org
> > [mailto:owner-verilog-ams@eda.org] On Behalf Of
> > Geoffrey.Coram
> > Sent: Monday, April 05, 2004 11:36 AM
> > To: David W. Smith
> > Cc: 'Kevin Cameron'; 'Verilog-A Reflector'; verilog-ams-devmod@eda.org
> > Subject: Re: V-AMS DevModeling meeting April 6, new proposal doc
> >
> > David -
> > We don't need "ref" as a keyword, so I don't see any reason to
> > inflict that pain now. The merge with SystemVerilog will likely
> > cause a lot of pain, and it could destroy Verilog-A if that
> > merge were done in pieces, so every N months, everyone has to go
> > through the whole library of Verilog-A modules and figure out
> > what needs to be changed.
> >
> > I also wouldn't be surprised if a number of Spice simulators
> > only ever implemented Verilog-A 2.2 (or whatever these
> > extensions become) -- not even the full AMS.
> >
> > -Geoffrey
> >
> >
> >
> > "David W. Smith" wrote:
> > >
> > > Just a quick comment. You are going to have to eventually
> > accept all of the new keywords in SystemVerilog anyway so the argument
> > that ref may collide (while true) is not particularly
> > relevant. Changing the syntax will not be an option since
> > SystemVerilog is now
> > an approved standard.
> > >
> > > Regards
> > >
> > > David
> >
> >

***********************************************************
Jonathan L. Sanders
Product Engineering Director
Custom IC Solutions
Cadence Design Systems, Inc.
555 River Oaks Pkwy
San Jose, CA. 95134
  INTERNET:jons@cadence.com Tel: (408) 428-5654 Fax : (408) 944-7027
***********************************************************
Received on Tue Apr 6 01:15:54 2004