Subject: [sv-ec] Minutes from today's meeting
From: David W. Smith (david.smith@synopsys.com)
Date: Mon Nov 17 2003 - 17:29:40 PST
Greetings,
Here are the minutes from today's meeting.
Regards
David
SV-EC Meeting Minutes
17 November 2003 12:00 pm. Monday
(rrrrrrrrrrxrx)
Voting Members (3/4 or > 75%)
(aaaaaaaaaaaaa) Arturo Salz (Synopsys)
(-aaaaaaaaaaaa) Brad Pierce (Synopsys)
(--aaaa-aaa---) Cliff Cummings (IEEE 1364)
(aaaaa-aaaa-aa) Dave Rich (Synopsys)
(aaaaaaaaaaaaa) David Smith (Synopsys)
(aaaaapaaaaaa-) Jay Lawrence (Cadence)
(aaa-aaaaaaaaa) Michael Burns (Motorola)
(-aaaaaaaaaaaa) Mehdi Mohtashemi (Synopsys)
(aa-aaaaaaaaaa) Neil Korpusik (Sun)
(--aaaaaaaaaaa) Ray Ryan (ModelTech)
|||||||||||||_ 17 November
||||||||||||__ 11 November
|||||||||||___ 3 November
||||||||||____ 27 Octobter
|||||||||_____ 20 Octobter
||||||||______ 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)
(-aaa-aaa-a-aa) Dennis Brophy (ModelTech)
(-----s-------) Francoise Martinolle (Cadence)
(--a-aaa-a----) Jeff Freedman (ModelTech)
(-----------a-) Peter Flake
(---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-40: Arturo: Write-up intialization and lifetime behavior of
automatic variables in fork..join.
AI-41: Arturo: Update ERR-5 based on built-in packages
AI-42: Arturo: Updates to EXT-7
Section 17.15: Second to the last paragraph, second to last sentence,
change "must occur" to "must start".
Section 17.15: Second to the last paragraph, first sentence,
change "expect statement blocks the first statement" to
"expect statement blocks the second statement".
Section 17.15: Rework expect BNF to create an expect_statement that is
similar to the assert_statement (property_spec and
property_instance)
Section 17.15: Second paragraph. In first sentence change "declare"
to "assert".
Section 17.15: Second paragraph. In second sentence remove
"(i.e., the sequence reacehs its end point)".
Section 8.11: Second paragraph, last sentence. Change to
"remainder of the time-step".
Section 8.10.1: Last paragraph, last sentence. Change to
"Arguments to these sequences shall be static".
Section 8.10.1: Second paragraph, last sentence change
'..shall continue..', to 'resume execution'
AI-43: Arturo: Updates to EXT-3
Section 19.8: mnodule top should be module top in example.
Section 19.8: "interface SBus" should be "SBus" with parenthesis.
AI-44: Arturo: Add errata to functional coverage indicating that any
events
used within coverage has immediate semantics.
Minutes 11/17/03 taken by Mehdi Mohtashemi
1. Review of the meeting minutes (5 Minutes)
<http://www.eda.org/sv-ec/Minutes/SV-EC-Minutes-2003-November-11.txt>
http://www.eda.org/sv-ec/Minutes/SV-EC-Minutes-2003-November-11.txt
David: Will delay until everyone had a chance to look at them.
Will review it with today's meeting minute next week, since
not too many people have had a chance to review it.
2. Review and assignment of new action items and errata
ERR-4 (A)
David: Status on these. Neil you had an email on discussion on lifetime
also had a proposal for it. The pdf file does not seem to be
attached. This is for ERR-4.
ERR-5 (P)
David: Has a proposal on it, Arturo needs to update it based on
packages.
ERR-8 (A)
Dave: I have not looked at that.
ERR-20/ERR-21 (A)
David: Waiting for ERR-4 to be complete.
ERR-44 (A)
David: Implication operator is assigned to Jay. Some email traffic on
consistency issues. Deal with it next week.
David: Two more, one on wild-cards, and semicolon. To get assignments
correct consider ERR-47, keywords as identifiere, that Arturo
has send out an email on this.
Arturo: I think this is a BNF errata, should be Brad's
Brad: Will take this one.
David: Has anyone had a chance to look at ERR-45 to 49. Like to
finalize them and vote on them.
ERR-45 (P)
Michael: Was there any response to wild-card-equality.
David: There was one email from Shalom on this, wait to see if Dave had
a chance to look at it.
Neil: Looks like two are labled at ERR-45, wildcard and missing
semicolon.
David: No, ERR-45 is wild-card equality, ERR-46 is missing semicolon.
Incorrect in email but correct on the page.
Dave: This needs more discussion,
Michael: You are saying in simulation Xs propagated through.
Dave: Also matching xs and zs eventhough it is unknown, it maybe a
misunderstanding.
ERR-46(P)
Motion: To approve ERR-46
Move: Dave
Second: Neil
Abstain:none
Against: none.
Passed
ERR-47 (A)
Assigned to Brad.
ERR-48 (P)
David: Going to ERR-48, set of BNF changes.
Brad: Like to amend the changes, you can have empty parenthesis, tf as
optional. Something that Herman raised in email
David: You have also tied in the covergroup/declaration in program item.
Brad: Most of it is list of function proto-formals, it should be
optional where you would use it. It is unifying things.
Minor items, labels instead of coverpoint identifiers, adding
identfier to endless identifier section.
Motion: To approve ERR-48 with modification to make
list_tf_proto_formals in named_task_proto optional.
Move: Brad
Second: Artruo
Abstain: Neil [Not having time to go through it]
Against: none.
Passed
ERR-49 (P)
Brad: On ERR-49, introduced a rand-case statement. Other
simplification, moved attribute instance up, instead of one per
item. Mostly clean up.
David: Any discussion.
Arturo: Looks good.
Motion: To approve ERR-49
Move: Brad
Second: Artruo
Abstain: None
Against: None.
Passed
David: Two action items, and also Neil's item. AI38 and 39.
AI-38 has no owner, we leave this to 1364, and not pursue in our
committee. Any disagreement with this? Close the AI-38.
AI-39: SV-AC assume proposal, will schedule some time to review
this proposal so we understand implication of this.
ERR-4
David: Neil, is it usefull to spend time on ERR-4. Not having Jay here
is a concern.
Neil: I did talk to Jay about one aspect of it, not putting the
automatic variable inside the fork-join.
David: There is an email link to the .pdf file sent by Neil. Link
may have failed. The changes are bottom of page 1 and page 2.
Neil: How we would pass variables into fork/join-none? Suggestion by
Jay, as arguement [left], another way, to declare local/automatic
variable inside, so when the sub-process is created, it would
create this variables and initialization takes place, so you
get the correct value of the looping variable.
Michael: This would be a special initialization for looping variable.
Arturo: Yes, that is the way it behaves in1364, in a presence of
automatic variable, the only question is what to the lifetime issue.
Michael: The difference here is with fork/join-none, what happens
before and after the process.
Dave: Verilog allows fork/join like begin/end.
Michael: If you moved out of begin/end then all the sub-processes
will share the same variable.
Dave: The lifetime, we are saying that the variables exist while
the sub-processes exist.
Michael: If it is inside begin/end it would not initialize until
process starts. It does not make any difference if you are
sharing one.
Dave: Initialization occurs upon entering the fork/join.
Arturo: That is the way it is today in 1364.
Brad: Is someone making the proposal to 1364., just an erratta or
a proposal.
Dave: One part, initialization occurs before spawning, that is
the errata. Second part is the lifetime, variables within
the processes.
Arturo: They forgot to update the language to include automatic in 1364.
Mostly they would take out the restriction, 'static'
Neil: Jay did not see the example, i have it wrong here, the
variable should be outside of begin/end. We did not discuss the
lifetime issue.
Davdi: Next step, to get a specific proposal for the language we
want to add, clarification for the lifetime. Who can do it.
Arturo: I volunteer.
Neil: Using automatic inside the fork/join, and re-entrant processes.
Ray: As I understand it, page 5 of Neil's writeup, 2ai,
Arturo: It should be 'the lifetime depends on all subprocesses..'
David: If this is acceptible we want to write it up and put it for vote.
Ray: Does it last when subprocess uses it, or as long as the last
subprocesses until all threads in the fork/join terminate?
Dave: There is nothing you could use that feature for, we still
have the probelm that in the loop you need to use the local copy.
Ray: That solves the problem of passing. The original problem,
the lifetime of the automatic variable declared above the
fork/join, and used in the fork/join.
Michael: I would expect that those would go away when you go out
of scope. It would still be possible to reference dead variable.
Ray: That is what 2a is about.
Dave: The fork/join block is a scope higher than the actual process.
David: Maybe that there is no item that does match that correctly.
If you are in the fork/join, the automatic variable has the
lifetime of the subprocesses.
Ray: In the example lifetime of j, the fork/join-none, does not go away
untill all sub-processes in it terminate.
Dave: The scope still alive,
Arturo: As long as any object is alive, the activation-record is alive.
Dave: If there is no references, you do not have to keep
activation-record alive.
David: If you take the case of this example, j, it would have a
value until all the threads within fork/join-none go away.
Dave: No one outside of scope can reference that variable anyway,
so whether it exists/or/not, does not matter.
Brad: Hierarchical references to it?
Dave: No.
David: Once you left the scope, j is not visible, can not discern
it exists.
Ray: It does not matter if there is a thread is around. As long as
the threads that are referencing it, it will be around.
Arturo: Outside the fork/join we can figure out. Inside the fork/join
then each one gets its own copy.
Ray: In terms of lifetime, it does not make any difference, inside
or outside.
David: We make it AI for Arturo to write this up and then bring
it to the committee to vote on.
3. Review 3.1a Extensions and discussion
EXT-7: Reacting to Assertions
Arturo: Three parts, first part allows event control to wait for
end of sequence. End of sequence is well-defined.
Ray: The last paragraph says the event control synchronizes the
end regardless of start time. Does this mean that sequence
could have started before trying to match?
Arturo: Yes, this is alive at all time, declarative sequence.
Ray: In that paragarph, should the semicolons be periods?
Arturo: Sentences are closely related, second one is redundant.
Michael: Does it mention here how long the sequence tiggered is alive?
What if you run into the event control in last cycle of sequence?
Does it say triggered throughout the whole cycle.
Arturo: Sequences are evaluated in observed region. If you execute in
the program block then it will be during the same cycle.
Ray: Semantics you are looking for an event and not a condition.
Arturo: The next section, triggered method of a sequence, some
discussion whether ended or triggered should be used.
David: Has there been any conclusion on the ended vs. triggered?
Arturo: Do not know. The discussion is between Adam and Surrendra.
But no disagreement on the semantics.
Michael: In this example, should there be parenthesis after the
method call.
Arturo: It is optional.
Ray: If it was and'ing instead of or'ing you would be lookin for both
of the terminations in the same time step?
Arturo: Yes, that is correct. You are not waiting for the condition,
you can query afterwards.
The third one, expect statement, not declarative, it is
procedural. This is a procedural statement that allows you
to inline the sequence and wait for its occurence.
The starting point is when you executed the statement
(upcoming clock). The first attempt must succeed. When
the expect statement is true or false it goes away.
Because it is a blocking statement you can use automatic
variables in the sequence (something you can not do with
regular sequences).
Neil: In the second to last paragraph and second to the last sentence
of Section 17.15 you need to change "must occur" to "must start".
Arturo: Ok.
Neil: Just change the word 'occur' to 'start'.
Ray: In the same paragraph, first sentence, it should say
that the expect blocks the third statement and not the first.
Arturo: It should be the second statement.
Ray: It would be usefull to have references in the writeup (to
properties, sequences, action blocks, etc). In the text mention
where you can find them in.
David: Not necessarily the BNF statement.
Brad: This is just two sections later. The reference would not
necessarily be required
Ray: Can the expect statement use a named property rather than
including the whole property spec?
Arturo: Yes you can do that.
Ray: I do not think so by looking at BNF.
David: If you look at the property spec, it can be a name. Maybe a
problem with BNF in this case. Property instance is the only
production that has a property identifier. The expect BNF
has to become two rules.
Arturo: Property spec and property instance are different.
Neil: The assert property statement does show both, both property
spec and property instance.
Brad: Create an expect_statement and use it the same as the
assert_statement.
Neil: Sounds right.
Neil: In the first sentence below the BNF it says the "same syntax used
to declare a property". This is confusing.
Brad: You have expect in it, so not property, looks like more when
you assert property rather than declaration.
Neil: So it is not always declaring,
Arturo: Every property is a sequence,
Neil: It may be ok, looked like it was using two terms interchangabely.
David: Did we decide to take it out?
Brad: The way you declare a property is with a keyword. Same syntax is
used as the assert property.
Neil: It should change "declare" to "assert".
Arturo: Also remove "(i.e., the sequence reacehs its end point)".
Neil: In 8.11, second paragraph and last sentence. Should that be
throught the "remainder" of the time step.
Arturo: This is the same verbiage as for triggered event. What is
the difference?
Neil: It does not exist before it occurs?
David: It does not exist, until the observed region.
Brad: I do not think it is written wrong, but re-wording would be
better.
David: It would be clearer if you say the remainder of timestep.
Neil: In 8.10.1, the last sentence. This refers to sequences used in
this context. Why do they have to be static?
Arturo: They are like declarative sequences. All of those have to
be static. If it is automatic the it will be problematic.
It behaves just like a declarative sequence. The expect allows it.
Neil: This is just here? Not all cases?
Arturo: Actually all sequences except for expect are static.
"Arguments to these sequences shall be static".
Neil: If we change it to 'these sequences', then it will make it
clearer.
Neil: One more item. The last sentence of the paragraph under
Syntax 8-9. The process may have been running in a different
region. When it unblocks it has to be in the reactive region.
The way it is worded implies it started in the reactive region.
If you change "continue to execute" to "resume execution" it is
clearer.
Micahel: How about 'resume execution'
Arturo: I like that.
David: We will revise the proposal and put it out for email vote.
EXT-3: Virtual Interfaces/ports
David: Not have had updates for a while, everyone has a copy?
Section 19.8
Arturo: To allow parameterizing functions/methods with interfaces.
Once you have created an interface, you can pass that entire
interface to a function. We do that with keyword virtual on the
interface declaration. It behaves like a data type. The operations
are limited (similar to chandle), it has to
be same type, assigned null, checked for. There is no such
thing as calling new. the virtual interface is a kind of a
reference to an instantiated interface.
This is something like universal type.
Section 19.8.1
Arturo: This is just explanation of how virtual interface works with
clocking domains. This was added during the first review.
David: In 19.8.1. no new materials, just how it is being used?
Arturo: Yes.
Section 19.8.2
Arturo: This covers the support with modports. The new item is that
the clocking domain declaration can be passed to the modport.
There is also the ability to instantiate a property by a modport.
If it is in a clocking domain then this is available here.
Neil: The assert for the property (19.8.2 last example), do we need
to mention the name of clocking domain or does the modport take
care of that?
Arturo: You do not need the clocking domain name since the modport
takes care of it.
Neil: Looks like typos on page 2 example, mnodule (instead of module).
Right below that, at interface SBus, you use keyword for
instantiation. Don't you just say SBus?
Arturo: page 2, on the top, parenthesis is needed. It is instantitaion.
It is defined up above.
Ray: I looked through it, it will take a little bit to comprehend it.
David: We will do the same thing with this as the previous item.
Update the proposal, corrections, and send it to site for
discussion with email vote on it. If lots of discussion will
bring it up next time.
EXT-16: Event control
David: At the last meeting we decided to split EXT-16 from EXT_10. It
has been posted to the site. This is the same as the last two
pages of EXT-10 from last week. It adds the ability to add
begin/end in function and tasks, to capture coverage on it.
Neil: Did Peter raise an issue with 0 delay function and the
order of execution if we use this?
Artruo: Verilog does not define any such order if you are waiting
for an event. It would be usefull in case of coverage to have it
happen immediately. It would be new semantics.
Ray: This would be a new semantic on enevt control.
Arturo: Correct. When waiting conditions for events in different
processes, Verilog does not specify the order. If you are
looking at the coverpoint, which is just a monitor, and does
not drive anything, it would be useful. It would address
the beginning and end of event to look at from coverpoint.
David: If not part of coverage then what happens?
Arturo: Not specified, you do not want to add determinism in H/W.
This is what Jay had suggested. More like function call semantics
rather than event semantics.
Neil: Do you mean that it is a function call?
Arturo: No. The meaning would be as if you had added a function call
when it is used with a covergroup.
David: Then we should modification to 8.10 discussion to explain this.
Arturo: You are inserting a function call beginning of, as to
coverage you can look at the arguements and cover them. The
effect of waiting for one of these calls would be as if you had,
block is activated immediately.
Ray: The semantics depend on the context which you use it.
Arturo: Correct. This would not change any of the semantics if used in
design. Only for coverage would it have this special behavior.
David: There is nothing about where it is being used,
Arturo: You should be able to use this in a design, it is only
for coverage.
Ray: Still trying to grasp it. Where would you identify this.
Arturo: In the covergroup, where you state begin @.
David: The approach is to re-use the event control mechanism here,
or create a new language. The way it is used, you do not know
where it is used. The coverage interprets it this way, otherwise,
how would it be known?
Arturo: It is also useful debug feature, would not change the semantics
anywhere, but for coverage.
David: We have one AI on this, special interpretation of begin/end
in coverage or come up with a new keyword.
Arturo: If we make it that any event being used in coverage behaves this
way then it does not change this proposal but is an errata to
the coverage proposal.
Neil: We already approved EXT-10.
David: Yes, so this would be an errata to EXT-10 to clarify it. It
just gives a uniform semantics to event control.
Ray: I will have to look at.
David: If no change to this proposal, this would be an enhancement
to already approved coverage. Would be useful to create the
errata and get it out. I will put it up as discussed for
email vote.
4. Meeting logistics
November 17
EXT-3: Virtual Interfaces/ports (5 pages)
EXT-7: Reacting to Assertions (3 pages)
EXT-16: Event control for coverage
November 24
Complete review of errata, action items, complete vote on EXT-3, EXT-7,
and EXT-16.
EXT-12: Bitsream support (6 pages)
5. Next Meeting
Monday November 24, 2003, 11:00am-1:00 pm PST
6. Meeting adjourned at: 1:54 pm.
This archive was generated by hypermail 2b28 : Mon Nov 17 2003 - 17:46:06 PST