EP0437550A1 - Information processing system emulation apparatus and method - Google Patents

Information processing system emulation apparatus and method

Info

Publication number
EP0437550A1
EP0437550A1 EP90905836A EP90905836A EP0437550A1 EP 0437550 A1 EP0437550 A1 EP 0437550A1 EP 90905836 A EP90905836 A EP 90905836A EP 90905836 A EP90905836 A EP 90905836A EP 0437550 A1 EP0437550 A1 EP 0437550A1
Authority
EP
European Patent Office
Prior art keywords
processor
bus
data
address
viop
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
EP90905836A
Other languages
German (de)
French (fr)
Other versions
EP0437550B1 (en
Inventor
Stephen Morss
Boris Dreyfus
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Samsung Electronics Co Ltd
Original Assignee
Wang Laboratories Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Wang Laboratories Inc filed Critical Wang Laboratories Inc
Publication of EP0437550A1 publication Critical patent/EP0437550A1/en
Application granted granted Critical
Publication of EP0437550B1 publication Critical patent/EP0437550B1/en
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/10Program control for peripheral devices
    • G06F13/105Program control for peripheral devices where the programme performs an input/output emulation function

Definitions

  • This invention relates generally to information processing systems and, in particular, to an information processing system having an applications processor (AP) and a virtual input/output (I/O) processor (VIOP) , the system being responsive to the operation of the AP to suspend operation of the AP when the AP accesses predetermined regions of the system address space.
  • AP applications processor
  • I/O virtual input/output
  • VIOP virtual input/output
  • One impediment to this type of system emulation is that the software is typically written to interact with a specific type of I/O device. For example, a serial communications program is written for a particular type of serial communication integrated circuit located at a specific system address.
  • One approach to emulation may be to provide the specific types of I/O devices required by the application software. However, in many types of systems this is not desirable or practical in that the system may be primarily used for significantly different applications.
  • a method of the invention for use in a data processing system having at least a first and a second data processor a method of emulating with a second one of the data processors an I/O device accessed by an application program executed by a first one of the data processors.
  • the method includes the steps of (a) detecting a read or a write access cycle made by the first data processor that is directed to a predetermined address location associated with the I/O device, (b) suspending the operation of the first data processor such that the access cycle is not completed and (c) notifying the second data processor that operation of the first data processor is suspended.
  • the method further includes the steps of (d) determining with the second data processor the identity of the I/O device to be emulated, (e) emulating the I/O device by accepting or providing an information unit associated with the read or the write access cycle, respectively, and (f) resuming the operation of the first data processor such that the access cycle is completed.
  • the system including a system bus having a system address bus and a system data bus and at least two data processors coupled to the system bus, emulation apparatus for enabling a first one of the data processors to execute, in conjunction with a second one of the data processors, a program requiring access to predetermined address locations associated with a specific type of device, typically an I/O device.
  • the emulation apparatus includes circuitry for detecting an occurrence of an access cycle by the first data processor to the predetermined address location, circuitry for halting the first data processor before completion of the access cycle and circuitry for notifying the second data processor that the first data processor is halted.
  • the emulation apparatus further includes circuitry for indicating to the second data processor a value of the predetermined address location being accessed and a type of access to the predetermined address location.
  • the second data processor includes circuitry for interpreting the address value and type of access, for accessing a corresponding address location having a same type of specific device or a corresponding type of device and for causing the first data processor to be released to complete the access cycle.
  • Fig. 1 is a detailed block diagram of an information processing system having an AP and a VIOP which is constructed and operated in accordance with the invention
  • Fig. 2 is a block diagram of the information processing system
  • Fig. 3 is a block diagram which shows the arrangement of VIOP and AP data buffers and latches.
  • Figs. 4a and 4b are timing diagrams that illustrate an AP write cycle and an AP read cycle, respectively, the diagrams showing the intervention by the VIOP.
  • IPS 10 includes an AP 12, a VIOP 14, a Master System Bus (MSBus) 16 and a VIOP Local Bus 18.
  • MSBus 16 includes a Master System Address Bus (MSAB) 16a and a Master System Data Bus (MSDB) 16b.
  • the VIOP Local Bus 18 includes a Local Address Bus (LAB) 18a and a Local Data Bus (LDB) 18b.
  • a number of I/O peripheral devices are provided and are grouped into different categories depending on which of the buses 16 or 18 that a particular peripheral is coupled to.
  • the AP 12 is an 80286 microprocessor device which is manufactured by the Intel Corporation of Santa Clara, California. The functionality of this device is fully described in the 80286 Hardware Reference Manual, published by the Intel Corporation, the disclosure of which is incorporated herein by reference.
  • the VIOP 14 is a High Performance Microcontroller (HPC16040) which is manufactured by the National Semiconductor Corporation of Santa Clara, California. As such the ensuing description references specific inpu /output pins and functions associated with these devices. It is pointed out however that the practice of the invention is not limited to only these types of devices and may be practiced with a number of different types of microprocessors or other processing devices. The ensuing description is therefore not intended to be read in a limiting sense but instead as a presently preferred embodiment of the teaching of the invention.
  • the AP 12 operates over the MSBus 16.
  • a plurality of System Peripherals are coupled to the MSBus 16 providing the AP 12 with access to certain of these System Peripherals.
  • the VIOP 14, through bus interface circuitry, also has access to the System Peripherals.
  • the System Peripherals include a System Video Peripheral 32 which is comprised of a video controller, a video memory and a Video I/O.
  • the System Peripherals also include a System Communication Peripheral 33 comprised of a Communication Controller, a communication memory and an I/O device.
  • the Communication Controller is comprised of a Z-80 microprocessor device having firmware and other resources to implement a communication port known in the art as a 928 communications interface.
  • Coupled to the 928 interface may be a VS computer system of the type manufactured by Wang Laboratories of Lowell, Massachusetts.
  • the IPS 10 may function as a VS-type 2256C terminal or may function as a WANG IBM Compatible (280) Computer.
  • application software for execution by the AP 12 is downloaded from a host system via the communication port and is stored within the RAM 48.
  • the VIOP 14 totally emulates disk for the AP 12.
  • the VIOP 14 operates over the associated VIOP Local Bus 18.
  • a plurality of Local Peripheral Devices (LPDs) 20 are coupled to this bus, the LPDs 20 being accessed only by the VIOP 14.
  • the AP 12 has no direct access to the LPDs 20.
  • the LPDs 20 include the following devices: an Interrupt Controller, a Counter/Timer, a Real Time Clock, a Serial Communication Port and a Parallel Port.
  • Other local peripherals which are coupled to and accessed only by the VIOP 14 include a Keyboard 22, Status/Control Ports 24a and 24b, a 16KByte Local RAM 26 and a VIOP 14 Master Address Register 28.
  • the Master Address Register 28 is employed by the VIOP 14 during an access to the MSBus 16 in a manner to be described.
  • the LPDs 20 and the keyboard 22 are peripheral devices of a type typically found in the processing device which is the target of the emulation.
  • an AT-type data processing device includes the same peripheral devices, but not necessarily the same functionally identical peripheral devices.
  • any applications software which is executed by the AP 12 is written to access these peripheral devices at predetermined address locations.
  • the VIOP 14 In order to emulate the operation of the target processor the VIOP 14 must detect when application software executed by the AP 12 has performed a read or a write access to one of these predetermined locations.
  • the IPS 10 also includes a plurality of system peripherals which are located on the MSBus 16. Some of these system peripherals are accessed by both the VIOP 14 and the AP 12 while others of these peripherals are accessed only by the VIOP 14. As such, the system peripherals are referred to as Private Peripherals and Shared Peripherals. Private Peripherals are those coupled to the MSBus 16 but which are accessed only by the VIOP 14. Shared Peripherals are those peripherals coupled to the MSBus 16 that are accessed by both the AP 12 and the VIOP 14.
  • the Private Peripherals include an Address Decoder RAM 30, Video I/O 42, Communications I/O 34, Data Buffers and Latches 36 and a Font RAM 38.
  • the Video I/O 42 controls the manner in which data for a display screen 44 is generated and managed.
  • the Video I/O 42 is implemented by a LSI device known as a Paradise PVC4A Video Controller which is manufactured by the Western Digital Corporation.
  • a Paradise PVC4A Video Controller which is manufactured by the Western Digital Corporation.
  • a complete description of the functionality of the Video I/O 42 is found in the Paradise PVC4A Specification, published by the Western Digital Corporation.
  • the Font RAM 38a stores up to two sets of alphanumeric character fonts.
  • the fonts are permanently stored in a System ROM 46 from where they are transferred to the Font Ram 38a by the VIOP 14 during system initialization.
  • the AP 12 is maintained in a reset condition while the VIOP 14 is released and begins execution of code from ROM 46.
  • the VIOP 14 locates further executable code in ROM 46 and transfers same to local RAM 26 from which the VIOP 14 initializes the system and eventually accesses a predetermined location to release the AP 12 from the reset condition.
  • the above mentioned Shared System Peripherals include a System RAM 48 and the System ROM 46 which, in addition to storing the fonts, also stores the system diagnostic and initialization code.
  • the Shared Peripherals also include a 64K Video Memory 38b and a Communications buffer memory 40.
  • the Shared Peripherals also include Stop AP circuitry 50 that generates a signal to halt the operation of the AP 12 when the AP 12 attempts to access a predetermined area or areas of the system memory.
  • the predetermined areas of memory are programmed into the Decoder RAM 30 by the VIOP 14 during system initialization, the Decode RAM 30 having address inputs coupled to the system address bus 16a.
  • Any AP 12 initiated Master System Bus 16 cycle which generates the MEM/10 Hold signal causes STOP AP 50 to generate a Not Ready (READY*) signal that is applied to a Ready input terminal of the AP 12.
  • the STOP AP signal may be generated directly by the VIOP 14 accessing a predetermined I/O location, thereby generating a signal 56a.
  • the operation of the AP 12 is halted by the imposition of wait states beginning at the next AP 12 bus cycle.
  • the STOP AP select signal is instead generated by the AP 12 during an AP 12 access the AP 12 is halted and immediately begins the execution of wait states within the current bus cycle.
  • the Decoder RAM 30 detects same and initiates the assertion of the AP 12 Not Ready signal line, thereby causing the AP 12 to suspend the I/O access and execute Wait states.
  • the VIOP 14 is notified that the AP 12 is suspended via an interrupt input or by polling a VIOP_REQ bit that is coupled to the VIOP 14.
  • the VIOP 14 responds by determining, in a manner to be described, the cause of AP 12 processing suspension such as which address location the AP 12 was attempting to access and what type of access was attempted.
  • the VIOP 14 subsequently performs the desired I/O access such as to one of the LPDs 20.
  • the VIOP 14 When the I/O access is completed, the VIOP 14 generates a signal 56b that causes the STOP AP circuitry to release the AP 12 Not Ready signal line, thereby allowing the AP 12 to resume operation.
  • the AP 12 completes the suspended bus cycle and begins a next bus cycle without knowledge of the intervention of the VIOP 14.
  • the Decoder RAM 30 is embodied by a static RAM device employed to dynamically allocate regions of the system address map.
  • One function of the Decoder RAM 30 in the IPS 10 is to remap various sections of memory to other areas of memory. By changing values in the Decoder RAM 30, for example, the addresses associated with the Communications Memory 40 can be moved to other locations within the AP 12 address space.
  • the Decoder RAM 30 operates on memory blocks of a predetermined size and disposed on predetermined boundaries. As implemented, the Decoder RAM 30 reassigns any 4K byte block of memory to any other 4K block.
  • the AP 12 application software may be executing code associated with I/O addresses that results in the reading and writing of the Communications Memory 40, when in actuality the VIOP 14 has programmed the Decoder RAM 30 so that any access of the Communications Memory 40 by the AP 12 causes the AP 12 to instead access System RAM 48 locations chosen by the VIOP 14.
  • the IPS 10 also includes a number of Bus Interface devices.
  • the VIOP 14 is coupled to the VIOP Local Bus 18 via a 16 bit address latch 52 and a 16 bit data transceiver 54.
  • a Local Bus Decoder 56 decodes a portion of the Local Address Bus 18a to generate a plurality of local device select signals.
  • the Local Address Bus 18a is also buffered by a buffer 58 and applied to a shared decoder 60, which generates select signals for the Shared Peripherals, and to a private decoder 62 which generates select signals for the Private Peripherals.
  • AP 12 Bus Interface devices include a 24 bit address latch 64, a 16 bit data input latch 66 and a 16 bit data output latch 68.
  • the latches 66 and 68 also form a VIOP Data Buffer 36 Private Peripheral device. That is, the AP 12 Data In latch 66 is written by the VIOP 14 while the AP 12 Data Out latch 68 is read by the VIOP 14.
  • Another function of the Bus Interface circuitry is arbitration between the AP 12, the VIOP 14, and refresh of the system RAM 48.
  • the VIOP 14, via address latches 28 and data latches 29, waits for arbitration in order to gain access to the MS Bus 16.
  • the memory refresh function has the highest Master System Bus 16 priority, followed by the VIOP 14 and the AP 12. Between every consecutive Master System Bus cycle the AP 12 is given an opportunity by arbitration logic 31 to gain control of the MS Bus 16 if it has a pending request. If the MS Bus 16 is not in use, bus control defaults in favor of the AP 12 such that a subsequent AP 12 request is serviced as quickly as possible.
  • the VIOP 14 writes the Master Address Latch 28a with the value of the upper 16 bits of the Master System Address. Then, using another port value for the target peripheral, the VIOP 14 lower 8 address bits are used to access a 256 byte block via Address Buffer 28b. In other words, for every 16 bit value written into the VIOP 14 Address Register 28a, the VIOP 14 can access via Address Buffer 28b 256 consecutive locations on the Master System Bus 16.
  • the Status/Control Ports 24a and 24b are used by the VIOP 14 to read status bits or write control bits for various circuitry of the IPS 10. There are a plurality of multi-level 16 bit Status Ports 24a accessible by the VIOP 14. These ports are used by the VIOP 14 to determine several current operating parameters of the IPS 10, including the state of the AP 12 address and other output signal lines.
  • VIOP 14 An important function of the VIOP 14 is to control the IOP 10 hardware in response to actions by the AP 12 in such a manner that the AP 12 application software is unaware of the presence of the VIOP 14 or that any external intervention has occurred. It is therefore necessary that the VIOP 14 be able to determine the state of the AP 12 and also to control the AP 12 by controlling certain ones of the AP 12 input pins.
  • the VIOP 14 determines the state of the AP 12 microprocessor by reading the Status Port 24a to determine the state of the certain AP 12 output pins.
  • the VIOP 14 is also apprized of the current operating state of the AP 12 by several other status signals read from the Status Port 24a. These include the following status signals.
  • Word_Byte* when deasserted, indicates that the current AP cycle is a word width (16 bits) operation. Word_Byte* is deasserted when Master AO and Master BHE* are both low.
  • AP SHTDWN* AP_SHTDWN* when asserted, indicates that the AP 12 has entered the shutdown mode of operation. Shutdown occurs when a severe error is detected that prevents further AP instruction processing.
  • AP VIOPXPT AP_VIOP Exception when asserted, indicates that the operation of the AP 12 has been halted for one of the following reasons: a) a system parity error, b) a HLDA by the AP, c) a forced exception by the VIOP, or d) a forced AP hang condition initiated by the VIOP.
  • the VIOP 14 controls the states of certain of the AP 12 input pins via the Control Port 24b. These input pins include the following.
  • AP NMI When asserted, generates a non-maskable interrupt (NMI) to the AP 12.
  • AP INT When asserted, generates an Interrupt Request to the AP 12 that requests the AP 12 to suspend current program execution and service a pending external request.
  • AP HOLD When asserted, permits another local bus master to request control the local bus.
  • AP BUSY* When asserted, indicates to the AP 12 that a processor extension is busy such that the AP 12 suspends program execution and waits until BUSY* becomes inactive.
  • AP ERROR* When asserted, causes the AP 12 to perform a processor extension interrupt when executing AIT or some ESC instructions.
  • AP PEREQ When asserted, requests the AP 12 to perform a data operand transfer for a processor extension.
  • RESET AP* When asserted, causes a reset pulse to be sent to the AP 12.
  • the current state of the Master System Address Bus 16a is also read by the VIOP 14 through the Status Port 24a.
  • the information accessed from the Master System Address Bus 16a depends upon when it is read.
  • the Master System Address Bus 16a holds the current value of AP 12 Address Bus bits 0-23.
  • the basic technique for the VIOP 14 to read the status of the AP 12 is a three part process.
  • a current bus cycle memory cycle, 10 cycle, interrupt acknowledge cycle, bus error
  • the AP_VIOPXPT bit is asserted whenever there is a system parity error, the AP 12 has relinquished its associated bus, or the VIOP 14 has directly placed the AP 12 into wait states by asserting the STOP AP control bit that causes the AP 12 READY* signal to be deasserted. If the Exception bit is high, the exception condition is always handled first. Once the main status register is read, the VIOP 14 reads bits in other status registers to properly specify the condition.
  • the VIOP 14 status reads are modified from a three part to a two part process. That is, instead of requiring the VIOP 14 to read the six AP 12 status bits to determine a general AP status, and then read other status bits to determine a specific status condition the invention combines these functions in hardware such that the VIOP 14 determines the general status as well as the specific status in one status read.
  • This technique is not employed for all status reads relates to the memory capacity of the specific embodiment of the VIOP 14 and to the relatively large number of bits required to communicate the general and specific AP 12 status bits.
  • Jump tables are employed in the VIOP 14 memory to process the status bits, where the status bits are used as an offset into the jump tables.
  • a balance between VIOP 14 memory capacity and optimum system response and performance is achieved by enabling the most common request type, the I/O request, to be handled by the VIOP 14 as a two part process.
  • the VIOP 14 reads instead a different set of Status Port 24a status bits.
  • One of these bits indicates to the VIOP 14 whether there is a pending AP 12 I/O request. If there is a pending AP 12 I/O request, the other status bits reflect the state of the AP 12 address lines. That is, the address bits indicate the identity of the I/O location accessed by the AP 12 and thus the type of I/O device that the VIOP 14 is to emulate.
  • Other, non-I/O, AP 12 requests are processed by reading the six general status bits as previously described.
  • Figs. 2 and 3 show the interface between the VIOP 14 and AP 12 data buses. Because both processors are 16 bit devices, there is a one to one correspondence between each bit of the data buses 16b and 18b. It can be seen that each processor is capable of accessing the Master System Data Bus 16b. Additionally, the VIOP 14 is enabled to read data that the AP 12 is attempting to write, as well as to write data for the AP 12 to read.
  • the Master System Data Bus 16b is driven by Data Out buffer 29a after the VIOP 14 is granted access to the Master System Bus 16.
  • the VIOP 14 is reading the Master System Data Bus 16b, the value being read is latched into Data In latch 29b. This happens in two instances. The first is when the VIOP 14 is reading data from a System Peripheral. The second instance is when the VIOP 14 is reading the current AP 12 data on the Master System Data Bus 16b.
  • Fig. 3 it can be seen that, when the AP 12 is reading data, the data is latched by Data In latch 66. Data can be loaded into this latch by two methods.
  • the first method involves the AP 12 reading data from a System Peripheral without intervention from the VIOP 14.
  • the second method involves the VIOP 14 writing data to the latch 66 for the AP 12 to read.
  • the data is buffered by Data Out buffer 68.
  • This buffer is enabled by two methods.
  • a first method is when the AP 12 writes data to a System Peripheral, without intervention from the VIOP 14.
  • a second method is when the VIOP 14 reads the Master System Data Bus.
  • the value the VIOP 14 reads is the value of the AP 12 Data Bus.
  • the Data Bus Interface 36 between the VIOP 14 and the AP 12 is one of the VIOP 14 Private Peripherals.
  • VIOP 14 addresses that allow the VIOP 14 to read/write the Master System Data Bus 16b, and simultaneously clear conditions that temporarily halt, or hang, the AP 12.
  • halting the AP 12 is accomplished by inserting wait states into the AP 12 bus operation in progress.
  • Addresses read by the VIOP 14 include three which generate signals to (a) clear the MEM/IO Hold signal and read the AP 12 write data latch 68, (b) clear the STOP AP signal and read the AP 12 write data latch 68 and (c) clear the master parity error signal and read the AP 12 write data latch 68.
  • Addresses written by the VIOP 14 include three which generate signals to (a) clear the MEM/IO Hold signal and write the AP 12 read data latch 66, (b) clear the STOP AP signal and write the AP 12 read data latch 66 and (c) clear the master parity error signal and write the AP 12 read data latch 66.
  • Figs. 4a and 4b show that operations which the AP 12 initiates but cannot complete cause the AP 12 to hang and execute wait states until the VIOP 14 can determine why the AP 12 is hung and what the proper response should be.
  • One of the steps the VIOP 14 performs is to read the various status bits from Status Port 24a to determine why the AP 12 is hung. By example and as previously described, if the AP 12 was attempting an I/O access this condition will be indicated by a single bit with other status bits reflecting the identity of the AP 12 accessed I/O address.
  • the VIOP 14 may also determine from Status Port 24a whether a particular memory access is a memory or I/O type cycle and whether the memory access is a read or a write cycle.
  • the VIOP 14 either reads data from or writes data to the Master System Data Bus 16b and the AP 12 Data Interface circuitry 36. Simultaneous with or separately from reading/writing data, the VIOP 14 clears the condition that caused the AP 12 to hang. Clearing the hang condition allows the AP 12 to continue operation.
  • the VIOP 14 when the VIOP 14 reads one of the previously described predetermined I/O locations the data on the Master System Data Bus 16b is latched into the VIOP's Read Latches 29b. If the AP 12 is writing data that the VIOP 14 must read, the action of reading the data by the VIOP 14 latches the data into the VIOP 14 Read Latches 29b and releases the hold condition on the AP 12, allowing it to continue operation.
  • the VIOP 14 if the AP 12 is attempting to read data that the VIOP 14 must provide, the VIOP 14 writes one of the previously described predetermined I/O locations thereby latching the VIOP's data into the AP 12 Read Data latch 66 and clears the corresponding hang condition. The AP 12 thereafter accepts this data as though the data was sourced from the actual device it attempted to access.
  • the AP 12 attempts to write data to the Counter/Timer device, it causes the Decoder RAM 30 to generate the MEM/IO HOLD signal because the Counter/Timer device is defined as a VIOP 14 Local Peripheral. That is, the Counter/Timer device is not directly available to the AP 12.
  • the VIOP 14 is notified of the AP 12 hang condition by the VIOP_REQ signal either generating an interrupt or by directly polling the state of this signal line.
  • the VIOP 14 responds to the AP 12 hang condition by determining, via Status Port 24a, from the Master System Address Bus 16a which location the AP 12 was attempting to access, what type of access was attempted and, in that a write access was attempted, determines from the Master System Data Bus 16b via Data In latch 29b what data the AP 12 was attempting to write.
  • This latter operation is accomplished by the VIOP 14 reading the predetermined I/O location, thereby latching the AP 12 data from the Master System Data Bus 16b into the Data In latch 29b. Reading the predetermined I/O location and latching the data into the latch 29b simultaneously generates the AP 12 READY signal, permitting the AP 12 to terminate the present instruction cycle and initiate a next instruction.
  • the VIOP 14 subsequently writes the data read from latch 29b to the appropriate register within the actual LOP 20 Counte /Timer device.
  • the AP 12 read cycle illustrated in Fig. 4b is similar to that described above except that the VIOP 14 writes the required data into the Data In latch 66, thereby releasing the AP 12 to accept the data and continue operation.
  • the AP 12 application software is unaware of the existence of the VIOP 14.
  • the imposition of WAIT states is invisible to the AP 12 processor and thus has no impact on the logical flow of the application software.
  • the VIOP 14 provides a total emulation of disk for the AP 12 and loads data to and stores data from the RAM 48.
  • the emulation apparatus and method of the invention permits the execution of application software without modification even though the hardware embodiment of the processing system may be substantially different than that for which the application software was initially written.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Bus Control (AREA)
  • Hardware Redundancy (AREA)
  • Test And Diagnosis Of Digital Computers (AREA)

