Hi John, I was just wondering why we are putting this restriction about having untyped arg for passing '$'. In general in the LRM '$' can be assign to int types. Here is an example for $isunbounded in 19.6.3: parameter int foo = $; "The terminal $ may be an actual argument in an instance of a named sequence, either declared as a default actual argument or passed in the list of arguments of the instance. If $ is an actual argument, then the corresponding formal argument shall be untyped and each of its references either shall be an upper bound in a cycle_delay_const_range_expression or shall itself be an actual argument in an instance of a named sequence." Thanks. Manisha -----Original Message----- From: owner-sv-ac@server.eda.org [mailto:owner-sv-ac@server.eda.org] On Behalf Of John Havlicek Sent: Sunday, September 30, 2007 11:04 PM To: sv-ac@server.eda-stds.org Subject: [sv-ac] another small flaw in 1549 Annex F Hi Folks: I am really trying to finish with 1549 Annex F changes. I found another small flaw. It amazes me how troublesome parentheses are. The flatten_property function returns a parenthesis-enclosed expression. If a "disable iff" appears inside the declaration of a named property that is instantiated as the top-level property in an assertion directive, then the result is that the "disable iff" is enclosed in an extra set of parentheses. On this point, we need to use the abstract syntax to judge what is legal because the extra parentheses are not allowed in the Annex A syntax. The extra parentheses are already allowed in the abstract syntax if there is a local variable declaration, but they are not allowed if there is no local variable declaration. I have puzzled about how to fix this easily. The best way I have thought of is to add a "parenthesis" form for the top-level property grammars for T and U. This means adding some trivial cases to the top-level satisfaction relations, but that is not hard. I just have to go find that other Mantis item that is already fixing the descriptions of those relations to ensure that the changes are aligned. Comments or alternative suggestions? J.H. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Mon Oct 1 02:53:07 2007
This archive was generated by hypermail 2.1.8 : Mon Oct 01 2007 - 02:53:13 PDT