Tobias Webel

Robust power management in the IBM z13

The power management strategy adopted for the IBM z13™ processor chip (referred to as the CP or Central Processor chip) is guided by three basic principles: (a) controlling the peak power consumption by setting a realistic limit on the so-called thermal design power or thermal design point (TDP) driven by customer workloads and maximum-power stress microbenchmarks; (b) reduction of the voltage margin by using a novel dynamic guard-banding technique; and (c) the creation of a rich new set of fine-grained, time-synchronized sensors that track performance, power, temperature, and power management behavior for a running machine. A prime requirement of the power management architecture is that the efficient control mechanisms be designed in such a manner that the high standards of IBM z Systems™ application performance and reliability be maintained without any compromise. In this paper, we describe the key features constituting the z13 CP robust power management architecture and design that meet the stipulated objectives.

Scalable and modular pervasive logic/firmware design

With the advances in semiconductor technology, more and more units such as cores, caches, memory controller, and input/output (I/O) can be integrated on a single processor. The latest generation of the IBM System z® processor family exploits these technology capabilities and integrates four cores, along with several cache, memory, and I/O units on a single die. More parallel units not only promise increased throughput but also add significant complexity to all chip-wide functions such as on-chip communication among the units. Many of the System z reliability, availability, and serviceability features are based on chip-wide functions, which are referred to as pervasive functions. Among others, the pervasive functions include chip initialization, test, control of clocks, monitoring of status information, and error reporting during system operation, as well as system reconfiguration while the system is running. As the complexity of many pervasive functions dramatically grows with the increasing number of integrated units, a new modular and scalable architecture for pervasive functions has been developed for the IBM zEnterprise® 196 processor (central processor (CP) chip) and system controller (SC chip) to cope with these challenges. This paper outlines the architecture for the CP and SC chips as they pertain to pervasive design. We discuss the architecture considerations taken when the new pervasive architecture was devised and elaborate on the implementation. Furthermore, we show how the novel pervasive architecture is used for very-large-scale integration testing, how it supports power management features, and how it facilitates a modular firmware design.

26.2 Power supply noise in a 22nm z13™ microprocessor

Successful power supply noise mitigation requires a system-level approach that includes design and modeling of the mitigation circuits with the power delivery network (PDN) on the chip, the chip module, the backplane, and the voltage regulator module (VRM). Traditionally, periodic square-wave activity patterns with all cores in sync, which yield low-frequency (LF) or mid-frequency (MF) impedance peaks associated with the backplane and chip/module, respectively, are considered to give rise to the worst case power supply noise. However, voltage droops that are both deeper and faster at a single victim core are created when cores change activity in more complicated patterns, termed as perfect storms in this work. These patterns excite high-frequency (HF) modes that are not stimulated when all cores switch simultaneously, and require an accurate model of the packaged chip, including effective core-to-core inductances due to currents traveling between cores through low-resistance module planes.

Innovations in infrastructure firmware for the IBM z13

In this paper, we describe advances in the Support Element (SE) and Flexible Support Processor firmware design for the IBM z13™. Significant changes in hardware packaging, system control structure, and internal service network topology required major adaptations in critical hardware management components. The Configuration Manager redesign applied a modular programming approach to split a previously tightly coupled code base into isolated and now separately maintainable and testable units. The Hardware Object Model component was extended by a language-independent inter-process query interface based on concepts used in graph query languages. A licensing procedure, Feature on Demand, was refactored to a smart-card-based approach. In the networking firmware, new hardware platforms required a redesigned SE location detection mechanism to guarantee redundant accessibility via separated network paths. The introduction of a virtual self-boot engine (vSBE) for chip initialization provided hardware designers with a simplified means to efficiently integrate initialization procedures into firmware. An interpreter executes these hardware initialization procedures, avoiding the need for translation to programming languages. In addition to an in-depth introduction of the new design aspects, this paper outlines the improvements achieved with respect to development and bring-up efficiency as well as hardware initialization time.

Run-control migration from single book to multibooks

This paper describes the migration of the hardware-implemented run-control functions from a single-book structure with one flexible service processor (FSP) and one service element (SE) per system to a multibook structure with one FSP per book and one SE per system. The new system structure required two new interfaces between the clock chips on the different books. The first interface is required for dynamic configuration data exchange between books. The alternative path via the SE would not meet the performance requirements. This interface is available in the initial millicode load flow before the L2 caches with their ring structure are operational. Another requirement is the necessity of starting and stopping all books synchronously. The second additional interface between the clock chips on different books enables this function. Nevertheless, the hardware implementation is so flexible that each book may operate independently of the other books. The clock chips are connected as a peer-to-peer network, so no special master is necessary in the system.