| OCR Text |
Show 7 implementations (the Amdahl 470 V/6 and the IBM 370/168) of the same architecture with a combined instruction and memory trace. Lang, Agerwala, and Chandy [24] based their pipeline processor performance model on trace driven simultaion. More recently, MacDougall [27] used instruction traces to estimate mean instruction execution rates. Kumar and Davidson [22] traced microinstruction streams as a tool for optimizing the design of an instruction set. Similarly Marovac [28] has advocated microinstruction traces for "the systematic design of an instruction set together with its underlying hardware." Wiecek and Steely [41] suggested that trace driven techniques are appropriate for all phases of processor design from product positioning to systems configuration. While trace driven modeling is effective for a wide variety of simulation applications, it is not without its problems. The modeler must have access to an existing system or an accurate behavioral simulator in order to generate traces. A program trace typically generates large amounts of trace data (more than 25 megabytes per traced second is not uncommon [31 ]). A relatively small program can generate many times its size in trace data. Dealing with these large amounts of data forces the modeler to either filter out some of the detail of the trace or limit the number of traces. Either solution reduces the flexibility and general applicability of the model. 1.4.4 Register Transfer Models The three processor models described above share a common trait: they are not executable [ 1 O]. In other words, the processor models do not have the behavioral accuracy required to simulate the execution of arbitrary programs. Register transfer models, on the other hand, are executable. Historically, register transfer simulation models have not been used as performance models (although they can give precise timing information) so much as they have been used for the verification of processors and for the |
