=================Attendance=============================
20 Day
17
00 Month
44
00 Year
88
-a Arturo Salz - Synopsys
a- Abigail - Mentor
-a Bassam Tabbara - Synopsys
-a Brad Pierce - Synopsys
aa Cliff Cummings - Sunburst Design
aa Dave Rich - Mentor Graphics
aa Dmitry Korchemny - Intel
a- Don Mills -
aa Eduard Cerny - Synopsys
aa Erik Seligman - Intel
aa Francoise Martinolle - Cadence
aa Gordon Vreugdenhil - Mentor Graphics
a- Jin Yang - Intel
aa John Havlicek - Freescale
-a Jonathan Bromley - Doulas
-a Karen Pieper - Accellera
aa Lisa Piper - Cadence
aa Manisha Kulshrestha - Mentor Graphics
aa Mark Hartoog - Synopsys
aa Mehdi Mohtashemi - Synopsys
aa Mirek Forczek - Aldec
aa Neil Korpusik - Sun Microsystems
a- Ray Ryan - Mentor
aa Shalom Bresticker - Intel
aa Steven Sharp - Cadence
aa Stu Sutherland - Sutherland HDL
aa Surrendra Dudani - Synopsys
aa Tom Thatcher - Sun Microsystems
====================Agenda==============================
Agenda:
1. Review the patent policy
2. Approve the minutes from the April 7, 2008 meeting
Attached are the minutes from the first meeting.
3. Election of committee chair
We have a nominee (thank you Erik)
4. Review of action items
5. List of Mantis items to be addressed
1. 1900 - checkers
2. 2088 - allow covergroup in checkers
3. 2089 - allow final block in checkers
4. 2110 - Allow checkers in procedural for loops
5. 2182 - Elaborate VPI diagrams for checkers
6. 1995 - Allow concurrent assertions in for loops
7. 1728 - let statement
6. Next meetings
Possible f2f meeting
May 5, 2008 9am-11am - next conference call
** Minutes taken by Tom Thatcher and Neil Korpusik ////////////////// April 21, 2008 /////////////////////////
Agenda:
-------
1. Review IEEE patent policy
-------------------------
ref: http://standards.ieee.org/board/pat/pat-slideset.ppt
2. Approve the minutes from the April 7, 2008 meeting
Attached are the minutes from the first meeting.
Link - is the one that Erik sent out.
Move: Erik - approve the minutes from April 7
Second: Cliff
Passed unanimously
3. Election of Chair/Co-chair
Move: Cliff - Nominated Erik Seligman (Intel) as chair
Second: Dmitry
Passed unanimously
Move: Cliff - Nominated as Tom Thatcher (Sun Microsystems) as co-chair
Second: Gord
Passed unanimously
4. Review of action items
AI/All - come to the next meeting with nominees for the Chair
position.
Erik was the only nominee.
AI/Neil - we need an email alias for this group
This has been set up
Not everyone that was in the first meeting is on the alias yet.
AI/Dmitry - possibly distill down to a set of requirements.
Completed and is now on the web page.
AI/Dmitry - send out his slides
- <not done>
AI/All - read 1900 - 2 part proposal
AI/Dmitry - list of reasons why existing constructs can't be used - why not
straight-forward.
AI/Gord - put together his list of issues
It was sent this morning (04/21/2008)
AI/Steven - put together his list of issues with procedural code
<not done>
AI/All - contact Erik for permission to update the Wiki page
erik.seligman@intel.com
Logistics
Erik - wants to meet weekly to keep the attendees focused.
Dave - thinks that would be a good idea.
- The other committees could possibly shrink their meetings
down to 1 hour.
Cliff - ok with taking the 9am-11am slot
Dave - there will be some work when next draft comes out.
Stu - there will be a lot of bc mantis items in draft 5
Mehdi - ok as long as we can get time if needed.
AI/Cliff - notify Matt of this decision
Move: Cliff - hold weekly meetings from 9-11 on Mondays
Second: Dave
Passed unanimously
Erik: Suggests a face-to-face meeting
Cliff: Want to have EDA vendors representitive
Erik: Don't want to hold it at DAC: Probably hold in the Bay area
Possible sites:
Bay area: Cadence people couldn't come
East coast: Many bay area
Seems like Bay Area would have the highest attendence
Date:
Erik suggests week of May 12, possibly a 2-day.
Stu can't make that week.
AI: Erik will mail out possible locations, dates, and we'll have
members e-mail back their availability
Change to Agenda:
3. Modify item #5: rather than going through the Mantis items in order,
due to the nature of this committee, perhaps we should try to focus on
specific goals at each meeting that will move us closer to conensus. I
suggest we attempt to focus on the following for this meeting:
- Concurrent assertions in procedural code: Come to an agreement on
accepting the SVA2005 definition of assertions in procedural loops and
moving forward, or agree that we really are reopening this.
- Checkers: Agree on the motivations and goals for checkers, as
described by Dmitry, or define any additions / corrections /
restrictions needed.
- Let: Attempt to resolve the open discussion issues with 'let',
with the goal to try to agree on a revised proposal by the next meeting,
so we can then focus on checkers.
Technical Issues
1. Should we revisit the issue of concurrent assertions within procedural code?
Steven - It's broken: It would be much easier to remove it than to fix it.
Gord - Feels that there is a shaky foundation.
Dave - There is definitely stuff that needs to be fixed.
Stu - Removing feature may have fewer side effects
- Feature is deprecated, put into an annex, tools have option of
supporting feature.
- Feels that putting assertions in procedural code is bad style.
- Also, there are tools which do synthesize assertion constructs.
This usage will grow
Dmitry - This shouldn't be a big problem. Feels that concurrent
assertions are a useful feature
Steve - One possiblitity would be to prevent assertions from
referencing
any variables assigned by blocking assignments.
Cliff - Could attributes be used for assertions? Attributes
would need to
be string based. Could we put assertions inside them?
Gord - Would have lots of issues with this: There are ways that
assertions could feed back to design. Attributes should not
affect simulation.
Dave - This is similar to how PSL is handled now.
AI: Dmitry will write up proposals for restrictions.
AI: Steven will try to add proposed directions in his writeup
John - One idea might be to have a new "$unsampled()" function
specifically for assertions. This would cause assertions to see
a value sampled after the active region.
2. Review of Dmitry's document on Motivation and Requirements for Assertions
Dmitry - Went through his e-mail
Dave - Would like to go through in more detail
- Why are modules not sufficient?
- We could extend modules to allows sequences/properties as ports.
- Synthesis: There's a more general issue: How do you specify
that certain code is not part of design to be synthesized?
- Would also like to allow concurrent assertions in functions:
- Formal verification support: This issue should definitely be
separated out.
Gord - Clearly not all modules are synthesized. E.g. testbench
files.
Tom - Clarify: The free variable feature is what's needed for
formal modeling. Checker construct is not really necessary
for formal modeling.
Gord: - Seems that main reason for checker is that you don't like
instantiation syntax of modules.
Could we use modules?
Mark: - Would be opposed to allowing module instantiations in
procedural
code.
Gord: - Agreed.
Gord: - Are there semantics of checker that are inexpressible in any
other current constructs?
Erik: - What are the directions?
Gord: - Assumptions about inlining semantics of checkers
- Is it possible to describe without this inlining?
- Would be a lot more happy if there were no inlining semantics for
checkers..
- Has concerns about untyped, and inferences, scheduling semantics
AI: Gord to send an email about differences between inlining,
and non-inlining semantics for discussion
John: - What is your feeling about removing inference capabilities
for checkers
Dmitry: - Opposed
Defer rest of of agenda items to next week.
Reminder to everyone to subscribe to sv-sc mailing list.
Next Meeting: April 28, 2008 9am-11am (PDT)
Meeting adjourned.
--
ErikSeligman - 25 Apr 2008