Subject: RE: Verilog-AMS LRM Committee Meeting - Minutes
From: Vassilios.Gerousis@Infineon.com
Date: Wed Mar 19 2003 - 22:50:28 PST
Hi John,
My message was not intended to be harsh. It intended to provide
clarification to a very confusing message.
The message was intended to stop the rumors that one company (ore two) are
trying to give Accellera a bad name.
Accellera standard will go to IEEE and this is a matter of fact. Seeing
messages below that one reason the committee is not considering SV, is
because Accellera does not want to send SV to IEEE. THIS MESSAGE is false.
Accellera will send SV to IEEE when it is ready.
There are many technical challenges that Verilog-AMS must solve. Any of
these technical challenges requires more volunteers and a consensus to be
reached at the technical level. That is why I insisted earlier that more
people must join to provide a better technical assessment. Thanks to the
chair and Jon, this was accomplished.
The technical challenges are as I understood it:
1- More clean up of Verilog-AMS : According to the email below the standard
still contains issues.
2- RF capabilities.
3- Device model development and interface.
4- MEMS.
So my hope that the committee focus on those issues and identify
people who really want to do these. This is the primary focus of the
committee. It helps to provide the Accellera board with possible technical
directions.
From the TCC chairs point of view, I rather see proposals for the
above technical challenges First. Second priority is what to link to. I
prefer to see technical analysis of what it takes for Verilog-AMS to link it
to IEEE 2001. And a similar analysis should be done for SV. Do the technical
assessment and let the Accellera board decide on the direction.
Vassilios
-----Original Message-----
From: John Shields [mailto:jshields@Synopsys.COM]
Sent: Thursday, March 20, 2003 4:19 AM
To: Gerousis Vassilios (CL DAT CS); 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@motorola.com;
brian.mulvaney@motorola.com; rwilson8@agere.com; sherrard@amis.com;
gbell@nassda.com; Geoffrey.Ying@Synopsys.COM; edcheng@Synopsys.COM
Cc: dennisb@model.com
Subject: RE: Verilog-AMS LRM Committee Meeting - Minutes
Hi,
Though it may stir more controversy, I think your message was unneccesarily
harsh,
Vassilios.
In order to discuss what is a meaningful next focus for this group,
the items reported were necessary,reasonable talking points. At issue is
how the
group should focus its next effort, not where the efforts will ultimately
lead. As such, focussing on bringing the standard to IEEE or toward
1364-2001 vs SystemVerilog is a fair matter of "what next", and not just
whether to do so
or not.
I am not trying to say that your points are not (in their intent) valid
either, but this is
an arrogant way to confront a community of volunteers.
Sincerely,
John Shields
-----Original Message-----
From: owner-verilog-ams@eda.org [mailto:owner-verilog-ams@eda.org]On
Behalf Of Vassilios.Gerousis@Infineon.com
Sent: Wednesday, March 19, 2003 12:01 PM
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@motorola.com;
brian.mulvaney@motorola.com; rwilson8@agere.com; sherrard@amis.com;
gbell@nassda.com; Geoffrey.Ying@Synopsys.COM; edcheng@Synopsys.COM
Cc: dennisb@model.com
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 - 22:54:07 PST