Subject: Re: Verilog-AMS LRM Committee Meeting - Minutes
From: Sri Chandra (schandra@asc.corp.mot.com)
Date: Wed Mar 19 2003 - 14:45:27 PST
Hi Vassillios,
Hi all,
Just to further clarify for those who did not attend the call...
The comments expressed in the email "Minutes of the LRM committee call..."
were not my personal opinions and the document just reflected the minutes of
what was expressed by different members in the meeting that was held.
Unfortunately with so many opinions and with the length of the call i
couldnt document who exactly expressed what opinions and hence that
information was not available in that email.
If I have misquoted something that i have heard please feel free to correct
me.
Regards,
Sri
-- Srikanth Chandrasekaran Global Software Group, EDA Motorola Australia Phone: +61-8-8168 3592 Fax: x3501----- Original Message ----- From: <Vassilios.Gerousis@infineon.com> To: <schandra@asc.corp.mot.com>; <verilog-ams@eda.org>; <j_moore@agilent.com>; <kundert@cadence.com>; <jess.chen@resonext.com>; <mary-ann.maher@memscap.com>; <tamal@ece.cmu.edu>; <fedder@ece.cmu.edu>; <stephen.breit@coventor.com>; <Geoffrey.Coram@analog.com>; <rick_poore@agilent.com>; <iyusim@cadence.com>; <mcandrew@ieee.org>; <D.B.M.Klaasen@philips.com>; <kgreen@msp.sc.ti.com>; <zweid@ti.com>; "Laurent Lemaitre" <Laurent.Lemaitre@motorola.com>; "Brian Mulvaney" <Brian.Mulvaney@motorola.com>; <rwilson8@agere.com>; <sherrard@amis.com>; <gbell@nassda.com>; <Geoffrey.Ying@synopsys.com>; <edcheng@synopsys.com> Cc: <dennisb@model.com> Sent: Thursday, March 20, 2003 6:31 AM Subject: RE: Verilog-AMS LRM Committee Meeting - Minutes
> There are few clarification that should be given based on this email: > > 1- It seems that one or two companies are still trying to divide Accellera > and IEEE. The fact is simple and is part of of Accellera technical and > bylaws. > > a- ALL Accellera standard will go to IEEE. This is a fact with both OVI > and VI. > > Anything that is being advised in this regards is against what Accellera > standards for and we believe. > > > > 2- SystemVerilog is as a standard is built on the evolution of IEEE Verilog > 2001. To say there is a difference between supporting IEEE 2001 and > SystemVerilog is again goes to what Accellera and its board board has > approved as the standard for SystemVerilog 3.0 last June 2003. > > > > 3- Accellera board has approved the strategy and plan for Verilog-AMS to be > the coordinated with SystemVerilog. In fact the current plan is to make > Verilog-AMS to be a subcommittee of SystemVerilog so that better dialogue > and communication between Verilog-AMS and SystemVerilog be established more > stronger than it had even with Verilog 2001 when its activities started. > > Many of the comments and suggestion based in this email goes against what > Accellera has decided as its strategy to move forward and its continuos > plans to support every of its standard into IEEE. Anything else is a big > lie. > > > > Best Regards > > > > Vassilios > > -----Original Message----- > From: Sri Chandra [mailto:schandra@asc.corp.mot.com] > Sent: Wednesday, March 19, 2003 3:08 AM > To: Verilog-AMS LRM Committee; John Moore; Ken Kundert; Jess Chen; Mary-Ann > Maher; Tamal Mukherjee; Gary Fedder; Stephen Breit; Geoffrey Coram; Rick > Poore; Ilya Yusim; Colin McAndrew; Dr. Dick Klaassen; Keith Green; David > Zweidinger; Laurent Lemaitre; Brian Mulvaney; Wilson S. Ross; Dwayne A. > Sherrard; Graham Bell; Geoffrey Ying; Ed Cheng > Cc: Gerousis Vassilios (CL DAT CS); Dennis Brophy > Subject: Verilog-AMS LRM Committee Meeting - Minutes > > > Attendees: > Kevin (National Seminconductors) > Jon & Martin (Cadence) > Peter, Don & Dr. Hahn (Expedion) > Ken (Mentor) > Jeffrey (Analog Devices) > Brian, Graham & Sri (Motorola) > > Date: 10th March 2003, Time: 2:30pm US, PST. > > Sync'Up with current digital standards (SystemVerilog vs 1364-2001) > * currently there is no IEEE standards for VerilogA/VerilogAMS > * the current digital standard for VerilogAMS is IEEE 1364-1995. This is an > obsolete standard and VerilogAMS should adapt one of the more current > standards for digital. > > Discussion for moving towards IEEE Verilog2001 > * Enhancements to SV can be combined with VerilogAMS, however there is no > commitment from SV to move towards IEEE. > * There were some opinions that moving towards SystemVerilog would be more > controversial because SystemVerilog as a language has moved further from > Analog, and the resolution of user types are done differently to Analog > * SystemVerilog, tho' based on the mixture of Verilog1995 and Superlog has > deprecated some syntax of Verilog and this would involve more rework on > Analog part of the language to make it in sync with SV. Discipline > resolution might under significant changes from its current std, and syntax > and semantics might need to undergo further changes. > * Is it not possible to sync up with Verilog2001 for the short term and > making concious decision based on SV when it comes to syntax and semantics > of the digital portion. This may not be that easy to execute. > > Moving towards SV > * If SV is going to be the digital standard for the future it would be good > for VerilogAMS to move towards SV sooner than later. It will be more > difficult to migrate the language at a later stage. > * However, since a cleanup of Verilog-AMS in terms of BNF, and having a more > formal grammer, needs to be done for the current Verilog-AMS version this > could be done as part of a coordinated effort with SystemVerilog. > > General points on SV vs 2001: > * Is there going to be two digital Verilog Standards in the future? This > question gets important because, if the current standardization of digital > is going down this path, then there might be a need for AMS versions for > both Verilog2001 std as well as the SytemVerilog Std. What is the future of > SystemVerilog. > * Is there a reason why SystemVerilog is not syncing with Verilog-AMS > instead of it being driven from the AMS committee? > * There is always going to be different dialects of the language thats going > to remain and have to be supported. Dealing with interoperability and > addressing that issue would be of a bigger concern. There is probably a need > for an interoperability standard between SV and Verilog2001. > * There is a need to identify the discrepancies between Verilog2001 and SV > to be able clearly understand the effect on Verilog-AMS > * Participation of few members from SV committee would have been more useful > in understanding why the language should move towards adapting SystemVerilog > as the digital standard. > > Should we donate VerilogAMS to IEEE as is? > * There is currenlty no IEEE working group for Verilog-AMS > * Moving towards IEEE would ensure that the committee works under more > formal rules in terms of changes made to the document, in terms of the > structure of the technical content, and the review process of the document. > * Procedures for review are stated explicitly under IEEE. > * Firstly, if the language needs to be donated, a PAR needs to be requested > to form a IEEE working group for VerilogAMS. > * However comment were made that the application for PAR and the > administrative procedure for moving the language can happen in parallel with > the current development efforts for future revisions of the language, as it > might take some time to setup the working group in IEEE. Who will do the > administrative work? > * Also, it looks like the same committee would be involved in working with > the IEEE version tho' the process might be bit different. > > > LRM Cleanup Plans > * Currently the grammer (BNF) is in a more narrative style than a more > formal definition of the language. > * The BNF for the AMS language is not complete > * There are few conflicts and contridictions to the digital counterpart when > it comes to expression grammer. The grammer should clearly identify reuse > from digital and which parts are deviating from digital and these should be > identified as part of the grammer, in the way it is constructed. > * The LRM committee is going to cleanup the BNF as a very high priority so > that it is consistent within itself and also consistent with the digital > BNF. This would be taken up very immediately by the technical working group > in the coming weeks. > > > RF & MEMS > * There is a great deal of interest to expand the scope of the VerilogA > modeling syntax to address some of the needs of behavioral modeling of RF. > * This can be probably handled as part of another subcommittee within > Accellera as part of Verilog-AMS > * The extensions to the language is expected to be rolled up under one > VerilogA language where the designer could relavent features based on > whether the model is a RF or Analog model. > * What are the current needs and requirements to support RF modeling as part > of VerilogA? > * It will be good to create a subcommittee with interested parties and they > can come back with recommendations to merge the technical extensions to the > current Verilog-AMS language standard. > > > Compact Modeling Support > * Agilent, Motorola, Expedion, Analog Devices, and Tiburon-da (European > based, spinoff from Agilent) seem to be very keen on extending the VerilogA > language to deal with compact model support and there is already some > initial work that has been happening > * The current language does not allow designers to deal with > - mfactors > - model parameters vs instance parmeters > - Usage of attributes - What are attributes - it was commented that > attributes are used to increase the efficiency and not to change or extend > the language > - shorting out of internal branches for efficiency reasons > * There is already a list of extensions that are being worked on to extend > VerilogA. > * It was suggested that this could happen more formally through a > subcommittee to derive the requirements for compact device models and > incorporate them in the current VerilogA standard. > > Need to look at RF & Compact models and identify subcommittees and members > to work on these individual requirements and recommendations as part of > Accellera. These subcommittees need to be formed so that there is formal > forum for members from different EDA groups and vendors can participate and > contribute to these efforts. > -- > Srikanth Chandrasekaran > Global Software Group, EDA > Motorola Australia > Phone: +61-8-8168 3592 Fax: x3501 >
This archive was generated by hypermail 2b28 : Wed Mar 19 2003 - 14:46:57 PST