jxw@fas.ri.cmu.edu (John Willis) (02/01/91)
I agree completely with Dave Barton's observation that a single file declaration cannot be visible to more than one VHDL process. A model author can however write code resulting in more than one elaborated file declaration with the same file_logical_name. To make matters more complex, the same file may be opened using an infinite variety of textually unique, functionally equivalent file names such as "P4.srec", "./P4.srec", "/usr/xxx/design/P4.srec" ... In several network file systems, even the inode number can vary. Unfortunately, I believe that the problem of concurrent read or write operations on the same file exists and is non-trivial to solve completely. Hopefully model authors will avoid writing code which tickles this ambiguity. Initialization: Designers often initialize memories of various kinds, sometimes with contents which are known when a model is compiled and will not change over many simulation runs. Consider an address decode PROM initialized from an ASCII file in srecord format. A function reads in a file "P4.srec", line-by-line, and initializes either a static array or dynamically allocated storage. Some interactive VHDL tools must execute this code every time the simulation runs or force the user to externally translate the srecord file (in the example above) into a VHDL package format. I believe that the system Dave Barton works with operates in this fashion. Please correct me if I am wrong, but I believe that such tools re-elaborate prior to each simulation run. In cases where a design is compiled once and simulated many times such that simulation performance is critical, it is very useful to do as much elaboration as possible during compilation. What I am looking for is a standard means by which the model author can say: the contents of this file are known when the model is compiled; execute the read operation once during compilation rather than many times during successive simulation runs. The benefits of such a comilation technique are at least four-fold: - memory loads need not be externally converted, eliminating a possibly out-of-date intermediate file format. - knowledge of memory initialization allows further optimization of the simulation code during compilation. - simulation start-up need not include execution of code to initialize memory. - proprietary files need not be made visible to all simulation users. For simulation users interested in a highly-interactive simulation of a frequently altered-model (perhaps once per simulation run), the suggested optimization is probably not useful. I hope this clarifies the original question; any suggestions short of supplying a distinct library with this functionality? -John