Subject: Re: [sv-cc] Minutes for 04/08/03 meeting
From: David W. Smith (David.Smith@synopsys.com)
Date: Tue Apr 08 2003 - 16:37:43 PDT
Greetings,
I notice in your minutes that the concept of SV-CC doing one more round of
edits on the master came up.
Please be aware that the LAST round of edits before sending this to the
board is to close this Friday.
All changes for the board voting version must be included. In that line I
will incoporate any of the changes I find resolved in your minutes. If there
are other changes please make sure you send them to me.
Regards
David
----- Original Message -----
From: "Warmke, Doug" <doug_warmke@mentorg.com>
To: <sv-cc@eda.org>
Sent: Tuesday, April 08, 2003 10:15 AM
Subject: [sv-cc] Minutes for 04/08/03 meeting
>
> ---+ 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 - 16:40:05 PDT