Development Techniques for Using Simulation to Remove Risk in Software/Hardware Integration

Cygnus Next Generation Playstation Simulation Environment

This section describes the Next Generation Playstation Simulator and environment developed by Cygnus Solutions for SONY Computer Entertainment. This environment illustrates many of the transparency and visibility traits desirable in a co-development tool.

Figure 2: Block Diagram of the SONY Next Generation Playstation.

Figure 2 shows a high-level schematic of the SONY Next Generation Playstation hardware. The CPU, called the Emotion Engine, is a custom version of a MIPS 64-bit processor with 128-bit extensions [4]. It has two integer units, hardware floating point and divide units, plus MMU, instruction and data caches, and 32 MB of main memory.

The new system is capable of drawing 66 million polygons per second, which places it among the world's fastest rendering engines. These impressive results are due to the two Vector Processing Units (VPUs) shown in Figure 2. Each VPU contains a Vector Unit (VU), a Vector Interface FIFO (VIF), and local instruction and data memory. A VU can issue one integer instruction and one vector instruction per cycle. The vector instruction performs four simultaneous floating point operations, drawing its operands from a bank of 32 128-bit vector registers. The VIF is responsible for downloading code and data from main memory to the local memory of the VPU. These transfers are supported by the DMA controller. VU0 is accessible from the main processor as a coprocessor (COP2), while VPU1 runs asynchronously to the main processor. The last stage in the graphics pipeline is the Graphics Processing Unit, or GPU. The GPU can be accessed through VIF1 or the DMAC.

The Cygnus simulator models all these components and their interactions. The CPU model is an instruction accurate architectural level ISS. The model supports the MMU, floating point unit, and COP2, but does not include a cache model. This level of detail is sufficient to boot the operating system on the simulator. The VPU simulator is more detailed: it is pipeline accurate and can be configured to use a detailed floating point simulator or a faster but less accurate version.

The Cygnus co-development tool provides transparency because code compiled and linked for the simulator can be run without modification on the real hardware. There are also a number of features that improve visibility into the hardware and enhance debug capabilities:

• All the registers on the main processor, VPUs, and VIFs can be displayed in the GDB debugger. The user can see all the register sets at once, or just the registers of a particular unit by setting a context variable within GDB. As well, there are command extensions to access and view all four registers in a vector register as a single entity.
• Since there are three different instruction sets (the VIFs actually have their own!) three different disassemblers are required. GDB uses memory maps, cpu contexts, and annotations in the executable to automatically select the correct disassembler.
• Breakpoints in the simulator are non-intrusive, so the user can place them at any instruction on both the VUs and VIFs, as well as the in the code that runs on the main processor.
• The contents of the VIF FIFOs can be displayed. If the destination is to instruction memory, the bytes are disassembled as VU instructions.
• Because of the limited size of the instruction memory in the VPUs, they are managed using overlays. This means that a particular range of VPU instruction addresses can have any one of several functions resident at a particular moment. The code for each function is downloaded from a different location in main memory. The debugger and simulator cooperate to keep track of which main memory segments are currently resident in each VU. This allows users to set symbolic breakpoints on VU code - GDB automatically sets the breakpoint when the function is downloaded to the VU, and clears the breakpoint if the resident overlay changes.
• The simulation environment supports tracing from each of the components separately or in any combination. For the latter case, the traces from the different components are interleaved in time order. This allows one to view the interactions between components during post mortem analysis.

These features demonstrate the integration between the simulation and debug environments, which is the key strength of a good co-development tool. This integration provides a synergy that makes the tool very powerful, so much so that the simulator is the preferred development environment even though physical hardware prototypes are already available!

It is interesting to note that even though the simulator is 100 to 1000 times slower than the real hardware, developers can get acceptable speed by reducing the resolution (number of polygons) in their scenes. The images that result do not look very pretty, but they retain the essential elements of the higher resolution version and are thus rendered quickly and still useful for debugging and testing algorithms.

The Cygnus Next Generation Playstation Simulator was made available to a selected number of developers in late 1998. At that time, the physical prototype was not yet ready. The developers were able to run and debug their applications in time for the product announcement and launch in February 1999.