Verilog-AMS committee meeting minutes - 8 Sept 2010

Attendees:
Achim Bauer
Geoffrey Coram
Ian Wilson
Graham Helwig
Ken bakalar
Scott Little
Sri Chandra
Martin O'Leary
Dave Cronauer
Dave Miller
Started from A.0.2.1 port declarations
* How to handle wreal and real?

    * can wreal be treated just as AMS only extension or integrated within SV
      grammar
    * Currently sv-dc committee is addressing "equivalent" wreal syntax within
      systemverilog
          o enables modeling analog components for discrete simulator which
            requires a real type that is obtained within an aggregate (with
            driving/loading strength)
          o there might be a real port type and has built in resolution
            function with X/Z state; it would be a very simple type;
            simplification of more powerful systemverilog type
          o possibly some user defined aggregate types
    * leave wreal it as a placeholder for the time being in port declaration
      which needs to be clarified; need to understand the work done by sv-dc
      committee and also implications of just maintaining it as a backward
      compatible element
    * resolution functions on wreal - how? does the donation address this?
      required to resolve issues like real-wreal connectivity digital 0/1-wreal
      connectivity
    * Is the drive strength supported for wreal? (In current AMS LRM 2.3.1 - no
      its not.)
    * Clarified that the integrated version of grammar developed by Graham does
      not take into account Cadence wreal proposal at this stage

* How about discipline identifiers in port declaration. Should it be handled as
part of net_port_type?

    * can this be pushed down rather than appear in top level syntax - how and
      where?
      - data or net declaration; not a simple issue to add this
    * configuration? sv-dc is not looking at disciplines currently. This is not
      part of the requirements list. Achim was wondering whether this should be
      raised within SV-DC committee
          o Scott mentioned that its likely sv-dc committee may not look at
            disciplines
          o this capability is required for enabling multi-power supplies.
            Now this information is back annotated

* Discussions on real and reg declarations

    * The concept of a reg has become obsolete in SV and are nothing more than
      a variable..
    * They are not specific net types and hence these declarations are not
      found in the grammar.

* net_declaration discussions

    * can ground be an optional syntax? It should appear before the discipline
      identifier - it is consistent net_type net declaration

* analog function declaration

    * It was mentioned that it would be nice to have common domain user defined
      functions.
    * Should we remove the restrictions on calling a digital UDF from the
      analog context or an analog UDF from the digital context.
    * If not all features of a digital UDF can be supported in the Analog
      domain, can they be semantically restricted based on the context of the
      UDF call?
    * Mantis Item: 3198 has been raised to track this.

* SV manual availability to committee members?

    * this manual is purchased at cost from IEEE hence cannot be hosted in
      public website
    * need to check with Karen whether this can be distributed within active
      committee members for SV-AMS integration development?

Stopped today at block_item_declaration (A.0.4).
Next call will be in 2 weeks: Wednesday 22nd Sept 2010

Regards
Dave

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.