Number | 637
|
Category | errata
|
Synopsis | 12.7: missing words
|
State | lrmdraft
|
Class | errata-simple
|
Arrival-Date | Nov 28 2004
|
Originator | Shalom.Bresticker@freescale.com
|
Release | 2001c: 12.7
|
Description |
In 12.7 (Scope Rules), para. 3 currently reads (in P1364-2005/D4): "If an identifier is referenced directly (without a hierarchical path) within a task, function, named block or generate block, it shall be declared either locally within the task, function, named block or generate block, or within a module, task, function, named block or generate block that is higher in the same branch of the name tree that contains the task, function, named block or generate block. If it is declared locally, then the local item shall be used; if not, the search shall continue upward until an item by that name is found or until a module boundary is encountered. If the item is a variable, it shall stop at a module boundary; if the item is a task, function, named block or generate block, it continues to search higher-level modules until found. The search shall cross generate block, named block, task, and function boundaries but not module boundaries. This fact means that tasks and functions can use and modify the variables within the containing module by name, without going through their ports." The important part is the following: "If the item is a variable, it shall stop at a module boundary; if the item is a task, function, named block or generate block, it continues to search higher-level modules until found. The search shall cross generate block, named block, task, and function boundaries but not module boundaries." The first sentence quoted has 2 parts, differentiating between variables and other constructs. The second sentence makes no differentiation. I checked the archives. The 1995 standard and the original XL documentation don't have the 2nd part of sentence 1. 1364-1995 says, for example, "If it is declared locally, then the local item shall be used; if not, the search shall continue upward until an item by that name is found or until a module boundary is encountered. The search shall cross named block, task, and function boundaries but not module boundaries." The differentiation between variables and other constructs dates back to a 1997 proposal by Adam Krolnik which came in part to document actual implementation behavior. Thus, the following statement was added: "If the item is a variable, it shall stop at a module boundary; if the item is a task, function, named block or generate block, it continues to search higher-level modules until found." Adam's proposal included changing the following sentence: "The search shall cross named block, task, and function boundaries but not module boundaries." to "The search for variables shall cross named block, task, and function boundaries but not module boundaries." It appears that adding the words "for variables" was simply missed in the editing. These words would fix the unclearness. However, it appears to me that the entire statement: "The search shall cross generate block, named block, task, and function boundaries but not module boundaries." is redundant, as it repeats the preceding sentences without adding any new information, nor is it any clearer than the preceding setences. Therefore, I propose to delete the entire sentence. Shalom -- Shalom Bresticker Shalom.Bresticker @freescale.com Design & Verification Methodology Tel: +972 9 9522268 Freescale Semiconductor Israel, Ltd. Fax: +972 9 9522890 POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 5441478 [ ]Freescale Internal Use Only [ ]Freescale Confidential Proprietary |
Fix |
In 12.7, DELETE the sentence in para. 3: "The search shall cross generate block, named block, task, and function boundaries but not module boundaries." |
Audit-Trail |
Fix replaced by Shalom.Bresticker@freescale.com on Sun Nov 28 04:10:28 2004 In 12.7, DELETE the sentence in para. 3: "The search shall cross generate block, named block, task, and function boundaries but not module boundaries." |
Unformatted |
|
Hosted by Boyd Technology