Subject: RE: Verilog-AMS LRM Committee Meeting - Minutes
From: Vassilios.Gerousis@Infineon.com
Date: Wed Mar 19 2003 - 12:01:24 PST
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 - 12:03:09 PST