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

* One power cage (with FSP master/slave), one CEC cage (master only), and one I/O (master only) cage.

* One power cage (with FSP master/slave) and two CEC nodes (master only) without an I/O cage.

* One power cage (with FSP master/slave) and one CEC or I/O cage (master and slave).

The primary components of an FRU simulator are the FRU gate array (FGA) slave, providing the card access, and a seePROM, as on a real system. The seePROM content (also referred to as vital product data, or VPD) defines which type of card (e.g., OSC, ETR, STI, ESCON, and ISC-3) should be generated by the cage controller object model. This allows the same FRU simulator hardware to be used for different card types by modifying the seePROM data. The FGA slave which is connected to the FGA master on the FSP card provides several standard interfaces such as UART, JTAG, I^sup 2^C, general-purpose input/output (GPIO), and the proprietary service bus adapter interface. all of these interfaces are necessary for the out-of-band control of a real system.

Figure 7 is an overview of the office hardware environment, in which chip control signals are verified under real-time conditions, voltage violations can be detected, interrupt mechanisms are verified, and cable traffic is sensed. Figure 8 shows a generic view of the differences between a real system and the office hardware.

Cage controller simulation

In another major improvement in the z990 firmware verification, the cage controller code was simulated for the first time. Approximately 75% of this firmware was verified with the simulation approach. The cage controllers, which are embedded in the CEC cage, initialize and maintain system operations. Each cage in a zSeries system contains one pair of cage controllers, of which one is defined as a master, the other as a slave. The slave works as a backup that is ready to take over all tasks when the master fails (for details, see [If]). The cage controller has interfaces to other firmware components [Figure 9 (a) shows a very generic view of the z990 cage controller architecture]:

* The cage controller uses a system support interface (SSI) to communicate with the CEC.

* The TCP/IP connection with the support element is used for the reporting and controlling of system operations.

To be able to verify the cage controller code prior to the availability of the hardware, it was decided to build connections to the existing simulation environments ET4 [2] and CECSIM [Figure 9(b)]. To use the cage controller code in the existing simulation environments, some adaptations have been necessary. Both CECSIM and ET4 have TCP/IP interfaces but do not offer SSI support as used for the communication between the cage controller code and the CEC on a real system. Therefore, a special simulation SSI driver has been implemented which translates SSI commands. This driver provides the same application interface as the real SSI device driver (e.g., initializations, command execution, interrupt handling).

On a real z990 system, the cage controller code runs on a PowerPC controller with the OS Open operating system. Since it is very difficult and complex to establish a communication between OS Open and CECSIM or ET4, it was decided to port the cage controller code from OS Open to an Intel**-based Linux. In addition, some hardware accesses were replaced with simulation-specific code. With this approach, each developer is able to verify cage controller code on his Intel-based workstation by connecting to the simulation environment.