[sv-ac] RE: Call to vote: Due May 30

Mantis 2556 __X__ Yes ____ No

http://www.eda-stds.org/mantis/view.php?id=2556
http://www.eda-stds.org/mantis/file_download.php?file_id=4965&type=bug

Mantis 3069 ____ Yes __X__ No

http://www.eda-stds.org/mantis/view.php?id=3069
http://www.eda-stds.org/mantis/file_download.php?file_id=5091&type=bug

-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

Mantis 3213 ____ Yes __X__ No

http://www.eda-stds.org/mantis/view.php?id=3213
http://www.eda-stds.org/mantis/file_download.php?file_id=5099&type=bug

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?

I like the definitions in the sampled value functions much better now. Thanks for the effort involved in arriving at this point.

Mantis 3295 __X__ Yes ____ No

http://www.eda-stds.org/mantis/view.php?id=3295
http://www.eda-stds.org/mantis/file_download.php?file_id=5097&type=bug

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