Subject: RE: Minutes 8/8/02
From: Erich Marschner (erichm@cadence.com)
Date: Thu Aug 08 2002 - 11:58:32 PDT
Tom,
Regarding this one:
Op9-
RR: Change at least once in the window. No implication on what it does after
the first change.
I understood the resolution to be that this requirement was intended to mean exactly one change during the window - e.g., to describe a bounce-free rising edge that occurs some"where" within a window (actually some*time* within a temporal window).
To elaborate, I believe there are the following cases to consider regarding the stability or change of a boolean signal during a temporal window:
1. No change at all.
2. Exactly one change (rising or falling edge) - which may occur anywhere in the window.
3. Even number of changes - the signal may glitch, but it has the same value at the beginning and end.
4. Odd number of changes - the signal may bounce, but it has a different value at the end than at the beginning.
5. Arbitrary number of changes - the signal has an unpredictable value at the end.
Of these cases, I believe that cases 3 and 4 are the most useful, particularly for description of cycle-level behavior. Cases 1 and 2 are more restrictive versions of 3 and 4, respectively, and are also useful when considering sub-cycle level behavior. Case 5, in my opinion, is useless.
Regards,
Erich
-------------------------------------------
Erich Marschner, Cadence Design Systems
Senior Architect, Advanced Verification
Phone: +1 410 750 6995 Email: erichm@cadence.com
Vmail: +1 410 872 4369 Email: erichm@comcast.net
| -----Original Message-----
| From: Tom Fitzpatrick [mailto:fitz@co-design.com]
| Sent: Thursday, August 08, 2002 1:59 PM
| To: sv-ac@eda.org
| Subject: Minutes 8/8/02
|
|
| 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 - 12:01:09 PDT