Low Pin Count

From Infogalactic: the planetary knowledge core
Jump to: navigation, search


Low Pin Count interface IT8705F Super I/O chip. Data sheet available from ITE Tech. Inc.[1]
Trusted Platform Module installed on a motherboard, and using the LPC bus

The Low Pin Count bus, or LPC bus, is used on IBM-compatible personal computers to connect low-bandwidth devices to the CPU, such as the boot ROM, "legacy" I/O devices (integrated into a super I/O chip), and Trusted Platform Module (TPM).[2] "Legacy" I/O devices usually include serial and parallel ports, PS/2 keyboard, PS/2 mouse, and floppy disk controller.

Most PC motherboards with a LPC bus have either a Platform Controller Hub (PCH) or a southbridge chip, which acts as the host and controls the LPC bus. All other devices connected to the physical wires of the LPC bus are peripherals.

Overview

A diagram showing the LPC bus connecting the southbridge, the flash ROM, and the Super I/O chip.

The LPC bus was introduced by Intel in 1998 as a software-compatible substitute for the Industry Standard Architecture (ISA) bus. It resembles ISA to software, although physically it is quite different. The ISA bus has a 16-bit wide data bus and a 24-bit address bus that can be used for both 16-bit I/O port addresses and 24-bit memory addresses; both run at speeds up to 8.33 MHz. The LPC bus uses a heavily multiplexed four-bit-wide bus operating at four times the clock speed (33.3 MHz) to transfer addresses and data with similar performance.

LPC's main advantage is that the basic bus requires only seven signals, greatly reducing the number of pins required on peripheral chips. An integrated circuit using LPC will need 30 to 72 fewer pins than its ISA equivalent. It is also easier to route on modern motherboards, which are often quite crowded. The clock rate was chosen to match that of PCI in order to further ease integration. Also, LPC is intended to be a motherboard-only bus. No connector is defined, and no LPC peripheral daughterboards are available, except motherboard-specific Trusted Platform Modules (TPMs).[2] Device discovery is not supported; since only motherboard devices or specific models of TPM are connected, the host firmware (BIOS, UEFI) image will include a static description of any devices and their I/O addresses expected to be present on a particular motherboard.

Signals

The LPC specification defines seven mandatory signals required for bidirectional data transfer:

  • LCLK: 33.3 MHz clock, provided by the host. May be connected to the conventional PCI clock (PCICLK), thereby not requiring a dedicated pin on the host (south bridge).
  • LRESET#: Active-low bus reset. May be connected to PCIRST#.
  • LFRAME#: This active-low signal indicates the beginning of an LPC bus transaction. Driven by the host only.
  • LAD[3:0]: These four bidirectional signals carry multiplexed address, data, and other information. Like the previous two control signals, these signals have weak pull-up resistors on them, so they will remain in the all-ones state if not actively driven by a device.

There are six additional signals defined, which are optional for LPC devices that do not require their functionality, but support for the first two is mandatory for the host:

  • LDRQ#: DMA/bus master request. This is an output from a device that wants to perform direct memory access, either via the Intel 8237 compatible DMA controller, or the LPC-specific bus master protocol. The host must provide one corresponding input pin per device that needs it (minimum two).
  • SERIRQ: Serialized Intel 8259 compatible interrupt signal.[3] One line is shared by all LPC devices and the host.
  • CLKRUN#: Open-collector signal used to restart the clock in systems that can stop it for power management. Not required if the host does not stop the clock. May be connected to the equivalent PCI signal.
  • LPME#: Open-collector power management event, to wake the system from a sleep state. Equivalent to the PCI bus PME# signal.
  • LPCPD#: Optional output from the host to warn the LPC device that power is about to be removed and it should not make any interrupt or DMA requests.
  • LSMI#: System management interrupt request. This is only required if an LPC device needs to trigger an SMI# in response to a bus access (e.g. to perform software emulation of a missing hardware peripheral). Otherwise, the slower SERIRQ protocol can be used to request an SMI.

Timing and performance

The LPC bus derives its electrical conventions from those of Conventional PCI. In particular, it shares the restriction that two idle cycles are required to "turn around" any bus signal so that a different device is "speaking". In the first, the bus is actively driven high. In the second, the bus is undriven and held high by the pull-up resistors. A new device may begin sending data over the bus on the third cycle. LPC operations spend a large fraction of their time performing such turn-arounds.

