minutes of Accellera HDL+ committee meeting on systemverilog 3.1 5th June 2002 at snps


Subject: minutes of Accellera HDL+ committee meeting on systemverilog 3.1 5th June 2002 at snps
From: Simon Davidmann (simond@co-design.com)
Date: Thu Jun 13 2002 - 16:06:15 PDT


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]

##



This archive was generated by hypermail 2b28 : Thu Jun 13 2002 - 16:13:09 PDT