Subject: [sv-ec] Minutes from 2 September 2003 meeting
From: David W. Smith (david.smith@synopsys.com)
Date: Thu Sep 04 2003 - 16:17:49 PDT
Greetings,
Here are the minutes from the Tuesday meeting. I am in the process of
updating the site with the new items as well.
Regards
David
SV-EC Meeting Minutes
2 September 2003 11:00 am. Monday
(rrrr)
Voting Members (3/4 or > 75%)
(aaaaa) Arturo Salz (Synopsys)
(-aaaa) Brad Pierce (Synopsys)
(--aaa) Cliff Cummings (IEEE 1364)
(aaaaa) Dave Rich (Synopsys)
(aaaaa) David Smith (Synopsys)
(-aaa-) Dennis Brophy (ModelTech)
(aaaaa) Jay Lawrence (Cadence)
(aaa-a) Michael Burns (Motorola)
(-aaaa) Mehdi Mohtashemi (Synopsys)
(aa-aa) Neil Korpusik (Sun)
(--aaa) Ray Ryan (ModelTech)
|||||_ 2 September
||||__ 18 Aug
|||___ 4 Aug
||____ 21 July
|_____ 7 July
Non-Voting Members (attendance based)
(-----) Chris Spear (Synopsys)
(-----) Francoise Martinolle (Cadence)
(--a-a) Jeff Freedman (ModelTech)
(---a-) Stefen Boyd (IEEE 1364)
(-a---) Stu Sutherland (IEEE 1364)
Guests (non-voting)
(-a-- ) Kevin Cameron (National)
(--a-a) Don Mills (LCDM Engineering)
Inactive Members (Missed last 4 meetings)
r => Regular meeting
x => Extra meeting (Presence counts for attendance, absence does not)
a => Attended
p => Attended by proxy
- => Missed
Action Items:
[identified with AI (#) in this text, # refers to AI number]
This week:
AI-11 : Neil - Write-up the three different options for ERR-4.
AI-12 : Arturo - Add order and number of evaluation for case (EXT-8)
and an example using expressions, negative becomes 0,
self-determined and sum issue.
AI-13 : Arturo - Move 8.5.3 section of EXT-14 to a new proposal for
EXT-15 (and remove from EXT-14 proposal).
AI-14 : Arturo - Move 7.10.1 section from EXT-14 proposal in response
to ERR-5 (and remove from EXT-14 proposal).
AI-15 : David - Add errata for description of use of wait using,
methods - Dave owns.
Minutes 9/02/03 taken by Mehdi Mohtashemi
1. Review of meeting minutes from 18 August 2003 meeting
Motion: Accept the minutes from 18 August 2003 meeting
Moved: Brad
Second: Jeff
Abstain: Mike Burns
Against: None
Passed
2. Review of action items
AI-5: Arturo and Cliff, scheduling, Arturo sent email. There is a
problem
Cliff is working on response. Keep as AI-5.
AI-8: EXT-2 was resent by Arturo with changes.
AI-10: EXT-2 was resent by Arturo with changes for kill.
3. Review of Inter-committee dependencies
David: nothing to report
4. Review of Errata list:
ERR-4: Lifetime of automatic variable and fork/join_none
Jay: Neil's response was a cogent response. Explicit mechanism seemed
like a good approach. Good compromise to allow consistency
with other forms of fork...join.
Ray: Sounds like a good idea as well. Also avoided fork..join_none
being different from fork..join_any.
Arturo: So what is the mechanism?
Neil: Did not define a specific mechanism. More work needs to be done.
Cliff: Can you describe the problem and response?
Neil: Sharing of automatic variables in spawned
processes may be illegal if parent process goes away.
Proposal in ERR-4 was to make variables be automatically copied.
Response was that this should be consistent with 2001 in form.
3 main points in email:
1. ALL sub-processes share/access to automatic variable as
fork/join
2. LifeTime, auto variables in sub-processes, cannot go away
until sub-process goes away.
3. User has to explicitly code for copy of variable in
sub-process.
Brad: If they exist why do you need to copy?
Neil: This is related to Dave Rich's index example.
Arturo: It is not enough to make sure that variables do not go away.
You must make sure that the value is correct in the spawned
process. In looping fork/join_none example each variable would not
get their copy, share the same variable.
Neil: You could have that problem.
Arturo: In Vera you never see this. Dave Rich's example will work the
same in Vera with either shadow or non-shadow.
Mike: Is this the only place you can see the difference between
copying or not? I thought that you needed to call a method.
Arturo: Yes. Since the parent process does not block with join_none or
join_any. Dave Rich's example with/without shadwoing you get
same result.
Ray: Currently no need to make copy of automatic variable.
Arturo: Since parent process does fork/join, scope of variable is
shared, by copying there is no sharing.
Neil: By default it should be the same as V2k.
Arturo: Cannot replicate the condition with V2k.
Ray: Is this one copy per thread or one for all threads.
Arturo: Could make for all cases and would not see a problem with
this example.
Ray: Can create example where you see it.
Jay: Solution where we explicitely specify the copy would be good. I
have to disagree with Neil on the lifetime issue. Keeping
track of lifetime of variable is non-trivial.
Arturo: You can wrap the variable in a class and deal with it just like
other automatic variables. Garbage collection mechaninsm will take
care of it.
David: Desire to keep consistency between fork/join_none and _any
also approaches to the solution. Trade-offs between solutions.
Jay: Yes, you could keep track of scope etc... You would have to
add code to protect it.
Arturo: You could use garbage collection mechanism deal with it.
Jay: Yes. You have to check everytime.
Arturo: Only if you implement it this way. It removes the performance
problem.
Jay: Should you be able to access an automatic variable after the
scope goes away? The answer should be no. Raise an error or
statically determine it
Arturo: How do you detect this? It would be a performance problem.
Jay: V2k does not allow access to automatic variables in fork..join.
Arturo: But v2k does not disallow it. The reason to use automatic
variables is because the task is re-entrant.
This is not a corner case. This is the normal mechanism.
Jay: Life-time of automatic variables should be illegal to access.
Arturo: You cannot detect it statically, this is usually how cshell,
heap in unix works.
Jay: We need a copy mechansim, but not change the automatic variables.
David: good philosophical point, however we introduced new thread
creation.
Jay: Make a copy of it, with the yet to be done copy method.
Arturo: If re-entrant task, passing arguements will allow.
Ray: Case where sharing a variable that need.
David: Problem with the parent process going away.
Arutro: Hard to detect it.
David: You have to explicitly declare it and copy it.
Arturo: fork/join_none would be different from fork/join.
Ray: Other than arg passing is there any other place you want to access
it?
Arturo: Task that forks checker threads, common, can do it with explicit
synchronization.
Ray: Flag in the parent process to make sure all sub-processes have all
variables they need.
Jay: Put a parameter list around fork, fork (a,b,c) ... copy these
variables and available to sub-processes.
Arturo: When you do not copy and fork, what is the result, illegal, or?
Ray: Performance issue? does it become one?
Jay: Number of cases is small,
David: more concerned about how it can work in some implementation.
Ray: Introducing a race condition, if it is done, you get inconsistency
across implementation.
David: Do we allow it or not, define a mechansim for copy.
Also resolution to the life-time of automatic variables.
We need to write-up the solution, as well as local copy syntax.
Jay: It would be good to do it separately for each basis.
Neil: Vera would do it consistenly for all sub-processes.
Jay: Arguement list may work, and maybe reasonable.
David: Need statement of what the three recommendations are.
Neil: Will put it together the set of options.
ERR-5: Add explanation that built-in classes can be redefined and to
distinguish from built-in types in 13.1.
Arturo: Delay until we review proposals on namespaces. Related to
built-in class anonymous namespace.
Jay: The discussion in separate compilation seems different.
Arturo: Agreed.
David: We will wait until we go through the other proposals.
5. Review of Extensions:
EXT-5: Optional order of lifetime, datatype, and sign
Arturo: I thought the issue was with respect to classes in which case
there are a number of modifiers. With non-class the only issue
is for sign. Would prefer to leave it as is.
Jay: I agree on the topic. Dave Rich might disagree.
Arturo: Talked with Peter and he agrees. Dave was in the discussion
were it was tabled.
Motion: Move that it remains as defined and close extension.
Moved: Arturo
Second: Jay
Abstain: None
Against: None
Passed
EXT-8: RandCase
Ray: 32 bit restriction was due to expectation that the numbers would
be small. The issue was more with expressions than with constants.
Arturo: Ray suggested that negative number counts as a negative weight.
Brad: I thought it was illegal.
Ray: Cannot detect as a compilation error (since it is a variable).
Arturo: My thought was that there was an implicit cast (so negative
becomes positive number).
David: Is it a run-time error (if we make it an error) since it cannot
be detected as a compilation error?
Jay: This is the category of this is an error and we will do something
screwey with it.
Arturo: Agreed. That is why 0 is just as screwey. So, if issue as an
error then what happens? Terminate, make an error, or make a
large number?
Jay: Implementation dependent.
Ray: Some rational for making it become 0 since it is likely this
was due to reduction of probability. It would be useful to make
it a value and not generate an error.
David: for random generation what does portability mean?
Ray: Second thread was on stability. One of the features was
convenience. The other issue was ordering and how the random
number is generated.
Arturo: Did you see my other email?
David: Stability is primary concern, the second, repeatability across
multiple implementation/application.
Arturo: Explicitly want thread stable. Then specify the order of
evaluation.
David: What conclusion?
Ray: How important is repeatability?
Arturo: It is important to have stability so that interaction between
processes within a single vendor is important.
Neil: It is usually important. With probability not sure as important.
Ray: There are two parts. The randomness and the case evaluation.
The order of evaluation could be specified.
Arturo: And how many times is it evaluated.
Ray: You mean it may be evaluated more than once?
Arturo: Yes. The coding for the example shows caching. Appropriate
to specify each evaluated once in the order they appear.
Arturo: Need to add that: Each weight expression should be
self-determined in terms of position. The sum of the weights
should be calculated using standard verilog semantics (maximum
precision of all weights).
Ray: So there cannot be overflow?
Arturo: No different than standard Verilog.
Ray: Each of the weights are evaluated as an unsigned number and the
sum is an unsigned sum.
Arturo: Self-determined expression then cast to unsigned number.
Neil - It would be useful to have this in the write-up.
David: Let's the proposal out on email and then vote on it by next
meeting.
Jay - Not sure I like at all (the concept and not the issues).
David: We can get the issues worked with, one of it was to show more
complex example.
David: The extension EXT-2,14, and 9 have been out for a few weeks. I
want
to open the discussion about the form/completeness/etc, vote to accept
the proposals, and then have the technical discussions.
EXT-2: Process Control
David: Any discussions on Ext-2?
Jay: No problem with this.
Motion: Accept EXT-2 proposal.
Move: Mike Burns
Second: Arturo
Abstain: None
Against: None
Passed
EXT-14: Constraint completion
Jay: Need to define the built-in global namespace (7.10.1) before it
is used within this proposal. Move 7.10.1 and 8.5.3 to separate
proposals.
Arturo: Necessary for constraint, if we use them [foreach, ] it
is usefull for general code.
Ray: You could have them just for constraint only.
Arturo: You could do them that way. The name-space because of randomize
and how it is proposed, did not want to introduce new keyword.
Jay: Built-in global name-space is trying to solve a fundamental
problem. Mailbox, semaphore and the Errata, go through all other
areas of 3.1. If this place exists, and what goes there?
Arturo: $root is below it, name-space resides above it.
Ray: The semantics is a little different between constraint vs
procedural.
Ray: Woul like to break 8.5.3 out since it does have some different
issues. Agree that they should be the same.
Proposal:
Motion: Move 8.5.3 from EXT-14 to EXT-15 and handle separately but
consistently with EXT14.
Move: Jay
Second: Neil
Abstain: None
Against: None
Passed
Propsal:
Motion: Move 7.10.1 to proposal for ERR_5.
Move: Jay
Second: Neil
Abstain: None
Against: None
Passed
Proposal:
Motion: Accept EXT-14 proposal as modified by previous two
proposals.
Move: David Smith
Second: Arturo
Abstain: None
Against: None
Passed
EXT-9: Stream Generation
David: any problems with proposal/self-consistency/form/ etc?
Motion: Accept EXT-9
Move: Mehdi
Second: Arturo
Abstain: None
Against: None
Passed
EXT-2: Technical discussion.
David: Michael, does this meet the requirements?
Michael: Yes. May need more work.
David: Since it meets the requirements we now need to decide what
additional work is required.
Michael: Proposal as is meets the requirement but some more work needs
to be done. The child thread has to start, use self function to
pass its process object to parent. Issues with race condition,
parent thread needs to wait till child starts up.
Jay: This is the example that requires the copy of variable.
Michael: The example demonstrates the problem we were discussing before.
Neil: Except when spawning the process, j is one thing.
Arturo: No automatic variable?
Mike: All get the last value of J,
Arturo: Only a looping construct that need the copy is required.
using jay's pseudo example [fork(a,b..) ] may solve it.
Ray: If fork off processes, how one knows about last process?
David: Last process started ..
Ray: Truely concurrent, may not have reached storing the value.
Mike: The #0, how does it help?
Arturo: Wait for job n to start, race condition is that job 1 may not
exist.
Mike: Can the parent get access to child?
Arturo: Can have fork and processes in the loop, explicit.
Dave: Instead of fixed size array for jobs, can we have dynamic or
variable array, and then use array.size to find if they have all
been created?
Mike: Does it check every simulator cycle?
Arturo: The wait would be sensitive to size (and therefore delete/add).
Jay: Is this defined where we can put method call inside of wait?
VHDL/primary erratta for sensitivity of object.
Dave: It would be good to add this description.
David: Are there any more issues with this proposal besides cleaning up
the example?
Arturo: Only other issue, from Michael, was to query all of the process
objects.
Michael: This proposal does not prevent that in the future.
Jay: Would this leave in the anonymous namespace?
Arturo: Not any different than for mailbox or semaphores.
Jay: Do we want to use this as a keyword or call it by a different name
since process was reserved for future use.?
Ray: If placed in names-space, it does not have to be reserved/keyword.
Arturo: If this lives in the namespace then it does not conflict with
a keyword.
David: This has the same issues as other built-in classes.
Ray: Do you have other built-in classes that are also keywords?
Arturo: No. There may be ambiguity.
David: Looking in appendix B, it is not there as a keyword in 3.1.
Cliff: It was removed from 3.1, was in 3.0.
Arturo: Note in page 46? SV3.1 deprecated it so it was removed.
David: Rework example, no other changes suggested.
6. Next meeting:
15 September 2003 at 11:00pm
7. Close of meeting at 1:04pm
This archive was generated by hypermail 2b28 : Thu Sep 04 2003 - 16:23:41 PDT