As mentioned, the LPC bus is designed to have performance similar to the ISA bus. The exact data transfer rates depend on the type of bus access (I/O, Memory, DMA, firmware) performed and by the speed of the host and the LPC device. Overhead dominates all bus cycles except the 128-byte firmware read cycle, in which 256 of the 273 clock ticks consumed by this cycle actually are used to transfer data to get a throughput of 15.63 MB/s.[4] The next fastest bus cycle, the 32-bit ISA-style DMA write cycle that was defined in this standard, can transfer up to 6.67 MB/s because only 8 out of 20 clock ticks used in this bus cycle actually transfer data with the rest of the cycles are overhead.[4]

One of the slowest bus cycles is a simple memory read or write, where only 2 of the 17 clock ticks (plus any wait states imposed by the device) transfer data, for a transfer rate of 1.96 MB/s.

Applications

Intel designed the LPC bus so that the System BIOS could be stored in a single flash memory chip directly connected to the LPC bus. Intel also made it possible to put operating system images and software applications on a single flash memory chip directly connected to the LPC bus, as an alternative to a Parallel ATA port.[5]

A CPLD or FPGA can implement an LPC host or peripheral.[6]

The original Xbox game console has an LPC debug port that can be used to force the Xbox to boot new code.[7][8]

ISA-compatible operation

All LPC bus transactions are initiated by the host briefly driving LFRAME# low, for one cycle at least. During the last cycle with LFRAME# low (referred to as the START field), the host drives LAD[3:0] to all-zeros to indicate an ISA-compatible transaction will follow.[4] During the first cycle with LFRAME# high again, the host drives a "cycle type/direction" (CTDIR) field: three bits indicating the type (I/O, memory, or DMA) and direction (read from device, or write to device) of the transfer to follow. This is followed by the transfer address field. The size of the address depends on the type of cycle:

  • For I/O access, the address is 16 bits, transferred most-significant bit first over 4 cycles.
  • For memory access, the address is 32 bits, transferred most-significant bit first over 8 cycles.
  • DMA accesses do not have an address per se, but a two-cycle field transfers the channel number and size. See the section on DMA below.

In the case of a write, this is followed the data field, 8 bits transferred lsbit-first over two cycles. Following this, the host turns the bus over to the device. This turn-around take two cycles, and operates the same way as the conventional PCI bus control signals: for one cycle, the host drives the LAD lines high (1111). During the second cycle, the host ceases to drive the lines, although they remain high due to the pull-up resistors.

Following any turn-around to the device is a minimum of one SYNC cycle. The number is variable, under the control of the device to add as many wait states as it needs. The bit patterns 0101 and 0110 indicate that the sync cycles will continue. The wait ends when the device drives a pattern of 0000 (ready) or 1010 (error) on the LAD bus for one cycle. Following this are two turn-around cycles, which are the same as those on the PCI bus control signals. During the first cycle, the host drives the LAD lines high. During the second cycle, the host ceases to drive the lines. The device may drive the lines beginning with the third cycle.

After the turn-around cycles, the addressed device drives the LAD bus for one or more SYNC cycles. The number is variable, under the control of the device to add as many wait states as it needs. The bit patterns 0101 and 0110 indicate that the sync cycles will continue. The wait ends when the device drives a pattern of 0000 (ready) or 1010 (error) on the LAD but for one cycle.

If the host attempts a transfer to an unused address, no device will drive the SYNC cycles and the host will see 1111 on the LAD bus. After seeing three cycles of 1111 (two cycles are allowed, as well as the two turn-around cycles, for a slow device to decode the address and begin driving SYNC patterns), the host will abort the operation.

Including the two turn-around cycles and the minimum of one SYNC cycle, a device has a minimum of three cycles between receiving the address and transferring data. In the case of a read, the sync cycles are followed by 8 bits of data, transferred lsbit-first over two cycles, the same as for a write. Finally, an additional two cycles are taken to turn the bus around to the host again.

ISA-compatible DMA

The Platform Controller Hub (PCH) chip or the southbridge chip acts as the host and controls the LPC bus, and also acts as the central DMA controller for devices on that bus. For compatibility with software originally written for systems with the ISA bus, that chip contains the circuit equivalents of "legacy" onboard peripherals of the IBM PC/AT architecture, such as the two programmable interrupt controllers, the programmable interval timer, and two ISA DMA controllers, which are all involved in "ISA-style DMA".

ISA-compatible DMA uses an Intel 8237-compatible DMA controller on the host, which keeps track of the location and length of the memory buffer, as well as the direction of the transfer. The device simply requests service from a given DMA channel number, and the host performs a DMA access on the LPC bus.

