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

With the IBM eServer(TM) z900, simulation methods and tools for verification of code that is to be embedded in the memory of the system (firmware) were introduced. Since that time, firmware developers have simulated their code prior to the availability of new system hardware components, thereby reducing the time required to bring a large computer system to market. With the z990 system, code simulation efficiency has been improved. The simulation coverage for host and service firmware has been increased from approximately 60% in the z900 to 85% in the z990 by introducing new concepts and extensions. For the first time, the central electronic complex (CEC) firmware simulator, CECSIM, has been enabled to run code in a logical partition (LPAR). This was a prerequisite for code verification of the intra-CEC connectivity, HiperSockets(TM). For verification of HiperSockets, a Linux� operating system is loaded into an LPAR. Code verification is accomplished more easily, more effectively, and with better coverage using Linux debugging features because of the ease of performing functional tests with Linux. Another major improvement was the connection of the channel code simulator for the networking I/O adapter OSA-Express to the CECSIM environment to provide a comprehensive verification that covers the entire path of firmware interaction between the CEC and the I/O channels. For the simulation of card control code, a combined software and hardware verification approach was introduced. The overall functionality was verified with a system simulation model, and the base hardware accesses were verified by attaching real hardware. In addition, the cage controller code was integrated into the simulation environment. As a result, the firmware interfaces between the support element (SE) and the cage controller as well as between the cage controller and the hardware have been tested.

Introduction

The application of simulation techniques for the z900 system, the predecessor of the z990, significantly reduced the time required for development of the z900 [1-3]. On the basis of an intensive analysis of the z900 system microcode verification by simulation, an improved firmware simulation concept was implemented for the z990 system. This resulted in an increase in verification coverage of the z990 system code, additional cost savings, and a shorter system development cycle when compared with the z900 system. The new key elements of the z990 firmware simulation concept are described in this paper. Besides enhancements to existing components, such as the firmware simulator, CECSIM, completely new firmware simulation environments have been established. Figure 1 shows an overview of the new components.

CECSIM enhancements for the z990

The use of the firmware simulator CECSIM during the development of the IBM eServer* z900 was very successful [3]. It was used by about a hundred users at four IBM locations. At the end of the project, CECSIM users requested a number of enhancements to the simulator in order to further increase productivity. One request was to simulate code that runs in a logical partition (LPAR). The logical partition concept is equivalent to running several independent systems, each with its own system resources and operating systems, within a single physical z990 system. The capability to simulate code in LPARs would become very important, since the z990 is the first zSeries* system that runs only in LPAR mode.

During the z900 project we could simulate the LPAR hypervisor (the control program that manages LPARs in a zSeries CEC) in CECSIM together with the underlying firmware. However, the simulator did not support running code within a logical partition. Therefore, a shortcut was implemented: Whenever the hypervisor attempted to run a logical partition, CECSIM returned a disabled wait program status word (PSW) in the partition to the hypervisor. Thus, at least this code path in the hypervisor could be simulated, but simulation was not available for the many other conditions within a partition that required assistance by the hypervisor.

When the z990 was developed, CECSIM was enhanced to actually run a logical partition controlled by the LPAR hypervisor. This capability allowed another level of complexity to be tested with firmware simulation: First, a variety of assembler programs were used to trigger many code paths in the LPAR hypervisor. second, the complete coupling facility control code was run in simulation. Third, a RAM disk image of Linux** on zSeries systems was used to test HiperSockets*, which is a technology that provides high-speed communication between LPARs within a CEC. Each of these environments increased the test coverage for millicode and I390 code, which are always an integral part of the simulation environment.

The LPAR hypervisor runs a logical partition by issuing the instruction start interpretive execution (SIE) [4]. This instruction is implemented in millicode, which is interpreted by CECSIM, as are many other instructions (e.g., start subchannel). The simulator now supports the hardware (HW) facilities used by SIE, such as the relocation of partition storage and partition timers. When SIE millicode is complete, all information relevant to describing the partition is known to the simulator. In particular, the PSW now points to the next instruction to be executed within the partition. CECSIM itself uses SIE to run the simulated processor, so there are now three logical levels: CECSIM, the LPAR hypervisor, and the LPAR. However, CECSIM sets up its own SIE state description such that it directly runs the simulated LPAR, as outlined in Figure 2.