GB2435335A

GB2435335A - Multi-processor emulation by a multi-processor

Info

Publication number: GB2435335A
Application number: GB0603446A
Authority: GB
Inventors: Colin Jonathan Hughes; Stewart Sargaison
Original assignee: Sony Computer Entertainment Inc
Current assignee: Sony Interactive Entertainment Inc
Priority date: 2006-02-21
Filing date: 2006-02-21
Publication date: 2007-08-22
Also published as: JP5746916B2; GB0603446D0; EP1987426A1; JP2011227908A; WO2007096602A1; US20090247249A1; JP2009527836A

Abstract

A multi-processor comprises a plurality of interconnected real processing units, and is arranged to emulate the operation of an emulated processor having a different plurality of interconnected emulated processing units. In operation, at least one emulated processing unit is emulated by contributions from two or more real processing units, and at least one real processing unit contributes to emulating two or more emulated processing units. This results in a reduction in the message traffic needed to provide communication between the emulated processors thereby providing a faster and more efficient emulation.

Description

1 2435335

DATA PROCESSING

This invention relates to data processing.

As an example of data processing, electronic games are well known and may be supplied on a variety of distribution media, such as magnetic and/or optical discs. General computers or more dedicated games consoles may be used to play these games.

There is sometimes a need to emulate the operation of one processor on another processor. That is to say, the emulating processor runs native program code arranged so that such native instructions or groups of native instructions have the same effect as data processing instructions relating to the emulated system.

A situation in which this need arises is where a data processor has been upgraded by the manufacturer to a new "generation" -for example, a new hardware architecture or instruction protocol, but the manufacturer still wants software relating to the older generation device to be handled (so-called backwards compatibility). Often the only way of achieving this is for the newer generation device to run emulation software which in turn acts upon instructions relating to the older generation device. In this case, while it is of course acknowledged that running an emulation is generally much more processor-intensive than running native software, the general trend of generational improvements in the performance of data processing hardware is such that the increased processing overhead can usually be handled.

This invention provides a data processor comprising a plurality of interconnected real processing units arranged to emulate the operation of an emulated processor having a plurality of interconnected emulated processing units, in which: at least one emulated processing unit is emulated by contributions from two or more real processing units; and at least one real processing unit contributes to emulating two or more emulated processing units.

The invention addresses a problem relevant to an emulating system which uses a multi-processor architecture, particularly one in which communication between processors (in the emulating system) is relatively slow compared to the general speed of operation of the emulating system. The invention recognises that a division of the emulation of an emulated processing unit between two (or more) emulating processing units can reduce the message traffic needed to provide communication between the emulations of those emulated processing units. Similarly, by grouping together (on a single emulating processing unit) the emulation of multiple processing units which normally communicate heavily with one another, once again the message traffic needed to provide communication between the emulations of those emulated processing units can be greatly reduced. These measures, taken together, can provide a faster and more efficient emulation.

Various further respective aspects and features of the invention are defined in the appended claims.

Embodiments of the invention will now be described, by way of example only, with reference to the accompanying drawings in which: Figure 1 schematically illustrates the overall system architecture of the PlayStation2; Figure 2 schematically illustrates the architecture of an Emotion Engine; Figure 3 schematically illustrates the configuration of a Graphics Synthesiser; Figure 4 schematically illustrates the structure of an emulating processor; and Figure 5 schematically illustrates logical interactions within the emulating processor.

Referring now to the drawings, Figure 1 schematically illustrates the overall system architecture of the PlayStation2 computer games machine. A system unit 10 is provided, with various peripheral devices connectable to the system unit.

The system unit 10 comprises: an Emotion Engine 100; a Graphics Synthesiser 200; a sound processor unit 300 having dynamic random access memory (DRAM); a read only memory (ROM) 400; a compact disc (CD) and digital versatile disc (DVD) reader 450; a Rambus Dynamic Random Access Memory (RDRAM) unit 500; an input/output processor (lOP) 700 with dedicated RAM 750. An (optional) external hard disk drive (HDD) 390 may be connected.

The input/output processor 700 has two Universal Serial Bus (USB) ports 715 and an iLink or IEEE 1394 port (iLink is the Sony Corporation implementation of the IEEE 1394 standard) (not shown). The lOP 700 handles all USB, iLink and game controller data traffic.