Requests are made using the device's LDRQ# signal. Normally high, a device can indicate a transition on an ISA-compatible DRQ line by sending a 6-bit request: a 0 start bit, the 3-bit DMA channel number (msbit-first), one bit of new request level (almost always 1, indicating that a DMA transfer is requested), and a final 1 stop bit. The host then performs a DMA cycle. DMA cycles are named based on the memory access, so a "read" is a transfer from memory to the device, and a "write" is a transfer from the device to memory.

The "address" consists of two cycles: a 3-bit channel number and 1-bit terminal count indication (the ISA bus' TC pin, or the 8237's EOP# output), followed by a 2-bit transfer size.

By default, DMA channels 0–3 perform 8-bit transfers, and channel 5–7 perform 16-bit transfers, but an LPC-specific extension allows 1- 2- or 4-byte transfers on any channel. When a multi-byte transfer is performed, each byte has its own SYNC field, as described below. DMA transfers allow an additional SYNC field value: a pattern of 1001 indicates that the device is ready with the current byte, and also wishes to transfer more bytes. The standard "ready" pattern of 0000 indicates that this is the last byte.

A normal SYNC "ready" pattern of 0000 (or an error pattern of 1010) requests that the host stop DMA after the immediately following byte, until the device makes another DMA request via the LDRQ# signal. A pattern of 1001 indicates that the host should consider he device's DMA request still active; the host will continue with any remaining bytes in this transfer or start another transfer, as appropriate, without a separate request via LDRQ#.

For a DMA write, where data is transferred from the device, the SYNC field is followed by the 8 bits of data and another SYNC field, until the host-specified length for this transfer is reached, or the device stops the transfer. A two-cycle turnaround field completes the transaction. For a DMA read, where data is transferred to the device, the SYNC field is followed by a turnaround, and the data—turnaround—sync—turnaround sequence repeats for each byte transferred.

Serialized interrupts

Serialized interrupts are transmitted over a single shared SERIRQ line with the help of the clock. A time slot is dedicated to each device, with the initial synchronization being done by the host.[3] As a simplified example:

  • The host drives the SERIRQ line low for eight clocks, then high for another, and lets the bus float for a final turnaround cycle.
  • If a device needs to request IRQ#6, it waits for 6×3=18 clocks, then drives SERIRQ low for a clock and high for another.

The devices can synchronize at the first step because the line can only be driven low for two or more consecutive clocks by the host: no other device drives it low for more than one clock. The host recognizes the sources of the interrupts by watching the line while counting the number of clocks: if it sees the SERIRQ line being driven low at the eighteenth clock, then IRQ 18/3=6 is asserted.

The above is the continuous mode, where the host initiates the protocol. In the quiet mode, a device requests interruption by driving SERIRQ low for a clock. The host then continues driving the line low for the other seven clocks. From this point on, the protocol is the same. In both modes, the number of clocks of the initial synchronization pulse may range from four to eight.

At the beginning, the protocol works in continuous mode. At the end of each complete bus transaction (after the host has driven SERIRQ low and then waited for all devices to send interrupt requests) the host sends a final message: it drives the SERIRQ line low for two or three clocks depending on the mode that will be used in the next transaction.

The advantage of using serialized interrupts over the traditional mechanism is that only the single SERIRQ line is necessary (apart from the clock, which is present anyway), not a line for each interrupt level.

LPC extensions

START field values other than 0000 are used to indicate various non-ISA-compatible transfers.[4] The supported transfers are:

START = 1101, 1110: Firmware memory read and write
This allows the firmware (BIOS) to be located outside the usual peripheral address space. These transfers are similar to ISA-compatible transfers, except that:
  • There is no CTDIR field; the direction is encoded in the START field (1101 for read, 1110 for write).
  • The address is 32 bits, with the high 4 bits encoding the chip number and the low 28 bits the address within the chip
  • The address is followed by a size field. Supported sizes are 1, 2, 4, 16 or (for read only) 128 bytes.
  • The data is transferred in one continuous burst, with no wait states. There is only one SYNC field for the whole transfer.
START = 0010, 0011: Bus-master DMA
A device can request a bus master transfer by using the LDRQ# signal to request use of the non-existent DMA channel 4. In this case, the host will begin a transfer with a special START field of 0010 or 0011, followed immediately by two turnaround cycles to hand the bus to the device indicated by the lsbit. Following the turnaround cycles, the transfer proceeds very much like a host-initiated ISA-compatible transfter with the roles reversed:
  • The device sends a one-cycle CTDIR field (only I/O and memory transfer types are permitted).
  • The device sends an address (16 or 23 bits, depending on the type).
  • The device sends a one-cycle transfer size field, encoding 8, 16 or 32 bits.
  • In the case of a write, the data follows. Unlike ISA-compatible DMA cycles, the data is transferred in one burst, with no more wait states.
  • Then come two turn-around cycles while the LAD bus is handed back to the host.
  • A variable-length SYNC field is inserted, under control of the host.
  • In the case of a read, the data provided by the host follows.
START = 1111: Transaction abort
At any time, although typically in response to an error by the device during a SYNC field, the host may abort the current transaction by driving LFRAME# low without waiting for the current transaction to end. It must hold it low for at least 4 cycles, then return it high with a special START field value of 1111. This performs a soft reset of the LPC bus and leaves the bus idle until the next transfer is commenced by driving LFRAME# low again.
START = 0101: TPM access
Recent trusted platform module specifications define a special TPM access using a START code of 0101, which is followed by a standard LPC I/O read or write access.[9] The 16-bit address includes a 4-bit field that communicates information about the state of the host.

Supported peripherals

The LPC bus specification limits what type of peripherals may be connected to it. It only allows devices that belong to the following classes of devices: super I/O devices, integrated audio including either AC'97 devices or devices that implemented the Sound Blaster interface, and generic-application memory including nonvolatile BIOS memory, firmware hubs, and embedded controllers. Furthermore, each class is restricted on which bus cycles are allowed for each class.[4]

Super I/O devices and audio devices are allowed to accept I/O cycles, accept ISA-style third-party DMA cycles, and generate bus master cycles. Generic-application memory devices like nonvolatile BIOS memory and LPC flash devices are allowed to accept memory cycles. Firmware hubs are allowed to accept firmware memory cycles. Embedded controllers are allowed to accept I/O cycles and generate bus master cycles. Some ISA cycles that were deemed not useful to these classes were removed. They include host-initiated two-byte memory cycles and host-initiated two-byte I/O cycles. These removed transfer types could be initiated by the host on ISA buses but not on LPC buses. The host would have to simulate two-byte cycles by splitting them up into two one-byte cycles. The ISA bus has a similar concept because the original 8-bit ISA bus required 16-bit cycles to be split up. Therefore, the 16-bit ISA bus automatically split 16-bit cycles into 8-bit cycles for the benefit of 8-bit ISA peripherals unless the ISA device being targeted by a 16-bit memory or I/O cycle asserted a signal that told the bus that it could accept the requested 16-bit transfer without assistance from an ISA cycle splitter.[10] ISA-style bus mastering has been replaced in the LPC bus with a bus mastering protocol that does not rely on the ISA-style DMA controllers at all. This was done in order to remove ISA's limit on the number of peripherals that could perform bus mastering. Both ISA-style third-party DMA and ISA-style bus mastering require the peripheral to monopolize one of the DMA channels, which could get scarce in a bus with many peripherals that use DMA channels. The ISA-style bus cycles that were inherited by LPC from ISA are one-byte host-initiated I/O bus cycles, one-byte host-initiated memory cycles, and one- or two-byte host-initiated ISA-style DMA cycles.[4]

However, some non-ISA bus cycles were added. Cycles that were added to improve the performance of devices beside firmware hubs include LPC-style one-, two-, and four-byte bus master memory cycles; one-, two-, and four-byte bus master I/O cycles; and 32-bit third-party DMA which conforms to all of the restrictions of ISA-style third-party DMA except for the fact that it can do 32-bit transfers. Any device that is allowed to accept traditional ISA-style DMA is also allowed to use this 32-bit ISA-style DMA. The host could initiate 32-bit ISA-style DMA cycles, while peripherals could initiate bus master cycles. Firmware hubs consumed firmware cycles that were designed just for firmware hubs so that firmware addresses and normal memory-mapped I/O addresses could overlap without conflict. Firmware memory reads could read one, two, four or 128 bytes at once. Firmware memory writes could write one, two or four bytes at once.[4]

See also

References

  1. Lua error in package.lua at line 80: module 'strict' not found.
  2. 2.0 2.1 Lua error in package.lua at line 80: module 'strict' not found.
  3. 3.0 3.1 Serialized IRQ Support For PCI Systems (Revision 6.0; September 1, 1995)
  4. 4.0 4.1 4.2 4.3 4.4 4.5 4.6 Intel LPC Interface Specification 1.1
  5. Lua error in package.lua at line 80: module 'strict' not found.
  6. "LPC Bus Controller". Lattice Reference Design RD1049. 2011.
  7. Lua error in package.lua at line 80: module 'strict' not found.
  8. O. Theis. "Modding the XBox". section "Details of the LPC".
  9. Lua error in package.lua at line 80: module 'strict' not found.
  10. Lua error in package.lua at line 80: module 'strict' not found.

External links