Espi Analyzer

[Martin Glow]

The Promira Serial Platform with eSPI Analysis Application non-intrusively monitors eSPI bus at up to 66 MHz bit rate in single, dual and quad IO modes. The Promira platform with eSPI analysis application supports two CS signals, two Reset signals, two Alert signals, and 11 Digital IO signals. The Promira platform connects to an analysis computer via Ethernet or Ethernet over USB. The application installed on the Promira platform is field-upgradeable and future-proof.

The Enhanced Serial Peripheral Interface (eSPI) bus interface is used for both client and server platforms. The devices that can be supported over the eSPI interface includes but not necessary limited to Embedded Controller (EC), Baseboard Management Controller (BMC), Super-I/O (SIO) and Port-80 debug card.

The eSPI has been specified by Intel as a replacement for the existing Intel Low Pin Count (LPC) interface on current server and client platforms. LPC bus is a legacy bus developed as the replacement for Industry Standard Architecture (ISA) bus. Some LPC bus limitations, which led to the development of eSPI, are:

The eSPI specification provides a path for migrating LPC devices over to the new eSPI interface. eSPI reuses the timing and electrical specification of Serial Peripheral Interface (SPI), but with a different protocol to meet a set of different requirements.

The Enhanced Serial Peripheral Interface (eSPI) operates in master/slave mode of operation where the eSPI master dictates the flow of command and data between itself and the eSPI slaves by controlling the Chip Select# pins for each of the eSPI slaves. At any one time, the eSPI master must ensure that only one of the Chip Select# pins is asserted based on source decode, thus allowing transactions to flow between the eSPI master and the corresponding eSPI slave associated with the Chip Select# pin. The eSPI master is the only component that is allowed to drive Chip Select# when eSPI Reset# is de-asserted. For an eSPI bus, there is only one eSPI master and one or more eSPI slaves.

In Single Master - Single Slave configuration, a single eSPI master will be connected to a single eSPI slave. In one configuration, the eSPI slave could be the device that generates the eSPI Reset#. In this case, the eSPI Reset# is driven from eSPI slave to eSPI master. In other configuration, the eSPI Reset# could be generated by the eSPI master and thus, it is driven from eSPI master to eSPI slave.

Multiple SPI and eSPI slaves could be connected to the same eSPI bus interface in a multi-drop Single Master - Multiple Slaves configuration. The number of devices that can be supported over a single eSPI bus interface is limited by bus loading and signals trace length. In this configuration, the clock and data pins are shared by multiple SPI and eSPI slaves. Each of the slaves has its dedicated Chip Select# and Alert# pins.

In an eSPI bus configuration with multiple slaves present, the eSPI master may support 2 eSPI Reset# pins, one from eSPI slave to eSPI master and another one from eSPI master to eSPI slaves. In this case, the master's eSPI interface will only be reset if all the slaves' eSPI interfaces are reset.

SPI slaves such as Flash and defined TPM are allowed to share the same set of clock and data pins with eSPI slaves. These non-eSPI slaves are selected using the dedicated Chip Select# pins and they communicate with the eSPI master through SPI specific protocols run over the eSPI bus.

In a Single Master - Single Slave configuration, there could be multiple eSPI host bridges within a single eSPI master and there could be multiple eSPI endpoints within a single eSPI slave. When Chip Select# corresponding to the eSPI slave is asserted, command and data transfer happens between the eSPI master and eSPI slave, which could be a result of the eSPI host bridge and eSPI endpoint communications. Each of the eSPI host bridges communicates with its corresponding eSPI endpoint through dedicated channel. The use of channels allows multiple independent flows of command and data to be transferred over the same bus between the eSPI master and eSPI slave with no ordering requirement.

In Single Master - Multiple Slaves configuration multiple discrete eSPI slaves can be dropped onto the eSPI bus. Each of the eSPI slaves should have a dedicated Chip Select# pin. On the master side, there are eSPI host bridges corresponding to each of the discrete slaves respectively, each driving the Chip Select# pin of the corresponding discrete slave. At any one time, only one of the Chip Select# pins can be asserted. Command and data transfer can then happen between the eSPI host bridge and the corresponding eSPI slave.

The Serial Clock must be low at the assertion edge of the Chip Select# (CS#) while eSPI Reset# has been de-asserted. The first data is launched from master while the serial clock is still low and sampled on the first rising edge of the clock by slave. Subsequent data is launched on the falling edge of the clock from master and sampled on the rising edge of the clock by slave. The data is launched from slave on the falling edge of the clock. The master could implement a more flexible sampling scheme since it controls the clock. All transactions on eSPI must be in multiple of 8-bits (one Byte).

