Subject: [sv-cc] Minutes for 04/08/03 meeting
From: Warmke, Doug (doug_warmke@mentorg.com)
Date: Tue Apr 08 2003 - 10:15:45 PDT
---+ SV-CC minutes 04/08/03
---++ Attendee list
* Swapnajit
* Joao Geada
* John Stickley
* Doug Warmke
* Francoise Martinolle
* John Amouroux
* Michael Rohleder
* Ghassan Khoory
* Kevin Cameron
---++ Action items
1. Francoise/Joao/Doug: Take care of cross-committee proposals today.
2. Swapnajit to bring up draft4 editing process with David Smith.
(See below, near top of the minutes)
---++ Proposals needed to address cross-committee consistency issues
1. Joao/Francoise: Inadequacy of Verilog-2001 attributes for
adorning assertion and coverage constructs.
2. Doug: Injudicious use of term "dynamic array" when used
with task/function formal arguments. (Should be "open array")
Please send proposals today so that other committees have a maximum
of time to consider and act on the proposals.
---++ Procedural Issues
Last meeting minutes approval proposed by Michael, seconded by Johnny.
Friday 4/11 is deadline for changes to draft4.
Swapnajit requests that corrections funnel through Joao,
who will collect them up and send to David Smith.
*** DEADLINE for sending comments to Joao is end of day Thursday ***
Swapnajit: Can we draw closure on John Stickley's example?
Not sure if this is closed -
JohnS: We did eventually agree on the API calls last week.
I revised the example and sent to Andrzej for review.
It would be good to have a neutral eye take a look at
the revised example.
Swapnajit: John, please make sure the latest example is
available on the reflector, give a reference to which
mail contains the proper example.
Doug: I will review John's example thoroughly, since I
have to present it at the SV-CC DAC SV workshop.
Michael: We need to look at at least 4 of the LRM issues.
Doug: What is the process for editing the Frame masters?
Joao: Exactly my question. Too many people will be
touching the master documents (at least 3).
Swapnajit: David Smith proposed at the chairs meeting
last Friday that he will own all the LRM issues. Committees
(such as SV-CC) need to provide:
- previous text
- modified text
- change list
Doug: Worried that we will lose lots of Andrzej's edits
if we are forced to go into a change list mode. Since
Andrzej already incorporated lots of SV-CC comments
*after* we had submitted the draft 4 text.
Swapnajit: Will look into this and see if SV-CC can do
one more round of changes on the master, without change
list mode. He will get back to Joao by end of day today.
---++ Review of draft4 LRM issues
Source for review is http://www.eda.org/sv-ec/LRM_Issues.html.
LRM-12: "signature" query from editor.
Joao: This is a well-known term in the world of
language design. What is the issue?
Francoise: What about x-ref'ing the LRM?
Michael: "signature" is defined immediately afterwards.
What about saying "function signature" instead?
Consensus: Doing nothing will be fine.
LRM-13: Cross-ref question to 1.4.5
Joao: Will handle off line, can't understand how
all our original automatic Frame cross-references
got so screwed up.
LRM-28: Cross-ref (again)
Joao will send list of cross-ref updates off-line.
LRM-29:
Should be all lowercase
LRM-30: '1' and 'l'
This is a misunderstanding. This is a lower-case ell,
rather than number 1. Joao wants to change this 'l'
to a 'b'.
LRM-31: Why the underlined comment above?
The comment should be removed.
LRM-32: Language issue, IEEE compliancy problems in vpi_user.h.
We are saying "shall", which implies *mandatory*.
Doug: Silly not to put these natural extensions into the file.
Joao: Technical vote is to change nothing.
Francoise: Thinks we should change the sentence.
What about creating "vpi_extensions.h" for now, then
merging into vpi_user.h later at IEEE standardization?
Joao: But that applies to every aspect of the SV LRM.
Michael: Other problem is that once we get into a side-file,
we will be stuck with it forever.
Joao: We're not changing the normative content of vpi_user.h,
we're just extending it.
Francoise: I disagree that we should extend vpi_user.h.
IEEE owns the contents of that file.
Joao: This is a "normative" part of the standard, the implementors
own the comments. The "shall" has to remain so that code is
portable.
Swapnajit, all (except Francoise): Keep the "shall", fix
grammar problems.
LRM-33: No change.
LRM-34: Should item 6 be deleted, inappropriate as part of standard?
- Yes, item 6 should be deleted.
- The 2 in "expression2" is a footnote indicator, and should
appear as a super-script referencing the footnote.
However, we can just delete the footnote, and hence the "2".
- The dashed-list lines should be deleted.
LRM-35: Why is "system" in double-quotes?
Should remove the quote marks.
LRM-36: Why is "thread" in quotes?
Joao: Should change wording, since "thread" doesn't exist?
Will change the term to "the progress of one path through the sequence"
(without quotes).
LRM-37: Why is "step control" in quotes?
Remove quote marks.
"Step control" is the granularity of stepping through assertions.
Right now it corresponds to clock ticks. Later the granularity
may change. Thus we need this term rather than "clock tick".
Francoise: OK, but for now we should define that "step control"
is a "clock tick".
Joao: Yes that is a good clarification, will add a line to that effect.
LRM-38: "This section ..."
Swapnajit: Looks like a hanging line that needs completion.
Joao: I wonder if they want diagrams here?
Swapnajit: Joao, please double check, complete sentence if
needed and add diagrams if needed.
LRM-39: Same kind issue as LRM-38
Same resolution as LRM-39.
LRM-40: Why using pragma comments rather than attributes?
Joao: We've been over this, attributes are not sufficient
for these purposes. The reason is that attributes have
limited application of scope, i.e.
parameter [1:0] S0 = 0, S1 = 1, S2 = 2, S3 = 3;
Putting an attribute before this statement would only
apply to parameter S0, not all the parameters here.
Attributes can only apply to objects. But we need
them to apply to more, i.e. expressions.
Francoise: What about recoding such that attributes
would work? i.e. using enumeration type rather than integers?
Joao: Significantly more typing, also more error-prone,
and no legacy code contains that yet.
Francoise:
Michael: Concerned here. First it looked like a technical
reason, now a ease-of-typing issue.
All: We agree that the "attribute" concept of Verilog-2001
has inadequacies that should be addressed by SV-BC.
Doug: Swapnajit, please make sure to raise this with SV-BC.
Swapnajit: Francoise, please create an "issue" regarding
the inadequacies of "attribute", then pass it to SV-BC.
Francoise: Can do, but need help from Joao.
All: We need to stick with pragmas for now due to these
limitations.
LRM-41: Related to LRM-40.
Same resolution as LRM-40.
LRM-42: Incomplete sentence.
Joao will look into.
LRM-43: Incomplete sentence.
Joao will look into.
LRM-44: Preceding sentence needs to be fixed.
Some unrecognized Joe Daniels comment.
Joao will take care of this.
LRM-45: Similar
Joao will take care of this.
LRM-62 through LRM-69: Bad cross-refs.
Joao will give a correct list.
LRM-70: svBitVec32
Andrzej may already have corrected this.
JohnS: This is still kind of a sticky issue.
Michael: There is a workaround that we can
return a "long int". If you are returning
a vector, you can return up to 32 bits.
If you are returning more than that, you
have to use a long int rather than bit vector.
Joao: Will make sure the text is very clear
about only allowing function results of up
to 32 bits, not 64 bits.
LRM-71: Editor's note is strange, seems like
this is a cross-reference issue.
LRM-72, LRM-73: Cross ref issues.
Will be resolved by Joao.
---++ Discussion of open vs. dynamic array terminology.
Joao: We could change "open" to "dynamic".
Doug: Concerned about misleading people.
When they see "dynamic", they might not
understand that they can use static actual
arguments for such functions.
Francoise: Agrees.
Joao: The deal is the same with native Verilog.
We are just allowing more dimensions.
Read section 4.6, 4.7, 4.8 to see native treatment.
John: Are you saying you can use the strange
term "dynamic" as a way of writing generic code
that can handle different types of actuals,
such as static multi-D arrays?
Joao: Yes - it is the same intent we have
always had for open arrays.
JohnS, Doug: It is a weird term, but we should be
compliant with the rest of the language.
Francoise, Doug: What about asking the other committees
to change the term (when used for subprogram formals)
to "open". Since there is a term called "dynamic array",
indicating an array allocated with operator "new".
This is confusing, since now "dynamic array" has two
totally different meanings.
<Skipped part of conversation due to frenzied talking>
Doug's proposal: Ask SV-EC to change the term "dynamic array"
to "open array", when used as formal argument. The reason is
that this term is misapplied. The formal argument feature
is *not* equivalent to dynamic arrays allocated by "new".
JohnS: Also, note that we should ask SV-EC to remove the
single-dimension restriction. That way we get full
consistency between DPI functions and native functions.
Summary:
1. Ask SV-BC (or SV-EC) to clarify that static arrays
can be passed as actuals to dynamic array formals.
Need an example to legitimize this use of the concept.
2. Send proposal to change the term from "dynamic" to "open",
when used in task/function argument context.
Swapnajit: Doug, please write up this proposal (Doug's
and John's) and send to Swapnajit. Then he will forward
on to David Smith.
This archive was generated by hypermail 2b28 : Tue Apr 08 2003 - 10:17:19 PDT