System Management Transactions

HT provides a message passing mechanism between the Host Bridge and the System Management Controller (SMC). One of the primary purposes of HT messages is to eliminate dedicated pins and traces that would otherwise be required to signal various events, reducing pin count and cost. These System Management (SM) messages are delivered via packets that support a wide variety of functions including:

• HT Power Management

• X86 Power Management

• X86 Legacy CPU Signalling (e.g. A20M, FERR#, and IGNNE#)

HT System Management messages in conjunction with LDTSTOP# may be used to support operations such as changes in operating frequency and link width, or to disable the links to save power. It is also through System Management (SM) requests that many of the x86 compatibility mechanisms are accomplished as indicated above. Further, x86 platforms are required to support SM and LDTSTOP# for power management. Power Management support for HT devices is optional in non-x86 platforms; however, many non-x86 systems do support power management. Note also that the specification requires all HT devices to forward SM packets in both directions.

Sources of SM Request

System Management requests may be either sent in the upstream or downstream direction, as illustrated in Figure 9-1 on page 217. All SM requests moving upstream originate at the System Management Controller (SMC) and downstream requests originate at the Host Bridge. Note that the SMC typically resides in the south bridge (or I/O Controller Hub) where the legacy signals typically originate and where power management registers reside.

Figure 9-1. SM Request Sources

System Management Address Range

System Management transactions are recognized by their assigned address range. The HT specification reserves a 1MB address range for system management transactions from FD_F910_0000h to FD_F91F_FFFFh. In reality, only the upper address bits are needed to identify that the transaction falls within the assigned 1MB range. SM request packets include only the upper 20 bits (A39:A20) of the HT address for identifying the SM range (FD_F91h). Note that the lower 5 nibbles (or 20 bits) of the address are not defined and could theoretically be any value between 0_0000h and F_FFFF. The 1MB block of SM address space serves only to identify SM transactions and does not actually target any memory locations.

The SMC & Upstream Request Packets

The System Management Controller generates SM requests in response to both software initiated events (i.e., writes to registers within the south bridge) and hardware events (e.g. inactivity timeouts).

Upstream Request Packet Format

SMC-originated messages are delivered as posted Sized Write transactions, consisting of a SM request packet followed by a 4 byte data packet. An SM transaction is identified by both the Sized Write command and the assigned SM address range. The format of the upstream moving SM request packet is illustrated in Figure 9-2. The specification requires the following field values:

• Byte 0 ” Cmd defined as posted, sized, byte write = 101000d

• Bytes 2 & 3 ” Count [3:0] = 0000b (specifies 4 byte data packet)

• Byte 4 ” Defines types of upstream SM Request. (See "System Management Commands ” Upstream" on page 219 for details.)

• Bytes 5 & 6 ” Address[39:20] = FDF91h

Figure 9-2. Format of SM Request Packet Issued by the System Management Controller

An interesting aspect of the upstream SM transactions is that the Host Bridge reflects them all back downstream across all links as broadcast SM messages.

System Management Commands ” Upstream

The System Management Command field (SysMgtCmd) defines the type of SM request being issued. Table 9-1 on page 219 summarizes the SM command options for the upstream direction. All of the upstream messages represent state changes of various signals as indicated in Table 9-1. (Chapter 22, entitled "X86 CPU Compatibility," on page 491 details each signal type.)

Three distinct pieces of information may be included in the upstream SysMgtCmd:

• The Base Command Type ” The upper nibble defines the primary command type (processor input signals and STPCLK) and is always present.

• Signal State Bit Map ” Defines new state of the signal (1 = signal asserted, 0 = signal deasserted). For example, STPCLK may be asserted by the SMC (bit 0 of SysCmd = 1) to indicate a power management request. Subsequently, the SMC would need to deassert STPCLK by sending another message, with bit 0 of SysCmd = 0. In addition, when an SM message is sent to the Host Bridge, the bridge will send the packet back downstream using its SM request packet.

• System Management Action Field (SMAF) ” In the upstream direction this field is only defined only for the STPCLK message. SMAF qualifies the nature of the power management event being signalled. Note that the definition of the SMAF is platform specific.

Table 9-1. Summary of Upstream SysMgtCmd Encodings

SysMgtCmd 7:4 3:0	Command Type
0000 xxxx	Reserved
0001 xxss	x86 legacy inputs to the processor. Bits [3:0], labeled "s," are bit maps that correspond to each input and the new logic state of the specified signal. (1 = signal asserted and 0 = signal deasserted) Bit 0 = IGNNE state Bit 1 = A20M state Bits 2 and 3 = Reserved
0011 aaas	STPCLK (Stop Clock) used to communicate a request to change power management states and can also be an input to the processor. Bit [0], labeled "s" specifies the new state of the STPCLK signal. Bits [3:1] are defined as system management action fields (SMAFs). (These values define the nature of the power management request.)

TheHost Bridge & Downstream Request Packets

The Host Bridge generates all SM packets moving in the downstream direction. These transactions are delivered via Broadcast request packets that have no associated data packet.

DownstreamRequest Packet Format

The SM request packet format delivered by the Host Bridge is illustrated in Figure 9-3. The packet format for downstream SM messages contains the following required data field values:

• Byte 0 ” Cmd defined as posted, broadcast = 111010d

• Byte 4 ” Defines types of downstream SM Request. (See "System Management Commands" on page 221 for details.)

• Bytes 5 & 6 ” Address[39:20] = FDF91h

Figure 9-3. Format of SM Request Packet Issued by the Host Bridge

System Management Commands

Table 9-2 on page 221 summarizes the SM command options. The highlighted entries in Table 9-2 indicate commands that originate at the Host Bridge, while the other entries originate from the SMC and are reflected back downstream by the Host Bridge.

Table 9-2. Summary of SysMgtCmd Encodings

SysMgtCmd 7:4 3:0	Command Type
0000 xxxx	Reserved
0001 xxss	x86 legacy inputs to the processor ” Originates at the SMC and is reflected downstream across all links. Bit 0 = IGNNE state Bit 1 = A20M state Bits 2 and 3 = Reserved
0010 xxxs	x86 legacy outputs from the processor. The bit map [3:0] corresponds to each output and the new logic state of the signal. The specification currently defines only FERR. (1 = signal asserted and 0 = signal deasserted) Bit 0 = FERR# Bits [3:1] = Reserved
0011 aaas	STPCLK (Stop Clock) ” Originates at the SMC and is reflected downstream across all links.
0100 xxxx	x86 CPU Halt Special Cycle (xxxx = Reserved)
0101 xxxx	x86 CPU Shutdown Special Cycle (xxxx = Reserved)
0110 aaax	STOP_GRANT Special Cycle. The SMAF values define the type of STOP_GRANT request. Bit 0 = reserved Bits [3:1] = system management action fields (SMAFs).
0111 xxxx	VID/FID Change (xxxx = Reserved)
1000 xxxx	WBINVD Special Cycle (xxxx = Reserved)
1001 xxxx	INVD Special Cycle (xxxx = Reserved)
1010 xxxs	SMIACK Special Cycle Bit 0 = new logic state of SMIACK signal Bits [3:1] = Reserved
1011 xxxx	Reserved for x86 platform-specific functions ” can originate at either the host or SMC.
11xx xxxx	Reserved

Detailed descriptions of each of the virtual wires and special cycles can be found in Chapter 22.