eSPI master and eSPI slaves must tri-state the interface pins when their respective eSPI Reset# is asserted. The Chip Select#, I/O[n:0] and Alert# pins require weak pull-up to be enabled on these pins whereas the Serial Clock requires a weak pull-down. The weak pull-up/pull-down should be implemented either as an integral part of the eSPI master buffer or on the board.

After eSPI Reset# is deasserted on the eSPI master, the eSPI master begins driving Chip Select# and Serial Clock pins to their idle state appropriately. The weak pull-up on the Chip Select# and the weak pull-down on the Serial Clock are allowed to be disabled after the eSPI Reset# deassertion. However, I/O[n:0] and Alert# pins continue to have the weak pull-up enabled for the proper operation of the eSPI bus.

An eSPI transaction consists of a Command phase driven by master, a Turn-Around (TAR) phase, and a Response phase driven by the slave. CRC generation is mandatory for all eSPI transactions where CRC byte is always transmitted on the bus. A transaction is initiated by the master by asserting the Chip Select#, starting the clock and driving the command onto the data bus. The clock remains toggling until the complete response phase has been received from the slaves.

The Command phase is used by the eSPI master to initiate a transaction to the slave or in response to an Alert event by the slave. It consists of a CMD, an optional header (HDR), optional DATA and a CRC. The Command Opcode is 8-bits wide.

After the last bit of the Command Phase has been sent out on the data lines, the data lines enter the Turn-Around window. The eSPI master is required to drive all the data lines to logic '1' for the first clock of the Turn-Around window and tri-state the data lines thereafter. The number of clocks for the Turn-Around window is a fixed 2 serial clocks independent of the eSPI I/O Mode (single, dual or quad I/O).

The Response phase is driven by the eSPI slave in response to command initiated by an eSPI master. It consists of a RSP opcode, an optional header (HDR), optional data, STATUS (STS) and CRC. The RSP opcode is a 8-bit field consists of a Response Code and a Response Modifier.

A transaction can be initiated by the slave by first signaling an Alert event to the master. The Alert event can be signaled in two ways. In the Single Master - Single Slave configuration, the I/O[1] pin could be used by the slave to indicate an Alert event. In the Single Master - Multiple Slaves configuration, a dedicated Alert# pin is required.

The Alert event can only be signaled by the slave when the Chip Select# is high. The pin, either IO[1] or Alert# is toggled from tri-state to pulled low by the slave when it decides to request for service. The slave then holds the state of the pin until the Chip Select# is asserted by the master. Once the Chip Select# is asserted, the eSPI slave must release the ownership of the pin by tri-stating the pin and the pin will be pulled high by the weak pull-up. The master then continues to issue command to figure out the cause of the Alert event from the device and then service the request.

At the last falling edge of the serial clock after CRC is sent, the eSPI slave must drive I/O[n:0] and Alert# pins to high until Chip Select# is deasserted. After Chip Select# deassertion, these pins are tri-stated by the slave, where the weak pull-ups maintain these pins at high.

A channel provides a means to allow multiple independent flows of traffic to share the same physical bus. Each set of the put_*/get_*/*_avail/*_free associates with the command and response of a corresponding channel. Each of the channels has its dedicated resources such as queue and flow control. There is no ordering requirement between traffic from different channels.

The number and types of channels supported by a particular eSPI slave is discovered through the GET_CONFIGURATION command issued by the eSPI master to the eSPI slave during initialization. The assignment of the channel type to the channel number is fixed. The eSPI slave can only advertise which of the channels are supported.

All masters and slaves support Single I/O mode of operation. Support for Dual I/O and Quad I/O mode of operation is advertised by the slave through the General Capabilities and Configurations register.

By default coming out of eSPI Reset#, both master and slave operate in Single I/O mode. The mode of operation can be changed by the master using the SET_CONFIGURATION command. The SET_CONFIGURATION is completed with the current mode of operation. The new mode of operation will only take effect at the deassertion edge of the Chip Select#.

Each of the fields for an eSPI transaction is shifted out accordingly in a defined order. For fields that contain multiple bytes, the order of the bytes being shifted out on the eSPI bus is as follows (LSB = Least Significant Byte, MSB = Most Significant Byte):

c80f0f1006