Re: Minutes of Verilog-AMS LRM call (9th Sept)


Subject: Re: Minutes of Verilog-AMS LRM call (9th Sept)
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Wed Sep 11 2002 - 09:45:18 PDT


> From owner-verilog-ams@server.eda.org Wed Sep 11 01:01:09 2002
>
> Attendees: Sri, Graham (Motorola), Martin, Jon (Cadence)
> Date: 9th Sept 2002
>
> * The freeze date for LRM changes have been moved from Sept 16th to Sept 23nd.
>
> * The following issues will be discussed next monday and the monday after
> that. Any proposal updated in the LRM document not submitted before Sept
> 22nd shall not be reviewed as part of 2.1.
>
> 1. Support of instantiating digital primitives in analog blocks

What was the issue?

> 2. `default_discipline usage dealing with digital and analog primitives
> 3. wreal issues with the current LRM

Personnaly I'm tempted to leave this one for later. wreal should be depracated
in favor of "typedef wire real wreal" when we merge with System Verilog - any
type should be capable of being bound to a single wire, and the connect/resolution
scheme can be extended to use typedefs as well as disciplines.

> 4. sychronization updates from Martin
>
> - Issues 1, 2 have been previously submitted to the LRM committee in textual
> format. However for review purposes these are to be updated in the
> relavent sections of the LRM and reviewed. These two are expected to be
> reviewed for 16 Sept
>
> 5. closure on the `include proposal sent by Kevin.

I'd like to amend that proposal to use square brackets instead of angle
brackets since there is a potential clash with C code i.e. you'ld use

 `include [disciplines.vams]

If System Verilog wants to have it's own standard includes it can use []
too or maybe {}.

(I'm not planning to resend the LRM version)

> * The BNF for the LRM is being reworked upon because the current BNF is
> 1. incomplete
> 2. Not very clear when it comes to digital/analog definitions
>
> - Graham has been working on reworking the AMS BNF taking into account the
> current 1995 std reference for digital to come up with a more cleaner and
> implementable BNF.
> - It was decided that since its a fairly big cleanup it may not meet the
> Sept 22nd deadline. So this will be the major activity post 2.1 release
> - New updated BNF for Verilog-AMS will be released as a LRM 2.2 version
> before the end of the year.
>
> * Hope to have version 2.1 of LRM sometime in October.
>
> Next call: 16 Sept 2002
>
> Sri

Was the last rev of the scheduling section OK, or does it still need work?

BTW, should the next objective after 2.1 be the merging of Verilog-AMS with
System Verilog or what? If folks do want to merge the two it would be best
to do it as part of SV 3.1 and maybe leave detailed cleanup to the IEEE
committees. (Maybe discuss at next meeting?)

Regards,
Kev.



This archive was generated by hypermail 2b28 : Wed Sep 11 2002 - 09:46:13 PDT