Subject: Fwd: minutes of Accellera HDL+ committee meeting on systemverilog 3.1 5th June 2002 at snps
From: Stuart Sutherland (stuart@sutherland-hdl.com)
Date: Thu Jun 13 2002 - 21:32:34 PDT
All,
I would like to add to Dave's minutes the notes I took on how the issues
were divided into the subcommittees. I sent this list to Vassilios to add
to the minutes shortly after our meeting, but I understand he has had
difficulties with e-mail while traveling. Please note that the "buckets"
I've listed were based on my feeble memory. Vassilios has the official
list of what issues were placed in which bucket. The assignments to the
various subcommittees is accurate--I made those notes as the divisions were
determined during the meeting.
Stu
Clean-up issues with 3.1 from the 5 Jun 2002 issue list:
COMMITTEE BUCKET ISSUE
BC basic a. Deprecation follow on
BC basic b. Time precision and timescale in general
BC system n. Dynamic process control
BC basic r. DSM
BC basic s. Data alignment and data packing issues
BC basic - Clarify auto increment/decrement
BC basic - Cadence issues w/ Section 2 literals
BC basic - Cadence issues w/ Section 3
BC basic - Section 3.1, parameterized data types
BC basic - Displaying enumerated types, affect on VCD
BC basic - Section 4: are elements of a signed packed
array signed?
BC basic - Constant expressions
BC basic - Change BNF to simplify attributes--for 1364
committee?
BC system - Section 9: process execution efficiency
BC basic - Interleaving, event scheduling
BC basic - Constant expressions
BC interfaces - Interface enhancements/simplifications
Proposed Extensions to 3.1 from the 5 Jun 2002 issue list:
COMMITTEE BUCKET ISSUE
EC interfaces c. Data channels
EC system d. Pointers
EC mixed-signal e. Force/release with strengths
EC basic f. FSM (original ESS donation)
EC basic g. Extern modules
EC? system h. OO
EC basic i. Data path (possible Cadence donation)
CC system j. C-blend / DirectC capabilities
EC basic k. Alias
EC basic l. Inherited declarations
EC basic m. Multi-clock FSM
CC system o. API/PLI
AC verification p. Temporal logic
EC basic q. Inferred reg types
BC = Basic Committee (primarily clarifications & minor extensions to 3.0 LRM)
EC = Enhancement Committee (primarily modeling enhancements to 3.0 LRM)
CC = C/C++ Committee (primarily C language, API, PLI enhancements to 3.0 LRM)
AC = Assertions Committee (primarily verification enhancements to 3.0 LRM)
>X-Sender: his-home@pop3.demon.co.uk
>X-Mailer: QUALCOMM Windows Eudora Version 5.1
>Date: Thu, 13 Jun 2002 16:06:15 -0700
>To: vlog-pp@eda.org
>From: Simon Davidmann <simond@co-design.com>
>Subject: minutes of Accellera HDL+ committee meeting on systemverilog
> 3.1 5th June 2002 at snps
>Sender: owner-vlog-pp@eda.org
>
>As I have not seen any minutes for this meeting that was over a week ago,
>I thought I would send out my notes.
>Also nobody has sent out any of Vassilios' slides or the Synopsys
>technology directions ideas slides.
>Simon
>
>I apologise for any spellings, incorrect names etc - these are just my notes.
>
>people in meeting room
>grant martin cdn - observer
>jo daniels - tech pups
>rich goldman - snps - observer
>
>karen peiper - sim dev, now synth, ieee behave
>paul graham cdn synth vhdl
>serge? - system level design
>david smith - avanti - mixed signal
>asan? novas
>jayant nagda - snps, vhdl sim
>stu sutherland - sim user, ieee
>stefen boyd - user - ieee
>harry foster - sim, formal
>dennis brophy
>
>people on phone
>cliff cumming - user - ieee, chair behave
>erich marchner - cdn vhdl, formal
>simon davidmann - co-design
>steve sharp - cdn ieee behave
>dave kelf - verilog sim, co-chair hdl+
>adam krolink - LSI, , user, ieee behave
>drew lynch - vcs pli, ieee
>mike mcnamara - verisity, vcs, ovi, ieee chair
>karen bartleson - sim at ti, standards comittee, accellera board
>peter flake - co-design hilo, verilog, ieee, superlog
>david lacey - hp, chairs assertions committee
>tom fitzpatrick - co-design, verilog, ieee, co-chair assertions
>
>simon's notes:
>- no agenda foils sent out, nor any that vassilios presented
>
>- mikem - spirit of the PAR in IEEE as an HDL - so new extensions will not
>be accepted by that miss this PAR
> we need to be very careful not to extend out of scope - we must focus
> and add value
>- Dennis - we could always change the PAR.... - we need to be very careful
>- Steve sharp - could get new PAR, new standard, then not need to be
>compatible
>- Vassilios - voting rules changing - company voting from now on and IEEE
>guys vote as individuals, TCC changes the voting rules
> 3 out of last 4 meetings must be attended, can have proxy attend and
> can vote
>[nobody was warned before meeting this would happen, this was not on the
>agenda of the meeting sent out before the meeting]
>[surely it is not the TCC that can just change the rules when he wants]
>
>- david lacey - update on ovl - trying to make it an ieee standard
>library, want procedural elements
> trying to get an LRM done - working on verilog, thinking of vhdl
> subcommittee - but not his focus
>
>- erich et al went through issues into buckets
>
>buckets allocations:
>basic: in focus of 1364
> deprecation - no items needed at this point
> time precision, form of time expressions
> Extern modules ($root, modular compile)
> Datapath enhancements (got proprietary stuff in cadence, want to donate)
> Interfacing to "foreign" languages - e.g. VHDL and C/C++,
> API/PLI/C-interface, alignment of structures
> Alias capability
> implicit reg declarations: Alternative to declaring (or not) one bit
> regs, regs in general, etc
> inferred declarations
> DSM issues 1364, -ve timing constraints
> section 2 literals
> section 3 keywords
> type use before declaration
> Parameterized data types
> Implications of Enum type I/O
> VCD needs fixing
> Passing large structs/arrays
> Packed array of signed
> Constant expression
> Interleaving of execution, Scheduling Algorithm
> Interfaces vs. Modules - and lots of issues - 6 major issues
> semantics of auto incr/decr clarify
>
>system: (future)
> data channels (abstract modeling of data communication beyond hw
> description)
> Pointers (reduces the PLI) (Passing large structs/arrays)
> Object Orientation
> Interfacing to "foreign" languages - e.g. VHDL and C/C++,
> API/PLI/C-interface, alignment of structures
> Dynamic process naming and control
> State Machines, Hierarchical, multi-clock FSMs
>
>mixed signal
> Force Release extensions for strength etc (signal resolution, for
> mixed signal)
>
>verif, assertion
> Object Orientation
> Temporal Logic
> unification of syntax of assertions/semantics versus sugar
>
>Jayant Nagda of snps - presented
>----------------------------------------
>[almost impossible over the phone to know what was going on]
>[no foils sent out in advance]
>notes on what was said:
>
>basically ideas of directions that systemverilog could grow into
>stressed this is not detail, nor anything specific about donation, just
>directions and ideas
>
>verification users need better testbenches [of course - that is why people
>have adopted vera/specman/testbuilder]
>
>assertions are for formal/static
>C interface
>proposed API: all interacting via PLI
>motivation for accellera is standards for current and future requirements
>systemverilog is a good platform
>needs to be comprehensive and complete
>
>testbench features:
> verilog - for gate level, few features for testpattern
> feels we need to extend testbench
> what are features needed: expect automatic creation of dynamic objects
> handshakes, semaphores, lists, mailboxes
> advanced control constructs - fork/join
> assertions start/stop
> reactive tests
>[seems like we don't really need all this as it is already available to
>verilog users in vera/testbuilder]
>[not verilog syntax all this - it is something different - vera]
>
>assertions are independent of implementation - write once and not many times
> wants them written in one language [of course that is what DAS is]
> temporal language to do this....
> needs to be "compatible" with verilog...
> [usage model is same as systemverilog DAS - why would he propose
> something new - we already have DAS in systemverilog?]
> needs coverage of assertions
>proposal - unifying this lots in systemverilog - bringing some of the
>temporal expressions in and multiple clocks
>
>C
>direct interface for calling C functions from verilog
>direct interface for calling verilog functions from C
>today PLI does data conversion
>embed C in code directly into Verilog
>[seems like this is proprietary VCS interface, not really a language thing?]
>
>extended API
>goes further than just adding pli functions
>need better ways of interacting with the simulators
>(this is proprietary API, again not a language issue? ie not a
>systemverilog thing - there is another committee for this lot?]
>he said it is needed to add new tools to the simulator (said needed for
>systemverilog - but I cant see why?)
>
>discussion:
>issues: - testbench - we have vera, verisity, testbuilder, rave, c++,
>systemC - lets not get into that issue for now
> - new committee
>issues - assertions - got vformal committee for that - so that is where we
>should put all that
>issues C interface - PLI extensions needed - real issue is better systemC
>interface
> - need to get the other api committees involved.
>
>systemverilog 3.1 targets
>get feedback from implementations of 3.0 and cleaning them up
>extensions from several places
> committee approved issue list
> from donations, snps, cdn - datapath
>if appropriate and meet the timescales
>original target is dec 2002
>maybe we could extend?
>
>
>vote:
>limit 3.1 work as working on basic bucket
>harry - no
>alec ieee - no
>stu ieee - no
>snps - no
>novas - no
>cdn - no
>cliff - ieee yes
>mac - verisity yes
>simon - yes
>real intent - abstain
>
>committees that vassilios wants, and people he has chosen to run them
>assertion committee will need to look into assertions
> OVL
> sugar/DAS compatibility will be done by the chairs of the committees
> direction and focus on direction.... and then requirements (Tom
> will co-ordinate)
>create an issue list clean up sub committee for 3.1 (chair = Cliff = think)
> for prioritizing lists
>create new sub committee - C/C++/PLI/interfaces with systemverilog (chair
>= Stu) [surely this should merge with SCE-API guys]
>create new sub committee - systemverilog language enhancements (chair = ??)
> system
> verification [this should be new top level committee - alongside HDL+
> - maybe an HVL+ committee??]
>
>MikeM plan for IEEE
>should start in Aug
>lots of errata in v2001
>likes 3.0 and agreed delayed to start IEEE till this fall based on 3.0
>implementations
> to work on cdn /snps/ment implementation experience
>if accellera goes off extending it and delaying etc - then he will take
>3.0 and turn it into IEEE
>and warns that accellera should not go off and build a different language...
>he warns not to go off at a tangent
>when IEEE starts then the IEEE guys go work on that
>
>vote:
>whether new committees to focus on new topics should be created
>C i/f (stu)
>enhance - chair open - pick later
>cleanup - (open)
>proposed
>co-design - no
>verisity = no
>snps = 2nd, yes
>cdn = yes
>mentor = yes
>verplex = yes
>novas = yes
>cliff abstain
>stu yes
>alec yes
>real intent - yes
>
>milestones
>target 2002 december
>each committee - needs to come back with what it wants to do in the time
>main committee will meet once a month
>subcommittees is 1 month after dac to establish 1st milestone - july 15th
>
>vote
>limit freq of meetings so participants keep meeting total at less than 8
>hours per week and finish before 4pm pst
>verplex - yes
>alec - yes
>snps - no
>novas yes
>mentor no
>cdn yes
>cliff yes
>drew yes
>co-design yes
>real intent yes
>stu yes
>
>[problems Vassilios - he feels he can change voting rules - without vote]
>[problems Vassilios - he feels he can create new committees without board
>approval]
>[problems: Vassilios - he feels he can assign chairs of committees -
>without committee vote]
>
>##
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Stuart Sutherland Sutherland HDL Inc.
stuart@sutherland-hdl.com 22805 SW 92nd Place
phone: 503-692-0898 Tualatin, OR 97062
www.sutherland-hdl.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This archive was generated by hypermail 2b28 : Thu Jun 13 2002 - 21:22:23 PDT