Abstract

Ce système, à utiliser dans le cadre d'un système de traitement de l'information, se compose d'un bus du système (16) possédant un bus d'adresses du système (16a) et un bus de données du système, ainsi qu'au moins deux processeurs de données (12) et (14), couplés au bus du système, d'un dispositif d'émulation permettant au premier processeur d'exécuter, conjointement avec un autre processeur, un programme nécessitant l'accès à des emplacements d'adresses prédéterminées associées à un type spécifique de dispositif, plus particulièrement du type d'un dispositif I/O ne résidant pas en permanence en mémoire centrale. Le dispositif d'émulation comprend un ensemble de circuits (30) servant à détecter l'occurence de l'accès par le premier processeur à un emplacement d'adresse prédéterminée, un autre ensemble de circuits (SO) servant à arrêter le premier processeur avant l'achèvement d'un cycle d'accès et, enfin, un ensemble de circuits servant à prévenir le second processeur de l'arrêt du premier. Le dispositif comprend ensuite un ensemble de circuits (24a) destiné à indiquer au second processeur, une valeur de l'emplacement d'adresse prédéterminée à laquelle on a accédé et un type d'accès à l'emplacement d'adresse prédéterminée qui soit tel que le second processeur ait accès à un dispositif I/O du même type ou à un type correspondant de dispositif I/O. Le second processeur provoque le déblocage du premier processeur pour achever le cycle d'accès.This system, for use as part of an information processing system, consists of a system bus (16) having a system address bus (16a) and a system data bus, as well. at least two data processors (12) and (14), coupled to the system bus, of an emulation device allowing the first processor to execute, together with another processor, a program requiring access to predetermined address locations associated with a specific type of device, more particularly of the type of an I / O device not permanently residing in main memory. The emulation device includes one set of circuits (30) for detecting the occurrence of access by the first processor to a predetermined address location, another set of circuits (SO) for stopping the first processor before the completion of an access cycle and, finally, a set of circuits to notify the second processor of the shutdown of the first. The device then comprises a circuit assembly (24a) for indicating to the second processor a value of the predetermined address location that has been accessed and a type of access to the predetermined address location that is such. whether the second processor has access to an I / O device of the same type or to a corresponding type of I / O device. The second processor unlocks the first processor to complete the access cycle.

