VHDL Issue Number: 1088 Classification: Language Definition Problem Language Version: VHDL-93 Summary: Problems with physical mapping of libraries Related Issues: Relevant LRM Sections: 1.2, 1.3, 11.2 Key Words and Phrases: Library, logical to physical mapping. Current Status: Submitted 1076-1993 Disposition: N/A Disposition Rationale: N/A Superseded By: N/A ----------------------- Date Submitted: 1994/04/22 Author of Submission: Jacques Rouillard Author's Affiliation: ESIM Author's Post Address: 13451 Marseille cedex 20 France Author's Phone Number: +33 91054342 Author's Fax Number: +33 91054343 Author's Net Address: rouillard@acm.org ----------------------- Date Analyzed: TBD Author of Analysis: TBD Revision Number: $Revision: 1.8 $ Date Last Revised: $Date: 1995/07/25 18:37:19 $ Description of Problem ---------------------- There are a number of cases where the correctness or behaviour of a VHDL unit depends on the knowledge of the mappings of libraries logical names. This was already a problem in VHDL'87 because of global signals, but now there are shared variables, and the generalized aliasing allows aliases of libraries and design units, which augments the problem by an order of magnitude. The LRM says in 11.2 that the mapping mechanism is not defined by the language, but this mechanism does indeed impact language semantics. LRM definitions: LRM 11.2: A design library is an implementation-dependent storage facility for previously analyzed design units. A given implementation is required to support any number of design libraries. ... A library clause defines logical names for design libraries in the host environment. ... Each logical name defined by the library clause denotes a design library in the host environment. For a given library logical name, the actual name of the corresponding design libraries in the host environment may or may not be the same. A given implementation must provide some mechanism to associate a library logical name with a host-dependent library. Such a mechanism is not defined by the language. 1. Consider entity E is ... end; Now, is this legal? (assuming FOO maps on the same physical than WORK) architecture B of FOO.E is ... end; Note that most implementations allow (incorrectly in the absence of a use WORK.E or use WORK.all) the following: architecture A of E is ... end; LRM 1.2: For a given design entity, both the entity declaration and the associated architecture body must reside in the same library. LRM 1.3: For a configuration of a given design entity, both the configuration declaration and the corresponding entity declaration must reside in the same library. 2. Consider in library Physical1: package P1 is signal S : BIT; end P1; in library Physical2: library L1; -- maps on Physical1 package P2 is alias PP is L1.P1; end P2; in WORK: library L1,L2; -- L2 maps on Physical2. The problem is on L1. architecture A of some_E is begin (L2.P2.PP.S, L1.P1.S) <= BIT_VECTOR'("01"); end; Here, since the two elements of the aggregate must denote different signals, the correctness depends on the fact that the mapping of L1, as seen from P2, is not the same than the mapping of L1 as seen from WORK.A (analysis time). 3. Consider in library Physical1: package P is signal S : BIT; end P; in library WORK, assuming L1 & L2 map on the same library Physical1 library L1,L2; architecture A of some_E is begin process(...) begin L1.P.S <= '1'; L2.P.S <= '0'; end process; end; Here, the question is to determine how many signals and thus how many drivers. If the system 'knows' that L1=L2, then there is only one signal and one driver. Otherwise (the system does not know) it is perfectly correct that two clones of package P be elaborated and two copies of S assigned to. This is a portability problem, since the correctness (or behaviour in some cases) depends on the fact that the system 'knows' the mappings, or not (elaboration time.) 4. Many libraries are published that refer to themselves with a name different from WORK. For example VITAL draft 2.2 has library clauses: "library VITAL;" in many places where VITAL must be identical to WORK. LRM 11.2, in note 1: The design of the language assumes that the contents of resource libraries named in all library clauses in the context clause of a design unit will remain unchanged during the analysis of that unit (WITH THE POSSIBLE EXCEPTION OF THE UPDATING OF THE LIBRARY UNIT CORRESPONDING TO THE ANALYZED DESIGN UNIT WITHIN THE WORKING LIBRARY,IF THAT LIBRARY IS ALSO A RESOURCE LIBRARY [emphasis mine]). Proposed Resolution ------------------- Case 1: Change syntax rules configuration_declaration and architecture_body architecture identifier of entity_name is ... configuration identifier of entity_name is ... to: architecture identifier of [library_name.]entity_simple_name is configuration identifier of [library_name.]entity_simple_name is where library_name must denote WORK, and is defaulted to WORK if missing. The more constrained approach would be to require that library_name be literally WORK. For portability, the minimum would be to require that library_name be known to be WORK, at analysis time, without any knowledge of the mappings. i.e., package P is alias X is WORK; end P; architecture A of WORK.P.X.E is ... ok architecture A of FOO.E is ... error even if FOO -> WORK Case 2 & 3 (& 4 maybe): Add phrasing to the LRM that define that libraries may have identical mapping. Define a way to be sure that two logical map on the same physical. For example, define that a given logical library name must denote a single given physical library in the closure of units needed by a compilation. Case 4: This is maybe a matter of guidelines. It is not very sound that a library refers to another one (including itself) under different logical names, because subtle inconsistencies may happen if for example, instead of refering to itself, it refers by mistake to another copy (a previous one) of the library. Maybe make it erroneous if two different logical map on the same physical, and modify 11.2, note 1 appropriately. VASG-ISAC Analysis & Rationale ------------------------------ This issue has been brought up in several meetings. There appear to be two issues: 1. Is it legal to have multiple library logical names denoting the same design library (other than work)? It appears to be implementation dependent. 2. If an implementation does support multiple library logical names denoting the same design library, then examples of the above code must be unambiguiously legal or illegal. The ISAC decided that the resolution of this issue does not belong to a maintenance group. VASG-ISAC Recommendation for IEEE Std 1076-1993 ----------------------------------------------- stand by. VASG-ISAC Recommendation for Future Revisions --------------------------------------------- This issue should be solved in the context of a new language design, and be part of a LCS.