DESIGN CONSIDERATIONS FOR A QM-I BASED MULTIMICROPROCESSOR EMULATION SYSTEM Steve Crocker USC/Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90291 Microprocessors, which are now readily available, are being used in the design of many systems. Soon avionic systems will be designed that use many microprocessors working together. Systems based on multiple microprocessors (MMP) will be designed to offer higher throughput and/or higher reliability than uniprocessor systems. There are now very few design tools to aid in developing or evaluating proposed microprocessor systems. One highly useful tool is an emulation facility for modeling, testing, and measuring proposed MMP systems. The standard difficulty in emulating even a uniprocessor is that the emulation rate is too slow. For example, an emulation of a standard military computer may run 10,000 times slower than real time when implemented on a conventional computer. Machines such as the MLP-900 and the QM-I, designed to execute user-written microcode, have special architectures to facilitate emulation. When they are used to emulate a uniprocessor, emulations run much faster -typically less than 100 times real time and possibly close to real time, depending upon the emulation's complexity and the speed of the emulated computer. For example, the UYK-20 emulation on the ISI MLP-900 using the PRIM system runs about 1/10 as fast as real time, and includes extensive debugging aids as well. For the problem of emulating MMP systems, the emulation speed is even more crucial. If a system has 20 processors and needs detailed emulation, the fastest possible single-hosted emulation can be only 1/20 the emulation speed emulation of one of the individual processors. Unfortunately, the actual speed of such a multiprocessor emulation may be far slower because switching contexts from one processor to the next may be very expensive. For example, if a multiprocessor system communicates within itself by sharing memory, contexts must be switched every instruction and processors kept in lock step. In some systems, the cost of this may be equivalent to emulating 10,000 - 100,000 instructions. If so, the whole emulation is immediately degraded by that factor. This problem has only two remedies: one is to switch contexts less often and the other is to use an emulation system providing faster context switching. The former is applicable only if processes in the emulated systems communicate infrequently or with long delays. In a closely coupled system, frequent context switching is essential and must be done cheaply. The QM-I, specifically designed for emulation, has been used extensively to emulate uniprocessors. The architecture of the QM-I has the capacity for a relatively large microstore, some 40K words; thus it can emulate a closely coupled multiprocessor system where the microcode and contexts for all of the processors are maintained in microstore concurrently. With this plan, a scheduling system in the microstore must control all of the emulations, and all of the emulations must adhere to the same conventions about keeping track of time and returning control to the scheduler. Code for the individual processors can be written in any existing emulation-writing language (e.g., SMITE, MULTI, ISPS), so this plan should be viewed as an extension to the QM-I's basic capability. RADC is sponsoring ISI's preliminary work on this approach, which has two parts: experimentation with a language for describing MMP emulations and design of a testing and measurement system to support them. This research is sponsored by The Rome Air Development Center and The Defense Advanced Research Projects Agency under contract DAHC-72-C-0308. 65 CIl1411-8/78/0000-0065500.75 (~) 1978 IEEE

/lp/association-for-computing-machinery/design-considerations-for-a-qm-1-based-multimicroprocessor-emulation-4asgp1uyi8