[sv-ec] Minutes of 29 September 2003 meeting


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