Subject: [sv-ec] Minutes for meeting on 24 November 2003
From: David W. Smith (David.Smith@synopsys.com)
Date: Mon Nov 24 2003 - 17:38:09 PST
Here are the minutes from today's meeting.
Regards
David
SV-EC Meeting Minutes
24 November 2003 11:00 am. Monday
(rrrrrrrrrrxrxr)
Voting Members (3/4 or > 75%)
(aaaaaaaaaaaaaa) Arturo Salz (Synopsys)
(-aaaaaaaaaaaa-) Brad Pierce (Synopsys)
(--aaaa-aaa---a) Cliff Cummings (IEEE 1364)
(aaaaa-aaaa-aaa) Dave Rich (Synopsys)
(aaaaaaaaaaaaaa) David Smith (Synopsys)
(-aaa-aaa-a-aap) Dennis Brophy (ModelTech)
(aaaaapaaaaaa-a) Jay Lawrence (Cadence)
(aaa-aaaaaaaaaa) Michael Burns (Motorola)
(-aaaaaaaaaaaaa) Mehdi Mohtashemi (Synopsys)
(aa-aaaaaaaaaaa) Neil Korpusik (Sun)
(--aaaaaaaaaaaa) 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)
(-------------s) Doug Warmke (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-45: David: Clean-up any SV-EC page with LRM change links.
ERR-53: Arturo: Add BNF clarification on where a virtual interface
declaration can occur.
ERR-54: Arturo: Split 19.8.2 into Section 19.5.4 and 19.8.2.
AI-46: Arturo: In EXT-7 remove the last sentence of second paragraph in
8.10.1 and in 17.15.
Minutes 11/24/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-17.txt
David: Folks did not have time to look at the minutes, now minutes
from 11th and 17th,
Neil: One comment on Nov 11.2003, one of the votes, Accept Errata
9, it should be Errata 19. [near the end of the minutes notes]
David: Yes, I believe it should be Errata, 19. We will amend the
minutes to show this.
Motion: Accept Minutes of 11 November
Moved: Ray
Second: Neil
Abstain: none
Opposed: none
Passes with above ammendment
Motion: Accept Minutes of 17 November
Moved: Michael
Second: Neil
Abstain: Jay - wasn't there
Opposed: none
Passes
2. Review of open Action Items (2 Minutes)
AI-5 (Arturo/Cliff): Cliff Cummings email
Cliff: In two weeks will have responce
AI-18 (Unassigned): Waiting on built-in package proposal
No action, waiting on built-in package proposal
AI-39 (Unassigned): SV-AC assume and sequential constraints proposal
There are some discussions, need to look at it after issues
settle down in AC.
3. Review of Inter-committee dependencies (2 minutes)
OCR-2: Discussion on inside proposal from SV-BC
David: New one came out today, has anyone looked at it? Dave
Rich sent
out the new proposal, inside operator becoming more generic.
Hold
off on this till next week.
Ray: Couple of items there that needs to be corrected. The BNF
has
braces missing in the first production.
Dave: They are included in the open range production.
Ray: Then it should not be included in the last production.
Where is
open_range defined?
David: On the LRM changes 2, appendix A, it will bring up all
the
changes there.
Arturo: Some of the links on the website does not work, some of
the
errata items does not work, points no-where.
David: All the LRM links are different, that is the problem.
OCR-3: Sequential constraints
David: Next time
4. Review email vote and resolve (40 minutes)
Errata:
ERR-5 (Arturo): built-in package (10 minutes)
David: Any comments or changes folks want? If not then I will
ask for a motion.
Motion: Accept ERR-5 (latest version)
Moved: Doug
Second: Michael
Abstain: none
Opposed: none
Passes
Extensions:
EXT-3: Virtual interfaces (10 minutes)
Jay: I guess I just do not understand it, all that is being done
here
is that we are creating a reference to an interface, and
store it.
Arturo: Yes, a reference is a way to implement this.
Jay: So if that is the case, why are we restricting it to
interfaces
and not anything else. I prefer to see here is declration of
ref
interface so it is known that it is a reference to an
interface,
reference to an object, if we want to allow it for
interfaces for
now, that is fine, but in the future we want to extend it
for
other things, we can do it. The word virtual does not make
sense.
Michael: I agree. We seem to be overloading the term virtual in
an
inconsistent way. The use of virtual was used more for
binding,
not a data-type, the meaning of the word virtual is messed
around
with.
Ray: I like the word ref better here. The way this is used in
C++ is
a reference.
Arturo: We picked virtual since it seemed to cause less
confusion.
The issue is that an interface is not a datatype. By putting
ref in front of a declaration you are turning it into a
datatype.
This seems irregular. This is called virtual port in Vera.
Virtual converts a declaration to reference, and you can
pass
it as arguement.
David: So there is a reason not to use ref, and a reason not to
use
virtual. The argument that this is not a data-type, Jay is
making an arguement that virutal is not a regular argument.
Jay: We are putting ref in front of something and getting a
reference
to something that is being instantiated. This is a reference
to
something that will exist. We are not declaring anything,
only
a pointer to this.
Arturo: This is not really a pointer. If we were to use ref then
this
leads to wire, ref module which do not want to suppoort. It
is
confusing.
Jay: Yes we do not want to confuse users. Ref may be the wrong
word.
We are using access in VHDL sense for our internal work. I
would
not mind virtual if we followed it by interface so that we
could
leave other options open.
Arturo: We did consider that form, but because it is followed by
an actual interface name it is not required. You can not
just
say reference to a generic interface. The name is required.
Jay: If I say sbus ref, I do not know what type this is.
Ray: To map this on things that I can understand. Interface is
similar to a virtual class, a declared interface is an
extended
class, and with virtual you can reference it.
Arturo: There is some parallel there, but not complete, it can
have wire.
Ray: Part of confusion here is that that an interface is almost
as ao
type, but not quite.
Jay: If you draw a parallel to classes then yes.
Arturo: The fact is that interfaces can also have tasks and
functions,
and initial blocks. Without that it would just an
interconnect
modeler.
Jay: The other 'rat-hole' is whether interfaces contain wires.
Can they
be passed this way. I looked at pass by ref to functions, we
do
disallow passing wires by reference. I think we can have the
same problem here if wires can be used here.
Arturo: You can not unless you use a continuous assignment.
Michael: Is the point here (Page 1 second to last paragraph)
that this
can only be used in a procedural context and is limited to
what
can be used here?
Arturo: Yes, the limitation is that we are not going to create
drivers
dynamically, it was addressing that point,
Michael: The first sentence I understand. The second sentence I
understand. Maybe it is not so bad, discussion has clarified
it
for me.
David: Two questions with the proposal:
1. the intent of what this proposal is doing, semantics;
2. what the syntax, usage of term virtual means.
Are we getting clarity of what this thing does.
Jay: I am ok with what this does (the semantics).
Doug: I liked the syntax "virtual interface" so that future
extensions
can be done. I like the concept of actual indicating the
interface.
You would have to refer to the LRM to see that this refers
to an
interface (if you were new to the language).
Arturo: We did discuss this internally. We thought about virtual
interface. We could leave the interface optional. It is not
ambiguous.
Jay: It would be.
Arturo: The type is not required since the identifier is
sufficient
to determine the type.
Doug: It would allow for future extension.
Arturo: You can do that now.
Doug: I guess that I prefer the lengthiness. There are not going
to be
100s of these.
Jay: Why is this different than pass by ref?
Arturo: When we first passed this by users the first thing they
try
to do is pass it through as a ref port. Then extend it to
ref wires and ref modules. This is not what this is. This
caused
more confusion because the generalization is not correct.
Doug: Having the ref wire seems to go where Cliff's and Karen's
dicussion went.
Arturo: This is different since they can change at run-time.
Dave: This does not change the connection that a ref has it just
changes procedural references. It should not change how sdf
works.
Doug: This is why we should not go the direction of using ref.
Dave: The only place this is useful for a wire is for an array
of
wires and having procedural access to the index.
Arturo: You can stick them in an interface now.
Jay: You cannot identify the type by the identifier. You may not
have seen it yet.
Arturo: Only for interfaces or modules.
Doug: This is better but I would prefer the explicit.
Neil: Your objection is verbosity. It is not an issue of
extensibility
or confusion.
Arturo: Correct.
Ray: The interface identifier is sufficient to determine it is
an
interface.
Arturo: Jay points out that interfaces are global and is
correct.
Michael: Can we do it so that if the identifier is not seen then
we
require the keyword and not otherwise.
Arturo: It is informative, which is why we should not require.
Ray: It was suggested that the interface keyword be required if
the name is not known. That would give both the
extendibility and
clarity.
Doug: This is not very Verilog like.
Ray: I definitely like the interface there.
David: After all these discussions does anyone what to push for
ref
instead of virtual.
Ray: How about a straw poll on this?
David: Ok, let's take a straw poll on using the inerface ter,
Straw poll (for using the "virtual interface name"):
For: Doug, Jay, Ray, Arturo (if optional)
Against: Mehdi
Abstain: Cliff, Michael, Neil, Dave
Michael: I am not sure if this changes extesibliity.
Jay: It makes the keyword interface for these. It might be an
indentifer
that has not seen.
Arturo: Anything other type must be declared before use.
Doug: I would still require it for clarification.
Jay: For registeration we would do it for backward
compabatitily,
if we are designing something new lets not put it there.
David: Compatiblity is not necessarily issue.
Arturo: The user would say why do you make me write "virtual
interface".
It is already known.
Michael: Addressing Jay's concern on identifier that has not be
seen,
Do we ask it to write it if it is not seen, adding another
check,
it may help for people who read the code.
Jay: Are we always requiring the name to match exactly the name
of
an interface.
Arutro: Correct, we do not allow generic interfaces.
Ray: If the name is not known then you have to have the
interface
keyword.
Doug: That is not like verilog-like.
Jay: That refers to verilog that has scoping rules.
David: Lets get closure on this, any definitive proposal on
handling
virtual interface.
Arturo: I would make the motion to allow virtual interface
identifier
with the keyword interface optional.
Ray: If the user uses virtual interface without keyword
interface, we
would not know.
Jay: So in the future we wanted to make a virtual reg, then we
had to
declare it.
Arturo: If you want to make it, it is a hierarchical reference.
Motion: Allow "virtual interface identifier" with the keyword
interface
being optional.
Moved: Arturo
Second: Michael
Discussion:
Michael: This does not allow extensibility.
Arturo: It does.
Abstain: Cliff
Opposed: Jay, Doug, Ray
For: Arturo, Michael, Mehdi, Neil
Vote: Personal: 5 for, 3 against, and 1 abstain. Motion passes.
Company based: 3 companies for and 2 against. Motion passes.
David: 9 eligible voters on the conference call. This is a
technical
change to a proposal. It is a personal and not company vote.
Doug: It is big improvement, I am reasonably happy.
Ray: Where can a virtual interface declaration occur? The first
production in Syntax 19-2 (virtual_interface_declaration) is
not
used anywhere.
Arturo: It can go anywhere function/task declaration is. Yes, it
is
not stated there. Let me go back to see which is the
production.
I can do that as an errata.
David: Two things, one is the errata, the next is agreement on
how it
should be used. If we have an agreement and clarity on this
usage,
then we can put an errata on the BNF.
Ray: Is it just any place that data-type is declared, you can
declare
it in a class, task, module and a function?
Arturo: Yes. It can be used where you can have a variable
declaration.
David: Can you declare it in a package?
Arturo: Good question. I do not think it should be since we
cannot
use hierarchical references. We do not allow interface
declarations
in the package.
Ray: Since the interface identifier cannot be in the package
then
this is illegal.
Arturo: Correct.
Neil: Is this correct? So a virtual interface declaration in a
class
could not be used?
Arturo: The question was if we can declare variable in package.
Neil: If I declare a class in package, with interface in it?
Michael: How does the symbol resolution work then?
Arturo: Cannot. It would have to be postponed until elaboration.
Packages are not post-elaboration.
Jay: Yes, you can not use the thing inside the package at parse
time.
I think we should allow interface declaration inside
package. If
we disallow this, then disallow declaration inside class.
Only virtual interfaces.
Ray: But the virtual interface declaration requires a name
[interface
name]. If you do this, then the interface name must be
hierarchical.
Jay: Only at elaboration.
Arturo: Yes, the interface names are that. You do the semantic
check
at elaboration.
Ray: The interface name must be a hierarchical name.
Arturo: Interface names are in the definitions name space.
Ray: So the name is not in the package, it is a simple name,
an it is not a hieararchical name. Should we have a an error
on this
if the name is not in the package?
Arturo: It should be ok. It makes packages have a component
which must
be semantically checked at elaboration time.
Jay: This is the same as modules.
Ray: One of the features of having a virtual interface referring
to
a named interface means that this cannot be done until
elaboration.
Arturo: I think so when used in a package. The idea was that a
generic
interface can be different interfaces. This is one type
only.
David: So any proposed changes?
Michael: in Sections 19.8.1 and 19.8.2, it appears that this is
really
part of interfaces and not virtual interfaces. The
discussion
seems to be more generic.
Jay: I agree. This could be 1/3 the size. What is different
between
this and other places.
Arturo: Most of the space is used by examples.
Ray: Is there anything in 19.8.1 and 19.8.2 that is not just
example?
Arturo: No, I think it is informative.
Michael: I was looking for new material.
Arturo: 19.8.1 is informative. 19.8.2 is new. The ability to
have
clocking domains as part of interfaces. It should be 19.4.5
where modports are discussed.
Michael: It needs to be touched up to talk about interfaces and
not just virtual interfaces.
Arturo: So I need to split it and keep some in Section 19.8.
Michael: What about 19.8.1?
Arturo: Leave it here.
Motion: Approve EXT-3 with modification that 19.8.2 be split
into
19.4.5 and brought back as an errata.
Moved: Michael
Second: Arturo
Discussion:
Jay: The contents of 19.8.2. This is a way to export the
clocking
domain with the modport.
Arturo: Correct.
Abstain: none
Opposed: none
For: Jay, Michael, Neil, Mehdi, Doug, Cliff
Passes
Doug: Going back to Errata-5, is there language that vendors do
not
add to it?
Arturo: I am not sure that it is not allowed.
David: Vendors can do what they want, but it is not standard.
If the vendor adds to standard package, later someone else
uses
the same name and add it to standard, the vendor does not
comply
with standard.
Jay: Adam was the first to bring this up, he was concerned about
the
attributes to the standard. Synopsys with the VHDL standard
packages added attributes that it took a while to get
standardized. Is it by language legal to add?
David: Is that not a problem with attributes?
Jay: We do not have attribute specification like VHDL.
David: If someone wants to make a proposal please feel free. We
need
to move on to EXT-7.
EXT-7: Reacting to Assertions (10 minutes)
Jay: The changes in the latest are no better then the original
wording.
I think the whole sentence is unnecessary. The process
resumes
in whatever region it resumes in. The entire sentence in the
second paragraph is unneeded. I would prefer to delete it.
Arturo: Correct. I was trying to point out that the observe
region
is there. Can we remove the second sentence.
Jay: That would be ok.
Michael: We would have to change all the other event control if
we
kept this sentence.
Jay: Same issue in 17.15.
Neil: This is the same as before.
Arturo: This is a slight change since the observe region can now
trigger processing in any region. If you can wait for the
completion
of an assertion in a procedural statement then we can go
back.
We can have an assertion clocked by another assertion. Which
means
you go back to the observe region. An arrow feeding back to
other regions.
David: This is in Section 14.4. There is no change to the
picture with
this proposal (as ammended).
Motion: Motion to approve EXT-7 with changes above.
Moved: Arturo
Second: Neil
Abstain: IEEE (Cliff)
Opposed: none
Passes
EXT-16: Event control for coverage (10 minutes)
Jay: This will just be a religous discussion. I agree with
Arturo's response on the reflector. I believe that there is
a place where people will be sensitive to the event ordering
and not understand it. If you trigger at the end point and
copy out parameter values the copy out may not have
happened.
Arturo's response is that this is Verilog.
Ray: The begin and end work a little different. Waiting for the
end
you will have finished the process.
Jay: If you trigger the end and you are in the middle of copy
out
then it will not be correct.
Ray: There are stuff that come from coding and some from LRM. Is
this the later.
Jay: Correct.
Arturo: I proposed that we add in the LRM that if an event is
triggered as the first or last statement of the procedure
(which would be before the copy out).
Jay: The output parameters would not be updated.
Arturo: You cannot have it both ways. You either need to make
this
deterministic or live with it.
Cliff: Anything I can do to make it deterministic.
Arturo: The argument is that if you are using this as part of a
design and you wish to trigger something on the activation
of the task then you do not want ordering (this is hardware
and
things happen concurrently). For coverage in the testbench
then the deterministic behavior is good.
Ray: Where is this being introduced from?
Arturo: To track in coverage.
Ray: Is this stable from where this coming from?
Jay: And, for example, in your coverage, do you bin before the
task
finishes? You might be using the data in the task.
Michael: When I read it, rather than parameters passed to the
task,
you are trying to look for some result of the task. I would
not
expect the task to have done anything by the time calls are
made.
You might have seen some of the effects of task and not see
some others.
Jay: When you think it is triggered before start of task, it is
not,
and at the end of task, coverage block sensitive to the end
of
task, the values of the bins may not have gotten the updated
values.
Michael: Specific example does help here.
Ray: What is the other behaviour, almost block the task?
David: There is an errata to do this for coverage, Errata-52, it
modifies one phrase in section 20.2
Jay: Oh that is bad. We have not voted for that errata.
David: No, but there is an errata to get trrigering immediate,
Arturo: Yes, one is the immediate, and the other is strobe.
Jay: Are you imposing ordering,
Arturo: Only for coverage,
Jay: This is major impact, to the language and some of the ways
that
NC does things. Use one-step values, same as assertions use,
we can have coverage do the same.
Arturo: This is coverage. Here if you are triggering on a
function call,
happen to have called function multiple times, you may want
to
know the values. If you are using edge of clock, in essense
you
are getting the sampled values.
David: From this extension-16, we either have inconsistent
behaviour
between simulation and HW. So the proposal that is..
Arturo: If you are covering the testbench, in the ractive
region,
only mechanism is mailbox, and race-prone.
Jay: In this case go ahead use the event mechanism.
Arturo: If you care about some modifications at the same time,
function calls multiple time.
Cliff: Neil what do you care about it?
Neil: I do not care for non-determininsm that much.
Cliff: I am kind of with Jay on this,
Jay: If we approve this, there is an errata out there. With this
people are triggering but not getting the right value.
Arturo: How is it different from any other event?
Neil: Because of the usage of begin/end, it should be right
there.
Arturo: The trigger is there.
Cliff: That is why asking question from Neil, Jay is swaying me,
but
Neil can sway me back.
Ray: I would like to talk about it next week.
David: Arturo, does this exist in Vera? This behaviour? Is the
predictability a problem?
Arturo: Yes it does exist, no unpredictiblity.
Doug: This has high value and there is another errata on this.
Jay: Unlike some of the other things, scheduling semantics is
core to
this one, add them to this proposal.
Arturo: I do not agree, all this says that there is an
instrument for
users to trigger at the beginning or end of tasks, I do not
think we
need to change scheuling semantics.
David: If this is used in Vera, users have not had problems,
what are
we missing?
Jay: Missing the fact that this is done in Vera, on very defined
synchronization points.
Arturo: This is not true. This was used in the testbench where
things can be racey.
Jay: If you put this in the middle of a Verilog description then
the syncrhonization points are different.
Cliff: Neil have you used it for coverage Tesbenches.
Neil: Not too much.
David: Two questions, the behaviour we want, and then how do we
get the
scheduling mechanisms. Looking at the actual proposal, not
much
about explicitly on scheduling semantics.
Need to make a motion to do something with this. Do we want
to have ability to instrument to deal with it.
Jay: In the current form I do not think it is useful.
David: The way it is written it does nothing to the scheduling
semantics. The question is that, is this useful behaviour.
Motion: Motion to approve EXT-16 as written
Moved: Arturo
Second: Cliff
Abstain: none
Opposed: Jay (Cadence), IEEE (Cliff), Neil (Sun)
For: Michael (Michael), Mehdi (Synopsys), Doug (Mentor).
David: Approval of extension is split, according to the
Operating
Guidelines I vote to break the tie. What I have not
heard people say is that that they do not want the ability
to
trigger an event at the beginning or the end.. The
capability
is very good capability in coverage. The issue is when the
execution of the action block associated with the event is
executed and the data that can be used there. We need to get
this
resolved to get a consistent behaviour. ERR-52 was created
to
address this. So as a chair I am going to vote for it, there
is
a route to address the concern.
Item to look at is to get agreement on scheduling semantics.
Passes.
(NOTE: After the meeting the Chair reviewed the operating
guidelines
and realized that, for company votes the TCC chair is the tie
breaker.
Based on this the vote is still a tie that will be resolved by
Vassilios).
David: I know we have pushing things, appreciate time folks are
spending
on this. It is not clear that we have all issues out.
Next meeting on Monday, I would like to get comments before
the meeting. We need to cover the bitstream extension
(EXT_12) and
ERR-52. Jay has sent out more comments on implication
operators,
ERR-44, scheduling for next week.
So the priorities are: EXT-12 and ERR-52.
7. Meeting logistics (2 minutes)
December 1
EXT-12: Bitstream support
ERR-52 (Arturo): Events used within coverage are immediate
ERR-4 (Arturo): automatics in fork/join_none
ERR-45 (Dave): Wildcard equality
ERR-50 (Arturo): Program visibility rules
ERR-51 (Brad): Method calls and class parameter overrides
December 8
Start LRM editorial review
8. Next Meeting
Monday December 1, 2003, 12:00pm-2:00 pm PST
9. Meeting adjourned at: 12:57pm
This archive was generated by hypermail 2b28 : Mon Nov 24 2003 - 17:44:27 PST