For example when a user is playing a game, the lOP 700 receives data from the game controller and directs it to the Emotion Engine 100 which updates the current state of the game accordingly. The lOP 700 has a Direct Memory Access (DMA) architecture to facilitate rapid data transfer rates. DMA involves transfer of data from main memory to a device without passing it through the CPU. The USB interface is compatible with Open Host Controller Interface (OHCI) and can handle data transfer rates of between 1.5 Mbps and 12 Mbps. Provision of these interfaces means that the PlayStation2 is potentially compatible with peripheral devices such as digital video cassette recorders (VCRs) e.g. camcorders, digital cameras, microphones, printers, and input devices such as a keyboard, mouse and joystick.

Generally, in order for successful data communication to occur with a peripheral device connected to a USB port 715, an appropriate piece of software such as a device driver should be provided. Device driver technology is very well known and will not be described in detail here, except to say that the skilled man will be aware that a device driver or similar software interface may be required in the embodiment described here.

In the present embodiment, a USB microphone 730 is connected to the USB port. It will be appreciated that the USB microphone 730 may be a hand-held microphone or may form part of a head-set that is worn by the human operator. The advantage of wearing a head-set is that the human operator's hands are free to perform other actions. The microphone includes an analogue-to-digital converter (ADC) and a basic hardwarebased real-time data compression and encoding arrangement, so that audio data are transmitted by the microphone 730 to the USB port 715 in an appropriate format, such as a streaming compressed audio format for decoding at the PlayStation 2 system unit 10.

Apart from the USB ports, two other ports 705, 710 are proprietary sockets allowing the connection of a proprietary non-volatile RAM memory card 720 for storing game-related information, a hand-held game controller 725 or a device (not shown) mimicking a hand-held controller, such as a dance mat.

The system unit 10 may be connected to a network adapter 805 that provides an interface (such as an Ethernet interface) to a network. This network may be, for example, a LAN, a WAN or the Internet. The network may be a general network or one that is dedicated to game related communication. The network adapter 805 allows data to be transmitted to and received from other system units 10 that are connected to the same network, (the other system units 10 also having corresponding network adapters 805).

The Emotion Engine 100 is a 128-bit Central Processing Unit (CPU) that has been specifically designed for efficient simulation of 3 dimensional (3D) graphics for games applications. The Emotion Engine components include a data bus, cache memory (part of its CPU core) and registers, all of which are 128-bit. This facilitates fast processing of large volumes of multi-media data. Conventional PCs, by way of comparison, have a basic 64-bit data structure. The floating point calculation performance of the PlayStation2 is 6.2 GFLOPs. The Emotion Engine also comprises MPEG2 decoder circuitry which allows for simultaneous processing of 3D graphics data and DVD data. The Emotion Engine performs geometrical calculations including mathematical transforms and translations and also performs calculations associated with the physics of simulation objects, for example, calculation of friction between two objects. It produces sequences of image rendering commands which are subsequently utilised by the Graphics Synthesiser 200. The image rendering commands are output in the form of display lists. A display list is a sequence of drawing commands that specifies to the Graphics Synthesiser which primitive graphic objects (e.g. points, lines, triangles, sprites) to draw on the screen and at which co-ordinates.

Thus a typical display list will comprise commands to draw vertices, commands to shade the faces of polygons, render bitmaps and so on. The Emotion Engine 100 can asynchronously generate multiple display lists.

The Graphics Synthesiser 200 is a video accelerator that performs rendering of the display lists produced by the Emotion Engine 100. The Graphics Synthesiser 200 includes a graphics interface unit (GIF) which handles, tracks and manages the multiple display lists.

The rendering function of the Graphics Synthesiser 200 can generate image data that supports several alternative standard output image formats, i.e., NTSC/PAL, High Definition TV and VESA. In general, the rendering capability of graphics systems is defined by the memory bandwidth between a pixel engine and a video memory, each of which is located within the graphics processor. Conventional graphics systems use external Video Random Access Memory (VRAM) connected to the pixel logic via an off-chip bus which tends to restrict available bandwidth. However, the Graphics Synthesiser 200 of the PlayStation2 provides the pixel logic and the video memory on a single high-performance chip which allows for a comparatively large 38.4 Gigabyte per second memory access bandwidth. The Graphics Synthesiser is theoretically capable of achieving a peak drawing capacity of 75 million polygons per second. Even with a full range of effects such as textures, lighting and transparency, a sustained rate of 20 million polygons per second can be drawn continuously.

