I would say that SV integration is about as far along now as it was a year ago, or probably less likely given Gord's successful efforts at convincing everyone that Verilog has VHDL port/resolution semantics and the concomitant "interconnect" proposal. Exercises in polishing grammar prior to being a proper part of the IEEE effort are (IMO) pointless.
So, since nothing else seems to be going on I would suggest revisiting analog back-annotation and power connections for connect modules, so at least we can do some better verification in power managed design flows.
Another useful exercise might be moving the built-in primitives into user space, i.e. providing Verilog-AMS descriptions of primitives such that you can run a simulator with alternate implementations.
A clean API into C++ (for SystemC integration) might also be useful. I'll propose just making the old PLI "opaque handles" pointers to C++ objects so that it's entirely backward compatible.
Or to put it another way: I see no enthusiasm for integrating analog into SV from the SV side, so why not develop Verilog-AMS as a good standalone standard with the goal of accurately simulating hardware and leave the UVM/OVM level verification to the C++ guys. A good C++ API will enable integration with other languages for anyone that wants to do it.
Kev.
On 02/06/2012 03:38 AM, Sri Chandra wrote:
> Hi all,
>
> Based on the last call held on 11th Jan, I have categorized the changes required for the next revision which addresses the issue of integrating System Verilog 1800 standards with Verilog-AMS LRM 2.3.1 standard.
>
> I have broadly classified the requirements into 3 major categories
>
> 1. SV-AMS interface requirements: Set of requirements required to be implemented to allow simulation of designs that contain both SV and Verilog-AMS blocks (modules). The focus here is enhancements to the SV language that are required to allow at a minimum co-simulation of System Verilog with Verilog-AMS (AMS/Spice) - this would include (but not restricted to) requirements for allowing continuous ports and connect module instantiations, bind keywords etc as part of the integrated SV-AMS language.
>
> 2. Integration of Verilog-AMS syntax/semantics w/ System Verilog 1800 standard:. As part of integration of the AMS grammer into SV these requirements will focus on changes required to Verilog-AMS to support an unified SV-AMS grammar and adaption of SV syntax where appropriate and will also focus on conflict resolution while integrating SV with Verilog-AMS grammar.
>
> 3. Verilog-AMS analog extension: Extensions to Verilog-AMS that have been proposed to enhance existing capabilities of the mixed signal language. These set of requirements would also include any bug fixes, correction that are present in the current LRM 2.3.1 language. These fixes and enhancements would be included and planned to be released as part of the SV-AMS release.
>
> I would like to take this opportunity also to request for donations from organizations and individuals which address any of the above requirements which can be used as a starting point for our discussions. In case there are multiple donations and proposals for these requirements we will follow the appropriate process to review all donations/proposals and take a consensus on moving forward with the set of required features and proposals. The donation window will be open for a period of 6 weeks, till mid-March (16th March).
>
> Regards,
> Sri
> --
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean.
-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Fri Mar 30 00:49:55 2012
This archive was generated by hypermail 2.1.8 : Fri Mar 30 2012 - 00:50:08 PDT