[sv-ac] Email ballot result (May 30 April)

Below are the results of the email ballot:

2556 3069 3213 3295

Yes Yes Yes Yes Laurence Bisht (sent late)

Yes Yes Yes Yes Eduard Cerny

Yes Yes Yes Yes Ben Cohen

Yes Yes Yes Yes Shaun Feng

Tapan Kapoor

Yes Yes Abstain Yes Jacob Katz (sent late)

Yes No No Yes Scott Little

Yes Yes No Yes Manisha Kulshrestha

Anupam Prabhakar

Erik Seligman

Samik Sengupta

Yes Yes Yes Tom Thatcher

Issue 2556 passed 6y/0n/0a with friendly amendments

Issue 3295 passed 6y/0n/0a.

Issues 3069 and 3213 failed.

Comments and friendly amendments

Ben:

3069:

Make the following editing:
In the following example the property p is declared in a module which contains containing a global clocking declaration

3213:
[Ben] Need to add a reference to a subsection that clarifies how .triggered is used after "The sampled value of s.triggered is its current value, and $stable(s.triggered) compares the current value of $stable(s.triggered)with its value from the Postponed region of the previous clock tick."
This reference is currently in the works and was not yet approved. It's in
http://www.eda-stds.org/svdb/view.php?id=3552
Updated on 5/24/01

1) Added

a1: assert property(@ (posedge clk) $stable(s1) |-> c );

a2: assert property(@ (posedge clk) (s1.triggered) |-> c);

2) These guidelines are in 16.14.6 Sequence methods, which is a subsection of 16.14 Multiclock support; Yet these guidelines are shown for singly clocked properties. Shouldn't these guidelines belong to the end of section "16.9.11 Detecting and using end point of a sequence"

[Ben] Editing and clarification changes needed,
This is because s.triggered is evaluated in the Observed region, and the function $rose in a concurrent assertion is also called in the Observed region after the value of s.triggered has been computed, compares this value of s.triggered with its value in the Postponed region of the previous clock tick.
This does not read well, compares this ... I don't understand it.
....
In the latter case the sampled value of s.triggered is always 0 regardless of the sequence match, and therefore $rose(s.triggered) always returns false in this context.
[Ben] Again, do we need a reference to examples, as mentioned above?

Tom:

2556:

Friendly amendment; Where in A.9.3 should the definition of ps_checker_identifier be added? It might be nice to have it just following the definition of ps_covergroup_identifier, or in that area. Add some context to the proposal to indicate the insertion point.

Manisha:

3069:
Friendly amendments:

1. In the note related to backwards-incompatibility, it should be rephrased as:

In the 2009 definition only one global clocking declaration was allowed in the elaborated design description, it could be specified in any module, interface or checker and referred from anywhere in the description.

3213:
Here are my comments:

1. In 16.5.1, it says "An initial sampled value of an expression is defined recursively using values of its arguments as explained below in the definition of a sampled value of an expression. " Do we really need to make this clear. As long as intial sampled values of variables are defined, it is just obvious ??

2. Sentences like "A sampled value of an expression ...", shouldn't it be 'The sampled ...' ?

3. There are terms like "sampled value" and "preponed value" in italics, I do not see their usage anywhere. What is the reason for making them italic ?

4. What is the reason for striking out "free checker variables" in section 16.5.3.

5. The deleted section 16.6.2, does have more details. What was the reason for deleting it ? have the things in there have moved somewhere else ?

6. In section 16.9.3, there is new word added 'future', but this section does not have future value functions.

7. In 16.10, instead of 'uses a sampled', it should be 'uses the sampled'.

8. In 16.9.3, you have no restriction on using sequence methods in sampled value functions but later in 16.14.6, it says:

It shall be considered an error to use the sequence methods matched in sampled value functions (see 16.9.3).

9. In 16.15.6.1, "are used, rather than the sampled values. This contrasts with the assertion's expressions arguments, where sampled values are used. ..". I think a reference to the section where sampled values are defined will be good here also.

Scott:

3069:
-A given module, interface, checker, or program

-However, any of its instances in the elaborated design description shall contain at most one global clocking declaration. It shall be an error if there is more than one global clocking declaration in a given module, interface, checker or program instance in the elaborated design description.

The above two sentences seem to be saying the same thing to me. Is there a difference I don't see? I would prefer to strike the first.

-I find "global clocking declaration in effect" to be awkward. I suggest revising in the following way:

Although more than one global clocking declaration may appear in different parts of the elaborated hierarchy, only one global clocking declaration is in effect active at each point in the elaborated description. The $global_clock system function shall be used to explicitly refer to the event expression in the active global clocking declaration in effect. The active global clocking declaration in effect for a specific reference is determined using the following hierarchical lookup rules, which iteratively check the elaborated hierarchy of the design to find the global clocking declaration closest to the point of reference.

-I suggest the following revision and a similar one to the last sentence of b(:

If not found and the current scope is a top level hierarchy block (see 3.11), the lookup shall terminates and shall result with an error.

-To be more clear and consistent with a( I suggest:

Look for a global clocking declaration in the parent module, /interface, or/checker scope instance scope of the enclosing module/interface /checker/program instantiation, or a generate block therein.

-Otherwise, continue up the hierarchy until a global clocking declaration is found or a top level-hierarchy block is reached

-All references to top level should be top-level.

-I would like to see the language in the paragraph at the top of page 3 tightened and clarified. I don't have time to work through specific suggestions now. The first sentence is very long and wordy. Is the description of F.4.1 necessary? Could the list be reworked to avoid multiple ors in a single list? I would suggest striking "As a result" and "containing a reference to global clocking" in the second sentence. I would suggest striking " when global clocking is referenced in an actual argument of a checker instance" in the third sentence.

-In the following example the elaborated design hierarchy of the design contains

-Please change "elaborated hierarchy of the design" to "elaborated design hierarchy" everywhere.

-The resolution of the calls to $global_clock is performed after the substitution of the actual checker arguments in place of the corresponding formal arguments, and after the flattening of the properties in the assertion statements,. therefore a All calls to $global_clock in this example refer to top.check.checker_clk.

-Please fix the spelling of description in The following example is illegal, because the module top in the elaborated design description

backwards-incompatibility

In the 2009 definition only one global clocking declaration was allowed in the design description,; it could be specified in any module, interface, or checker and apply everywhere in the description. A design conforming to IEEE Std 1800-2009 could have a global clocking declaration defined in a non-top-level module and use $global_clock out offrom the subhierarchy of that non-top module. Such a design shall not be conforming to this standard

3213:

When a past or a future value of an active checker variable is referredreferenced ...Please fix all instances of this issue

The sampled value of sequence methods triggered and matched (see 16.14.6) areis defined as current values returned by these methods.

I share Manisha's concern regarding the removal of 16.6.2. In your response you ask what about automatic variables? My understanding is that in the current LRM references to automatic variables in an assertion are illegal. Am I mistaken? Why can I reference them in assertions but not sampled value functions?

Laurence:

3069:

2 Friendly amendments:

Links to F.5.1 should be replaced with links to F.3.1

You have extra enter before the last line.

Jacob:

3213

haven't read in depth

---------------------------------------------------------------------
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, and is
believed to be clean.