Accordingly, the Graphics Synthesiser 200 is capable of rendering a film-quality image.

The Sound Processor Unit (SPU) 300 is effectively the soundcard of the system which is capable of handling 3D digital sound such as Digital Theater Surround (DTS ) sound and AC-3 (also known as Dolby Digital) which is the sound format used for DVDs.

A display and sound output device 305, such as a video monitor or television set with an associated loudspeaker arrangement 310, is connected to receive video and audio signals from the graphics synthesiser 200 and the sound processing unit 300.

The main memory supporting the Emotion Engine 100 is the RDRAM (Rambus Dynamic Random Access Memory) module 500 licensed by Rambus Incorporated. This RDRAM memory subsystem comprises RAM, a RAM controller and a bus connecting the RAM to the Emotion Engine 100.

F'igure 2 schematically illustrates the architecture of the Emotion Engine 100 of Figure 1. The Emotion Engine 100 is a collective term for a number of processing units interconnected to give a desired set of functionality. Viewed in this context, the Emotion Engine comprises: a floating point unit (FPU) 104; a central processing unit (CPU) core 102; vector unit zero (VUO) 106; vector unit one (VU 1) 108; a graphics interface unit (GIF) 110; an interrupt controller (INTC) 112; a timer unit 114; a direct memory access controller 116; an image data processor unit (IPU) 118; a dynamic random access memory controller (DRAMC) 120; a sub-bus interface (SIF) 122; and all of these individual processing units are connected via a 128-bit main bus 124.

The CPU core 102 is a 128-bit processor clocked at 300 MHz (in fact 294.912MHz, but 300 MHz tends to be used as shorthand for this figure). The CPU core has access to 32 MB of main memory via the DRAMC 120. The CPU core 102 instruction set is based on MIPS III RISC with some MIPS IV RISC instructions together with additional multimedia instructions. MIPS III and IV are Reduced Instruction Set Computer (RISC) instruction set architectures proprietary to MIPS Technologies, Inc. Standard instructions are 64-bit, two-way superscalar, which means that two instructions can be executed simultaneously.

Multimedia instructions, on the other hand, use 128-bit instructions via two pipelines. The CPU core 102 comprises a 16KB instruction cache, an 8KB data cache and a 16KB scratchpad RAM which is a portion of cache connected by a dedicated bus to the CPU, allowing data access independent of the main bus.

The FPU 104 serves as a first co-processor for the CPU core 102. The vector unit 106 acts as a second co-processor. The FPU 104 comprises a floating point division calculator (FDIV). The vector units 106 and 108 perform mathematical operations and are essentially specialised FPUs that are extremely fast at evaluating the multiplication and addition of vector equations. They use Floating-Point Multiply-Adder Calculators (FMACs) for addition and multiplication operations and Floating-Point Dividers (FDIVs) for division and square root operations. The FMACs operate on 32-bit values so when an operation is carried out on a 128-bit value (composed of four 32-bit values) an operation can be carried out on all four parts concurrently. For example adding 2 vectors together can be done at the same time. The VUs have built-in memory for storing micro-programs and interface with the rest of the system via Vector Interface Units (VIFs) referred to by the same number as the corresponding Vector Unit. Vector unit zero 106 can work as a coprocessor to the CPU core 102 via a dedicated 128-bit bus so it is essentially a second specialised FPU. Vector unit one 108, on the other hand, has a dedicated bus to the Graphics synthesiser 200 and thus can be considered as a completely separate processor. The inclusion of two vector units allows the software developer to split up the work between different parts of the CPU and the vector units can be used in either serial or parallel connection.

Vector unit zero 106 comprises 4 FMACS and 1 FDIV. It is connected to the CPU core 102 via a coprocessor connection. It has 4 KB of vector unit memory for data and 4 KB of micro-memory for instructions. Vector unit zero 106 is useful for performing physics calculations associated with the images for display. It primarily executes non-pafterned geometric processing together with the CPU core 102.

