VHDL Issue Number: 0027 Classification: Language Definition Problem Language Version: VHDL-87 Summary: It is unclear in which region a generate parameter is declared. Related Issues: 0029, 0072, 0112 Relevant LRM Sections: 9.1, 9.7, 10.1, 10.2, 10.3, 12.4.2 Key Words and Phrases: Declarative Part, Declarative Region, Generate Statement, For Generation Scheme, Elaboration. Current Status: VASG-Approved 1076-1993 Disposition: Closed (All Issues Completely Addressed) Disposition Rationale: LRM is clear now, Generate statements now have declarative regions. Superseded By: N/A ----------------------- Date Submitted: Author of Submission: Doug Dunlop Author's Affiliation: Intermetrics, Inc. Author's Post Address: Author's Phone Number: (301) 657 3775 Author's Fax Number: Author's Net Address: Dunlop@Inmet.Inmet.com ----------------------- Date Analyzed: 1988/10/31 Author of Analysis: A. G. Stanculescu Revision Number: $Revision: 1.10 $ Date Last Revised: $Date: 1995/05/13 21:53:48 $ Description of Problem ---------------------- The example in LRM 9.7 shows two parallel generate statements with a generate parameter "I". It seems this is illegal because the generate parameters are declared in the containing block declarative part (the LRM does not say this, but no where else would make sense since generate statements are not declarative regions (LRM 10.1) and "I" cannot be declared twice in the same declarative part (LRM 10.3). Either the example should be corrected or the rules concerning the scope and visibility of a generate parameter should be redefined. Proposed Resolution ------------------- It is important for the language that generate statements (unlike loop statements) not be declarative regions. If generate statements were declarative regions, there would be no place to write a configuration specification for a component instantiation in a generate statement. (there is no declarative part to put it in). Hence we assume that LRM 10.1 is correct and that a generate statement is not a declarative region. We assume the example in LRM 9.7 is incorrect. VASG-ISAC Analysis & Rationale ------------------------------ Detailed Problem Description;; Let us consider a slightly more general example that the one in LRM 9.7, that contains concurrent statement labels within generate statements. ARCHITECTURE a OF e IS B1: FOR i IN 1 TO 2 GENERATE L: ct1; END GENERATE; B2: FOR i IN 1 TO 2 GENERATE L: ct2; END GENERATE; END a; The following questions arise: 1. Is a generate statement a declarative region ? 2. Is the generate parameter declared in the declarative region of the generate statement ? 3. Are labels of concurrent statements within a generate statement declared in the declarative region of the generate statement ? 4. Should labels be allowed as part of selected names ? The following two LRM quotations show that the generate parameter is declared in the immediate declarative region: LRM 9.7: "For a generate statement with a For generation scheme, the generate parameter specification is the declaration of the generate parameter with the given identifier". LRM 10.2: "The scope of a declaration that occurs immediately within a declarative region extends from the beginning of the declaration to the end of the declarative region." Since it appears to be the intention of the language design to accept the example in 9.7 as correct, it follows that the generate statement is a declarative region, and that LRM 10.1 must be modified accordingly. Otherwise, the example in 9.7 would be illegal because there would be two declarations with the same identifier in the declarative region of the architecture, due to the two generate parameters named I. The following LRM quotation shows that the labels on concurrent statements that occur within a generate statement are declared (before elaboration) outside the scope of the generate statement: LRM 9: "All concurrent statements may be labeled. Such labels are implicitly declared at the beginning of the declarative part of the innermost enclosing entity declaration, architecture body, or block statement". After elaboration, the concurrent statement labels appearing within a generate statement are declared in each of the declarative parts of the blocks that replace the generate statement, along with the constant declaration corresponding to the generate parameter. It is appropriate for the declarations corresponding to the generate parameter and any concurrent statement label contained in the the generate statement to be declared in the same declarative part. LRM 9 should be modified to include generate statements. Given that labels on generate statements become labels on blocks, it should be allowed for generate statement labels to be used in selected names, as any other block label. LRM 6.3 should be modified to allow this. Rationale of proposed solution: Generate statements are elaborated into blocks. All the declarations associated to a generate statement are associated to the elaborated blocks. One can identify three steps when a given name is used by a VHDL compiler. First names are encountered and registered. Second, names may be used at compile time and or elaboration time to build objects. Third, the named objects are used at runtime. Only the second and third steps represent the actual language goals. The first step represents the means to achive the subsequent steps. Rules that apply in the first step should be intended to help the second and third steps. The reason for defining scope and visibility rules is to give precise meanings to names (unique meaning with the exception of overloading). The precise meaning of names is supposed to help at the time the names are used. Therefore, the rules for scope and visibility should be adapted to the requirements imposed at the time the names are actually used. Any other approach is artificial and counterproductive. In other words, rather than be of any help, such rules would just be impediments (e.g. the example in 9.7 becomes illegal just to conform with some artificial rules, rather than to prevent possible ambiguities at the time the name is used for its intended purpose). The solution proposed by the VASG-ISAC acknowledges that generate statements are elaborated into block statements and establishes scope and visibility rules that support the use of all declarations associated to the generated statement, and do not hinder such use. VASG-ISAC Recommendation for IEEE Std 1076-1987 ----------------------------------------------- Generate statements represent declarative regions and have implicit declarative parts. The generate parameter (in the case of a for generation scheme), as well as any labels encountered within the generate statement are considered to be declared in the declarative region of the generate statement. Remark: No explicit declaration can be made within a generate statement. In particular, no configuration specification can be provided in the generate statement, unless a block is declared within the generate statement. The recommended additional text is presented between angle brackets. Text recommended to be removed is presented between square brackets. i) LRM 10.1 should be modified to read: A single declarative region is formed by the text of each of the following: 1. An entity declaration, together with a corresponding architecture body. ...... 11. A component configuration. <12. A generate statement.> ii) LRM 9 should be modified to read: ... All concurrent statements may be labeled. Such labels are implicitly declared at the beginning of the declarative part of the innermost enclosing entity declaration, architecture body, [ or] block statement<, or generate statement. Note that generate statements have only implicit declarative parts.> iii) LRM 6.3, paragraph 10, should be modified to read: ... An expanded name denotes an entity declared immediately within a named construct if the prefix denotes an entity, an architecture, a subprogram, a block statement, a process statement, [or] a loop statement<, or a generate statement>, and the suffix is the simple name, character literal, or operator symbol of an entity whose declaration occurs immediately within the construct itself. VASG-ISAC Recommendation for Future Revisions --------------------------------------------- Generate statements should have actual declarative parts, so that configuration specifications can be provided for components instantiated inside generate statements, without having to declare block statements for this purpose.