[sv-ac] Re: Comments on proposal for 1668

Hi Ed:

I have updated the proposal, and I think I have addressed
all of your comments.  The new proposal is on Mantis and attached.

See also the remarks below.

J.H.

> Hello John,
> 
> I have looked at the proposal (not yet the formal semantics) for Local
> Variable Initializers. It looks good. Please see some minor comments
> below.
> 
> Best regards,
> ed
> -------------
> 
> pp1, par.1: "be performed in order at" --> "be performed in the order of
> declaration at"
> 

Done, although this does not affect the text changes to the LRM.

> pp1, par.2: "For properties, our formal semantics" --> "For properties,
> the current formal semantics"
> Also, should it mention more explicitly that it is an error when the
> sequence admits an empty match?=20

Done, although this does not affect the text changes to the LRM.

> 
> pp3, after Syntax 16-12: Should it mention the kind of types that are
> allowed (or forbidden like for assertions) to be used with local
> variable declarations? I have had quite a few inquiries about that.

Done.  I said that the types allowed are the same as those allowed
in 16.5.1.  As a separate matter, we could consider relaxing 16.5.1.
For example, I guess that bounded queues could be allowed.  Probably
other things could be allowed too.

> 
> pp5, longer par. before 16.9, p.336 CHANGE: "a local variable that s
> assigned shall later become" --> "a local variable that s assigned may
> later become". I think that "shall" should only be used in the specific
> case that is stated in the next sequence.

I considered this carefully.  The entry phrase "Under certain
circumstances" limits the scope of the "shall" to those circumstances,
even though they have not yet been defined.  I don't think "may" is
the right word because we are saying that the variables are required,
not permitted, to become unassigned under the particular
circumstances.

In the end, I changed the sentence to use neither "shall" nor "may":

  Under certain circumstances, a local variable that is assigned later
  becomes unassigned.

Is this acceptable?

> 
> pp6, count_a_cycles: formatting perhaps split the sequence expression
> over two lines.

Done.

> 
> pp8, 16.13.7 1st 2 paragraphs: Why is it necessary to introduce the
> notion of time step and then relate it to the clocking event occurrence.
> I think that it could be stated more simply using "clock tick" which is
> defined in 16.4.

I have changed the text to use "clock tick" or "tick of the clock" 
rather than "occurrence of the clocking event" in these two paragraphs.
I think the wording is simpler than what I had before.

I think that 16.4 is actually defective in introducing "clock tick" as 
an apparently new basic concept rather than defining it in terms of 
other SystemVerilog concepts.  We could fix this in a separate Mantis
item.

To my mind, any "clock" that can have a "tick" in the sense of
Clause 16 is associated with a "clocking event" that can "occur", and
there is no difference between a "clock tick" and an "occurrence of
the clocking event".

> 
> pp8, last par.: "preponed value" --> "sampled value"

Done.

> 
> last page, before A.2.10: Would it be useful to also give the equivalent
> formulation that does not use the initialization at declaration in this
> example? I.e., use the ##0?
> ------------
> 

Done, although I use |-> rather than ##0 to match the function push
in the formal semenatics document.


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.