Vector unit one 108 comprises 5 FMACS and 2 FDIVs. It has no direct path to the CPU core 102, although it does have a direct path to the GIF unit 110. It has 16 KB of vector unit memory for data and 16 KB of micro-memory for instructions. Vector unit one 108 is useful for performing transformations. It primarily executes patterned geometric processing and directly outputs a generated display list to the GIF 110.

The GIF 110 is an interface unit to the Graphics Synthesiser 200. It converts data according to a tag specification at the beginning of a display list packet and transfers drawing commands to the Graphics Synthesiser 200 whilst mutually arbitrating multiple transfer. The interrupt controller (INTC) 112 serves to arbitrate interrupts from peripheral devices, except the DMAC 116.

The timer unit 114 comprises four independent timers with 16-bit counters. The timers are driven either by the bus clock (at 1/16 or 1/256 intervals) or via an external clock.

The DMAC 116 handles data transfers between main memory and scratchpad RAM, or between main memory or scratchpad RAM and peripherals. It arbitrates the main bus 124 at the same time. Performance optimisation of the DMAC 116 is a key way by which to improve Emotion Engine performance. The image processing unit (IPU) 118 is an image data processor that is used to expand compressed animations and texture images. It performs macro-Block decoding, colour space conversion and vector quantisation. Finally, the sub-bus interface (SIF) 122 is an interface unit to the lOP 700. The IPU has its own memory and bus to control 110 devices such as sound chips and storage devices.

Figure 3 schematically illustrates the configuration of the Graphic Synthesiser 200.

The Graphics Synthesiser comprises: a host interface 202; a pixel pipeline 206; a memory interface 208; a local memory 212 including a frame page buffer 214 and a texture page buffer 216; and a video converter 210.

The host interface 202 transfers data with the host (in this case the GIF 110). Both drawing data and buffer data from the host pass through this interface. The output from the host interface 202 is supplied to the graphics synthesiser 200 which develops the graphics to draw pixels based on vertex information received from the Emotion Engine 100, and calculates information such as RGBA value, depth value (i.e. Z-value), texture value and fog value for each pixel. The RGBA value specifies the red, green, blue (RGB) colour components and the A (Alpha) component represents opacity of an image object. The Alpha value can range from completely transparent to totally opaque. The pixel data is supplied to the pixel pipeline 206 which performs processes such as texture mapping, fogging and Alpha-blending and determines the final drawing colour based on the calculated pixel information.

The pixel pipeline 206 comprises 16 pixel engines PEI, PE2, PE16 so that it can process a maximum of 16 pixels concurrently. The pixel pipeline 206 runs at 150MHz (in fact 294.912 / 2 MHz)with 32-bit colour and a 32-bit Z-buffer. The memory interface 208 reads data from and writes data to the local Graphics Synthesiser memory 212. It writes the drawing pixel values (RGBA and Z) to memory at the end of a pixel operation and reads the pixel values of the frame buffer 214 from memory. These pixel values read from the frame buffer 214 are used for pixel test or Alpha-blending. The memory interface 208 also reads from local memory 212 the RGBA values for the current contents of the frame buffer. The local memory 212 is a 32 Mbit (4MB) memory that is built-in to the Graphics Synthesiser 200. It can be organised as a frame buffer 214, texture buffer 216 and a Z-buffer 215. The frame buffer 214 is the portion of video memory where pixel data such as colour information is stored.

The Graphics Synthesiser uses a 2D to 3D texture mapping process to add visual detail to 3D geometry. Each texture may be wrapped around a 3D image object and is stretched and skewed to give a 3D graphical effect. The texture buffer is used to store the texture information for image objects. The Z-buffer 215 (also known as depth buffer) is the memory available to store the depth information for a pixel. Images are constructed from basic building blocks known as graphics primitives or polygons. When a polygon is rendered with Z-buffering, the depth value of each of its pixels is compared with the corresponding value stored in the Z-buffer. If the value stored in the Z-buffer is greater than or equal to the depth of the new pixel value then this pixel is determined visible so that it should be rendered and the Z-buffer will be updated with the new pixel depth. If however the Z-buffer depth value is less than the new pixel depth value the new pixel value is behind what has already been drawn and will not be rendered. Alternative Z-buffer tests are available, so that (a) the new pixel always replaces the previous value, or (b) the new pixel replaces the previous pixel value if its depth is greater than or equal to the previous value stored in the Z buffer.

