jxw@fas.ri.cmu.edu (John Willis) (01/28/91)
(Philip A. Wilsey) writes: > > I have been studying VHDL and have turned to file I/O. The LRM is not > particularly helpful in this matter and so I have a coupe of > questions. The context of my questions will be where a common > architecture exists with two process statements. Assume that each > process statement contains a I/O request to the same file. > ... > What happens? > ... > Secondly, what happens on output? > I believe that the LRM assures the modeler that any line will be read or written atomically, however if multiple processes read or write a single file at the same simulation time and delta, I do not believe that any order is implicit; further there is no implied monitor or critical section between a call endfile and a readline stmt. Thus no modeler can expect deterministic execution of such a modeler and should avoid writing such a model. Auriga, an optimizing simulation compiler for VHDL targeting networked computers, does not impose a deterministic ordering rule between calls or statements executing concurrently in different processes. When a simple IF expression calls endfile then immediately proceeds to call readline in one branch, the compiler aggregates the calls into what is functionally a monitor, but this goes beyond what I read as the letter of the LRM. > Finally, how is a line defined. Consider a file of type character. > Is the newline character read/writable? If so, then what actually > defines the line? I would be nice if the LRM spelled out the meaning of each character type. Given the ordering and symbology, ASCII clearly seems to be the IMPLIED meaning. This implies that the last character in each line (denoted in a UNIX file system as '\n') should be mapped to LF, CR, or CR folllowed by LF as the last character of each line. For practical purposes, choosing the host's newline convention seems to make the most sense (for ASCII-based machines). This character would seem to be just as readable as any other tag of type character. This is what Auriga does. QUESTION: It would be useful for a compiler to know about files which could be read during compilation, such as a ROM or PLA initialization. Given the letter of the LRM, we need to wait until runtime to read in any file. Such a statically read file would be useful, but cannot be reliably detected now (?) without using another readline procedure defined in another library (ugly). Any ideas as to how this could be cleanly communicated to the compiler? -John
davidb@inmet.inmet.com (01/30/91)
/* Written 1:04 pm Jan 27, 1991 by jxw@fas.ri.cmu.edu */ >I believe that the LRM assures the modeler that any line will be read >or written atomically, however if multiple processes read or write a >single file at the same simulation time and delta, I do not believe >that any order is implicit; further there is no implied monitor or >critical section between a call endfile and a readline stmt. Thus no >modeler can expect deterministic execution of such a modeler and >should avoid writing such a model. See my answer to the other question; unless I am very much mistaken, this question is null (file access cannot occur across multiple processes). >I would be nice if the LRM spelled out the meaning of each character >type. Given the ordering and symbology, ASCII clearly seems to be >the IMPLIED meaning. This implies that the last character in each >line (denoted in a UNIX file system as '\n') should be mapped to LF, >CR, or CR folllowed by LF as the last character of each line. For >practical purposes, choosing the host's newline convention seems to >make the most sense (for ASCII-based machines). This character would >seem to be just as readable as any other tag of type character. This >is what Auriga does. This is deliberately left up to the implementation. >QUESTION: >It would be useful for a compiler to know about files which could be >read during compilation, such as a ROM or PLA initialization. Given >the letter of the LRM, we need to wait until runtime to read in any >file. Such a statically read file would be useful, but cannot be >reliably detected now (?) without using another readline procedure >defined in another library (ugly). Any ideas as to how this could be >cleanly communicated to the compiler? This question confuses me. If the question concerns how a file can be read prior to simulation time, a function call in an initializtion expression can read an ASCII file and return an initialized array (in, say, a constant). This will occur at elaboration. If you wish for this to happen prior to elaboration, the only way I can think of is to put it in a deferred constant, with the actual initialization given as an aggregate in a package body. If I am missing the boat completely, please Email or post clarification, and I will try to respond. Dave Barton barton@i2wash.com