Subject: [sv-ec] Minutes of 18 August 2003 meeting
From: David W. Smith (david.smith@synopsys.com)
Date: Tue Aug 19 2003 - 16:35:47 PDT
Here are the minutes for the SV-EC meeting of August 18, 2003. They can also
be found at:
http://www.eda.org/sv-ec/Minutes/SV-EC-Minutes-2003-August-
<http://www.eda.org/sv-ec/Minutes/SV-EC-Minutes-2003-August-18.txt> 18.txt
Regards
David
SV-EC Meeting Minutes
18 August 2003 11:00 am. Monday
(rrrr)
Voting Members (3/4 or > 75%)
(aaaa) Arturo Salz (Synopsys)
(-aaa) Brad Pierce (Synopsys)
(aaaa) Dave Rich (Synopsys)
(aaaa) David Smith (Synopsys)
(aaaa) Jay Lawrence (Cadence)
(aaa-) Michael Burns (Motorola)
(-aaa) Mehdi Mohtashemi (Synopsys)
(aa-a) Neil Korpusik (Sun)
||||_ 18 Aug
|||__ 4 Aug
||___ 21 July
|____ 7 July
Non-Voting Members (attendance based)
(----) Chris Spear (Synopsys)
(-aaa) Dennis Brophy (ModelTech)
(----) Francoise Martinolle (Cadence)
(--a-) Jeff Freedman (ModelTech)
(--aa) Ray Ryan (ModelTech)
Guests (non-voting)
(--aa) Cliff Cummings (IEEE 1364)
(---a) Stefen Boyd (IEEE 1364)
(-a--) Stu Sutherland (IEEE 1364)
(-a--) Kevin Cameron (National)
(--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-8: Arturo: Modify to change new handling to be an error.
AI-9: David: Create errata item to add explanation that built-in
classes can be redefined and to distinguish from built-in types in 13.1.
AI-10: Arturo: Update/add description for 'kill'.
Minutes 8/18/03 taken by Mehdi Mohtashemi
1. Review of meeting minutes from 4 August 2003 meeting
Motion: Accept the minutes from 4 August 2003 meeting
Moved: Dennis
Second: Mehdi
Abstain: Neil, since was not there
Against: None
Passed/Approved
2. Review of action items
AI-5:
Aruturo: Cliff has been busy, not yet completed.
AI-6:
David: Separate compilation, bc or other committee.
Discussed in chairs' mtg, primarily a BC issue, needs BC to figure
out the case.
Jay: to send it to Karen's for information.
AI-7:
Brad: Comments for the BNF for randcase were sent to the reflector.
3. Review of Inter-committee dependencies
4. Review of Errata list:
ERR-4: Arturo
Arturo sent out the proposal to the reflector.
'life time of automatic variables and fork/join-none'
Jay: Disagree with forking automatic variables. This opens a pandoras
box.
In what other context will this apply. not allowed to be referenced
in heirarchical way.
Dave: This is not limited to hierarchical reference.
Arturo: Direct reference to the scope. what would need be done.
Should this be a compiler error? So, since we have this, how do we
deal with it?
Jay: Just make it a warning (or error) that this is undefined.
Automatic variable in a named block, in this case you get an extra
copy of the variable.
Dave: Need this to be able to pass arguments to forked processes,
otherwise the same copy is given. This is a required feature. Need to
be able to personalize processes. Could use a mailbox.
Arturo: Why make simple things complicated?
David: We need to define either the behavior or warning.
Arturo: Warning is not appropriate.
Jay: The value is being copied in? Why not pass it to the function in
the
fork.
Arturo: This is to late since it is non-deterministic.
Dave: The problem exists since you do not know when the thread starts
executing and they will all get overwritten.
Arturo: This is the implemented solution in Vera and Superlog.
Dave Rich: This is a needed feature, need to use the looping
variable. Complicated way with other things (mailbox)
Arturo: Like a functional call to pass the arguement.
How does it get the copy? Function is within the fork.
Dave Rich: We have looked at it in superlog, not an easy way
to do this, ...all get overwritten.
Jay: Is it only the automatic variables that get copied?
What about the non-automatic/regular static variable?
Arturo: So far, due to the uncertain lifetime of the automatic variable.
The context may not exist when access is being made,
hard to detect, the issue does not exist with static variables.
Dave: This was the way that process worked.
Jay: Not a problem in process. Do not like lack of symmetry with rest of
fork..join options.
Arturo: In the simple case it is the same. For the shared variable case
would be different.
Dave: Could restrict to read-only.
Arturo: Why complicate it? This is the expected behavior we found when
dealing with customers.
David: Need more time? or wrap up.
Jay: sent it to Steve Sharp, to see if there is response.
David: There are two issues, is there requirement to have this,
then if it is required, to make the solution better if can be.
Ray: Why is this limited to fork..join_none and any?
Dave: These are the only cases where the lifetime is an issue, it
outlives
the sending.
Ray: Is it not a separate problem?
Dave Rich: The issue is the problem with the loop outside of the fork,
Ray: Going out of scope in join/none.
Dave Rich: The processes will continue, re-executing the fork, multiple
times and all at the same time.
Arturo: fork/join-none and any should use this.
David: Will look at it again in the next meeting and finalize.
5. Review of Extensions:
EXT-8: RandCase
David: Discuss and wrap up today (if possible).
Jay: This extension is unnecessary, it provides a shorthand, you can
directly write the case statement with $random
Arturo: True, but more involved, specially if expression.
The example should really show it explicitly,
David: BNF has it in,
Ray: Although in constraint section, but it is executible statement.
Nested randcase...
Arturo: This results in lengthly expressions even for simple statement.
????: Nesting of randcase acts as a random instead of a set of
constraints.
Cliff: Jay, why do you not like it?
Jay: It is just bloat since the language already has the ability to
do this. Can just use $random%2.
Arturo: Not as easy as that. Need to take into account weights.
Can do the same with procedural code. A bit more work since
the full probability must be calculated. It is a short hand.
Ray: Can do this in function.
Cliff: Can see where Jay is coming from, on the other hand E language
makes a big deal.
Stefen: Think it is cool that vendor's want to do this but not sure
want to added it to the language.
Jay: What is stability here? Do we have to define this in terms of
$random (write the function) so we have stable behavior?
Neil: This is a good point. It would be problem if it were not.
Getting different results is always a big problem.
David: Does any one else have any comments on this?
Arturo: Motion to accept the randcase as written.
Jay: Do we vote on this as written or handle the randcase vs caser
or caserand?
Arturo: Not thought about caserand.
Brad: Nothing to match in paranthesis.
Cliff: I like the option of caserand.
Dave Rich: Or case_w for weighted.
Cliff: In other langugages, you were not guaranteed to get
the exact number.
Arturo: This is more of constraint in the e language, soft distribution.
Discussion on hard vs. soft constraints - Cliff, Arturo, Jay
Jay: Executing it 8 times, you are not hitting the it.
Arturo: The cyclic nature is randc.
Jay: Do we need one more syntax to do what can be expressed, not
hard to do in easy cases.
Brad: You can use this to do easy random distributions.
Ray: you can do it in a sub-function, each of possible, would have
a case for it, sum-values of all parameters, to correspond.
Cliff: I do not know at this point about, and about e,
I will have to abstain on this.
Jay: on the function usage, stability between implementaions
here, repeatability ... constraint is harder.
In this case users want stable behaviour in multiple vendors.
Neil: This would be an issue if it is not stable by different
implementation. getting different results between simulators
is always a problem.
Stefan: New random functions not standard?
Arturo: The code is out there.
Jay: Synopsys refused to document.
David: Synopsys documented it.
Jay: Different constraint solver does not guarantee reproducibility.
David: All the vendors had a lack of desire to standardize the
constraint solver.
Jay: Yes, do we want repeatability in this case?
Cliff: That favors the algorithm in the standard.
Arturo: That is fine, but if you come up with a better random number
generator, you can not use it in part.
Stefan: do i want to add new and more random function that are not
the same across multiple simulators.
Arturo: But this is specified, will be the same.
Neil: Where does it say, defined to random call, it is not in the
writeup, it would be on any implementation,
Arturo: Based on urandom, on the thread stability.
Ray: Any chance users want to specify their own random function.
Arturo: There is no mechansim that allows the users to get the
their own random functions instead.
David: Process checkpoint, first: need to review the syntax,
style, review of the submission. After all of these, we can
then to vote to accept the submission, then refining process
starts. The questions on the acceptacne, keyword, sounds
like refinement.
I would like to do the vote on Acceptance.
Motion: To accept this submission.
Moved: Arturo
Second: Dennis
Abstain: None
Against: None
Passed for acceptance
David: The issues:
1. Syntax ( where it is placed in the LRM)
2. Name (case_r,w,..)
3. Repeatability across vendors (is there clarification requiered)
4. Is it required at all?
Brad: Mehdi, I take it that this would not have been donated unless
users liked it.
Mehdi: Users do like it. It is being used at the top layer to generate
multiple scenarios as well as for networking. It has been used
heavily in the Vera environment.
Arturo: This should go in the procedural statement sections.
David: We will go through the next three items to familirize everyone
with this.
EXT-2: Process Control
Arturo: Fine-grain process control. Mike had requested. Reuses process
as a built-in class. Introduces enumeration, state of process,
queried by other process, plus a set of control functions (status,
kill, wait, suspend, resume). This gives the standard control
over processes. The static function self is used to get a process
id and then pass it to other processes that are sharing. Each
process owns its own key and can pass it for manipulation.
David: How to get access to process id.
Arturo: Each process owns its own access key, to pass it to others.
Brad: Does the status function need to be automatic. If user defined
then could overwrite state. This is not user defined.
Arturo: Only catch is that users cannot create objects of this type
but just access. Processes are created by initial block, fork
join etc.
Neil: In the description it says that new returns a handle to an
existing object and not a new object. This seems strange. I do not
understand why. New does not create an object, you are re-defining
the behavior of new,
Arturo: In the new function of class, like assinging self.
it is returning a copy of handle to the current process.
one: To allow forking the process. or simply disallowing calling 'new'.
David: Question: in the forked process, access to self?
global reference to the process, process::self.
Arturo: Or declare variable type process.
David: Self, object of type process three of them,
outside of a thread, what does the new mean, getting object of
process bound to the thread we are in.
Only thing to do with object, is state variables. It is an enum, no
data: how are the objects different?
Arturo: Could be done with only an intermediate class, but it can
outlive the process itself, and then cannot collect the references.
David: To solve this then new acts different.
Ray: Should make new invalid since you may want to define it to do
something else later. Not having a new is not unusual in other
languages.
Neil: That is what i would like to see, get rid of 'new'.
Ray: Not creating it looks like a class with no visible constructor.
It is not that odd not to have new. It would be an error to try
and use it.
Arturo: It would be default constructor. It could be ok for the
proposal.
David: can you determine at compile time that this 'new' is error?
Not a run time check, by elaboration time it can catch it.
Ray: When it was caught not important, return an error, to make it
more useful in the future.
Neil: I agree with that as well.
Arturo: Shall we change the verbage, to say it is an error.
David: Then need to update:
AI-8: Arturo: Update the write-up to include 'calling new
result is an error'
Jay: What is meant by a built-in class. Is it defined in a header
like we did with list?
Arturo: The list is parameterized and therefore needs the definition.
What I meant was that this is a type that can be refdefined but
is just included in the root.
Jay: Is this the same as mailbox, semaphore, and process?
The current LRM does not define the ability to redefine built-in
classes.
Arturo: Process is a keyword, you can redefine the mailbox as well.
The intent was that built-in classes should be redefinable.
David: mailbox is not a keyword, it is a built-in or pre-defined class.
Jay: I do remember, that users can re-define their mailbox.
David: LRM section 7-10, built-in methods,
Arturo: Semaphore and mailbox defined as built-in classes.
David: Built-in types are not documented so that you can redefine.
Ray: With the process, you will not be able to extend it.
Jay: With mailbox,semaphores, 13.1 (page 115 LRM) it says these are
built-in type? Users can not redefine 'int'.
Neil: The third paragraph, it says, can be used as base class to define
higher level classes.
Jay: This may be an erratta topic.
Arturo: The intent was to allow re-defining these [built-in class],
that is why it was not keyword. I do not believe we allow redefining
built-in types.
AI-9: David: Create errata item to add explanation that built-in
classes can be redefined and to distinguish from built-in types.
Neil: Enum has several different states. May need to have a distinction
between normal completion and killed.
Arturo: We did review this, we do not currently keep track of the
process, makes it hard to distinguish between the two,
it could be useful.
Jay: Please do not make us keep track of this. It would cause a
memory leak.
Jay: Does this talk about reuse of ids?
Arturo: This is why they are handles and not ids.
Jay: Is there a requirement on uniqueness? Are you guaranteed that
each time through you get a new one.
Arturo: All references to existing process must go away before the
handle can be reused.
Jay: Use a static variable and set it to handle and then the fork ends.
Can you reuse the handle in the static variable?
Arturo: When the variable is reassigned then the handle can be reused
but not before.
Jay: Need to make sure that the user sees these as unique.
David: If they are referrenced.
Ray: May need a statement about the lifetime here. They need to be
unique, specify, system can optimize to reuse the space, for the
user' the concern is that they appear unique.
Neil: It needs to be clarified.
Arturo: So, we can add "objects of type process can be reused or
destroyed when the process dies and are no references to the
process".
Neil: It appears that there is some ambiguity about when the process
is killed. Is this correct?
Arturo: Yes. This is a multi-threaded environment. They need to
explicitly synchronize. from the process that issues the
kill, it happens immediately, but there are other parallel
processes happening.
Ray: When does the kill happen?
Arturo: From the process point of view immediately. For other
concurrent threads (separate processors) it will happen at a
synchronization event.
Neil: The section on 'kill' does not go into detail. I would prefer
to see more explanation, more like 'suspend'.
Arturo: Is the wording of Suspend ok?
Neil: Yes. It looks good.
AI-10: Arturo: Update/add description for 'kill' in EXT-2.
Arturo: should we create errata for 2001 disable statement?
Cliff: Yes, lots of problem. lousy right now.
Neil: The example uses array notation, 1 to N, for the process.
Is this legal? Not able to find in the BNF.
Arturo: Yes, on page 25 of 3.1.
Neil: Is there a description of referencing an enum within a class?
Arturo: Yes, see section 11.21 page 89, example bottom of page..
David: We will vote on accepatnce at the next meeting.
EXT-14: Constraint completion
EXT-9: Stream Generation
David: The last two items require more time to get them started.
Please review for next meeting and we will discuss them at that
time.
6. Next meeting:
David: The next meeting, september 1st, is not a good date due to
the labor day vacation. We could reschedule it on Monday 25th Aug,
Monday 8 Sept, or Tuesday 2 Sept.
After discussion we decided to hold the next meeting on:
Tuesday Sept. 2, 2003 from 11:00 am to 1:00 pm.
7. Close of meeting at 12:47pm.
This archive was generated by hypermail 2b28 : Tue Aug 19 2003 - 17:28:58 PDT