The local memory 212 has a 1024-bit read port and a 1024-bit write port for accessing the frame buffer and Z-buffer and a 512-bit port for texture reading. The video converter 210 is operable to display the contents of the frame memory in a specified output format.

An arrangement will now be described to allow the emulation of the system described with reference to Figures 1 to 3. Note that for convenience, the processing units shown in Figures 1 to 3 will be referred to as "emulated" processing units, whereas in the emulating system to be described below, processing units of that (emulating) system will be referred to as "emulating" processing units. To avoid any possible confusion, note that both categories of processing units ("emulated" and "emulating" processing units) represent physical processing units capable of running native software appropriate to those processing units.

Figure 4 is a schematic diagram illustrating the structure of the emulating system used in the present embodiment.

The system comprises: a CPU 1300, eight emulating sub-processors (EPUs) 1310..1380, an input/output (I/O) interface 1390 and system main memory 1400. These are all connected together by a message data interconnection 1410. (In fact the present embodiment includes two I/O interfaces, but just one is shown for clarity of the diagram).

The CPU 1300 is a multi-thread processor which can directly address the main memory 1400. The CPU is a processor core implementing a 64 bit version of the known PowerPC architecture. It has its own level 2 cache (not shown).

Each EPU is a vector processor with 128 bit word length and 256KB (kilobytes) of internal storage. The EPUs cannot directly address the main system memory, but can do so via a respective DMA unit 1311, 1321... 1381.

The operation of the PS2 arrangement described with reference to Figures 1 to 3 is reproduced (or very nearly reproduced) by software running on the processing units of Figure 4, despite the fact that the emulating processing units of Figure 4 have (in general terms) a different architecture, speed, memory accessing capabilities and so on, compared to the emulated processing units of Figures 1 to 3. The reproduction of the operation of the PS2 arrangement is an emulation rather than a simulation. That is to say, it is not the case . 9 that all of the operations contributing to the functionality of the PS2 are reproduced by the emulating system in a lock-step, clock-by-clock manner. Rather, some functions may be carried out by time division on a single emulating processing unit, and in general the processing units communicate with one another only when there is a need (within the emulated system) to do so.

The CPU 1300 controls the overall operation of the emulating system and runs an operating system (OS) for the emulating system. It also has one thread which provides interpretation of native Emotion Engine PS2 instructions, while another thread provides the function of recompiling new code native to the emulating system to provide the particular functionality defined by the interpreted PS2 code. Emulation of the various parts of the PS2 system described above is devolved to the eight EPUs, which emulate PS2 functionality as set out below. It will be appreciated that the precise identity of the individual EPUs is just a convenient notation and has no technical significance because of the nature of the message-passing interface between the EPUs. So, for example, the operations assigned to the EPUs 1310 and 1320 could be swapped in their entirety with no technical effect on the overall emulation process.

EPU131O IPU118 EPU 1320 Emotion Engine CPU 102 and Vector Unit 0 EPU 1330 VIFO,VIF 1,GIF 110 EPU 1340 Vector Unit 1 EPU 1350 GS 200 (i.e. that part of the operation of the GS 200 specific to the PS2 system; the EPU 1370 also interfaces with a graphics controller of the emulating system (not shown) for non-P S2-specific graphics operations) EPU 1360 generally unused, but can be used to recompile code to emulate Vector Unit I, to ease the load on the one thread of the CPU 1300 described above EPU 1370 SPU300 EPU 1380 lOP 700 and SIF 122 The PS2 used a conventional bus for communication between the various emulated processing units. The emulating system makes use of the data interconnection 1410 for passing messages between EPUs and between an EPU, the CPU 1300 and the I/O controller 1390. The PS2 system had conventional memory access arrangements to access the RDRAM 500. The emulating system uses a distributed DMA system (the DMA controllers 1311... 1381). The main system memory 1400 is treated as a common memory "pooi", with all EPUs having access to it.

