VHDL Issue Number: 0032 Classification: Language Definition Problem Language Version: VHDL-87 Summary: Inconsistencies in the definition of I/O in VHDL. Related Issues: 0074, 0091, 0093, ???? (yet-to-be-installed Issue Report from MCC), ???? (yet-to-be-installed Issue Report from Vantage) Relevant LRM Sections: 2.1.1, 3.3, 3.4.1, 4.3.2, 4.3.3, 14.3 Key Words and Phrases: file object, read, write, endfile, textio, endline, function, constant, variable, file type, parameter Current Status: VASG-Approved 1076-1993 Disposition: Closed (All Issues Completely Addressed) Disposition Rationale: LRM was revised. Superseded By: N/A -------------------- Date Submitted: 1988/10/18 Author of Submission: Doug Dunlop (and many others) Author's Affiliation: Intermetrics 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: 1988/11/10 Author of Analysis: Doug Dunlop Revision Number: $Revision: 1.11 $ Date Last Revised: $Date: 1995/08/03 00:11:38 $ Description of Problem ---------------------- For sake of completeness, this Issue Report covers the total set of inconsistencies in VHDL I/O that are known at the present time. This issue report does not cover ambiguities concerning the external format of files read and written by the package TextIO, nor does it address confusion over the host-dependent aspects of VHDL I/O. These two topics are the subjects of separate Issue Reports (see 0036 and 0025). The inconsistencies in VHDL I/O addressed here have been reported by a variety of sources. Many of these are themselves Issue Reports (see "Related Issues") that are now superseded by the present Issue Report. The problems covered by this Issue Report are as follows: Problem 1: The term "file object" needs a more careful definition. LRM 4.3.2 defines a file object to be that which is "created by a file declaration". This does not cover a formal parameter of a file type since these objects are declared with variable declarations, not file declarations. It makes sense for formal parameters of file types to be considered file objects; otherwise assignment to them would be allowed (LRM 4.3.2) and it would not be possible to pass them as parameters (LRM 4.3.2). Problem 2: LRM 3.4.1 states that "ENDFILE always returns True for an output file". However, since the mode of the formal parameter to ENDFILE is IN, this contradicts the last paragraph of Section 4.3.2 which states "a file object of a given mode may only be passed to a formal file variable of the corresponding mode". Problem 3: The parameter F of TextIO.ReadLine should be of class variable. As specified by LRM 2.1.1, F is of class constant since no object class is explicitly stated. As specified by LRM 4.3.2, F must be of class variable for a file object to be passed to it. Problem 4: The parameters F to the implicitly declared procedures Read (LRM 3.4.1) should be of class variable. As specified by LRM 2.1.1, these parameters F are of class constant since no object class is explicitly stated. As specified by LRM 4.3.2, these parameters F must be of class variable for file objects to be passed to them. Problem 5: The parameter L to TextIO.ReadLine should be of mode INOUT instead of OUT. As specified in LRM 14.3, TextIO.ReadLine reads the value of L in order to deallocate if necessary. Problem 6: The parameter L to TextIO.WriteLine should be of mode INOUT instead of IN. As specified in LRM 14.3, TextIO.WriteLine updates the value of L so that it designates a null string. Problem 7: The parameter F to the implicitly declared function EndFile (LRM 3.4.1) is necessarily a constant by LRM 2.1.1 (variable is disallowed since EndFile is a function). For Endfile to be usable, however, F must be a variable by LRM 4.3.2 (see also the Notes in LRM 4.3.3). Problem 8: The parameter L to TextIO.EndLine is necessarily a constant by LRM 2.1.1 (variable is disallowed since TextIO.EndLine is a function). This is in conflict with LRM 3.3 which requires L to be of class variable. Proposed Resolution ------------------- N/A (refer to the Issue Reports referenced above under "Related Issues"). VASG-ISAC Analysis & Rationale ------------------------------ It is clear that I/O is one of the most poorly defined aspects of VHDL. A number of alternate approaches have been considered for improving the definition of VHDL I/O. For example, it has been shown that many I/O inconsistencies can be solved by defining a new object class specifically for files. As another example, unmerging the concepts of the "mode" given in a file declaration with the "mode" given in the declaration of an interface object would also clean up many of the problems in the definition of VHDL I/O. However, all of these "new approaches" to VHDL I/O are considered too significant a departure from the I/O as it is presently defined in IEEE Std 1076-1987. Hence the recommended approach to the known I/O inconsistencies in VHDL is a set of small, individual, low-impact LRM corrections that eliminate these difficulties. Different approaches should be considered for future versions of the standard (see "VASG-ISAC Recommendations for Future Revisions") below. VASG-ISAC Recommendation for IEEE Std 1076-1987 ----------------------------------------------- The solutions listed below parallel the problem list given under "Description of Problem": Solution 1: We say that the term "file object" means "an object of a file type". In particular, a subprogram parameter of a file type is a file object. This is likely the intended definition and remedies the problems discussed above. Solution 2: We say that ENDFILE simply cannot be used on OUT-mode files. Allowing this seems somewhat pointless anyway. Solution 3: We say that the parameter F of TextIO.ReadLine is explicitly declared to be class variable. Solution 4: We say that the parameters F to the implicitly declared procedures Read (LRM 3.4.1) are explicitly declared to be of class variable. Solution 5: We say that the parameter L to TextIO.ReadLine is declared to be of mode INOUT instead of OUT. Solution 6: We say that the parameter L to TextIO.WriteLine is declared to be of mode INOUT instead of IN. Solution 7: We say that the parameter F of the implicitly declared function EndFile (LRM 3.4.1) is explicitly declared to be of class variable. This violates the LRM 2.1.1 rule concerning the object class of function parameters but this problem is ignored. It is acknowledged that Endfile is not a true VHDL function. However, its meaning is clear and there are no known implementation problems. Solution 8: We say that the function TextIO.EndLine is deleted. In place of calling this function, the expression "L'Length = 0" can be used. The TextIO.EndLine problem could alternatively be "solved" as was done for the similar problem with the implicitly declared function EndFile. However, the recommended approach has the advantage that the package declaration for TextIO is true VHDL and can be processed (and placed in STD) by a standard VHDL analyzer. VASG-ISAC Recommendations for Future Revisions ----------------------------------------------- Consider some new approach to I/O such as one or more of the following (and possibly others): - making files a separate class of object, - redefining the meaning of the mode of a file subprogram parameter, - treating files more like they are treated in Ada, - not using access types to define the package declaration for TextIO, - altering mode/class compatibility requirements for parameter associations, - defining explicit Create, Open, Close, and Delete operations for files, and - relaxing the strict requirements on VHDL function subprograms.