Subject: RE: Minutes from Assertions/OVL meeting 11/20
From: Sean W. Smith (sesmith@cisco.com)
Date: Tue Nov 27 2001 - 10:49:42 PST
That works great for me....
Sean
Sean W. Smith ASIC Design & Verification
sesmith@cisco.com Cisco Systems, RTP, NC
seansmith@nc.rr.com Empowering The Internet Generation
http://qcontinuum.tzo.com/sean for PGP key and more information
http://www.fototime.com/inv/23BD67820A2B057 for Lots of Personal Photos
-----Original Message-----
From: John Emmitt [mailto:johne@verplex.com]
Sent: Tuesday, November 27, 2001 12:37 PM
To: 'Sean W. Smith'; 'Harry Foster'
Cc: 'assertion@eda.org'
Subject: RE: Minutes from Assertions/OVL meeting 11/20
All,
How does Tues 12/4 at 10:30am pst work for an OVL mtg?
John
-----Original Message-----
From: Sean W. Smith [SMTP:sesmith@cisco.com]
Sent: Monday, November 26, 2001 4:12 PM
To: John Emmitt
Subject: RE: Minutes from Assertions/OVL meeting 11/20
John,
Wednesday doesn't work for me anytime. Any other day would be great....
SEan
-----Original Message-----
From: John Emmitt [mailto:johne@verplex.com]
Sent: Monday, November 26, 2001 4:09 PM
To: 'Sean W. Smith'; fitz@co-design.com; assertion@eda.org
Subject: RE: Minutes from Assertions/OVL meeting 11/20
Hi Sean,
No, there was no discussion on OVL at the last meeting. We focused entirely
on the Assertion Requirements. I would like to schedule a meeting to focus
solely on the OVL and the changes we need to decide on for the year-end
release. Those who are interested in this mtg- let me know whether Wed 12/5
at 9am pst is OK. Thanks.
Regards,
John
-----Original Message-----
From: Sean W. Smith [SMTP:sesmith@cisco.com]
Sent: Monday, November 26, 2001 2:57 PM
To: fitz@co-design.com; assertion@eda.org
Subject: RE: Minutes from Assertions/OVL meeting 11/20
All,
Was there any discussion of OVL during the last meeting. I apologize but I
had to leave after 1 1/2 Hours. If not when is the next scheduled OVL
meeting...
Sean
-----Original Message-----
From: owner-assertion@eda.org [mailto:owner-assertion@eda.org]On Behalf
Of Tom Fitzpatrick
Sent: Tuesday, November 20, 2001 3:55 PM
To: assertion@eda.org
Subject: Minutes from Assertions/OVL meeting 11/20
Attendees:
Key: 'a'=attended in person;
'r'=represented by replacement;
'-'=skipped;
'.'=not yet participating;
'?'=unknown;
'*' indicates voting member (by "3 of last 4 meetings attended" rule)
(a--a) Tom Anderson 0-In
(------a-a) Susan Wong Axis
(--a) Dan White Axis
(a--a) Sean Smith Cisco
(a-aaa-aaa) Henry Cox* Co-Design Automation
(aaa--a) Simon Davidman* Co-Design Automation
(aaa-a) Tom Fitzpatrick* Co-Design Automation
(---a) Peter Flake Co-Design Automation
(----a---a) Dave Kelf Co-Design Automation
(---aa----) Sean Dart Forte Design Systems
(---------) Steve Sutherland Forte Design Systems
(--aa) Vassilios Gerousis Infineon
(aa) Prakash Narain Real Intent
(a) Rajeev Ranjan Real Intent
(a) Rajiv Kumar Real Intent
(aa) Steve Pollock Real Intent
(-----a-a) Jerry Vauk Sun
(---aa-a-a) Claudionor Coelho Verplex
(aaaaaaaaa) John Emmitt* Verplex
(aaaaaaaaa) Harry Foster* HP/Verplex
(----aaaaa) Michal Siwinski Verplex
(-aaaa-a) Richard Stolzman* Verplex
(a) Dan Lacey HP
Next meeting: Friday, 12/7 at 12:30pm EST (9:30am PST).
(405)244-5555
passcode: 3715
Comments on Harry's Assertion Requirements Spec
------------------------------------------------
Section 1 - Introduction
The basis of the intro section is to position the work of this committee
relative to the VFV committee.
Rajeev Ranjan - 2.2.2 Liveness
The definition section will be removed.
Requirement to express assertions that may not map to FV?
Example: assert_quiescent_state
Prakash - semantics need to be explained to show what maps to FV and what
does not. Harry: just as a subset of Verilog is synthesizable, a subset of
assertions should be FV-able.
Initial effort will be limited to synchronous assertions, and then later we
may add simulation-specific asynchronous assertions.
Timeline:
Assertions donation to occur in December to line up with SystemVerilog
committee. This will give language experts on SystemVerilog to "move over"
to also consider the assertions and how they fit with the SystemVerilog
extensions. There will be one document including both SystemVerilog and
Assertions in draft form in March, to be voted on by the board in May and
released in June.
Requirements document must be approved by the next meeting.
4.1.1 Assertion Identifier - Approved
4.1.2 Assertion Reset -
Can be built into the construct or part of the expression
Alternatives:
1. reset/clear the state of the assertion and suppress execution
2. suppress the firing of the assertion but still continue execution
3. suppress the firing and suspend execution
Once the assertion is fired, it must be fulfilled.
Action: There must be a signal to do #1 - reset/clear the state and
suppress execution. Change the word 'disable' to 'prevent the assertion
from
firing'.
4.1.3 Assertion Sampling Clock
The sampling clock mechansim must allow for gating the clock which
therefore suppresses the firing of the assertion. The sampling clock shall
be an event expression.
4.1.4 Assertion Expressions
The assertion expression shall be a boolean expression. The boolean
expression may be extended to allow the concise description of a sequence.
The sequential expression may itself be a new language construct.
Add discussion of sequential expressions prior to the requirements
discussion. Sequential expressions shall be "standalone", i.e. you can
declare a sequential expression and then refer to it by name to, for
example, build up other sequential expressions.
4.1.5 Assertion Severity Level
The severity level does not necessarily have an implication for static
tools. Prakash feels that overloading assertions to include severity levels
is unnecessary since note-type assertions can be detected in other ways.
Should these note/coverage/reachability type of assertions have a separate
keyword? Everyone agrees that this capability is needed, but not about how
actually to implement it.
Error will issue a message and halt simulation. Warning will issue a
message and continue.
4.1.6 Assertion Action
Must allow a statement to be executed on success or failure. This is
simulation-specific.
4.1.7 Concurrent and Procedural Assertions
Concurrent assertion is no longer a requirement. It can be built from a
procedural assertion in an always block.
Change title to "Non-blocking Assertions"
- Rajeev suggested that FV tools do not fire off multiple threads of
non-blocking assertions.
4.1.8 Event Rise of Fall Detection
Drop this section.
4.1.9 Options of Flags
Drop this section.
Tom Fitzpatrick will take over ownership of the Requirements Specification,
to be distributed before the next meeting.
+----------------------------+------------------------------------------+
| Tom Fitzpatrick | Tel: 1 978 448 8797 |
| Technical Product Manager | Mobile: 1 978 337 7641 |
| Co-Design Automation, Inc. | email: fitz@co-design.com |
+----------------------------+------------------------------------------+
| Web: www.co-design.com | Latest News: |
| www.superlog.org | http://www.co-design.com/news/index.htm |
+----------------------------+------------------------------------------+
| SUPERLOG = Faster, Smarter Verilog |
+-----------------------------------------------------------------------+
This archive was generated by hypermail 2b28 : Tue Nov 27 2001 - 10:54:56 PST