Re: [sv-dc] RE: Notes on SV-CC feedback

As a side note, once we finish up with these changes, we
should ask Shalom to re-review prior to passing it again
as he mentioned that he didn't review the entire proposal.
I'd like to make sure that his review is complete prior to
resubmitting it to the Champions so that we can avoid
too many iterations.

Gord.

On 7/25/2011 2:24 PM, Little Scott-B11206 wrote:
>
> Hi Francoise:
>
> I did a quick scrub of the attached version and found a few lingering
> problems.
>
> 1. In the comment at the bottom of page 2 there is a nettype that is
> not bold and a data_type (should be data type). There are additional
> instances of these problems. Please fix them all.
>
> 2. On page 3 in the comment //an unresolved nettype 'wTR' whose...
> there are still instances of the single quotes that you state you
> removed. There are additional instances of this problem. Please fix
> them all.
>
> 3. In the changes to 10.6.2, would it be more succinct and equally
> clear to say, "It shall not be a bit-select or a part-select of a
> variable or of an atomic net."?
>
> 4. On page 7, the ordering of those changes is bothersome to me.
> There are multiple changes to A.2.1.3 but they are listed separately.
> The change to A.9.3 is before the change to A.2.1.3. This should be
> cleaned up. There is also a stray 9 in the data_declaration item.
>
> 5. I understand your response to the code examples to indicate that
> you would remove the duplication. There is still significant
> duplication. Can you explain that response more clearly or remove the
> duplication?
>
> Thanks,
>
> Scott
>
> *From:*owner-sv-dc@eda.org [mailto:owner-sv-dc@eda.org] *On Behalf Of
> *Francoise Martinolle
> *Sent:* Thursday, July 21, 2011 3:10 PM
> *To:* sv-dc@eda.org
> *Cc:* francoise martinolle
> *Subject:* [sv-dc] RE: Notes on SV-CC feedback
>
> Scott,
>
> here is our response to Shalom's comments in blue. I am creating
> version 14 which contains all the changes.
>
> During our internal discussion we found 2 issues which merit more
> discussion:
>
> 1). definition of the valid datatype for a net of a user-defined nettype
>
> 2) default initialization values of such nets.
>
> I attach the version 14 which contains all the changes we propose to
> make based on Shalom' comments.
>
> Francoise
>
> '
>
> ------------------------------------------------------------------------
>
> *From:*owner-sv-champions@eda.org
> [mailto:owner-sv-champions@eda.org] *On Behalf Of *Bresticker, Shalom
> *Sent:* Friday, July 01, 2011 6:16 AM
> *To:* sv-champions@eda.org
> *Subject:* Re: [sv-champions] Email vote ending July 1, 2011
>
> P1800 Champions,
>
> We are conducting an email vote for mantis items that are in the
> resolved state. There are 8 mantis items ready for the Champions.
> I have put all 8 into this email vote. Three of these mantis items
> are for for no changes at all. Four of them have a significant
> amount of changes.
>
> Mark your votes as being either Approve or Oppose. If you Oppose,
> please specify a reason. You have until July 1, 6pm (PST) to cast
> your votes.
>
> Neil
>
> 1. 3398 <http://www.eda-twiki.org/svdb/view.php?id=3398> SV-DC User
> defined nets and resolution functions
> There is a proposal (6 pages of completely new text)
> Unanimous voice vote in SV-DC committee meeting on 2011-06-15.
>
> Approve __ Oppose _x_
>
> "A.9.3 Identifiers" should include "net_type_identifier ::=
> identifier".
>
> Added
>
> In "A.2.1.3 Type declarations", "data_declaration" should include
> "net_type_declaration".
>
> Added
>
> The BNF definition of net_type_declaration in 6.6.7 should have a
> syntax "box".
>
> Added
>
> "datatype" should be "data type" everywhere in the text. The code
> comments use a mixture of 'datatype' and 'data_type'. They should
> be all 'data type' or all 'data_type'.
>
> Replaced all occurrences with data type.
>
> "user defined" should be "user-defined" everywhere.
>
> Replaced all occurrences with user-defined
>
> 6.6.7 mentions a "composite value", but this term is not defined
> and will not be clear to many readers.
>
> Replaced with aggregate value. (The composite term is more a VHDL
> term).
>
> In 6.6.7, "Re-Active" should be "Reactive".
>
> Changed.
>
> 6.6.7 says, "A user defined resolution function for an atomic net
> with a data type T shall be an automatic function with a return
> type of T and a single input argument whose type is a dynamic
> array of elements of type T." Then, two paragraphs later, it says,
> "A resolution function shall be automatic (or preserve no state
> information) and have no side effects." The descriptions of and
> restrictions on resolution functions should be combined and
> redundancies should be removed.
>
> I did move the restrictions on the kind of function that were in a
> following paragraph back up with we defined what is a user-defined
> resolution function.
>
> *//*
>
> Is it allowed to re-define a built-in net type as a user-defined
> net type?
>
> No it is not allowed, built-in net types such as wand and wor
> are keywords . The BNF does not allow to redefine a builtin
> nettype as a user-defined nettype.
>
> */./*
>
> 6.6.7 says, "A force statement can override the value of a
> user-defined net". "force" should be in bold code font.
>
> Done
>
> "user-defined net" is used here, before being defined in 6.7.1.
>
> I dislike the term "user-defined net" anyway. All nets are
> user-defined. The term does not reflect the intended meaning, that
> the net has a net type that is user-defined. For example, we do
> not call a variable whose data type is defined in a typedef, a
> "user-defined variable", and rightly so.
>
> I agree. What we should have said is a net of a user-defined
> nettype. Wording has been changed.
>
> The term "atomic net" also does not reflect the nature of the net.
> A net can be defined with type integer, which belongs to
> integer_atom_type. Why would that be less of an 'atomic net'?
>
> In any case, I see no reason to invent two terms. Just have one
> term and use it everywhere.
>
> The terms 'atomic net' and 'net of user-defined nettype' are not
> equivalent.
>
> The atomicity of a net is a property of a net. A net with a
> user-defined nettype is always an atomic net. A regular logic net
> (without a user-defined nettype is also an atomic net).
>
> The atomicity is a property of the net value updation and
> resolution. The net value needs to be updated as a whole,
> consequently the net is said to be atomic. I Imade modification to
> define what is an atomic net in 6.6.7
>
> 10.6.2 says, "The left-hand side of the assignment can be a
> reference to a singular variable, a net, a constant bit-select of
> a vector net, a constant part-select of a vector net, or a
> concatenation of these." That should be updated to reflect the new
> types of nets as well. \
>
> We added a sentence to clarify force and release for atomic nets.
>
> 6.6.7 has the following code comment:
>
> "// a nettype 'wTsum' whose data_type is T and"
>
> "nettype" should be bold.
>
> Done
>
> The single quotes in the code comments everywhere should be
> straight and not "smart quotes".
>
> I remove the quotes
>
> The code examples in 6.6.7 and 6.7.1 should be combined. The
> duplication is unneeded.
>
> We prefer to leave the code part related to nettype declarations
> in section 6.6.7 (which is a section about nettype declarations)
>
> and the code part that is related to the net declarations
>
> in section 6.7.1 (since 6.7 is a section about net declaration)
> and have the exmaple in 6.7.1 refer to the section in 6.6.7 for
> the nettype and resolution function declarations.
>
> In the second code example in 6.6.7, in the line "*real r;", *the
> "r" should not be bold.
>
> Fixed
>
> A few lines down, "Tsum.r= 0.0;" there should be a space before
> the = sign.
>
> Fixed
>
> The BNF change to net_declaration in 6.7, etc. should be in CHANGE
> FROM -- TO form.
>
> Fixed
>
> The following text in 6.7 needs to change:
>
> "A valid data type for a net shall be one of the following:
>
> a) A 4-state integral type, including a packed array or packed
> structure.
>
> b) A fixed-size unpacked array or unpacked structure, where each
> element has a valid data type for a net.
>
> The effect of this recursive definition is that a net is composed
> entirely of 4-state bits and is treated accordingly. In addition
> to a signal value, each bit of a net shall have additional
> strength information.
>
> ...
>
> The default initialization value for a net shall be the value z."
>
> */./*
>
> */This only applies to nets of non user-defined nettypes. Next
> sections 6.7.1 and 6.7.2 will define the legal datatypes for nets
> of user defined nettype/*
>
> */and their default initialization value./*
>
> 6.7.2 says, "Since the actual evaluation of the resolution
> function is subject to scheduling non-determinism, no assumptions
> can be made regarding the state of driven values during the
> guaranteed call, which may precede or follow any driver changes at
> time zero."
>
> But even if a driver values follows the resolution function
> evaluation at time 0, won't the resolution function then be
> re-evaluated? The sentence is not clear about that, and appears to
> hint that possibly no
>
> The resolution function is guaranteed to be called once at time
> zero no matter what, driver updates may happen after it and so the
> resolution function will be called again.
>
> 6.7.2 says, "The default initialization value for a user-defined
> net shall be the default value defined by the datatype." This is
> not clear. Table 6-7 specifies default intialization values for
> various data types. But it relates only to variables. For example,
> it says that the default value of a 4-state integral type is X.
> But for a normal wire (except trireg), it is Z. Till now, wires
> could only have these 4-state integral types, but this proposal
> allows them other types. So what value is applied here? Also see
> Mantis 2409 and 2420.
>
> The default value for a net of user-defined nettype needs some
> discussion. The table 6.7 tht Shalom refers to is for variables
> and contains datatypes that are not allowed for nets.
>
> I also added a minor addition to section 7.7.2 to indicate that
> initailization of memebers of struct apply to nets of user-defined
> nettypes.
>
> 6.10 says, "It shall be illegal to implicitly declare a user
> defined net." I don't see that as needed or relevant. The LRM says
> that an implicitly declared net has the default nettype, which can
> not be a user-defined net type.
>
> We agree to remove that sentence and that section.
>
> I did not review the rest of the proposal, so in the future there
> might be more comments.
>
> 2. 3213 <http://www.eda-twiki.org/svdb/view.php?id=3213> SV-AC Update
> definition of sampled value
> There is a proposal (11 pages)
> Passed by voice vote 2011-06-14: 12y/0n/0a.
>
> Approve __ Oppose _x_
>
> The proposal document should begin with the Mantis number and a
> 1-line description of it in bold font.
>
> In the new 16.5.1, the first paragraph ends, "Below is the formal
> definition of the sampled value.". The next paragraph begins, "The
> default sampled value of an expression is defined as follows:".
> That is, what actually follows the preceding sentence is a
> definition of 'default sample value', not of 'sampled value'. That
> is confusing.
>
> "sub-expressions" should not have a hyphen.
>
> The following two paragraphs seem to be contradictory. The
> difference should be made clearer:
>
> "- Sampled values of automatic variables (see 16.15.6), local
> variables (see 16.10), and active free checker variables (see
> 17.7.2) are their current values.
>
> - When a past or a future value of an active free checker variable
> is referenced by a sampled value function (see 16.9.3 and 16.9.4),
> this value is sampled in the Postponed region of the corresponding
> past or future clock tick."
>
> In "When a past or a future value of an automatic variable is
> referenced by a sampled value function, the current value of
> automatic variable is taken instead," add "the" after "the current
> value of".
>
> In "The sampled value of such variable is the sampled value
> produced by the *clocking *block," add "a" after "such".
>
> In the following two paragraphs,
>
> "- The sampled value of a constant cast expression (see 16.15.6)
> is defined as a current value of its argument. For example, if a
> is a variable, then the sampled value of *const*'(a) is the
> current value of a.
>
> - When a past or a future value of a constant cast expression is
> referenced by a sampled value function, the current value of this
> expression is taken instead."
>
> "constant cast" should be "*const* cast," where const is in bold
> code font. A constant cast is a cast of a constant expression (see
> the BNF).
>
> Add a xref to 6.24.1 as well as to 16.15.6.
>
> "a current value" should be "the current value".
>
> On the following:
>
> "The sampled value of sequence methods triggered and matched (see
> 16.14.6) are defined as current values returned by these methods.
> When a past or a future value of a sequence method is referenced
> by a sampled value function (see 16.9.3 and 16.9.4), this value is
> sampled in the Postponed region of the corresponding past or
> future clock tick."
>
> "The sampled value" at the start of the paragraph should be
> plural. "as current values" should be "as the current values". As
> before, the distinction between the cases described by the two
> sentences is not clear.
>
> In the following paragraph,
>
> "The sampled value of any other expression is defined recursively
> using values of its arguments. For example, a sampled value of an
> expression e1 & e2, where e1 and e2 are expressions, is the
> bitwise and of the sampled values of e1 and e2. In particular, if
> an expression contains a function application, to evaluate the
> sampled value of this expression, the function is applied to
> sampled values of its arguments at the time of the expression
> evaluation. For example, if a is a static module variable, s is a
> sequence, and f is a function, the sampled value of f(a,
> s.triggered) is the result of the application of f to the sampled
> values of a and s.triggered, i.e., to the value of a taken from
> the Preponed region and to the current value of s.triggered."
>
> "using values" should be "using the values". "a sampled value"
> should be "the sampled value". "bitwise and" should be "bitwise AND".
>
> The LRM does not use the term "apply" with respect to
> functions.
>
> Before the next change, "REPLACE", it would be good to add a note
> that it is also referring to 16.5, as two pages have passed since
> the previous reference.
>
> This change adds a heading "*16.5.3 Assertion clock".* The
> previous change adds 16.5.1. However, there is no 16.5.2.
>
> Before the next change, "REPLACE", it would be good to add a note
> that it is also referring to 16.5, as the addition of the 16.5.3
> header in the previous change could make the location of the text
> of this change unclear.
>
> This proposal deletes subclause 16.6.2. So the following also have
> to change:
>
> In 16.6, "There are certain restrictions on the expressions that
> can appear in concurrent assertions. The restrictions on operand
> types, variables, and operators are specified in 16.6.1, 16.6.2,
> and 16.6.3."
>
> In 16.6.1, "--- *class*, static class members are allowed (see
> 16.6.2)". See Mantis 2353.
>
> In 16.9.3, if the intent is for "The following functions are
> provided:" to begin a new paragraph (which I think is good), then
> an explicit note to the editor should be added. Otherwise, it may
> not be noticed.
>
> In 16.9.3, "The function $sampled is useful to access the value of
> expressions used in concurrent assertions in their action block,"
> "action block" should be plural.
>
> I did not review the rest of the proposal, so there may be more
> comments in the future.
>
> 3. 3293 <http://www.eda-twiki.org/svdb/view.php?id=3293> SV-EC
> Clarify $cast behaviour on class handles
> There is a proposal (1 page - all new text)
> Unanimously approved in sv-ec meeting June 6 2011, proposal
> 3293-proposal-v4.pdf
>
> Approve __ Oppose _x_
>
> No technical objections, but:
>
> The proposal document should begin with the Mantis number.
>
> Add a cross-reference from 6.24.2 to 8.15.
>
> After adding in the first paragraph the reference to $cast, the
> second paragraph becomes redundant and awkward and should be deleted.
>
> The first paragraph refers to "the $cast function". $cast can also
> be a task.
>
> That reference should be followed by "(see 6.24.2)".
>
> The font of "$cast" should be consistent.
>
> 6.24.2 shows the function form of $cast first, then the task form.
> Here, it is reversed.
>
> "function int" should be bold.
>
> 6.24.2 shows the $cast arguments as "dest_var" and "source_exp",
> whereas here they are "dest_handle" and "source_handle". If they
> are going to be shown here in a context-specific form, then
> "singular" is not needed.
>
> The end of the first paragraph says "an object whose actual type
> is assignment compatible with", whereas the text of the second
> case is, "an object that is assignment compatible with", omitting
> "whose actual type". They should be consistent.
>
> "will fail" should be "shall fail".
>
> The font size of the last paragraph should be like that of the rest.
>
> 4. 3279 <http://www.eda-twiki.org/svdb/view.php?id=3279> SV-EC
> Enhance method override rules to allow covariant typing
> Close as duplicate of 3278.
> Unanimously approved to CLOSE, already merged into 3278, in
> email vote, ended June 6 2011.
>
> Approve _x_ Oppose __
>
> 5. 3278 <http://www.eda-twiki.org/svdb/view.php?id=3278> SV-EC
> virtual method type rules
> There is a proposal (2 pages)
> Unamiously approved at sv-ec meeting, June 6 2011, proposal:
> 3278-v4.pdf
>
> Approve __ Oppose _x_
>
> No technical objection, but:
>
> The proposal document header should state more clearly which
> Mantis it is associated with in the database.
>
> The proposal should incorporate the changes in 8.19 from Mantis 2950.
>
> "virtual function" in the text should be "virtual method" everywhere.
>
> "super class" should have no space.
>
> In the following paragraph:
>
> "Example 2 illustrates the use of derived class types for virtual
> function return type, and formal argument matching types. In the
> derived class D, the virtual function return type is D, a derived
> class type of C. The formal argument datatype is T which is a
> matching datatype of the predefined type int."
>
> there is a singular-plural mismatch between "class types" and
> "return type". "formal argument matching types" should be
> "matching formal argument types". "datatype" should be "data
> type", twice. "int" should be in bold code font.
>
> The following example should be preceded by "Example 2:"
>
> In the line, "*class *E (type Y = logic) *extends * C*;*", "type"
> and "logic" should be bold.
>
> In the lines,
>
> "E #() v1; // Illegal: type parameter Y resolves to logic which is
> not a matching type for argument 'a'
>
> E #(int) v2; // Legal: type parameter Y resolves to int"
>
>
> "logic" and "int" should be bold, and the quotes around "a" should
> be straight.
>
> 6. 0210 <http://www.eda-twiki.org/svdb/view.php?id=0210> SV-BC Allow
> use of generate in module port list
> No change required
> On May 23, 2011 the SV-BC unanimously voted to resolve this
> issue with no change as the committee was unable to find a
> solution that is technically sound and acceptable to users.
>
> Approve _x_ Oppose __
>
> 7. 2556 <http://www.eda-twiki.org/svdb/view.php?id=2556> SV-AC
> Explicit package scope indication is not allowed for checkers
> There is a proposal (2 pages - a small number of BNF changes)
> Passed by voice vote 2011-05-31: 11y/0n/0a.
>
> Approve _x_ Oppose __
>
> This is OK, though I think the introduction of
> ps_checker_identifier was not necessary.
>
> It could simply have been written
>
> checker_instantiation ::=
>
> [ package_scope ] checker_identifier name_of_instance *(
> *[list_of_checker_port_connections] *) ;*
>
> 8. 3036 <http://www.eda-twiki.org/svdb/view.php?id=3036> SV-AC
> Explicitly allow unpacked data types for arguments of
> assertion system functions
> Duplicate of 2476
> Approved by the voice vote 2011-01-17: 7y/0n/0a.
>
> Approve _x_ Oppose __
>
> Shalom Bresticker
>
> Intel LAD DA, Jerusalem, Israel
>
> +972 2 589 6582 (office)
>
> +972 54 721 1033 (cell)
>
> http://www.linkedin.com/in/shalombresticker
>
> ---------------------------------------------------------------------
> Intel Israel (74) Limited
>
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
> --
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>,
> and is
> believed to be clean.
>
>
> --
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean.
>
>
> --
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean.

-- 
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.