IBM eServer z990 improvements in firmware simulation

IBM Journal of Research and Development, May-Jul 2004 by Stetter, M, Buttlar, J von, Chan, P T, Decker, D, Et al

This property of the system firmware makes the testing and debugging extremely difficult and time-consuming if done in a real system environment, since the system often requires special test equipment to monitor the firmware output. For the predecessor system z900, this was the only way to verify FSP code. However, for the z990 system a new concept has been invented which integrates an FSP firmware verification into the system simulation to achieve 90% simulation coverage. This section describes the simulation approach for the system configuration (cage configuration object model, or CCOM), which includes I/O and power configuration. The new verification environment for the CEC initialization and communication code is described in the section on cage controller simulation.

One main focus was to be as consistent as possible with the overall z990 system simulation efforts. This is essential in testing the correctness of the interfaces and protocols between the different firmware parts. However, timing issues must be tested under the same conditions as those existing in the real system. For the z990 system, an interbalanced approach between a software simulation and a hardware simulation was chosen, and a special hardware was built to simulate the timing conditions exactly as they would be seen in the real system. This environment, called office hardware or field-replaceable unit (FRU) simulator, was used for additional out-of-band firmware testing. This allowed us to participate in the overall system simulation while achieving extensive coverage of time-critical functions.

In the system control firmware, hardware access is via a device abstraction layer (DAL), as described in [11]. This defined interface is used to access real hardware via device drivers, and also in the firmware simulation environments to access simulation code.

Software simulation

Like the CEC simulation (described in the section on cage controller simulation), the configuration code employs a well-defined DAL interface. This interface allows easy replacement of the device driver code, which is needed to access real hardware with a simulation model [Figure 6(a)]. Since the CEC simulation and the configuration code use different devices and thus different DALs, the (wo simulation environments are independent and may (though they need not) run together. Furthermore, for each device type the DAL code (simulation vs. real hardware access) may be selected independently or mixed. The first extreme option is an independent code simulation model which uses shortcuts for hardware accesses whenever commands are sent to the DAL. The other extreme configuration is a comprehensive model in which the entire simulation environment executes hardware accesses in FRU simulators. This FRU simulator [Figure 6(b)] is equipped with a specially designed piece of hardware which, as an assembly, is called office hardware and is described in more detail in the next section.

Office hardware

To be able to verify the cage controller code on a PowerPC platform which uses the devices, the device drivers, and the operating system OS Open as the real system does, an office hardware environment was defined. We used a system that comprises one or more FRU simulator boxes and a box containing one or more FSP cards [Figure 6(b)]. The plugged FSP cards are responsible for power, CEC, and I/O control. The following system configurations are possible: