IEEE 200X Fast Track Change Proposal

ID:	  FT-31

Proposer:     Srinivasan Venkataramanan
email:        Srinivasan.Venkataramanan of http://www.synopsys.com

Status:       Open
Proposed:     
Analyzed:     1-Mar-05
  Revisions:  Minor edit (changed "and" to "any")  11-April-05
Resolved:     Date

Enhancement Summary:     
Related issues:          
Relevant LRM section:  
 

Enhancement Detail:
----------------------------

Request for a way to flush file output.

Analysis:
----------------------------

The VHDL LRM specifies that the WRITE procedure for a file type
appends a value to a file.  No further specification is provided to
indicate whether the appended data may be buffered before being
committed to the external file associated with the file parameter to
the WRITE procedure.

Most operating systems do buffer data written to a file in order to
improve performance.  As a consequence, data written by a program may
not actually be appended to the file before the effect of a read
performed after the write by the program is seen.  When a program
needs the effect of the write to occur before the effect of a
subsequent read (for example, if the write is a prompt for input to be
read), programs typically use a flush operation provided by the
operating system.  While this generally achieves the desired effect,
particularly when writes are directed at a screen, it cannot always be
guaranteed.  In particular, writes to file systems remotely located
and accessed through a network may be delayed despite a flush
operation.

Since VHDL does not define a flush operation in any form, there is no
opportunity for a model to request flushing of buffered data.  This is
an impediment to file-based bidirectional communication between the
model and an external agent, such as a user or an external program.
The file mechanism is a common approach to unifying communication, for
example, with user interfaces, I/O devices and pipes.  Providing a
flush operation in VHDL would improve usability of the language in
complex verification environments where communication with external
agents is required.

A flush operation should be included as a further implicitly defined
operation for a file type.  Given the declaration:

  type FT is file of TM;

the flush operation should be implicitly declared as:

  procedure FLUSH (file F: FT);

It should be an error if the access mode of the file is read-only or
if the file is not open.  The effect of the procedure should be to
request that the implementation write all buffered values from
previous WRITE operations to the external file associated with the
file parameter.  It should be recommended that the implementation
complete the write of buffered data before performing any READ
operation executed after the FLUSH operation.  However, it should be
noted that an implementation may not be able to guarantee the
recommended ordering, especially when the external files reside in
distributed file systems.


Resolution:
----------------------------
[To be performed by the 200X Fast Track Working Group]