VHDL Issue Number: 0025 Classification: Language Definition Problem Language Version: VHDL-87 Summary: Allowed variations in implementations of VHDL I/O are unclear. Related Issues: Relevant LRM Sections: 3.4, 4.3.2 Key Words and Phrases: File object, external file, file declaration, logical name, read, write Current Status: ISAC-Approved 1076-1993 Disposition: Closed (All Issues Completely Addressed) Disposition Rationale: VHDL-93 LRM was updated. Superseded By: N/A ----------------------- Date Submitted: 1989/02/22 Author of Submission: Doug Dunlop Author's Affiliation: Intermetrics, Inc. Author's Post Address: 4733 Bethesda Ave #415 Bethesda, MD 20814 Author's Phone Number: (301) 657-3775 Author's Fax Number: Author's Net Address: dunlop@inmet.inmet.com ----------------------- Date Analyzed: 1989/02/22 Author of Analysis: Doug Dunlop Revision Number: $Revision: 1.9 $ Date Last Revised: $Date: 1995/08/02 23:54:13 $ Description of Problem ---------------------- The VHDL LRM is unclear about the meaning of I/O in a variety of circumstances. For example, the LRM does not specify the effect of simultaneous use of multiple file objects associated with the same external file. It is necessary to clarify what users may assume from VHDL I/O and what freedoms an implementation of VHDL I/O is allowed. Proposed Resolution ------------------- Due to host operating system dependencies, device dependencies, etc., it makes sense for the LRM to be somewhat vague on the precise meaning of I/O. This is not particular to VHDL. For example, there are aspects of I/O in Ada that are not specified in the Ada LRM. Quoting from the Notes in Ada LRM 14.1: An implementation may restrict the number of files that may be associated with a given external file. The effect of sharing an external file in such a way by several file objects is implementation dependent. It seems what is needed in VHDL is simply a clarification of what aspects of VHDL I/O are outside the scope of the LRM and are thus implementation dependent. As an illustration, the paragraph beginning "If multiple file ..." in LRM 4.3.2 states one implementation-dependent aspect of VHDL I/O. This idea needs to be extended and generalized. All such implementation dependencies should be identified and the corresponding freedoms that are granted to implementations should be described. VASG-ISAC Analysis & Rationale ------------------------------ A description of the host dependencies in VHDL I/O would be valuable to both VHDL users and VHDL implementors. These host dependencies are necessary in order to take into account the different treatment of files and devices across various operating systems. VASG-ISAC Recommendation for IEEE Std 1076-1987 ----------------------------------------------- The following items define the variations that are allowed an implementation of VHDL I/O. Each item consists of a pair: a situation that can occur during the simulation of VHDL and the set of variations in meaning that an implementation is allowed for that corresponding situation. (1) WRITING TO EXISTING FILES VHDL Situation: An OUT-mode file declaration is elaborated. The logical name in the file declaration denotes some physical file F that already exists. Allowed Variations in Meaning: Existing file F is now opened for writing in append mode (no data is lost); or F is opened for writing at the beginning of the file (contents of file F are lost); or A new file (e.g., a new "version") is created and this is opened for writing at the beginning of the file. (2) WRITING TO A FILE ALREADY IN USE IN THE SIMULATION VHDL Situation: An OUT-mode file declaration is elaborated. The logical name in the file declaration denotes some physical file F that already exists and is already associated with another file object in this simulation. Allowed Variations in Meaning: A simulation error occurs diagnosing this problem; or No error occurs and the effect is as documented by the implementation vendor. (3) READING NON-EXISTENT FILES VHDL Situation: An IN-mode file declaration is elaborated. The logical name in the file declaration denotes some physical file F which does not exist. An attempt is subsequently made to read from the file. Allowed Variations in Meaning: A simulation-time error occurs at the time the file declaration is elaborated; or A simulation-time error occurs at the time the read operation is attempted. (4) READING A FILE ALREADY BEING WRITTEN TO IN THE SIMULATION VHDL Situation: An IN-mode file declaration is elaborated. The logical name in the file declaration denotes some physical file F that already exists and is already associated with an OUT-mode file object in this simulation. Allowed Variations in Meaning: A simulation error occurs diagnosing this problem; or No error occurs and the meaning is as documented by the implementation vendor. (5) MULTIPLE READERS FOR SAME EXTERNAL FILE VHDL Situation: An external file F exists. An IN-mode file declaration for file object N is elaborated with a logical name denoting F. An IN-mode file declaration for file object M is elaborated with a logical name denoting F. Intermixed READ operations are performed on N and M. Allowed Variations in Meaning: For a given external file, an implementation is allowed to implement the I/O in such a way that the results of READ operations on N either do or do not depend on READ operations that have been done on M. An implementation vendor is encouraged to document under what circumstances (and if at all) such dependencies can exist. The approach taken by a vendor may be dependent on a particular operating system underlying an implementation. The approach taken by a vendor may distinguish between file objects associated with physical "files" and those associated with physical "devices". (6) HOST OS SAYS NO VHDL Situation: A basic file I/O operation is attempted. A basic file operation is the elaboration of a file declaration, a READ, WRITE, or ENDFILE operation on a file object, or the deallocation of a file object (i.e., the "closing" of the file when the scope in which a file declaration is immediately declared is exited). Allowed Variations in Meaning: A VHDL implementation may run on top of a host operating system, and, if so, may implement a basic file I/O operation through services provided by the underlying operating system. Consequently, basic I/O operations may fail if the underlying host operating system does not allow the operation to be performed. When such failures occur, an implementation may terminate simulation with an appropriate error message. Possible reasons for the operating system disallowing I/O operations include but are not limited to: Privilege or protection violation Tape drive full File already opened by another OS process Device not mounted Quota/limit exceeded Remote node is down Etc VASG-ISAC Recommendation for Future Revisions --------------------------------------------- TBD