nigelw@cs.man.ac.uk (Nigel Whitaker) (05/01/91)
Here's a summary of the replies I got to the textio question I posted a while back. I now realise that `TEXTIO' was the wrong term to use, what I should have said was `file IO'. Anyway, I think most people understood what I was talking about. How has this helped? Well, firstly, it shows that file io is widely used in VHDL. Secondly, it shows that it is used for other purposes than initialisation. This has some consequences for our architecture. We have an array of processors evaluating the effects of events on components. This part of the pipeline looks like: | Events from timewheel / fanout lists | V -------------------------------------------- | | | | |--------| |--------| |---------| |---------| | | | | | | | | To/from shared | |----| |----| |----| |---<---->--- | | | | | | | | memory |--------| |--------| |---------| |---------| | | | | -------------------------------------------- | | Predictions to time wheel V Besides the main datapaths shown each processor is also linked via a shared bus to the interface processor. This processor is the only processor that has a disk. This bus is used to download the component models before simulation commences. In the past we have considered evaluating HDLs other than VHDL (eg. ELLA) which did not perform file IO and believed no significant contention would occur after the initial downloading. However, with VHDL the possibility of large amounts of file IO (and also assertion messages) means that this shared bus may become a bottleneck during the actual simulation cycle. We are attempting to re-assess the architecture (by VHDL simulation) in the light of some VHDL benchmarks. Here are the responses, thanks to everybody who replied, Nigel ============================================================================== From: Thomas Dettmer <dettmer@jupiter.informatik.uni-dortmund.de> In my opinion all three suggested ideas make sense. We are currently thinking about models wich include some physical and real-time parts. Our application concept uses textio first to initialize a ROM (So we don't have to change and recompile the model when changing the code) and RAM, during simulation some special outputs (Protocol) is written with textio and (because our simulator does not offer another way to communicate with other programs written in C) for reading/writing events from the outside world wich is modeled in other languages than VHDL. I beleive that there will be some more interest and suggest to summarize to the newsgroup - if I'm wrong, please send me your results by email. =============================================================================== From: zepter@isnix.ert.rwth-aachen.de (Peter Zepter) Dear Nigel! We use package TEXTIO with Intermetrics VHDL simulator for interprocess communication with a system simulator written in C/FORTRAN. The connection is established by two named pipes, one for each direction (VHDL to C, C to VHDL). If there are several signals to be transmitted in one direction we perform multiplexing. Due to the special implementation of TEXTIO with intermetrics we had to implement some tricks and to perform a lot of experiments to bring the connection to work. A VHDL Simulator with a C interface would have solved the problem earlier. P.S: All this was implemented under SunOS 4.1. =============================================================================== From: Bharat "P." Savel <savel@hoss.unl.edu> well i came across an application sometime back- the most practical one that i have seen: the problem was to create a random number generator (don't know what for); TEXTIO was used in the following manner; C program was used to write to a (ASCII) file with random numbers: then VHDL used TEXTIO to read these numbers another and probably the most common one would be for a memory of huge size_ like 2**32 which is a common hardware scenario; here, i think, we have a file of: o 2**32 locations, each having a byte/word; access may be hard to a specific byte, unless some sort of a subprogram feature is used in decoding/encoding; o same memory; using 'record' 'access' to have faster access to the address; this like conventional high-level-languages could be initialiased in the file o to be close to high-level-languages ( and verrry far from Hardware) could have the whole memory in the file, using TEXTIO copy the contents to the memory ( any TYPE) and then transfer them back at the end of the simulation i haven't particulary implemented any of these three; i have the same memory size problem and was trying out a lot of scenarios; ============================================================================== From: agw@mlb.semi.harris.com (Alan Whittaker) We typically use TEXTIO for reading input test vectors generated by other software packages and writing result vectors to be used by data analysis packages. The resultant files can be several Meg large. We have noticed a tendency for simulators to exhibit memory leaks when handling simulation runs of this size, so this is something you might look out for. ============================================================================== From: Jagadeesh Gullapalli <jag@ee.odu.edu> Can you please send me a copy of your replys and summary. I am using VHDL for simulating a 2-D signal processor. I am using a simulator developed at University of Pittsburgh. I am lost on how to implement a simulation by reading data from a file and storing the output to another file. Maybe your summary can answer my questions. Thanks. Jagadeesh. ============================================================================== From: "David R. Coelho" <drc%coelho@uunet.uu.net> Yes, TEXTIO can be used to initialize data structures. It is very useful for reading circuit stimulus from a file, and very useful for writing out "custom" results files. I also use it for reading in "random data". It is possible that data from through textio could also control the execution of VHDL code, I expect, although this is less common. > Please indicate the > expected usage patterns, the approximate sizes of any files produced > and any other info you might think would help us. TEXT i/o files could potentially be very large, especially for the stimulus and results examples mentioned above. Also, I could image a ROM model being initialized during simulator startup with a lot of data. ============================================================================== From: steve@titan.tsd.arlut.utexas.edu (Steve Glicker) In response to your inquiry on comp.lang.vhdl, I've used TEXTIO for two things, to read stimulus files and to write debug information. The stimulus files may contain things like input vectors or in the case of a timing model for (something like a microprocessor) a sequence of directives (e.g., write a byte, read N words in burst mode, disable a cache, reset, etc.). Directives sometimes have parameters like time and data vectors. Multiple files, one for each list driven model, may be used. Rarely is more than a couple of megabytes of disk space required for my work. The debug information is usually brief and to the point. I usually run simulations as batch processes so I have not often used TEXTIO to control simulations -- this may change in the future though. Steve Glicker (steve@titan.tsd.arlut.utexas.edu) ============================================================================== -- ------------------------------------------------------------------------------- Nigel Whitaker, Dept. of Computer Science, Univ. of Manchester, Manchester, UK Tel: (061) 275 6270 Fax: (061) 275 6280 EMAIL: nigelw@cs.man.ac.uk