Description

INFORMATION PROCESSING SYSTEM EMULATION APPARATUS AND METHOD
FIELD OF THE INVENTION;
This invention relates generally to information processing systems and, in particular, to an information processing system having an applications processor (AP) and a virtual input/output (I/O) processor (VIOP) , the system being responsive to the operation of the AP to suspend operation of the AP when the AP accesses predetermined regions of the system address space.
BACKGROUND OF THE INVENTION;
For certain applications it is desirable to provide an information processing system which emulates the functionality of another information processing system. Such a system is especially advantageous when it is desired to execute, with a first type of system, application software developed for a second type of system.
As can be appreciated, in such systems it is desirable that the software be executed with little or no change. That is, if it becomes necessary to rewrite portions of the software the desirability of executing the software on the first type of system is decreased.
One impediment to this type of system emulation is that the software is typically written to interact with a specific type of I/O device. For example, a serial communications program is written for a particular type of serial communication integrated circuit located at a specific system address. One approach to emulation may be to provide the specific types of I/O devices required by the application software. However, in many types of systems this is not desirable or practical in that the system may be primarily used for significantly different applications.
It has been known to provide in such systems a first application processor which executes the desired application software and a second emulation control processor. However, many of these conventional types of systems utilize a mechanism whereby an access by the application processor to a specific I/O device generates an interrupt which in turn invokes specific and different software routines by the application processor. Such interrupt driven systems typically require that portions of the application software be rewritten and/or that additional application software be provided in order to properly emulate the I/O devices. Thus, the portability and ease of use of the target application software is compromised.
SUMMARY OF THE INVENTION The foregoing problems are overcome and other advantages are realized by an emulation method and apparatus disclosed below. In accordance with a method of the invention there is disclosed for use in a data processing system having at least a first and a second data processor a method of emulating with a second one of the data processors an I/O device accessed by an application program executed by a first one of the data processors. The method includes the steps of (a) detecting a read or a write access cycle made by the first data processor that is directed to a predetermined address location associated with the I/O device, (b) suspending the operation of the first data processor such that the access cycle is not completed and (c) notifying the second data processor that operation of the first data processor is suspended. The method further includes the steps of (d) determining with the second data processor the identity of the I/O device to be emulated, (e) emulating the I/O device by accepting or providing an information unit associated with the read or the write access cycle, respectively, and (f) resuming the operation of the first data processor such that the access cycle is completed.
In accordance with apparatus of the invention there is disclosed for use in an information processing system, the system including a system bus having a system address bus and a system data bus and at least two data processors coupled to the system bus, emulation apparatus for enabling a first one of the data processors to execute, in conjunction with a second one of the data processors, a program requiring access to predetermined address locations associated with a specific type of device, typically an I/O device. The emulation apparatus includes circuitry for detecting an occurrence of an access cycle by the first data processor to the predetermined address location, circuitry for halting the first data processor before completion of the access cycle and circuitry for notifying the second data processor that the first data processor is halted. The emulation apparatus further includes circuitry for indicating to the second data processor a value of the predetermined address location being accessed and a type of access to the predetermined address location. The second data processor includes circuitry for interpreting the address value and type of access, for accessing a corresponding address location having a same type of specific device or a corresponding type of device and for causing the first data processor to be released to complete the access cycle.
BRIEF DESCRIPTION OF THE DRAWING The above set forth and other features of the invention will be made more apparent in the ensuing Detailed Description of the Invention when read in conjunction with the attached Drawing, wherein:
Fig. 1 is a detailed block diagram of an information processing system having an AP and a VIOP which is constructed and operated in accordance with the invention; Fig. 2 is a block diagram of the information processing system;
Fig. 3 is a block diagram which shows the arrangement of VIOP and AP data buffers and latches; and
Figs. 4a and 4b are timing diagrams that illustrate an AP write cycle and an AP read cycle, respectively, the diagrams showing the intervention by the VIOP.
DETAILED DESCRIPTION OF THE INVENTION Referring to Figs. 1 and 2 there is shown a block diagram of an Information Processing System (IPS) 10. IPS 10 includes an AP 12, a VIOP 14, a Master System Bus (MSBus) 16 and a VIOP Local Bus 18. The MSBus 16 includes a Master System Address Bus (MSAB) 16a and a Master System Data Bus (MSDB) 16b. The VIOP Local Bus 18 includes a Local Address Bus (LAB) 18a and a Local Data Bus (LDB) 18b. A number of I/O peripheral devices are provided and are grouped into different categories depending on which of the buses 16 or 18 that a particular peripheral is coupled to.
In a presently preferred embodiment of the invention the AP 12 is an 80286 microprocessor device which is manufactured by the Intel Corporation of Santa Clara, California. The functionality of this device is fully described in the 80286 Hardware Reference Manual, published by the Intel Corporation, the disclosure of which is incorporated herein by reference. The VIOP 14 is a High Performance Microcontroller (HPC16040) which is manufactured by the National Semiconductor Corporation of Santa Clara, California. As such the ensuing description references specific inpu /output pins and functions associated with these devices. It is pointed out however that the practice of the invention is not limited to only these types of devices and may be practiced with a number of different types of microprocessors or other processing devices. The ensuing description is therefore not intended to be read in a limiting sense but instead as a presently preferred embodiment of the teaching of the invention.
The AP 12 operates over the MSBus 16. A plurality of System Peripherals are coupled to the MSBus 16 providing the AP 12 with access to certain of these System Peripherals. The VIOP 14, through bus interface circuitry, also has access to the System Peripherals. The System Peripherals include a System Video Peripheral 32 which is comprised of a video controller, a video memory and a Video I/O. The System Peripherals also include a System Communication Peripheral 33 comprised of a Communication Controller, a communication memory and an I/O device. In a presently preferred embodiment of the invention the Communication Controller is comprised of a Z-80 microprocessor device having firmware and other resources to implement a communication port known in the art as a 928 communications interface. Coupled to the 928 interface may be a VS computer system of the type manufactured by Wang Laboratories of Lowell, Massachusetts. As such, and in accordance with one aspect of the invention, the IPS 10 may function as a VS-type 2256C terminal or may function as a WANG IBM Compatible (280) Computer. By example, application software for execution by the AP 12 is downloaded from a host system via the communication port and is stored within the RAM 48. In this regard the VIOP 14 totally emulates disk for the AP 12.
The VIOP 14 operates over the associated VIOP Local Bus 18. A plurality of Local Peripheral Devices (LPDs) 20 are coupled to this bus, the LPDs 20 being accessed only by the VIOP 14. The AP 12 has no direct access to the LPDs 20.
The LPDs 20 include the following devices: an Interrupt Controller, a Counter/Timer, a Real Time Clock, a Serial Communication Port and a Parallel Port. Other local peripherals which are coupled to and accessed only by the VIOP 14 include a Keyboard 22, Status/Control Ports 24a and 24b, a 16KByte Local RAM 26 and a VIOP 14 Master Address Register 28. The Master Address Register 28 is employed by the VIOP 14 during an access to the MSBus 16 in a manner to be described. The LPDs 20 and the keyboard 22 are peripheral devices of a type typically found in the processing device which is the target of the emulation. For example, an AT-type data processing device includes the same peripheral devices, but not necessarily the same functionally identical peripheral devices. As such, any applications software which is executed by the AP 12 is written to access these peripheral devices at predetermined address locations. In order to emulate the operation of the target processor the VIOP 14 must detect when application software executed by the AP 12 has performed a read or a write access to one of these predetermined locations.
The IPS 10 also includes a plurality of system peripherals which are located on the MSBus 16. Some of these system peripherals are accessed by both the VIOP 14 and the AP 12 while others of these peripherals are accessed only by the VIOP 14. As such, the system peripherals are referred to as Private Peripherals and Shared Peripherals. Private Peripherals are those coupled to the MSBus 16 but which are accessed only by the VIOP 14. Shared Peripherals are those peripherals coupled to the MSBus 16 that are accessed by both the AP 12 and the VIOP 14.
The Private Peripherals include an Address Decoder RAM 30, Video I/O 42, Communications I/O 34, Data Buffers and Latches 36 and a Font RAM 38.
The Video I/O 42 controls the manner in which data for a display screen 44 is generated and managed. In a presently preferred embodiment of the invention the Video I/O 42 is implemented by a LSI device known as a Paradise PVC4A Video Controller which is manufactured by the Western Digital Corporation. A complete description of the functionality of the Video I/O 42 is found in the Paradise PVC4A Specification, published by the Western Digital Corporation.
The Font RAM 38a stores up to two sets of alphanumeric character fonts. The fonts are permanently stored in a System ROM 46 from where they are transferred to the Font Ram 38a by the VIOP 14 during system initialization.
In regards to system initialization upon the generation of a reset signal the AP 12 is maintained in a reset condition while the VIOP 14 is released and begins execution of code from ROM 46. After performing an initial self-test the VIOP 14 locates further executable code in ROM 46 and transfers same to local RAM 26 from which the VIOP 14 initializes the system and eventually accesses a predetermined location to release the AP 12 from the reset condition.
The above mentioned Shared System Peripherals include a System RAM 48 and the System ROM 46 which, in addition to storing the fonts, also stores the system diagnostic and initialization code. The Shared Peripherals also include a 64K Video Memory 38b and a Communications buffer memory 40.
In accordance with the invention the Shared Peripherals also include Stop AP circuitry 50 that generates a signal to halt the operation of the AP 12 when the AP 12 attempts to access a predetermined area or areas of the system memory. The predetermined areas of memory are programmed into the Decoder RAM 30 by the VIOP 14 during system initialization, the Decode RAM 30 having address inputs coupled to the system address bus 16a. Any AP 12 initiated Master System Bus 16 cycle which generates the MEM/10 Hold signal causes STOP AP 50 to generate a Not Ready (READY*) signal that is applied to a Ready input terminal of the AP 12. Alternatively, the STOP AP signal may be generated directly by the VIOP 14 accessing a predetermined I/O location, thereby generating a signal 56a. For this latter case the operation of the AP 12 is halted by the imposition of wait states beginning at the next AP 12 bus cycle. If the STOP AP select signal is instead generated by the AP 12 during an AP 12 access the AP 12 is halted and immediately begins the execution of wait states within the current bus cycle. Thus, if the AP 12 attempts to access a predetermined portion of memory, such as an I/O device, the Decoder RAM 30 detects same and initiates the assertion of the AP 12 Not Ready signal line, thereby causing the AP 12 to suspend the I/O access and execute Wait states. At substantially the same time the VIOP 14 is notified that the AP 12 is suspended via an interrupt input or by polling a VIOP_REQ bit that is coupled to the VIOP 14. The VIOP 14 responds by determining, in a manner to be described, the cause of AP 12 processing suspension such as which address location the AP 12 was attempting to access and what type of access was attempted. The VIOP 14 subsequently performs the desired I/O access such as to one of the LPDs 20. When the I/O access is completed, the VIOP 14 generates a signal 56b that causes the STOP AP circuitry to release the AP 12 Not Ready signal line, thereby allowing the AP 12 to resume operation. The AP 12 completes the suspended bus cycle and begins a next bus cycle without knowledge of the intervention of the VIOP 14.
The Decoder RAM 30 is embodied by a static RAM device employed to dynamically allocate regions of the system address map. One function of the Decoder RAM 30 in the IPS 10 is to remap various sections of memory to other areas of memory. By changing values in the Decoder RAM 30, for example, the addresses associated with the Communications Memory 40 can be moved to other locations within the AP 12 address space.
The Decoder RAM 30 operates on memory blocks of a predetermined size and disposed on predetermined boundaries. As implemented, the Decoder RAM 30 reassigns any 4K byte block of memory to any other 4K block. For example, the AP 12 application software may be executing code associated with I/O addresses that results in the reading and writing of the Communications Memory 40, when in actuality the VIOP 14 has programmed the Decoder RAM 30 so that any access of the Communications Memory 40 by the AP 12 causes the AP 12 to instead access System RAM 48 locations chosen by the VIOP 14.
In operation, the Decoder RAM 30 uses the AP 12 address bits 23-12 to produce a four bit value. Three of these four bits, the Master System Select bits (MASYS_SELA2-0) are latched and decoded to access the target peripheral. The fourth bit from the Decoder RAM 30 is used to add a wait state to the peripheral being accessed, if desired. Also, there is a SHAREDSEL signal which is used to enable the proper decoder circuits. The SHAREDSEL signal identifies whether the cycle in progress is to a shared peripheral (SHAREDSEL = 1) or a private peripheral (SHAREDSEL = 0) .
The IPS 10 also includes a number of Bus Interface devices. The VIOP 14 is coupled to the VIOP Local Bus 18 via a 16 bit address latch 52 and a 16 bit data transceiver 54. A Local Bus Decoder 56 decodes a portion of the Local Address Bus 18a to generate a plurality of local device select signals. The Local Address Bus 18a is also buffered by a buffer 58 and applied to a shared decoder 60, which generates select signals for the Shared Peripherals, and to a private decoder 62 which generates select signals for the Private Peripherals. AP 12 Bus Interface devices include a 24 bit address latch 64, a 16 bit data input latch 66 and a 16 bit data output latch 68. The latches 66 and 68 also form a VIOP Data Buffer 36 Private Peripheral device. That is, the AP 12 Data In latch 66 is written by the VIOP 14 while the AP 12 Data Out latch 68 is read by the VIOP 14. Another function of the Bus Interface circuitry is arbitration between the AP 12, the VIOP 14, and refresh of the system RAM 48. The VIOP 14, via address latches 28 and data latches 29, waits for arbitration in order to gain access to the MS Bus 16. The memory refresh function has the highest Master System Bus 16 priority, followed by the VIOP 14 and the AP 12. Between every consecutive Master System Bus cycle the AP 12 is given an opportunity by arbitration logic 31 to gain control of the MS Bus 16 if it has a pending request. If the MS Bus 16 is not in use, bus control defaults in favor of the AP 12 such that a subsequent AP 12 request is serviced as quickly as possible.
The VIOP 14 writes the Master Address Latch 28a with the value of the upper 16 bits of the Master System Address. Then, using another port value for the target peripheral, the VIOP 14 lower 8 address bits are used to access a 256 byte block via Address Buffer 28b. In other words, for every 16 bit value written into the VIOP 14 Address Register 28a, the VIOP 14 can access via Address Buffer 28b 256 consecutive locations on the Master System Bus 16.
The Status/Control Ports 24a and 24b are used by the VIOP 14 to read status bits or write control bits for various circuitry of the IPS 10. There are a plurality of multi-level 16 bit Status Ports 24a accessible by the VIOP 14. These ports are used by the VIOP 14 to determine several current operating parameters of the IPS 10, including the state of the AP 12 address and other output signal lines.
Functions related to the AP 12 which are controlled by the VIOP 14 using the Control Port 24b bits are as follows:
(a) set/reset the AP 12 NMI, INT, HOLD, BUSY*, ERROR*, and PEREQ pins,
(b) stop the AP 12 on a next AP 12 bus cycle,
(c) enable the VIOP 14 to interrupt the AP 12,
(d) pass AP 12 Address bit 20, and
(e) reset the AP 12.
An important function of the VIOP 14 is to control the IOP 10 hardware in response to actions by the AP 12 in such a manner that the AP 12 application software is unaware of the presence of the VIOP 14 or that any external intervention has occurred. It is therefore necessary that the VIOP 14 be able to determine the state of the AP 12 and also to control the AP 12 by controlling certain ones of the AP 12 input pins.
The VIOP 14 determines the state of the AP 12 microprocessor by reading the Status Port 24a to determine the state of the certain AP 12 output pins. The various combinations of the SI*, SO*, M/IO*, and COD/INTA* output pins together indicate what type of bus cycle the AP 12 is attempting to perform.
The VIOP 14 is also apprized of the current operating state of the AP 12 by several other status signals read from the Status Port 24a. These include the following status signals.
WORD BYTE* Word_Byte*, when deasserted, indicates that the current AP cycle is a word width (16 bits) operation. Word_Byte* is deasserted when Master AO and Master BHE* are both low.
AP SHTDWN* AP_SHTDWN*, when asserted, indicates that the AP 12 has entered the shutdown mode of operation. Shutdown occurs when a severe error is detected that prevents further AP instruction processing.
AP VIOPXPT AP_VIOP Exception, when asserted, indicates that the operation of the AP 12 has been halted for one of the following reasons: a) a system parity error, b) a HLDA by the AP, c) a forced exception by the VIOP, or d) a forced AP hang condition initiated by the VIOP.
In addition to reading the AP 12 status the VIOP 14 controls the states of certain of the AP 12 input pins via the Control Port 24b. These input pins include the following.
AP NMI When asserted, generates a non-maskable interrupt (NMI) to the AP 12. AP INT When asserted, generates an Interrupt Request to the AP 12 that requests the AP 12 to suspend current program execution and service a pending external request.
AP HOLD When asserted, permits another local bus master to request control the local bus.
AP BUSY* When asserted, indicates to the AP 12 that a processor extension is busy such that the AP 12 suspends program execution and waits until BUSY* becomes inactive.
AP ERROR* When asserted, causes the AP 12 to perform a processor extension interrupt when executing AIT or some ESC instructions.
AP PEREQ When asserted, requests the AP 12 to perform a data operand transfer for a processor extension.
RESET AP* When asserted, causes a reset pulse to be sent to the AP 12.
The current state of the Master System Address Bus 16a is also read by the VIOP 14 through the Status Port 24a. The information accessed from the Master System Address Bus 16a depends upon when it is read. During normal operation, the Master System Address Bus 16a holds the current value of AP 12 Address Bus bits 0-23.
The basic technique for the VIOP 14 to read the status of the AP 12 is a three part process. First the VIOP 14 waits for the AP 12 to require assistance. This first step is accomplished by the VIOP 14 polling a single bit, specifically the VIOP_REQ bit that is coupled directly to an input pin of the VIOP 14. When the bit is asserted the VIOP 14 reads from Status Port 24a six status bits including the four AP status bits SI, SO, M/IO* and COD/INTA* and also the Word_Byte* and the AP_VIOPXPT bits. These bits inform the VIOP 14 of whether the AP 12 needs assistance in completing a current bus cycle (memory cycle, 10 cycle, interrupt acknowledge cycle, bus error) , or whether something exceptional has occurred. The AP_VIOPXPT bit is asserted whenever there is a system parity error, the AP 12 has relinquished its associated bus, or the VIOP 14 has directly placed the AP 12 into wait states by asserting the STOP AP control bit that causes the AP 12 READY* signal to be deasserted. If the Exception bit is high, the exception condition is always handled first. Once the main status register is read, the VIOP 14 reads bits in other status registers to properly specify the condition.
In order to optimize system performance, for some cases the VIOP 14 status reads are modified from a three part to a two part process. That is, instead of requiring the VIOP 14 to read the six AP 12 status bits to determine a general AP status, and then read other status bits to determine a specific status condition the invention combines these functions in hardware such that the VIOP 14 determines the general status as well as the specific status in one status read. One reason why this technique is not employed for all status reads relates to the memory capacity of the specific embodiment of the VIOP 14 and to the relatively large number of bits required to communicate the general and specific AP 12 status bits. Jump tables are employed in the VIOP 14 memory to process the status bits, where the status bits are used as an offset into the jump tables.
A balance between VIOP 14 memory capacity and optimum system response and performance is achieved by enabling the most common request type, the I/O request, to be handled by the VIOP 14 as a two part process. Instead of reading the six general status bits and deciphering their content, as previously described, the VIOP 14 reads instead a different set of Status Port 24a status bits. One of these bits indicates to the VIOP 14 whether there is a pending AP 12 I/O request. If there is a pending AP 12 I/O request, the other status bits reflect the state of the AP 12 address lines. That is, the address bits indicate the identity of the I/O location accessed by the AP 12 and thus the type of I/O device that the VIOP 14 is to emulate. Other, non-I/O, AP 12 requests are processed by reading the six general status bits as previously described.
Figs. 2 and 3 show the interface between the VIOP 14 and AP 12 data buses. Because both processors are 16 bit devices, there is a one to one correspondence between each bit of the data buses 16b and 18b. It can be seen that each processor is capable of accessing the Master System Data Bus 16b. Additionally, the VIOP 14 is enabled to read data that the AP 12 is attempting to write, as well as to write data for the AP 12 to read.
When the VIOP 14 writes data, the Master System Data Bus 16b is driven by Data Out buffer 29a after the VIOP 14 is granted access to the Master System Bus 16. When the VIOP 14 is reading the Master System Data Bus 16b, the value being read is latched into Data In latch 29b. This happens in two instances. The first is when the VIOP 14 is reading data from a System Peripheral. The second instance is when the VIOP 14 is reading the current AP 12 data on the Master System Data Bus 16b.
Referring to Fig. 3 it can be seen that, when the AP 12 is reading data, the data is latched by Data In latch 66. Data can be loaded into this latch by two methods. The first method involves the AP 12 reading data from a System Peripheral without intervention from the VIOP 14. The second method involves the VIOP 14 writing data to the latch 66 for the AP 12 to read. When the AP 12 writes data, the data is buffered by Data Out buffer 68. This buffer is enabled by two methods. A first method is when the AP 12 writes data to a System Peripheral, without intervention from the VIOP 14. A second method is when the VIOP 14 reads the Master System Data Bus. The value the VIOP 14 reads is the value of the AP 12 Data Bus.
The Data Bus Interface 36 between the VIOP 14 and the AP 12 is one of the VIOP 14 Private Peripherals. There are several VIOP 14 addresses that allow the VIOP 14 to read/write the Master System Data Bus 16b, and simultaneously clear conditions that temporarily halt, or hang, the AP 12. In accordance with the emulation system and method of the invention halting the AP 12 is accomplished by inserting wait states into the AP 12 bus operation in progress.
Addresses read by the VIOP 14 include three which generate signals to (a) clear the MEM/IO Hold signal and read the AP 12 write data latch 68, (b) clear the STOP AP signal and read the AP 12 write data latch 68 and (c) clear the master parity error signal and read the AP 12 write data latch 68.
Addresses written by the VIOP 14 include three which generate signals to (a) clear the MEM/IO Hold signal and write the AP 12 read data latch 66, (b) clear the STOP AP signal and write the AP 12 read data latch 66 and (c) clear the master parity error signal and write the AP 12 read data latch 66.
When the AP 12 attempts an operation that it cannot complete unassisted the VIOP 14 must intervene to ensure that the AP 12 can continue. Figs. 4a and 4b show that operations which the AP 12 initiates but cannot complete cause the AP 12 to hang and execute wait states until the VIOP 14 can determine why the AP 12 is hung and what the proper response should be. One of the steps the VIOP 14 performs is to read the various status bits from Status Port 24a to determine why the AP 12 is hung. By example and as previously described, if the AP 12 was attempting an I/O access this condition will be indicated by a single bit with other status bits reflecting the identity of the AP 12 accessed I/O address. The VIOP 14 may also determine from Status Port 24a whether a particular memory access is a memory or I/O type cycle and whether the memory access is a read or a write cycle.
Based upon this information the VIOP 14 either reads data from or writes data to the Master System Data Bus 16b and the AP 12 Data Interface circuitry 36. Simultaneous with or separately from reading/writing data, the VIOP 14 clears the condition that caused the AP 12 to hang. Clearing the hang condition allows the AP 12 to continue operation.
It should also be noted that when the VIOP 14 reads one of the previously described predetermined I/O locations the data on the Master System Data Bus 16b is latched into the VIOP's Read Latches 29b. If the AP 12 is writing data that the VIOP 14 must read, the action of reading the data by the VIOP 14 latches the data into the VIOP 14 Read Latches 29b and releases the hold condition on the AP 12, allowing it to continue operation.
Similarly, if the AP 12 is attempting to read data that the VIOP 14 must provide, the VIOP 14 writes one of the previously described predetermined I/O locations thereby latching the VIOP's data into the AP 12 Read Data latch 66 and clears the corresponding hang condition. The AP 12 thereafter accepts this data as though the data was sourced from the actual device it attempted to access.
For example, if the AP 12 attempts to write data to the Counter/Timer device, it causes the Decoder RAM 30 to generate the MEM/IO HOLD signal because the Counter/Timer device is defined as a VIOP 14 Local Peripheral. That is, the Counter/Timer device is not directly available to the AP 12. The VIOP 14 is notified of the AP 12 hang condition by the VIOP_REQ signal either generating an interrupt or by directly polling the state of this signal line. In either case, the VIOP 14 responds to the AP 12 hang condition by determining, via Status Port 24a, from the Master System Address Bus 16a which location the AP 12 was attempting to access, what type of access was attempted and, in that a write access was attempted, determines from the Master System Data Bus 16b via Data In latch 29b what data the AP 12 was attempting to write. This latter operation is accomplished by the VIOP 14 reading the predetermined I/O location, thereby latching the AP 12 data from the Master System Data Bus 16b into the Data In latch 29b. Reading the predetermined I/O location and latching the data into the latch 29b simultaneously generates the AP 12 READY signal, permitting the AP 12 to terminate the present instruction cycle and initiate a next instruction. The VIOP 14 subsequently writes the data read from latch 29b to the appropriate register within the actual LOP 20 Counte /Timer device.
The AP 12 read cycle illustrated in Fig. 4b is similar to that described above except that the VIOP 14 writes the required data into the Data In latch 66, thereby releasing the AP 12 to accept the data and continue operation.
For either of these cases the AP 12 application software is unaware of the existence of the VIOP 14. The imposition of WAIT states is invisible to the AP 12 processor and thus has no impact on the logical flow of the application software. By example, the VIOP 14 provides a total emulation of disk for the AP 12 and loads data to and stores data from the RAM 48. As such, the emulation apparatus and method of the invention permits the execution of application software without modification even though the hardware embodiment of the processing system may be substantially different than that for which the application software was initially written.
While the invention has been particularly shown and described with respect to a preferred embodiment thereof, it will be understood by those skilled in the art that changes in form and details may be made therein without departing from the scope and spirit of the invention.