Each of the EPUs runs locally, on its own time clock. The EPUs run software to allow parts of the functionality of the PS2 system to be emulated. As between EPUs, synchronisation is required only when the emulated processing units emulated by the EPUs need to communicate with one another. At that time, synchronisation takes place just between the devices concerned, using a message transfer mechanism.

To achieve this, when synchronisation is required between two EPUs, one of the EPUs places a message onto the message data interconnection 1410 (including a source EPU identifier, a destination EPU identifier etc), addressed to the other of the EPUs. The message may include a request for a certain piece of data, or may include a data item which is being sent to that other EPU. When an acknowledgement is returned by that other EPU, the transaction is complete. This is a reliable but rather slow method of synchronising two emulated processors.

The way in which the EPUs are logically arranged is shown schematically in Figure 5. Example paths of communication between the EPUs are also shown, although these need not be exhaustive. It can be seen that some functions are shared on the same EPU which avoids entirely the need to use the message-passing mechanism to communicate between them. So, providing the emulation of two (or more) emulated processing units on a single EPU can improve the system's performance by reducing the amount of inter-EPU communication needed.

Another feature which is not exhaustively indicated on Figure 5, for clarity of the diagram, is that where the emulated processing units emulated by two different EPUs need to communicate with one another a lot in order to carry out particular functions of the PS2, a part of the functionality of one real processor can be carried out by the "other" EPU..

For example, the PS2 sound processing unit is mostly emulated on one EPU. This processes samples and mixes them into the final samples for output. It also processes accesses to its register map. However, the registers used to write to sound processing unit sample memory are emulated on the lOP's SPU which manages the queuing of accesses, directly accesses the sample memory image in main memory, and raises any interrupts these might cause as though they had been routed from the sound processing unit.

Another example of a device in the PS2 system which is implemented on more than one SPU is the DMAC, whose function is distributed between the emulating components primarily used for the Emotion Engine, VIF, GIF, IPU and others.

An example of one emulating SPU handling the emulation of multiple PS2 system devices is that the emulation of the PS2's lOP is shared (on a single emulating device) with the bulk of the emulation of a CD disk controller.

This division of the emulation of an emulated processing unit between two (or more) emulating processing units again can reduce the message traffic needed to provide communication between the emulations of those emulated processing units.

In so far as the embodiments of the invention described above are implemented, at least in part, using software-controlled data processing apparatus, it will be appreciated that a computer program providing such software control, a storage medium by which such a computer program is stored and a transmission medium by which such a computer program is transmitted are envisaged as aspects of the present invention. It is noted that such software may be provided on a storage medium such as an optical disk or a hardware memory, anlor via a transmission medium such as a network connection or the internet.

Claims

CLAIMS

1. A data processor comprising a plurality of interconnected emulating processing units arranged to emulate the operation of an emulated processor having a plurality of interconnected emulated processing units, in which: at least one emulated processing unit is emulated by contributions from two or more emulating processing units; and at least one emulating processing unit contributes to emulating two or more emulated processing units.

2. A data processor according to claim 1, in which the emulating processing units communicate with one another by a message-passing communication protocol.

3. A data processor according to claim 1 or claim 2, comprising a supervisory processor to interpret instructions relating to an emulated processor and provide information to the emulating processing units to allow the interpreted instructions to be executed.

4. A data processor according to claim 3, in which the information supplied to the emulating processing units comprises object code, native to the emulating processing units.

5. Data processing apparatus substantially as hereinbefore described with reference to the accompanying drawings.

6. A data processing method relating to a system having a plurality of interconnected emulating processing units arranged to emulate the operation of an emulated processor having a plurality of interconnected emulated processing units; the method comprising the steps of: emulating an emulated processing unit by contributions from two or more emulating processing units; and emulating two or more emulated processing units by one emulating processing unit.

7. A data processing method substantially as hereinbefore described with reference to the accompanying drawings.

8. Computer software for carrying out a method according to claim 6 or claim 7.

9. A medium by which computer software according to claim 8 is provided.

10. A medium according to claim 9, the medium being a storage medium.

11. A medium according to claim 9, the medium being a transmission medium.