Subject: Minutes Verilog++ 7th committee meeting
From: David Kelf (davek@co-design.com)
Date: Mon Sep 10 2001 - 16:05:55 PDT
Verilog++ 7th committee meeting - Dave as minute taker.
September 10th, 2001
Attendees
(aaaaaaa) Vassilios Gerousis *
(ar-aaaa) Dave Kelf *
(a--aaaa) John Sanguinetti *
(ra-aaa-) John Emmitt
(a-aa---) Dennis Brophy *
(aaaaaaa) Stu Sutherland *
(--aaaaa) David Knapp
(aar-aaa) Tom Fitzpatrick *
(aaaaaa-) Phil Moorby *
(aaaaaaa) Anders Nordstrom *
(-aaaaaa) Cliff Cummings
(-aaaaaa) Simon Davidmann
(-aaaa--) Harry Foster
(a-a-aaa) Stefen Boyd *
(aaaaaaa) David Smith *
(-a--aa-) Mike McNamara
Attendance record key
a = attended, r = representative sent, - = not present
* beside name means attended this meeting - to make it more obvious
Agenda
Peter's Email Responses
Interface Writeup
Finish Chapter
Face to face meeting
Chapter Review
BNF only left to review - we need to review in light of the new docs. These
will be ready for the face to face meeting - therefore we do not want to
review this now - we will review in light of the new docs that will be
ready for this meeting from Stu
Interface Chapter.
Two things required -
1. More of an explanation of the requirement for interfaces and the purpose
of the capability.
2. Filling some of the holes.
Tom has filled the first requirement. Comments:
- Anders thought that Peter F's modport explanation should be included
- Should the use of processes be included in the introduction
- More examples required and existing ones improved. Light switch not very
realistic
- David - This new concept requires a fair amount of good explanation.
Check out SystemC. How does it fit with the simulation cycle - do we need
to describe.
- DaveK - lets leave this discussion to face to face meeting - can
everything think about the requirements we need for this chapter and then
at the meeting we need to decide how we can get this done.
- Stu - Has some reasonable ideas on what can be done here.
- Stu - Requires good definition of connections rules. Tom to talk with Stu.
Peter's responses to various questions.
Implicit Types
David - helpful but no recommendation as to how we deal with this issue
included.
What happens about abstract data types being implicit. This gets much more
complex. David and others think this would be useful, the major reason
being if the design is re configured does the designer have to go through
and change types right down through the hierarchy. Should we have an option
to define the default. However, this functionality will probably add in a
lot of complexity. What is the trade-off we want for this effort.
David to put together example and Tom will look at good solutions.
Face to face meeting
Monday 24th
Figure out roadmap
Agenda change
Assertion first at 10:00am followed by documentation discussion at 12:00,
followed by Verilog++ group at 2:00.
Assertion Requirements
Looking for feedback from this group. Someone from Co-Design (probably
Peter/Tom) will provide feedback
Press Release
DaveKto work on this week and get copy to folks participating.
Next meeting Sep 24th face to face at Mentor Graphics, as per the agenda
sent out by Vassilios already
Regards
Dave
______________________________
Dave Kelf
VP Marketing
Co-Design Automation, Inc.
Tel: 1 877 6 CODESIGN ext 404
Mobile: 1 617 571 9883
Fax: 1 781 662 2281
Email: davek@co-design.com
Web: www.co-design.com
www.superlog.org
Latest News:
http://www.co-design.com/news/index.htm
"Faster, Smarter Verilog"
______________________________
This archive was generated by hypermail 2b28 : Mon Sep 10 2001 - 19:26:32 PDT