Subject: [sv-ec] Minutes of 29 September 2003 meeting
From: David W. Smith (david.smith@synopsys.com)
Date: Tue Sep 30 2003 - 15:49:38 PDT
Here are the minutes of the last meeting. The are also posted on the web
site.
David
SV-EC Meeting Minutes
29 September 2003 11:00 am. Monday
(rrrr)
Voting Members (3/4 or > 75%)
(aaaaaaa) Arturo Salz (Synopsys)
(-aaaaaa) Brad Pierce (Synopsys)
(--aaaa-) Cliff Cummings (IEEE 1364)
(aaaaa-a) Dave Rich (Synopsys)
(aaaaaaa) David Smith (Synopsys)
(-aaa-aa) Dennis Brophy (ModelTech)
(aaaaapa) Jay Lawrence (Cadence)
(--a-aaa) Jeff Freedman (ModelTech)
(aaa-aaa) Michael Burns (Motorola)
(-aaaaaa) Mehdi Mohtashemi (Synopsys)
(aa-aaaa) Neil Korpusik (Sun)
(--aaaaa) Ray Ryan (ModelTech)
|||||||_ 29 September
||||||__ 15 September
|||||___ 2 September
||||____ 18 Aug
|||_____ 4 Aug
||______ 21 July
|_______ 7 July
Non-Voting Members (attendance based)
(------a) Chris Spear (Synopsys)
(-----s-) Francoise Martinolle (Cadence)
(---a---) Stefen Boyd (IEEE 1364)
(-a---a-) Stu Sutherland (IEEE 1364)
Guests (non-voting)
(--a-a-a) Don Mills (LCDM Engineering)
(-----a-) James Young (HP)
(-a-----) Kevin Cameron (National)
r => Regular meeting
x => Extra meeting (Presence counts for attendance, absence does not)
a => Attended
p => Attended by proxy
s => Attended as proxy
- => Missed
Action Items:
[identified with AI (#) in this text, # refers to AI number]
Added this week (please see the site for existing action items):
AI-21 : David - Resolve coordination of EXT-6 with SV-BC
AI-22 : Arturo - Add note for compatability in 12.10.4/12.10.5.
Add clarification on bi-directionality in 12.4.10.
Split first restriction into two *second on to end).
Add clafication that randc has highest priority in 12.4.10.
AI-23 : David - Review face-to-face issues action items for SV-EC.
Minutes 9/29/03 taken by Mehdi Mohtashemi
1. Review of meeting minutes from 15 September 2003 meeting
Motion: Accept the minutes from 15 September 2003 meeting
Moved: Mike Burns
Second: Arturo Salz
Abstain: None
Against: None
Passed
2. Review of action items
AI-5: (Arturo) - No progress
AI-11: (Neil)
David: Neil sent response email on this, we will deal with the response
during the ERR-4 discussion.
AI-16: (Arturo)
Arturo: AI-16 was sent earlier today. We will review during ERR-8
discussion.
AI-17: (David) - No progress
AI-18: (???) - No one assigned to this yet. For built-in namespace
documented we need to create an annex, have each of the items in the
built-in namespace defined and references as they get approved.
AI-19: (David) - Completed
AI-20: (David) - Completed
3. Review of Inter-committee dependencies
David: No new dependencies, some items from face-to-face, add new action
item for reveiwing those.
Ray: Name package for name-space,
David: Will wait to see how it turns out, BC is looking into it, will
make changes as it becomes final. The only anticipate change is what
to call it.
4. Review of Errata list:
ERR-4 (Dave): Lifetime of automatic variables in fork...join.
Mike: Scenario 6
Neil: Same as liked by Brad. Leaning to 2 and 4.
Ray: Prefer 4.
Dave: Looking at the meaning of automatic variables within SV.
Neil: Request that we integrate any other proposals into this write-up.
Neil: AI-11, issues and plus/minus for alternatives. Brad responded.
Came up with 7 alternatives, scenarios.
Michael: I liked the sceanrio 6.
Neil: That is same that Brad liked. I like number 2 or 4.
Ray: I would like 2. [referring to Neil's email]. 4 is 2a1.
David: Option 4, assuming this is attribute copy on declaration.
Neil: Showed an example of the list, in Vera this is done on the
declaration of the variable. This is not the actual syntax,
just show pros/cons for each of list of options.
Dave: Some other language in LRM had to do with life-time of individual
variable and may take care of this.
Arturo: In V2k, the variable is presumably automatic.
David: Does not seem everyone has looked at carefully,
Dave: Other issues may come up and affect which path to take.
David: Will keep it open, think through issues, please send proposals
before the next meeting for people to look at it.
Neil: If there are other issues, it would be nice to combine it in
one writeup to help us to make a decision.
ERR-5 (Arturo):
No progress
ERR-7 (Arturo):
No progress
ERR-8 (Dave):
No progress
ERR-14 (Brad):
No progress
ERR-15 (David):
No progress
ERR-16 (Mehdi):
Mehdi: Sent this morning. Remove discusson of constant expression
since it is described below.
Motion: Move to approve change in email.
Moved: Dave
Second: Arturo/Mike
Abstain: None
Against: None
Passed
ERR-17 (Mehdi):
Mehdi: Remove confusion by removing sentance.
Motion: Move to remove change in email.
Moved: Arturo
Second: Mehdi
Abstain: None
Against: None
Passed
ERR-18 (Arturo):
No progress
ERR-19 (Brad):
No progress
ERR-20 (Arturo):
No progress. Wait for ERR-4.
ERR-21 (Arturo):
No progress
Assign ERR-22:
David: This came in today, from Don, the list for compile time check,
list is not complete. We need to re-word it to include all the
appropriate methods, what the subset is, so forth.
Arturo: I will take this item.
5. Review of Extensions:
Vote on acceptance of:
David: number of submissions have come to SV-EC and we need to go
through
the acceptance vote.
EXT-3: (virtual interfaces)
Motion: Accept EXT-3
Moved: Neil
Second: Arturo
Abstain: None
Against: None
Passed
EXT-6: (find size of type)
Neil: Did not understand why it does not apply to classes, what are
the restrictions on classes.
Arturo: It is the number of bits in the handle.
Neil: What about instance of class, as a struct?
Arturo: The linked list is the issue, where bits cannot be extracted.
David: Restrictions are appropriate or we need to clarify.
Arturo: This is similar to a proposal within the BC.
Jay: Proposal in BC, has system functions of all of the bit operators,
as well as other ones (high, low, etc..), also it has methods for
all of them. My issue with this proposal is that it introduces
'built-in property'. What does this mean?
David: Is this the only submission that uses 'built-in property'?
Arturo: This is just a mechanism to talk about the built-in property,
Vhdl tick for example. Description and syntax.
Jay: Also make sure consistency in usage, are there things that need
to use this. Really using methods as 'pre-defined function value
attributes'.
Arturo: It can be used as elaboration constants...
David: Whether the proposal should be accepted, we can in the
committee to redo it to do what Jay is discussing. The discussion
is more on the substance than..
Jay: The current form does not have a meaning, coordination with BC is
also needed, should we get the BC to deal with the whole issue.
David: That does have to be resolved, responding to the same need,
action item for me to finalize it. Need to make a decision as a
committee on this proposal. There are two routes we can take.
We can pass this one to BC and make sure material in this
proposal is covered. The second route is to accept this and
coordinate with BC to come up with the complete proposal
AI - David - resolve with BC.
Motion: Move to BC
Moved: Jay
Second: Arturo
Abstain: None
Against: None
Passed
EXT-7: (reacting to assertions)
Jay: there were more discussion on this in SV-AC.
Arturo: We can go over this in detailed discussion.
David: Does the submission address what the original intent,
is the form not right?
Motion: Accept EXT-7
Moved: Arturo
Second: Mehdi
Abstain: None
Against: None
Passed
EXT-10: (functional coverage goal specification)
Ray, Neil: We have not had chance to look at it.
Dennis: Can we table this for next time?
David: Request is to leave it for more time to review.
No Objection to above, 'table it' until next meeting.
EXT-11: (dynamic queue support)
Motion: Accept EXT-11
Moved: Arturo
Second: Mehdi
Abstain: Neil (not have time to read)
Against: None
Passed
EXT-12:
Dennis: I suggest we table this one till next meeting.
David: I would encourage folks to review these.
Dennis: I have had problem with printing with acrobat...
David: Table until next meeting for more time to review.
Review and approval:
EXT-8:
Arturo: In the first paragraph: The positive is changed to non-negative.
In the last sentence next to last paragraph, algorithm description
last sentence of last paragrpah modified.
David: Ray, do these resolve the issues you had?
Ray: They do resolve the issues.
Motion: Motion to approve
Moved: Dennis
Second: Neil
Abstain: None
Against: None
Passed
EXT-14:
Arturo: First item is correcting a mistake.
Randstate issue:
Neil: Is the string a vendor specific string that gets saved/restored.
Ray: This is a very implementation dependent string. We should either
change this or explicitely describe it as non-portable.
AI - Arturo: Add note for compatability in 12.10.4/12.10.5
AI - Arturo: Add clarification on bi-directionality after example in
12.4.10. Split first restriction into two (second one to end).
AI - Arturo: To add clarification that randc has highest priority in
12.4.10.
Stop at 12.4.11 - Object handle guards
Section 12.4.4
Arturo: Mistake for distribution, BNF reflects that. First two pages
cover the change.
David: Are there anyother changes?
Ray: The BNF introduces foreach.
Sections 12.10.4/12.10.5
Neil: Is the string a vendor specific string that gets saved/restored?
Ray: This is a very implementation dependent string. We should either
change this or explicitely describe it as non-portable. It has a
common usage in Testbench, for example with a control file, write
it to a file and use to restart random number generation.
Arturo: There is, in the LRM, constructs that initialize the random
number generator. You may want to fork a thread, and save the
number and push it back to the main thread. Section 12.12
discusses manual seeding of randomize, srandomize takes in
an integer number.
Ray: How much is forced to be gauranteed. What can user count on?
Arturo: The statement was intended within same vendor, may need another
statement to specify than this more.
David: Three options, to change it to show vendor spcificity with it,
second is add text that explains non-portabililty. third is to
add other, enumerate cases... Makes it very hard to specify
the format.
Arturo: Initially this was initially a built-in type.
Ray: User calls get_random, saves it as string and reuses it, vendor A
get_random saves as string, now with vendor B and set_random
with the string, would it work?
Neil: What about saving it as a chandle? It would avoid this problem.
Arturo: Problem is with garbage collection,
Dennis: It is good practice to put note to serve as more clarifications
for the user.
David: We can add note to clarify the restrictions.
Neil: I would prefer to find something other than string, to avoid the
problem. Why can we not find handles to do this?
Arturo: If same vendor comes up with a different random number
generator, may require more bits,
David: Two options, need proposal.
Jay: Leave it alone the way it is.
David: We will not change the type, any additional texts?
Jay: Just add note.
Neil: the example that was mentioned, does string not have same problem.
David: if I type random set of characters in a string and pass it
to set_random, what happens?
Arturo: It is not-defined, it will take and does non-predictible result.
Ray: When you reset random number generation what gets reset?
David: Action item is to have Arturo to add notes for clarification.
Jay: Do we have to say anything about compatiblity of object types,
object type of get_random vs set_random have to be same.
Arturo: No, it is ok, unusual but ok.
Ray: Means not two different types of random number generator.
Arturo: We do not have a mechanism to change it now.
Sections 12.4.10
Arturo: The ability to use functions in a constraint was not previously
allowed.
Ray: The two constraints used in the example are not equivalent.
Arturo: Functions are not bi-directional, the same flavor, does not
go that far, limitations are explained as well.
Maybe we can add paragraph on this.
Jay: Should the first bullet be split into two bullets?
Two requirements?
Arturo: One says may not, so compiler may give error. We can split
it
into two bullets.
Implicit ordering by calling the functions, placed it as
state variable. the next one is circular dependencies result in
error. Final one, function calls are not in any particular order,
called at least once.
Ray: Argument to functions include randomized variables,
may imply orders, also randc cannot be used.
Arturo: Randc introduces ordering, randc is at the beginning, so it may
result in constraints failing by introducing ordering.
Ray: You cannot create conflict, constraints do not apply to randc
variables,
Arturo: You can, but order dependecies. Randc are sloved first, then
a function call may not be solvable (12.3.2 last sentence).
David: Action item to add clarification randc has highest priority
in 12.4.10 and reword the function call are allowed with some
limitations. No change on the last bullet from what is in LRM
already. Object handle calls.
Sections 12.4.10
Ray: Issue, constraint, no ordering of evaluation of these,
state-relationships. The problem: certain conditions, some cases
can be illegal, cannot proceed. With the object handle is to
prevent it. This is special case, object handle as a guard for
relationship.
Arturo: The constraint solver neither creates nor destroys object.
The first step is to allow expressions using handles.
Using null object handle undetermined effect, so using such
constraint will not cause an error.
Ray: If evaluation of expression, then semantics for object handles are
different than without. The condition expression includes
reference to handle,
Arturo: If foo=0, state variable, foo treated as a guard.
Handle is acting as a state variable. If it is a rand variable --
randomize inside the object
Ray: A handle is state variable, you can never randomize it.
Arturo: So this does not introduce any new semantics, the only
difference is when the object is null, special case is made that
implementation can ignore it,
Ray: But if conditional expression does not involve handle variable
it behaves differently.
Arturo: But there are no new semantics. It is up to the implementation,
only matters if there is an error.
Michael: Or if there was a function call inside the constraint.
Arturo: They should not have side effects.
David: Need to come back and finish the rest of proposal.
EXT-6:
6. Meeting Logistics
Discuss order of review for remaining Extensions:
David: milestone to hit is December 1st to finish all technical
discussions, hence the following order is proposed.
We will have to see what we cover in next meeting. EXT-6 is special
case.
Look at the submission and give feedback.
Please read carefully and send email questions on the EXT-14, and then
look at 15 and 9 for the next meeting.
September 29
EXT-8: RandCase (1 page)
EXT-6: Size of types (1 page)
EXT-14: Constraint Completion (11 pages)
October 13
EXT-15: Foreach (1 page)
EXT-9: Stream Generation (7 pages)
October 27
EXT-10: Functional Coverage (18 pages)
November 10
EXT-3: Virtual Interfaces/ports (5 pages)
EXT-11: Dynamic queue (6 pages)
November 24
EXT-7: Reacting to Assertions (3 pages)
EXT-12: Bitsream support (6 pages)
7. Next meeting:
13 October 2003 at 11:00pm
8. Close of meeting at 1:01pm
This archive was generated by hypermail 2b28 : Tue Sep 30 2003 - 16:00:02 PDT