Subject: [sv-ec] Minutes for meeting on 15 December 2003
From: David W. Smith (David.Smith@synopsys.com)
Date: Tue Dec 16 2003 - 11:47:21 PST
Greetings,
Thank you to each and everyone of you for the hard and diligent work you
have put in on 3.1a.
Here are the minutes from Monday's meeting.
Have a happy holiday, get some rest, and I look forward to seeing each of
you January 5th.
Warmest Regards and with Holiday wishes
David
SV-EC Meeting Minutes
15 December 2003 11:00 am. Monday
(rrrrrrrrrrxrxrxrr)
Voting Members (3/4 or > 75%)
(aaaaaaaaaaaaaaaaa) Arturo Salz (Synopsys)
(-aaaaaaaaaaaa-aaa) Brad Pierce (Synopsys)
(--aaaa-aaa---a-aa) Cliff Cummings (IEEE 1364)
(aaaaa-aaaa-aaaaaa) Dave Rich (Synopsys)
(aaaaaaaaaaaaaaaaa) David Smith (Synopsys)
(-aaa-aaa-a-aap-p-) Dennis Brophy (ModelTech)
(aaaaapaaaaaa-aaaa) Jay Lawrence (Cadence)
(aaa-aaaaaaaaaaaaa) Michael Burns (Motorola)
(-aaaaaaaaaaaaaaaa) Mehdi Mohtashemi (Synopsys)
(aa-aaaaaaaaaaaaaa) Neil Korpusik (Sun)
(--aaaaaaaaaaaaa--) Ray Ryan (ModelTech)
||||||||||||||||||_ 15 December
||||||||||||||||__ 8 December
|||||||||||||||___ 1 December
||||||||||||||____ 24 November
|||||||||||||_____ 17 November
||||||||||||______ 11 November
|||||||||||_______ 3 November
||||||||||________ 27 October
|||||||||_________ 20 October
||||||||__________ 13 October
|||||||___________ 29 September
||||||____________ 15 September
|||||_____________ 2 September
||||______________ 18 Aug
|||_______________ 4 Aug
||________________ 21 July
|_________________ 7 July
Non-Voting Members (attendance based)
(------a----------) Chris Spear (Synopsys)
(-------------s-s-) Doug Warmke (ModelTech)
(-----s-----------) Francoise Martinolle (Cadence)
(--a-aaa-a--------) Jeff Freedman (ModelTech)
(-----------a-----) Peter Flake
(---------------a-) Ron Goodstein (First Shot Logic Simulation and Design)
(---a-----------aa) Stefen Boyd (IEEE 1364)
(-a---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-53 (David): Extend annex B to include reserved package names and
other
reserved identifiers.
AI-54 (Arturo): Update EXT-16 as voted on and send to David for LRM
inclusion.
Minutes 12/15/03 taken by Mehdi Mohtashemi
1. Review of the meeting minutes (5 Minutes)
http://www.eda.org/sv-ec/Minutes/SV-EC-Minutes-2003-December-8.txt
Motion: Accept Minutes of 8 December
Moved: Dave
Second: Neil
Abstain: None
Opposed: None
Passed
David: Draft 2 is out, will be reviewing and place on the url site.
2. Review of open Action Items (2 Minutes)
AI-39 (): Review SV-AC Assume proposal
David: Any issues to be raised today. We will close this if none is
raised.
3. Review of Inter-committee dependencies (10 minutes)
All closed
4. Review Errata list (55 Minutes)
Proposals:
ERR-8 (Dave): Using event control with methods
David: It is up on the web-page reflector. Sent out Friday Dec 12th.
Dave: This is an errata, event control on either @ or wait on event
when
using a method or object handle. You can use an object as a
handle.
Only restricting on the result of expression to be singular value.
Using method to access class members, then event expression
evaluation after the method modifies the data member. If member
is written to that could also cause expression to be evaluated.
Similiar to a memory write, for example an element of memory being
written.
Jay: So you can write object.method and if method returns a value, you
wake up.
Dave: Yes, you can call the method and any write to that class causes
expression to be re-evaluated. Expression has to be evaluated if
it refers to the data member.
Jay: Even objects that are not referenced, we have to evaluate the
method.
Dave: Yes, exactly like access to memory (write to it).
Jay: May cause confusion,
Dave: We are saying that expression could be evaluated, if you have
written the method correctly, you will not get an event.
Jay: If a function has side-effect, object outside the function got
changed, we have to re-evaluate the function.
Dave: If a function call, arguement is memory reference,
Jay: I do not mind that, but if it is not those, any other element
in the class, so not other things that might be referenced in the
class. It may be correct in the text.
Dave: We do specify object data members, text is sufficient.
David: Any other questions.
Neil: Couple of typos: third paragraph with section. You want to drop
the handle, methods are part of the object not the handle. You
can get rid of the handle.
Arturo: You are differentiating between static method
Michael: The methods do not belong to the handle, but object.
Dave: I can remove the word.
Neil: The example, packer instead of Packet. Further, p=q, and then
@q, p is being updated.
Arturo: Yes it is backward, it should q=p.
Changes:
In third paragraph remove handle from "object handle"
In example change Packer to Packet
In the last assignment in the example change "p = q" to "q = p"
Motion: Accept EXT-8 as modified
Moved: Dave
Second: Neil
Abstain: None
Opposed: None
Passed
ERR-47 (Brad): Keywords as identifiers
Brad: There are various examples that are not accepted by the BNF.
This combines two kinds of task enables into a task enable
statement.
Rather than have void' as a special create a
function_call_statement
Adds the task_method_call and removed array_method_call
In function_call_statement, added void' for function methods and
system function calls. Also added function method call and system
function call as statements.
Added method_call_root to allow implicit class handles before the
.. Call function_method_call and task_method_call and defined
method_call as its own production (instead of an expression).
This subumes the array_call_method and adds note for with clause.
Removed . from implicit_class_handle to match style of rest of
BNF.
Add this.supper to implicit_class_handle
Add implicit_class_handle for variable_lvalue (due to change
in hierarchical variable identifier).
David: Questions or issues?
Neil: In the first part, array_call is removed. Is that in the updated
LRM version?
David: Yes.
Motion: Accept EXT-47
Moved: Brad
Second: Arturo
Abstain: None
Opposed: None
Passed
ERR-52 (Arturo): Events used within coverage are immediate
Arturo: The wording was not explicit, this makes it explicit.
Neil: Comment on the last sentence. I think you meant: Add
one between only and sample in the last sentence.
Cliff: This may not satisfy Jay's concern.
Arturo: This clarifies the request from Michael.
Michael: I think this clarifies the proposal better, but I do not
think
it addresses Jay's concern.
Neil: I do not understand how this changes the scheduling.
(Jay's arguement).
Arturo: It does not change the scheduling algorithm.
Cliff: I do not remember Jay saying that it changes the scheduling,
does
anyone remember Jay saying in the actual meeting this changes
actual scheduling.
David: This was in the minutes of Dec 8th, 2003 (minutes were read).
Arturo: I believe Jay was talking about regular event control. This is
not regular event control.
Cliff: I have a feeling that this will pass over objections Jay, or I
may or maynot have. Do we want to specify which regions.
Arturo: No.
Cliff: I thought postpone was for recording not sampling, observed or
reactive was for sample.
Arturo: I am reading the text of proposal. If you want to add 'in
the postpone region' we can add.
Cliff: You want to add sample, if we at least change 'at the end
of time slot' to 'postpone region'.
Cliff: Is this by company vote, like last time.
David: Extension 15 was with a company vote, do not remember that
Err-52 was company vote.
Change:
In last sentence change 'at the end of time slot' to
'postpone region'
Motion: Accept ERR-52 with indicated change
Moved: Arturo
Second: Neil
Abstain: None
Opposed: None
Passed
ERR-56 (David): Fix all locations in LRM for built-in package to use
std::
ERR-57 (David): Create appendix for std package
David: Annex-C was added, defines the declration currently in the
standard package. One email came on this, about list not included
here. List is well-defined and it was not quite as fundamental as
the other items. Any questions on either Err-56 or Err-57?
Brad: I would like to make sure that in BNF std is syntaxed, either
red or bold. Could you note this.
David: Stu how are you handling this. Courier in text, std is name
of standard package.
Stu: Good quetions, we did not have this before, option is bold,
new in draft 2.
David: This is really not keyword, but a reserved package name.
Stu: There is no specific rule, we can bold/courier other things that
are not keywords.
Brad: There is a precedence for this, $setup/$hold, not system
function, not keywords, but are bold.
Stu: In annex-B, reserved keywords, like to extend it to list other
packages.
David: I will have action item to extend annex-B to include reserved
package name and other reserved packaged names.
Stu: Only allowed two more keywords!
Neil: First page comment spills over to the next page.
David: We will make sure that does not spill over, lots of tabulation.
Motion: Accept ERR-56 ERR-57
Moved: David
Second: Arturo
Abstain: None
Opposed: None
Passed
ERR-58 (Arturo): State that constraints deal with 2-state values
David: Any discussions?
Motion: Accept ERR-58
Moved: Arturo
Second: Mehdi
Abstain: None
Opposed: None
Passed
ERR-61 (Brad): Expect property statement
David: Has SV-AC has approved expect related item?
Brad: The change property item, item 17 passed, we can now do this.
Two issues, BNF does not require a ; in action blocks, statement
and null, this change makes the action block required, so ;
is required.
The second issue, the look and feel BNF says to take it out as
non-terminal statement. Also change to property statement, you
can
get rid of property instance, it is redundant. In the () no longer
property instance is not there, inherited from property_statement
Motion: Accept ERR-61
Moved: Brad
Second: Arturo
Abstain: None
Opposed: None
Passed
ERR-62 (Brad): New copy constructor not in grammar
Brad: This is about the new keyword. Class constructors are not
supported in BNF currently. Class constructor is now allowed.
Dyanmic array initialization is allowed, with dynamic array new.
You can have expressions, not just list of arguement, since we
need to support shallow-copy. In dynamic array new, the change
there
says dynamic_array_identifier. Blocking assignment, class new and
dynamic array new are not optional. Reference to annex-4, in 5.4
was not correct. All places where new was used in text or example.
In text it should be bold, new is a keyword, always on the list.
If it is a keyword you can not use it to overwrite it. Only as a
class constructor, still a keyword.
David: Keyword binding to a class method.
Brad: Yes it is a keyword.
David: Will update on the Draft 3, since Draft 2 is completed for
review.
Stu: It is not clear when it is a keyword. So new should always be
marked as a keyword. The list is not quite correct for Draft 2.
Motion: Accept ERR-62
Moved: Brad
Second: Neil
Abstain: None
Opposed: None
Passed
ERR-63 (Dave): Add block variable to automatic default
Dave: This is a simple change. Variables can also be made automatic
in procedural blocks. This proposal moves the section to the
place scope is discussed. And makes corrections to indicate that
this is so.
Jay: It is just allowing it not changing any definition?
Dave: Yes. Also another clarification, last sentence,
for-loop variable are also automatic, regardless of module-type,
no way to change it. You cannot put a life-time in for-loop
definition.
Jay: Is it allowed to reference as an XMR?
Dave: No.
Motion: Accept ERR-63
Moved: Dave
Second: Arturo
Abstain: None
Opposed: None
Passed
5. Review 3.1a Extensions and discussion (50 minutes)
Discuss and re-vote on EXT-16: Event control for coverage
David: Jay were you and Arturo able to synchronize?
Jay: No.
Arturo: We left this as a coverage item only and not generalized
control. This would limit it so that it does not get confused
with coverage.
Jay: This was were we were at.
Arturo: Move this to the coverage section, move the BNF.
David: Any specific wording.
Arturo: We have to move it back to coverage section, remove this BNF,
move it into function BNF.
Jay: I do think we need to change it from a regular event control,
otherwise users will think this will work just like an event
control.
Dave: Any suggestions Jay?
Jay: No, I do not have any suggestion. Like a regular event control,
will be confusing.
Neil: Seems to have unique syntax, begin and end.
Jay: Yes, but people want to use it in other places.
David: Yes they will find out with compiler error, i understand
the confusion you mention, but not know what to do about it.
Jay: This is different sensitivity from before, we are creating this
new immediate sensitivity.
Arturo: We could just put a note that that is not allowed.
Jay: If it is actually a different event control, then make it
different from the regular one.
Cliff: My concern is that are we rushing it in.
Jay: Let me just make the proposal of @@ for this.
David: What about that suggestion?
Arturo: That is fine with me,
David: We need to formulate a motion, if we need to vote on it.
David: This is a company vote and Mentor is not present.
Motion: Accept EXT-16, move into Section 20, and add BNF for
clock_synchronization, use @@ instead of @ as part of the
covergroup declaration (from EXT-16), and change the verbiage as
appropriate.
Moved: Arturo
Second: Neil
Abstain: None
Missing: Mentor
Opposed: Cliff (IEEE)
Passed
6. Additional items:
Michael Burns proposal (ERR-64)
David: Michael you sent out an email about constraint ordering.
Michael: There was confusion using the solve before causing the solver
to fail. Additional clarification is required in the LRM to
clarify.
Jay: I tried to follow the debate. Is it that it is solved before or
not?
Michael: You are not solving before looking at the rest of the
constraints. You construct the solution space first with regard
to the solve before. Then use solve..before to decide which
variables to solve first. The second change is to describe a
slightly different ordering on function call arguments. This can
cause an overconstrained solution.
Arturo: I agree but have some comments on verbiage. In the first
change I would like to simplify it by:
Change:
Replace the ", and so cannot introduce ...". with
", and so cannot cause the solver to fail."
Arturo: It would be more 'change by sub-dividing the solution space'.
Michael: You want to add something.
Jay: I like the terminology, defining the ordering of solving
variables within the solution space.
Michael: The second change is just describing the function call.
Jay: Ok, ignore what i said (driving 60mph...)!
Michael: Even though the problem was not over-constrained, it would
still fail the constraint-solving, it would it take it to the
sub-space that has no solution.
Arturo: I would just add some editorial there.
David: So, change is:
Instead of describing the solution can change the solution
space...
"can change the solution space"
"subdivides the solution space thereby changing it.
Since... this subdivision can cause the overall constraints to
fail"
Michael: This is fine to me.
Changes:
In first addition:
Replace ", and so cannot introduce ...". with
", and so cannot cause the solver to fail."
In second addition:
Replace "can change the solution space, since constraints on
higher-priority variables are solved without considering
lower-priority constraints at all." with
"subdivides the solution space thereby changing it.
Since constraints on higher-priority variables are solved
without considering lower-priority constraints at all
this subdivision can cause the overall constraints to fail"
Motion: Accept proposal with changes
Moved: Michael
Second: Arturo
Abstain: None
Opposed: None
Passed
Brad: array method names should not be keywords (ERR-65)
Brad: Array method names, uniq instead of unique, and reduced, and
xor reduced for array methods that are reduction.
Neil: uniq gives you the unique enteries in the array.
Stu: I like reduced better than reduction, do not like uniq.
Cliff: I like reduced better reduction.
Brad: Can we change reduction to reduced.
Change:
Change reduction to reduced in names in proposal.
Motion: Accept proposal with ammendement to use reduce.
Moved: Brad
Second: Michael
Abstain: None
Opposed: None
Passed
Brad: optional () in subroutine call
Brad: Thomas Kruser brought up, sub-routine call, dropping () from
function call can be ambiguous. Whether name refers to register
value, implicit register or recursive function call. My proposal,
allow dropping (), except the function calls.
Cliff: Have you passed this by the Intel folks?
Brad: No, they are doing this as a statement.
Cliff: They give names like step1, step2, step3,
Brad: That makes sense, how about when it is not a statement.
Jay: You can not wait inside a function.
Brad: You can use the current value inside the function. Maybe there
is no consensus. The proposal was just to not allow empty(), on
the function calls. But Cliff raised the point that a function
used as a statement, function with a void return value.
Jay: When we allow dropping (), was questionable, given that we
have allowed it then we let it live,
Brad: I withdraw this.
Cliff: Clocking and Scheduling changes (ERR-42)
David: Cliff you are next on Agenda.
Cliff: Finally got it in the email this morning. The main issue,
sections 14 and 17.
Clocking-domain be changed to clocking-block. I think I have found
everywhere in the LRM. Sections 14-15 and 17.
In 14.3, numbered items, fourth paragrah after that.
In section 15.2 I added two examples. What is not clear, if we do
not have the posedge, are we allowed to use negedge. Is this
legal?
Arturo: Yes.
Cliff: Everyone agreed?
Jay: Yes we agreed, might be crazy to do, but we can.
Cliff: Arturo, did we say we need to change any wording just above the
example.
Arturo: We needed to change to 'as specific edge'.
Cliff: Does that take care of beginning of the sentence, we will
propose that we change opposite to specific. also add two
examples,
clear it up.
In 15.3, 3 paragarphs after the figure. change, inputs with
explicit
#0 skew, and clocking with no-skew. Does that look right.
Arturo: Yes, because no-skew defaults to 0. What happens if you put
explicit #0 skew.
Cliff: Does next paragraph clarify that. Should we add () in above.
Arturo: You would add it above, ' explicit #0 skew, ...)
Cliff: Is that true, #0 does not put in the active region?
Arturo: Yes. Should the word 'clocking' be bold.
David: Should the clocking be bold.
Michael: About the program, is it bold
Stu: I have tried to make it bold when we are refering to it.
Cliff: In 15.12,
Neil: This does not look right.
Cliff: As long as #0, you are looking at the
Arturo: As long as you do not use #0, values just before, if you use
step, then just before the prepone region.
Neil: If I do not specify #0, it is not a #0 skew.
Cliff: Yes, wording needs to be exact. I may have put the next one
without anyone approving it.
Arturo: I think this is not right, you changed it to say ' in the
postpone region' that is not true. I would leave it the way it
was before.
Cliff: I can take it off from this proposal.
In 15.14, just before 15.14.1, NBA. The next one, is it right?
Arturo: I think that is wrong,
Cliff: I will remove it. Now in section 16.1, third item, changed
the exectuion in reactive, to 'scheduling'.
David: Should we put it in as it is?
Cliff: On to the next items in the modifications.
On 16.5.1, is that correct.
Arturo: We call it observed-region. (change from observe-region)
Cliff: Figure 14.1 it is called observed region.
In 16.5. Is there any place where 'blocking-task' is defined?
David: Is blockig-task used in 1364 at all.
Cliff: No, we are thinking of blocking assignment. If we change to
task that has blocking statement.
Michael: Do we have to worry about task that may or maynot block?
David: How do we define a blocking task.
Stu: A task that does not execute in zero-simulation time.
If it is waiting for event you have to block. Not for an event
that has already occurred.
Blocking statements are not defined anywhere.
Cliff: I think it is at least in a BNF. Shall I kill that for now.
Arturo: I like Stu's definition.
Stu: I searched 1364-2001 c, blocking statement is not there.
Cliff: So, task that does not execute in zero-simulation time.
David: You have a few more that are typos.
Cliff: %0t, if $time format would fail.
Dave: 0t is not legal.
Cliff: Bolean may need to be capitalized.
David: We will get it straight for this.
Brad: Why can we not make a cross reference, is this a different
meaning of pure.
David: I have no problem with getting the word 'pure'.
Brad: The function should be automatic and pure.
Dave: I do not know if we need any of this since we have defined
function
Cliff: Remove the whole sentence?
Arturo: Change 'they do not need be automatic ..' to 'they should not
be automatic..
Dave: I would remove the whole sentence.
Cliff: OK.
David: Rest of your changes are clocking-block changes.
Dave: Where is %d or %0d is defined for $error.
Cliff: I am not sure for %0d,
Dave: %t does not require that $time format, there is default on that.
Cliff: We will leave the t there. I will remove the 0, and keep the
t.
Motion: Accept proposal with above changes
Moved: Cliff
Second: Arturo
Abstain: None
Opposed: None
Passed
7. Meeting logistics (2 minutes)
Next meeting scheduled for 5 January 2003 from 11:00am until 1:00pm
Start LRM editorial review
Glossary
Verification of all cross references
Check all changes for consistency and correctness
8. Next Meeting
Monday December 15, 2003, 11:00am-1:00 pm PST
9. Meeting adjourned at: 1:10pm
This archive was generated by hypermail 2b28 : Tue Dec 16 2003 - 11:53:38 PST