Date: 11 January 2012

Attendees:

Ken Bakalar Mentor Graphics
Shalom Bresticker Intel
Sri Chandra Freescale
Geoffrey Coram Analog Devices
Dave Cronauer Synopsys
Marq Kole NXP
Scott Little Intel
Dave Miller Freescale
Brian Mulvaney Freescale
Patrick O'Halloran Tiburon
Martin O'Leary Cadence

Opening thoughts from Sri and current status of SV-AMS efforts

The committee has not met in a while and there has been lack of progress within the technical committee with regards to SystemVerilog/Verilog-AMS integration activities.

There has not been a critical mass of technical committee members volunteering to work on the SV-AMS integration efforts. The task of integration is big and requires reasonable effort by multiple people from the committee.

In terms of current status, activity started with the initial basic draft of integration of the BNF between Verilog-AMS and 1800-2009. Graham Helwig had completed this basic draft which had lot of notes and open items to be resolved, based on the approach from committee in terms of level of integration required. The draft BNF was also reviewed. Dave Miller started working on chapter 1 as an example of integration of SV and Verilog-AMS which could be reviewed. Initial effort was to include SV extensions into AMS - it was agreed by committee to use SystemVerilog as the base and add AMS extensions to it.

It is critical to understand the requirements from vendors and semiconductor organizations to understand the level of integration required - the fundamental question being - What exist today, is it enough? or is further integration requiired; if so to what extent - deep language integration vs ensuring people are able to write SV and Verilog-AMS which works together (interface level interactions)

Discussion on need for SV-AMS integrated language

Scott Little from Intel mentioned that there is definitely a need for using some aspects of SystemVerilog into Verilog-AMS. Workaround exists for some of the capabilities and tool providers provide some hooks; however there is definitely a case for having a coherent and standard base for SV-AMS language along with capability for assertions

Ken from Mentor commented that the key focus should be to increase the bandwidth of interfaces to the two languages. To this point, he felt "bind" as one of the critical requirements that will enable this where bind capability is provided as part of the Verilog-AMS language. Ken also commented that there is definitely a need for enabling SV assertions as part of AMS blocks. Industry is moving towards cross-instantiations and where extensions are required for Verilog-AMS to include select features of SV.

Martin O'Leary from Cadence felt that there was a need for a deeper level of integration to allow for SV-AMS behavioral modeling and be able to use some of the rich constructs of SV; ability to access voltage and current in SV modules; ability to define mixed signal ports (concept of discipline in SV?). Also users are using SV for testbenches where there is a need for SV-AMS.

Mixed Signal Assertions sub-committee activity

This sub-committee was looking into more research aspects of analog/mixed signal assertions and looking at some of the more fundamental aspects. The committee reached a stage of finalizing a set of requirements and after that based on lack of effort to work on specific problems prevented any further progress.

Scott commented that if the aim is to just look at being able to use SV assertions inside Verilog-AMS that should be more straightforward - the sub-committee was not looking into that aspect of AMS assertions.

Call for Donations

Implementers have done extensions to existing language to support the customer base (internal/external) to enable them to do simulations of SystemVerilog with Verilog-AMS. These might be in the areas of cross instantiation or extensions to Verilog-AMS langauge from SV?

Sri commented that instead of working from scratch in terms of integration we could look at possible donations and use that as a good starting point for this integration activity; this will possibly prove to be more effective and reduce some of the cycle time and effort based on effort that has already been invested.

A list of high level requirements will be sent out based on today's discussions for moving forward and seek for donations addressing any of these requirement. It was felt that this might be a reasonable approach to take and there was some willingness for people to share the extension effort done in their implementations.

Verilog-AMS extensions, bug fixes in existing version not related to SV

How will this be done?

Marq wanted to understand about Verilog-AMS extensions as part of language development. These extensions will be captured along with the SV integration efforts.

The methodology for putting Verilog-AMS extensions will not change; Mantis will still be used to capture the requirements and we will make changes to the body of the document which will get reviewed and approved by technical committee.

How will the documentation/editing work be done going forward

Accellera worked with IEEE and has got approval to use the frame source of SV 1800-2009 language standard. This document has already been provided to Accellera by IEEE. This document will be used as the base for doing SV-AMS.

Approach is bit different to Verilog-AMS where all digital aspects where included/referred into the Verilog-AMS document. Going forward all AMS extensions will be added to the 1800-2009 document. This has been agreed upon by the technical committee.

Next release: Accellera v IEEE

Marq wanted to understand regarding how the release of Verilog-AMS extensions (improvements/extensions to current standard possibly not connected with SV integration) be done.

The plan at this point is to do all the initial technical activities, developing the draft version of standard and initial review of technical committee within Accellera. This will include both System Verilog integration requirements that have been identified and Verilog-AMS enhancements/bug fixes.

Once a draft is ready, the current plan is to raise a PAR (Project Authorization Request) and seek to donate this language to IEEE, as part of a 1800 dot standard.

Next steps

Set of high level requirements (category of requirements) will be posted to the reflector, seeking for feedback and also seeking for donations from companies which address these requirements.

Once requirements are understood there will also be a call for volunteers to participate, show of hands to work on various aspects of language integration. Unless there is sufficient volunteers working on this activity, this effort will be very difficult to achieve.

Topic revision: r1 - 2012-03-13 - 16:06:26 - DavidMiller
 
Copyright © 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback