IEEE 200X Fast Track Change Proposal ID: FT-16 Proposer: Jim Lewis email: Jim@SynthWorks.com Status: Proposed Proposed: 12/03 Analyzed: 24-Nov-04 Peter Ashenden Revisions 1-Mar-05 Peter Ashenden 11-Apr-06 minor typo fix. Changed Enhancement Summary to Request Summary. Resolved: Date Request Summary: ---------------------------- The context is a design unit that contains library declarations and package references. Related issues: Relevant LRM section: Request Detail: ---------------------------- A context is a design unit that contains library declarations and package references. Referencing a context is equivalent to referencing the libraries and packages locally. Exactly one context is permitted to be referenced by a design unit. A context clause may reference other context clauses. A context is referenced by context reference: Library Lib_P1 ; context Lib_P1.project1_ctx ; There exists a context in the work library named default_context. With the perspective of the current language definition, the default_context contains: Context default_context is library std ; use std.standard.all ; library work ; end ; To promote the use of ieee standard packages, the proposal recommends that the default context be the following: Context default_context is library std ; use std.standard.all ; library work ; library ieee ; use ieee.std_logic_1164.all; use ieee.numeric_std.all ; use std.textio.all ; end; Analysis: ---------------------------- Analyzed by: Peter Ashenden Date analyzed: 24-Nov-04 Last revised: 01-Mar-05 11-Apr-05 Fixed typo. Changed libary to library The intention is that a context be defined as a unit in a library so that it can be referenced by other units. This suggests that a context should be a declaration, and specifically a primary unit, so that it can be referenced using a selected name like any other unit in a library and so that no other primary unit in the library can have the same name. LCS: Add context_declaration to the production for primary_unit in 11.1. As a consequence, a context declaration is considered to be a declaration, since primary_unit is included as an alternative in the production for declaration in Clause 4. It should be an error if the context clause preceding a primary unit that is a context declaration contains anything. (This helps avoid having names referenced within the context declaration depend on context not present in the environment where the context declaration is referenced.) However, a context declaration should not be considered a declarative region. It is intended to contain only library clauses, use clauses and context references that introduce names into root declarative regions. Hence, context regions should not be included in the list of declarative regions in 10.1. A context declaration may include library clauses, use clauses and references to context declarations. LCS: Insert a new subclause in Clause 11 to describe context declarations. The grammar should be context_declaration ::= context identifier is context_clause end [ context ] [ context_simple_name ] ; Example: context project_context is library project_lib; use project_lib.project_defs.all; library IP_lib; context IP_lib.IP_context; end context project_context; Note that a context declaration and a context reference use a newly introduced reserved word, context. Introduction of a new reserved word has an adverse effect on legacy models. The proposal suggests that a default context be declared, containing library clauses naming STD and WORK and a use clause for STD.STANDARD.all. The proposal suggests that this be used if no context reference is included in a context clause. However, this admits of a model not using STD.STANDARD.all (if the model only refers to explicit context declarations that do not use that package). It would be safer to specify that, when determining the context for a design unit, the standard library and use clauses are included as a starting point. The proposal goes on to suggest that the default context be extended to include a library clause for IEEE and use clauses for the standard packages in IEEEE. However, that would break existing models that use packages containing declarations that are homographs of declarations in std_logic_1164, numeric_std, etc. If an organization or project wants to include use clauses for those packages, it can develop an appropriate context declaration for its design units. What would be appropriate would be to define a context in library IEEE that refers to the standard packages in that library. Since there are packages that declare homographs (e.g., numeric_bit.unsigned and numeric_std.unsigned), they should not be used in the same contexts. A context for STD_LOGIC based packages is as follows: context IEEE_STD_CONTEXT is library IEEE; use IEEE.STD_LOGIC_1164.all; use IEEE.NUMERIC_STD.all; use IEEE.FIXED_PKG.all; use ... end context IEEE_STD_CONTEXT; A similar context declaration could be considered for BIT based packages: context IEEE_BIT_CONTEXT is library IEEE; use IEEE.NUMERIC_BIT.all; use IEEE.NUMERIC_BIT_UNSIGNED.all; end context IEEE_BIT_CONTEXT; Context clauses are described in 11.3 as defining the initial name environment in which a design unit is analyzed. This needs to be revised to allow references to context declarations. LCS: Change the grammar for context_item as follows: context_item ::= library_clause | use_clause | context_reference context_reference ::= context selected_name { , selected_name } ; Clause 11.3 refers to 11.2 describing the effect of a library clause in a context clause and to 10.4 decscribing the effect of a use clause in a context clause. Clause 11.3 should be extended to describe the effect of a context reference. A context clause should be equivalent to an expanded context clause consisting only of library clauses and use clauses. The expanded context clause should be the context clause with each context reference replaced by the expanded context clause of the context clause contained within the corresponding referenced context declaration. It should be an error if a library logical name in a library clause in a context declaration denotes a different design library during analysis of a design unit that references the context declaration from the design library denoted by the library logical name during analysis of the context declaration. Moreover, it should be an error if a library clause in a context declaration references the logical name WORK, or if a prefix in a selected name in a use clause in a context declaration is the library logical name WORK. The rationale for excluding references to WORK is that, when a context declaration is analyzed into a library that is to be refrenced as a resource library, WORK denotes the resource library, whereas when the context declaration is referenced, WORK denotes the current library. Prohibiting reference to WORK in a context declaration will avoid a common case of a library name having a different denotation in a context declaration and in a context reference. The rules in 11.4, Order of analysis, specify analysis dependencies between design units. Since a context declaration is a primary unit, that may refer to other primary units (including other context declarations), dependency relationships are implied. For example, a design unit that references a context declaration depends on the context declaration. If the context declaration is reanalyzed, the dependent design unit must be reanalyzed. No further changes are required to 11.4. Resolution: ---------------------------- [To be performed by the 200X Fast Track Working Group]