Subject: [sv-ac] Minutes of 9/19 meeting
From: Faisal Haque (fhaque@cisco.com)
Date: Thu Sep 19 2002 - 17:16:31 PDT
Tom and I will updat the ballot and send it out by this weekend.
Agenda for next meeting:
Review Process:
We will continue discussion until next week.
Ballot due by 10/2 to Tom Fitzpatrick. Tom will tally and report on 10/3.
SV-AC will get updated ballots before the end of the week.
SV-AC will get a list of companies eligibile to vote by next week.
PSL Overview 9:00- 9:30 CE
OVA PSL Comparison 9:30-10:00 SM/EM
Requirements Discussion 10:00-11:00
-Faisal
Legend:
x = attended
- = missed
r = represented
. = not yet a member
* = voting rights
[xxx----x] Faisal Haque (Cisco, Chairman)
[-xxxxxrx] Tom Fitzpatrick (Co-Design, Co-Chair)*
[xx-x--xr] Tom Anderson (0-in)
[-------x] Jason Andrews (Axis)
[x-xxx--x] Roy Armoni (Intel)*
[-xxxxxxx] Gail Dagan (Intel)*
[---xxxxx] Simon Davidmann (Co-Design)
[xxxxrxx.] Surrendra Dudani (Synopsys)*
[xxxxrxrx] Cindy Eisner (IBM)*
[--xrrrxx] Peter Flake (Co-Design)*
[r-xxxrrx] Harry Foster (Verplex)* (represented by Richard Stolzman)
[rx-xxx..] John Havlicek (Motorola)*(represented by Kurt Schultz)
[x-xxxxx-] Richard Ho (0-in)*
[xxxxxrx-] Adam Krolnik (LSI)*
[xx--xx-x] David Lacey (HP, OVL Chairman)
[xxx---xx] Joseph Lu (Sun)
[xx--xxxx] Erich Marschner (Cadence)
[xx-x-x-x] Steve Meier (Synopsys)
[-------x] Paul Menchini (Menchini & Associates)
[xxx-xxxx] Prakash Narain (Real Intent)*
[xxxxxxx-] Rajeev Ranjan (Real Intent)*
[-xxxxxx.] Ambar Sarkar (Paradigm Works)*
[x-x-x...] Richard Stolzman (Verplex) (Harry Foster)
[-xxxxx-x] Andrew Seawright (0-in)*
[x-xrxxxx] Bassam Tabbara (Novas)*
[x-------] Wolfsthal (IBM)
|||||||||
||||||||+- 7/9/02
|||||||+-- 7/25/02
||||||+--- 8/1/02
|||||+---- 8/8/02
||||+----- 8/15/02
|||+------ 8/22/02
||+------- 9/5/02
|+-------- 9/12/02
+--------- 9/19/02
R50a
??:Our concern could be very broad do not see any obvious ways to limit the
side effects
??:A side effect is really not a side effect if the testbench explicitly
causes the effect.
R50b
??:System verilog allows assert to affect design.
R51
AK: Semantics do not account for ease of handshake. Pipelining requires some
ordering in handshake in protocol. First one is FIFO. Current assertion do
not allow
CE:In Sugar you can do it today and also use virtual tags
R52:
CE: Object to this one. There is a kind of side effect to that.
AK: Is this referring to local variables? We need to clarify.
CE: If changed to local would be happier but not support it. Would rather
see it expressed in a way so it is not an assignment.
R53:
AK: Don't know what it means
AK: It is useful
R54:
AK: Sounds similar to R53 except it is more explicit
R55:
AK: Same thing should be written procedural or declarative within same lang
To eliminate false firings
R56:
R57:
AK: oppose a) on the basis of limiting to only one cycle
R57b: unoppposed
R57c:
JL:c is more generic than a or b
CE: The reason why Sugar does not support it is complexity. It is also easy
for user to create problems with this construct
AK: You are talking about a veriable number as opposed to constant
R58a:
AK: would rather see 58c than a or b
R58b:
AK: Opposed on above basis.
R58c:
AK: Support enabled FF designs.
BT: Why enable needed is for this one application.
AK: This is diff from en clock. It is very difficult to write a property to
use past states with enable FF. True for any language today.
R58d:
AK: It should be tied to the design and be very difficult to compute
BT: Do we need a symm between mech for past and future
CE: Not neccessarily
R59a:
AK: Basically an edge with cycle semantics
R59b:
R59c:
R60:
AK: If you have multiple signal they would need to be concatenated. If the
system func could do it would remove that need
R61a:
AK: Context is in the System functions. Would prefer to see static set.
R61b:
AK: Opposed.Dyn set now you have to chg it somewhere so ambiguity in legal
values
R62:
EM: essentially first match. Recognizing first occurence does not clarify
other occurences. There is an issue of recognizing subsequent occurnc. Only
would be more comfortable. But not fully supportive of this.
AK: Proposal to modify:
Recognition of only the first occurence of the event of completion of
sequence
BT: Why don't we call it First Match it is clearer.
R63:
EM: recognition of all occ. of an event. Overlapping occurence of sequences.
R64:
EM: FVTC supports both
R65:
EM: Not of any property is a property and don't allow not on seq.
EM: OVA allows a kind of not.
R66:
EM: Should be deleted.
CE: Logic must be specified to allow automatic vaccuity checks
EM: It is a valid
R67:
R68:
EM: You must be able to specifiy properties in latch based designs
RR: Should be specify it as should handle latch based designs.
EM: Latch based designs not specific enough
R69:
EM: This should be removed
R70:
EM: should be able to build up simple prop into more complex prop. Build up
a hierarhy or relationships.
RR: Oppose it. Getting into domain of temp logic offered in the last decade.
Create more confusion for the users.
AK: Disagreeing because it is too complex
RR: By allowing nsting of operators confuses users
R71:
EM: Mangled in summary. First match semantics for seq . Not sure if he can
explain in a way that it makes sense to people
EM: Argument is a bit philosophical.
AK: What would be a concrete statement ex?
EM: In protocols you can't have overlapping xctn. protocols need to be
deterministic we don't get that with non-deterministic match semantics
today.
EM: Rewrite: Easy way to specify no-overlapping suffix implications.
R72:
R73:
BT: Disagree better left ot control API
EM: Agree with disagreement
R74:
AK: Fine Existing
R75:
EM: Have a problem withis. anyone understand algo. for this.
RA: 75a or b should be supported
Review Process:
We will continue discussion until next week.
Ballot due by 10/2 to Tom Fitzpatrick. Tom will tally and report on 10/3.
SV-AC will get updated ballots before the end of the week.
SV-AC will get a list of companies eligibile to vote by next.
OVA Review:
PSL Overview schedule 9/26 9:00-9:30 Cindy
OVA PSL Comparison 9/26 9:30-10:00 SM/EM
This archive was generated by hypermail 2b28 : Thu Sep 19 2002 - 17:17:42 PDT