[sv-ac] RE: Call to vote: Due June 20

Hi Scott,

Please, see my comments below.

Thanks,
Dmitry

From: Little Scott-B11206 [mailto:B11206@freescale.com]
Sent: Monday, June 20, 2011 17:14
To: Korchemny, Dmitry; sv-ac@eda-stds.org
Subject: RE: Call to vote: Due June 20

Mantis 3033 ____ Yes __X__ No

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

I haven't had time to thoroughly review the proposal, but I do have some questions/suggestions.

1. If always behaves exactly like always_ff in checkers why allow always in checkers? Is it only for backward compatibility? To me, it seems odd to have a restricted form of always in checkers that is exactly the same as another available construct.

[Korchemny, Dmitry] We can deprecate using always in checkers. I suggest discussing this at the meeting.

2. You say, "This checker determinism comes at a price of several restrictions, such as prohibition of using blocking assignments in always and always_ff procedures as described in 17.7.1. " Where is the restriction on blocking assignments as well as the other restrictions stated? Wouldn't it be better to reference that section here?
[Korchemny, Dmitry] I am not sure I understand your comment. These restrictions are listed in 17.7.1 as referenced in this statement.

  I find a similar concern with the opening changes to 17.1. Some restrictions are given, but there is no hint as to where I can find the full set.
[Korchemny, Dmitry] I don't think providing the list of such restrictions may be practical. We don't define checkers as modules without specific capabilities. The checkers have a different definition and a different BNF. We cannot state that the checkers do not allow nets, do not allow user-defined primitives, etc. This is not a limitation, but a definition of checkers. This opening contains the explicit reference to 17.7 where the checker modeling is described. I think that the LRM is required to define how the checker modeling is done, but not how it is different from the module. We can discuss this issue further in our meeting.

Mantis 3069 __X__ Yes ____ No

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

Below are the changes made in 3069:

- Replaced "global clocking declaration in effect" with "effective global clocking declaration"

- Fixed punctuation and spelling

- Changed
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.
To
However, any of its instances in the elaborated design description shall contain at most one global clocking declaration; it shall be an error otherwise.

- Changed
When global clocking is referenced in a sequence declaration, a property declaration, or as an actual argument to a named sequence instance, a named property instance, or a checker instance, the point of reference shall be considered after the application of the rewriting algorithm defined in F.4.1, which flattens properties and sequences, and substitutes actual arguments to sequence, property and checker instances for their corresponding formal arguments. As a result, when a property or a sequence declaration containing a reference to global clocking is instantiated in an assertion statement, the hierarchical lookup rules described above shall be applied from the place of the assertion statement appearance in the source description, not from the point of the sequence or the property declaration. Similarly, when global clocking is referenced in an actual argument of a checker instance, the lookup rules shall be applied after the substitution of the actual argument in place of the corresponding formal argument inside the checker body.
To
When global clocking is referenced in a sequence declaration, a property declaration, or as an actual argument to a named sequence instance, a named property instance, or a checker instance, the point of reference shall be considered after the application of the rewriting algorithm defined in F.4.1. As a result, when a property or a sequence declaration is instantiated in an assertion statement, the hierarchical lookup rules described above shall be applied from the place of the assertion statement appearance in the source description, not from the point of the sequence or the property declaration. Similarly, the lookup rules shall be applied after the substitution of the actual argument in place of the corresponding formal argument inside the checker body.

---------------------------------------------------------------------
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.
---------------------------------------------------------------------
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.