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

To simulate the networking environment (packets coming from neighbor networks, the link between networks going up and down, etc.), the network simulator (NETSIM) was created along with the simulator support facility (SIMSF) and added to the OSASIM/CECSIM environment [Figure 5(c)].

A NETSIM model is connected to each OSASIM model via a TCP/IP socket connection. The SIMSF model is also attached to the NETSIM model via another TCP/IP connection. SIMSF collects statistics from the NETSIM as well as making adjustments to the settings of the simulator. The NETSIM model can generate many test variations, including IP frames with and without acknowledgment, multicast frames, and broadcast frames in various frame sizes. In addition, address-resolution protocol caching, IP Version 6, and link up/down conditions are simulated by the NETSIM vehicle.

NETSIM generates datagrams and sends them to the test program through OSASIM copy number 1. The test program passes the data received to OSASIM copy number 2 and further on to NETSIM. While NETSIM executes test cases and sends frames up to OSASlM, SIMSF comes in and alters the configuration, causing NETSIM to behave differently. This simulates a continuously changing network environment.

In summary, the attachment of OSASIM to CECSIM has proven to be effective for I/O firmware development. The simulation approach enables the development process to proceed at a more rapid pace aided by the ease of setting up test scenarios. As a result, initial bringup time is reduced, and code delivered to system test is more stable. During the z990 project, a similar simulation environment for PCI crypto cards had already been realized on the basis of the OSASIM code. The implementation of the CECSIM infrastructure is independent of OSA-specific items; therefore, it may also be used for the connection of standalone test facilities of other channels.

Simulation of control code using office hardware

The coverage of the firmware simulation has been increased significantly by inventing verification mechanisms for the system control firmware, which have been included in the z990 firmware verification process for the first time. System control code is referred to as in-band system management whenever it is implemented within the scope of an operating system. The innovations of in-band control code verification are described in the previous sections of this paper. This section focuses on the verification improvements of the out-of-band firmware, i.e., control code that uses functions beyond the scope of the operating system.

Sysiem environment

System control firmware is deeply embedded in the system structure. This makes it difficult to design firmware test cases running in the system environment that make results visible but do not affect the system operation. This also applies to the out-of-band (OOB) firmware. The processor executing this OOB code is a controller card called the flexible support processor (FSP); it is located in each CEC, I/O, and power cage, as indicated in [U].