Subject: Minutes 8/8/02
From: Tom Fitzpatrick (fitz@co-design.com)
Date: Thu Aug 08 2002 - 10:59:22 PDT
x = attended
- = missed
r = represented
. = not yet a member
[--x.] Faisal Haque (Cisco, Chairman)
[xxrx] Tom Fitzpatrick (Co-Design, Co-Chair)
[--xr] Tom Anderson (0-in)
[---x] Jason Andrews (Axis)
[x--x] Roy Armoni (Intel)
[xxxx] Gail Dagan (Intel)
[xxxx] Simon Davidmann (Co-Design)
[rxx.] Surrendra Dudani (Synopsys)
[xxrx] Cindy Eisner (IBM)
[rrxx] Peter Flake (Co-Design)
[xrrx] Harry Foster (Verplex)
[xx..] John Havlicek (Motorola)
[xxx-] Richard Ho (0-in)
[xrx-] Adam Krolnik (LSI)
[xx-x] David Lacey (HP, OVL Chairman)
[--xx] Joseph Lu (Sun)
[xxxx] Erich Marschner (Cadence)
[-x-x] Steve Meier (Synopsys)
[---x] Paul Menchini (Menchini & Associates)
[xxxx] Prakash Narain (Real Intent)
[xxx-] Rajeev Ranjan (Real Intent)
[xxx.] Ambar Sarkar (Paradigm Works)
[xx-x] Andrew Seawright (0-in)
[xxxx] Bassam Tabbara (Novas)
||||
|||+- 7/9/02
||+-- 7/25/02
|+--- 8/1/02
+---- 8/8/02
Continuing with Ranjeev Ranjan's requirements.
EM Provided the following explanation for Sm6 - Cycle based semantics
Semantics should be based upon an underlying computational model that
involves a succession of times during at which the design and assertions are
evaluated. This base case is independent of clocks, and is therefore
"asynchronous". The succession of times may be determined by event-driven
scheduling, for example. For synchronous modeling, the semantics should be
defined in terms of evaluation at time points at which some boolean
condition is true (e.g., a clock edge occurs, or an enable is true). The
semantics should NOT be defined in terms of time delays.
Op10: Future value of signal means assert that at end of a window, signal
has specified value.
RR: assert that a 10 cycles from now will be the same as b 20 cycles from
now
Action: RR to clarify the future value requirement
EM: Does this have to be simulatable?
RR: The error message doesn't have to happen until the future time is
reached.
HF: What happens if simulation ends before future value is reached?
PN: If a future value is specified, then the assertion can't complete until
the future time is reached.
JG: It depends on the semantics
JH: We must understand exactly at which point an assertion fails, because
this is important when assertions are used with other temporal issues.
JG: OVA proposal is unambiguous at this point.
EM: Can I do a computation that involves s ten cycles from now? What can you
do with future values of signals. I hope not.
JG: OVA has a mechanism to move to the future and then to refer to values in
the past.
RR: Future values can only be used as an observation about the value at some
compile-time constant in the future.
Action: RR to provide an example of a future reference and what should
happen in simulation and formal analysis.
HC: Need to define when in the timeslot a past/future reference value is
taken.
EM: There may be a requirement for multiple sampling values in the same
assertion. Something like "reset line will not glitch between cycles 3 and 5
of protocol P".
JG: May want to specify a sampling clock for some signals independent of the
assertion. Mechanism for two assertions in different clock domains to feed
each other.
EM: glitches could be either cominational or sequential.
Action: RR to write explanation how to refer to asynchronous events.
Op5 -
PN: Need some keyword-based way to recognize a transition without making the
code unsynthesizable.
RR: Clarification - need a standard shorthand method for common
relationships
Action: RR to provide complete list of common relationships that are
required.
EM: This requirement should be separated into combinational and sequential
relationships.
Sq6,8 -
EM: How do identify the start/end of the window, can the window end
prematurely?
Action: EM to send list of additional quuestions about defining a "window":
Some details to consider w.r.t. window-based assertion checking (Op6-9, Sq6,
Sq8).
1. Window Definition:
- how the start is indicated
- beginning of time, or
- occurrence of a synchronous event, or
- occurrence of a synchronous event.
- how the end is indicated
- end of time, or
- by another (normal end) event, or
- by N (clock) cycles after begin, or
- by a premature discharge event (e.g. 'abort'), or
- by the success or failure of the assertion, or
- by a global reset
- whether the start cycle is included in or excluded from the window
- whether the end cycle is included in or excluded from the window
2. Assertion Obligation
- whether the assertion is obligated to
- hold throughout the window, or
- not fail ** throughout the window, or
- hold somewhere before the end of the window
- fail somewhere before the end of the window
- what happens if assertion is not satisfied by the end of simulation
** depending upon the precise definition of 'hold', there may be a
difference between 'holding' and 'not failing' within the window.
Op9-
RR: Change at least once in the window. No implication on what it does after
the first change.
Sq9-
PN: Sequence completion that has no implication on verification.
RR: In 3.0, this was handled by $info, etc.
EM: This separates the monitoring functionality from the overall assertion
pass/fail functionality.
Action: RR to submit additional requirement about similarity of style
between Sq9,Sq10
Issues that have come up:
Accept/Reject or cause an assertion to evaluate to true/false from some
other statement in the code for convenience (Us12)
Global statement when a (set of) assertions should be evaluated (Us18)
Tool capability to turn an assertion (evaluation and/or reporting) on/off
regardless of its truth value, and in making no judgment of pass/fail.
Each of these capabilities must be considered under the following three
conditions:
- As part of the same statement
- from within the same module
- from arbitrary place in the code
- Control all assertions globally or specific assertions individually
Next Meeting:
Thursday 8/15, 9am-11am PDT
405-244-5555 x4615
------------------------------------------------------
Tom Fitzpatrick
Director of Technical Marketing
Co-Design Automation, Inc.
------------------------------------------------------
Email: fitz@co-design.com Mobile: (978)337-7641
Tel: (978)448-8797 Fax: (561)594-3946
Web: www.co-design.com
www.superlog.org
------------------------------------------------------
SUPERLOG = Faster, Smarter Verilog
------------------------------------------------------
This archive was generated by hypermail 2b28 : Thu Aug 08 2002 - 11:02:13 PDT