Claims

CLAIMSWhat is claimed is:
1. In a first system including a first processor and a system bus coupled to the first processor, the first processor being responsive to a first signal to suspend program execution and responsive to a second signal to resume program execution, emulation apparatus for emulating operation of a device coupled to the system bus, the emulation apparatus operating in response to a control signal generated by program execution of the first processor, the emulation apparatus comprising:
a second system including a second processor coupled to and response to the control signal for generating the first and the second signals;
device identification detection means coupled to the system bus, the first processor, and the second processor for detecting an identification of a device to be emulated and for generating the control signal; and
emulation means operating under control of the second processor for emulating operation of the identified device.
2. The emulation apparatus set forth in Claim
1 wherein the system bus includes an address bus having addresses generated by the first processor during program execution, and wherein the device identification detection means is coupled to the address bus for determining an identification of a device corresponding to a particular address.
3. The emulation apparatus as set forth in Claim
2 wherein the device identification detection means further includes means for generating the first signal in response to detecting an identification of a device to be emulated.
4. The emulation apparatus as set forth in Claim
3 and further including means coupled to the second processor for generating the first and the second signals in response to a command from the second processor.
5. The emulation apparatus as set forth in Claim 2 wherein the second processor is readably coupled to the address bus and responsive to the occurrence of specific addresses thereon for causing the emulation means to emulate a device associated with a specific address.
6. A data processing system comprising an applications processor for executing an application program that accesses I/O devices at predetermined address locations and further comprising an I/O processor for emulating an operation of the I/O devices, the data processing system also comprising a system address bus, a system data bus, a local address bus and a local data bus, the system address bus and the system data bus being accessible by either the applications processor or the I/O processor, the local address bus and the local data bus being accessible by only the I/O processor, the system further comprising:
address detecting means having address input terminals coupled to the system address bus for identifying addresses thereon which correspond to predetermined application program address locations and including means for asserting an output signal in response to the detection of one of the predetermined application program address locations;
application processor processing cycle suspension means having an output signal coupled to an input terminal of the application processor and an input signal coupled to the output signal of the address detecting means, the cycle suspension means asserting the output signal for causing the application processor to suspend execution of a current processing cycle and to execute wait processing states in response to the assertion of the address detecting means output signal; and
means coupled to the I/O processor for notifying the I/O processor that the application processor is executing wait processing states for causing the I/O processor to execute instructions that emulate an operation of an I/O device associated with the predetermined application program address location.
7. A system as set forth in Claim 6 and further comprising status means having inputs coupled to the system address bus and to application processor processing status signals and having outputs coupled to the I/O processor such that the I/O processor is enabled to determine what type of I/O device to emulate.
8. A system as set forth in Claim 7 wherein for a data read type of I/O access by the application processor the I/O processor stores a data unit into a first storage means having inputs coupled to the system data bus, the first storage means having outputs coupled to data input terminals of the application processor such that the application processor is enabled to read the data unit therefrom.
9. A system as set forth in Claim 8 wherein for a data write type of I/O access by the application processor the I/O processor reads a data unit sourced from the application processor, the data unit being stored within a second storage having inputs coupled to the system data bus, the second storage means having outputs coupled to data input terminals of the I/O processor such that the I/O processor is enabled to read the data unit therefrom.
10. A system as set forth in Claim 9 and further comprising means, responsive to the I/O processor storing a data unit within the first storage means or reading a data unit from the second storage means, for causing the cycle suspension means to deassert the output signal thereby enabling the application processor to terminate the execution of wait processing states and complete the execution of the suspended processing cycle.
EP90905836A 1989-06-15 1990-03-28 Information processing system emulation apparatus and method Expired - Lifetime EP0437550B1 (en)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US07/367,297 US5093776A (en) 1989-06-15 1989-06-15 Information processing system emulation apparatus and method
US367297 1989-06-15
PCT/US1990/001642 WO1990016027A1 (en) 1989-06-15 1990-03-28 Information processing system emulation apparatus and method

Publications (2)

Publication Number Publication Date
EP0437550A1 true EP0437550A1 (en) 1991-07-24
EP0437550B1 EP0437550B1 (en) 1997-12-10

Family

ID=23446604

Family Applications (1)

Application Number Title Priority Date Filing Date
EP90905836A Expired - Lifetime EP0437550B1 (en) 1989-06-15 1990-03-28 Information processing system emulation apparatus and method

Country Status (6)

Country Link
US (1) US5093776A (en)
EP (1) EP0437550B1 (en)
AU (1) AU640134B2 (en)
CA (1) CA2062771C (en)
DE (1) DE69031799T2 (en)
WO (1) WO1990016027A1 (en)

Families Citing this family (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2590267B2 (en) * 1989-06-30 1997-03-12 株式会社日立製作所 Display control method in virtual machine
US5519873A (en) * 1990-08-31 1996-05-21 International Business Machines Corporation Apparatus for switching digital command execution between a general purpose microprocessor and dedicted execution logic
US5454092A (en) * 1991-02-04 1995-09-26 Motorola, Inc. Microcomputer having an improved internal address mapping apparatus
JP2839730B2 (en) * 1991-02-25 1998-12-16 株式会社東芝 Emulation device and semiconductor device
JPH05216712A (en) * 1991-10-23 1993-08-27 Internatl Business Mach Corp <Ibm> Computer system, method for performing inner-viewing task on computer system and i/o processor assembly
BR9204660A (en) * 1991-12-20 1993-06-22 Ibm COMPUTER NETWORK SYSTEM THAT CONTAINS AN INTERFACE FOR SMALL COMPUTER SYSTEMS (SCSI) FOR NON-LOCAL SCSI DEVICES
US6311286B1 (en) * 1993-04-30 2001-10-30 Nec Corporation Symmetric multiprocessing system with unified environment and distributed system functions
US5687312A (en) * 1993-07-30 1997-11-11 Texas Instruments Incorporated Method and apparatus for processor emulation
US5526503A (en) * 1993-10-06 1996-06-11 Ast Research, Inc. Virtual addressing buffer circuit
US5867655A (en) * 1993-12-08 1999-02-02 Packard Bell Nec Method to store privileged data within the primary CPU memory space
US5742841A (en) * 1993-12-08 1998-04-21 Packard Bell Nec Alternate I/O port access to standard register set
US5970237A (en) * 1994-06-14 1999-10-19 Intel Corporation Device to assist software emulation of hardware functions
JP2734992B2 (en) * 1994-07-25 1998-04-02 日本電気株式会社 Information processing device
US6106565A (en) * 1997-02-27 2000-08-22 Advanced Micro Devices, Inc. System and method for hardware emulation of a digital circuit
US6873948B1 (en) 1998-05-21 2005-03-29 Lsi Logic Corporation Method and apparatus for emulating a device within a data processing system
US7464044B2 (en) * 1998-12-08 2008-12-09 International Business Machines Corporation Method and system for using emulation objects for developing point of sale
US6560573B1 (en) * 1999-07-30 2003-05-06 Emc Corporation Storage controller with hardware emulation controller for emulation between control processor and transfer circuitry compatible to different processor
DE20204651U1 (en) 2002-03-18 2003-08-07 Peeters Bernd Device for protection against unauthorized use of software

Family Cites Families (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US3938101A (en) * 1973-12-26 1976-02-10 International Business Machines Corporation Computer system with post execution I/O emulation
US3955180A (en) * 1974-01-02 1976-05-04 Honeywell Information Systems Inc. Table driven emulation system
US4031517A (en) * 1974-04-24 1977-06-21 Honeywell Information Systems, Inc. Emulation of target system interrupts through the use of counters
US4315321A (en) * 1978-06-16 1982-02-09 The Kardios Systems Corporation Method and apparatus for enhancing the capabilities of a computing system
US4313162A (en) * 1979-12-14 1982-01-26 Burroughs Corporation I/O Subsystem using data link processors
US4482948A (en) * 1980-12-29 1984-11-13 Gte Automatic Electric Labs Inc. Microprocessor bus interchange circuit
US4447876A (en) * 1981-07-30 1984-05-08 Tektronix, Inc. Emulator control sequencer
US4547849A (en) * 1981-12-09 1985-10-15 Glenn Louie Interface between a microprocessor and a coprocessor
US4484266A (en) * 1981-12-11 1984-11-20 The United States Of America As Represented By The Secretary Of The Navy Externally specified index peripheral simulation system
US4509122A (en) * 1982-11-18 1985-04-02 International Business Machines Corporation Method for controlling the file transfer capability of an interactive text processing system that is emulating a host processing system terminal
US4590556A (en) * 1983-01-17 1986-05-20 Tandy Corporation Co-processor combination
US4665501A (en) * 1983-09-30 1987-05-12 Esprit Systems, Inc. Workstation for local and remote data processing
NL8401886A (en) * 1984-06-14 1986-01-02 Tno HEAT DISTRIBUTION WITH BUFFER SYSTEM.
US4727480A (en) * 1984-07-09 1988-02-23 Wang Laboratories, Inc. Emulation of a data processing system
US4675813A (en) * 1985-01-03 1987-06-23 Northern Telecom Limited Program assignable I/O addresses for a computer
US4638423A (en) * 1985-03-06 1987-01-20 Motorola, Inc. Emulating computer
US4707803A (en) * 1985-06-17 1987-11-17 International Business Machines Corporation Emulator for computer system input-output adapters
US4875186A (en) * 1986-02-28 1989-10-17 Prime Computer, Inc. Peripheral emulation apparatus
US4920481A (en) * 1986-04-28 1990-04-24 Xerox Corporation Emulation with display update trapping
CA1296807C (en) * 1986-09-08 1992-03-03 Paul R. Culley Computer system speed control at continuous processor speed

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO9016027A1 *

Also Published As

Publication number Publication date
DE69031799D1 (en) 1998-01-22
EP0437550B1 (en) 1997-12-10
DE69031799T2 (en) 1998-07-09
AU5353390A (en) 1991-01-08
CA2062771C (en) 2000-05-16
US5093776A (en) 1992-03-03
WO1990016027A1 (en) 1990-12-27
CA2062771A1 (en) 1990-12-16
AU640134B2 (en) 1993-08-19

Similar Documents

Publication Publication Date Title
US7209994B1 (en) Processor that maintains virtual interrupt state and injects virtual interrupts into virtual machine guests
US7707341B1 (en) Virtualizing an interrupt controller
EP0437550B1 (en) Information processing system emulation apparatus and method
EP0168034B1 (en) Emulation means in a data processing system
US5187802A (en) Virtual machine system with vitual machine resetting store indicating that virtual machine processed interrupt without virtual machine control program intervention
US5796984A (en) Operating system independent apparatus and method for eliminating peripheral device functions
US5357628A (en) Computer system having integrated source level debugging functions that provide hardware information using transparent system interrupt
US4888680A (en) Peripheral device interface and controller
US5943506A (en) System for facilitating data I/O between serial bus input device and non-serial bus cognition application by generating alternate interrupt and shutting off interrupt triggering activities
US6282601B1 (en) Multiprocessor data processing system and method of interrupt handling that facilitate identification of a processor requesting a system management interrupt
US6272618B1 (en) System and method for handling interrupts in a multi-processor computer
JPH0221018B2 (en)
US20010018721A1 (en) Upgrade card for a computer system
JPH0430053B2 (en)
WO1999012095A1 (en) Method and apparatus for concurrent execution of operating systems
US6496891B1 (en) Device and method to emulate interrupts to provide PS/2 mouse and keyboard functionality for a USB mouse keyboard
JPH06242987A (en) Method and equipment for making host computer execute succession of normal processing of microprocessor in computer unit
US5003468A (en) Guest machine execution control system for virutal machine system
US6907521B2 (en) Enabling video BIOS and display drivers to leverage system BIOS platform abstract
EP0139254A2 (en) Apparatus and method for direct memory to peripheral and peripheral to memory data transfer
US6106565A (en) System and method for hardware emulation of a digital circuit
WO2019127080A1 (en) Systems and methods of efficiently interrupting virtual machines
US4814977A (en) Apparatus and method for direct memory to peripheral and peripheral to memory data transfers
CN112559120B (en) Customized PCIE bus IO virtualization supporting method
JPS5819094B2 (en) Priority vector interrupt device

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 19910514

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): BE DE FR GB NL

GRAG Despatch of communication of intention to grant

Free format text: ORIGINAL CODE: EPIDOS AGRA

17Q First examination report despatched

Effective date: 19970130

GRAH Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOS IGRA

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: WANG LABORATORIES, INC.

GRAH Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOS IGRA

GRAA (expected) grant

Free format text: ORIGINAL CODE: 0009210

AK Designated contracting states

Kind code of ref document: B1

Designated state(s): BE DE FR GB NL

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: NL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 19971210

Ref country code: BE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 19971210

RAP2 Party data changed (patent owner data changed or rights of a patent transferred)

Owner name: SAMSUNG ELECTRONICS CO., LTD.

REF Corresponds to:

Ref document number: 69031799

Country of ref document: DE

Date of ref document: 19980122

NLT2 Nl: modifications (of names), taken from the european patent patent bulletin

Owner name: SAMSUNG ELECTRONICS CO., LTD.

ET Fr: translation filed
NLV1 Nl: lapsed or annulled due to failure to fulfill the requirements of art. 29p and 29m of the patents act
PLBE No opposition filed within time limit

Free format text: ORIGINAL CODE: 0009261

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: NO OPPOSITION FILED WITHIN TIME LIMIT

26N No opposition filed
REG Reference to a national code

Ref country code: GB

Ref legal event code: IF02

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: FR

Payment date: 20080311

Year of fee payment: 19

Ref country code: DE

Payment date: 20080407

Year of fee payment: 19

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: GB

Payment date: 20080402

Year of fee payment: 19

GBPC Gb: european patent ceased through non-payment of renewal fee

Effective date: 20090328

REG Reference to a national code

Ref country code: FR

Ref legal event code: ST

Effective date: 20091130

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: DE

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20091001

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: GB

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20090328

Ref country code: FR

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20091123