Bimbingan Skripsi TEKNIK ELEKTRO

PCI Signal Descriptions

2 PCI Signal Descriptions
2.1 System Pins

CLK
Clock provides the timing reference for all transfers on the PCI bus. All PCI signals except reset and interrupts are sampled on the rising edge of the CLK signal. All bus timing specifications are defined relative to the rising edge. For most PCI systems the CLK signal operates at a maximum frequency of 33 MHz. To operate at 66MHz, both the PCI system and the PCI add-in board must be specifically designed to support the higher CLK frequency. A 66 MHz system will supply a 66 MHz CLK if the add-in board supports it, and supply a default 33 MHz CLK if the add-in board does not support the higher frequency. Likewise, if a system is capable of providing only a 33 MHz clock, then a 66 MHz add-in board must be able to operate using the lower frequency. The minimum frequency of the CLK signal is specified at 0 Hz permitting CLK to be “suspended” for power saving purposes.

Figure 1: Signals defined in the PCI standard.

RST#
Reset is driven active low to cause a hardware reset of a PCI device. The reset shall cause a PCI device’s configuration registers, state machines, and output signals to be placed in their initial state. RST# is asserted and deasserted asynchronously to the CLK signal. It will remain active for at least 100 microseconds after CLK becomes stable.

2.2 Address and Data Pins
AD[31:0]
Address and Data are multiplexed onto these pins. AD[31:0] transfers a 32-bit physical address during “address phases”, and transfers 32-bits of data information during “data phases”. An address phase occurs during the clock following a high to low transition on the FRAME# signal. A data phase occurs when both IRDY# and TRDY# are asserted low. During write transactions the initiator drives valid data on AD[31:0] during each cycle it drives IRDY# low. The target drives TRDY# low when it is able to accept the write data. When both IRDY# and TRDY# are low, the target captures the write data and the transaction is completed. For read transactions the opposite occurs. The target drives TRDY# low when valid data is driven on AD[31:0], and the initiator drives IRDY# low when it is able to accept the data. When both IRDY# and TRDY# are low, the initiator captures the data and the transaction is completed. Bit 31 is the most significant AD bit. Bit 0 is the least significant AD bit.

C/BE[3:0]#
Bus Command and Byte Enables are multiplexed onto these pins. During the address phase of a transaction these signals carry the bus command that defines the type of transfer to be performed. During the data phase of a transaction these signals carry byte enable information. C/BE[3]# is the byte enable for the most significant byte (AD[31:24]) and C/BE[0]# is the byte enable for the lease significant byte (AD[7:0]). The C/BE[3:0]# signals are driven only by the initiator and are actively driven through the all address and data phases of a transaction.
PAR
Parity is even parity over the AD[31:0] and C/BE[3:0]# signals. Even parity implies that there is an even number of ’1′s on the AD[31:0], C/BE[3:0]#, and PAR signals. The PAR signal has the same timings as the AD[31:0] signals, but is delayed by one cycle to allow more time to calculate valid parity.

2.3 Interface Control Pins
FRAME#
Cycle Frame is driven low by the initiator to signal the start of a new bus transaction. The address phase occurs during the first clock cycle after a high to low transition on the FRAME# signal. If the initiator intends to perform a transaction with only a single data phase, then it will return FRAME# back high after only one cycle. If multiple data phases are to be performed, the initiator will hold FRAME# low in all but the last data phase. The initiator signals its intent to perform a master initiated termination by driving FRAME# high during the last data phase of a transaction. During a target initiated termination the initiator will continue to drive FRAME# low through the end of the transaction.
IRDY#
Initiator Ready is driven low by the initiator as an indication it is ready to complete the current data phase of the transaction. During writes it indicates the initiator has placed valid data on AD[31:0]. During reads it indicates the initiator is ready to accept data on AD[31:0]. Once asserted, the initiator holds IRDY# low until TRDY# is driven low to complete the transfer, or the target uses the STOP# signal to terminate without performing the data transfer. IRDY# permits the initiator to insert wait states as needed to slow the data transfer.
TRDY#
Target Ready is driven low by the target as an indication it is read to complete the current data phase of the transaction. During writes it indicates the target is ready to accept data on AD[31:0]. During reads it indicates the target has placed valid data on the AD[31:0] signals. Once asserted, the target holds TRDY# low until IRDY# is driven low to complete the transfer. TRDY# permits the target to insert wait states as needed to slow the data transfer.
STOP#
Stop is driven low by the target to request the initiator terminate the current transaction. In the event that a target requires a long period of time to respond to a transaction, it may use the STOP# signal to suspend the transaction so the bus can be used to perform other transfers in the interim. When the target terminates a transaction without performing any data phases it is called a retry. If one or more data phases are completed before the target terminates the transaction, it is called a disconnect. A retry or disconnect signals the initiator that it must return at a later time to attempt performing the transaction again. In the event of a fatal error such as a hardware problem the target may use STOP# and DEVSEL# to signal an abnormal termination of the bus transfer called a target abort. The initiator can use the target abort to signal system software that a fatal error has been detected.
LOCK#
Lock may be asserted by an initiator to request exclusive access for performing multiple transactions with a target. It prevents other initiators from modifying the locked addresses until the agent initiating the lock can complete its transaction. Only specific regions (a minimum of 16 bytes) of the target’s addresses are locked for exclusive access. While LOCK# is asserted, other non-exclusive transactions may proceed with addresses that are not currently locked. But any non-exclusive accesses to the target’s locked address space will be denied via a retry operation. LOCK# is intended for use by bridge devices to prevent deadlocks.
IDSEL
Initialization Device Select is used as a chip select during PCI configuration read and write transactions. IDSEL is driven by the PCI system and is unique on a per slot basis. This allows the PCI configuration mechanism to individually address each PCI device in the system. A PCI device is selected by a configuration cycle only if IDSEL is high, AD[1:0] are “00″ (indicating a type 0 configuration cycle), and the command placed on the C/BE[3:0]# signals during the address phase is either a “configuration read” or “configuration write”. AD[10:8] may be used to select one of up to eight “functions” within the PCI device. AD[7:2] select individual configuration registers within a device and function.
DEVSEL#
Device Select is driven active low by a PCI target when it detects its address on the PCI bus. DEVSEL# may be driven one, two, or three clocks following the address phase. DEVSEL# must be asserted with or prior to the clock edge in which the TRDY# signal is asserted. Once DEVSEL# has been asserted, it cannot be deasserted until the last data phase has completed, or the target issues a target abort. If the initiator never receives an active DEVSEL# it terminates the transaction in what is termed a master abort.

2.4 Arbitration Pins (Initiator Only)
REQ#
Request is used by a PCI device to request use of the bus. Each PCI device has its own unique REQ# signal. The arbiter in the PCI system receives the REQ# signals from each device. It is important that this signal be tri-stated while RST# is asserted to prevent a system hang. This signal is implemented only be devices capable of being an initiator.
GNT#
Grant indicates that a PCI device’s request to use the bus has been granted. Each PCI device has its own unique GNT# signal from the PCI system arbiter. If a device’s GNT# signal is active during one clock cycle, then the device may begin a transaction in the following clock cycle by asserting the FRAME# signal. This signal is implemented only be devices capable of being an initiator.

2.5 Error Reporting Pins
PERR#
Parity Error is used for reporting data parity errors during all PCI transactions except a “Special Cycle”. PERR# is driven low two clock periods after the data phase with bad parity. It is driven low for a minimum of one clock period. PERR# is shared among all PCI devices and is driven with a tri-state driver. A pull-up resistor ensures the signal is sustained in an inactive state when no device is driving it. After being asserted low, PERR# must be driven high one clock before being tri-stated to restore the signal to its inactive state. This ensures the signal does not remain low in the following cycle because of a slow rise due to the pull-up.
SERR#
System Error is for reporting address parity errors, data parity errors during a Special Cycle, or any other fatal system error. SERR# is shared among all PCI devices and is driven only as an open drain signal (it is driven low or tri-stated by PCI devices, but never driven high). It is activated synchronously to CLK, but when released will float high asynchronously through a pull-up resistor.

2.6 Interrupt Pins
INTA#, INTB#, INTC#, INTD#
Interrupts are driven low by PCI devices to request attention from their device driver software. They are defined as “level sensitive” and are driven low as an open drain signal. Once asserted, the INTx# signals will continue to be asserted by the PCI device until the device driver software clears the pending request. A PCI device that contains only a single function shall use only INTA#. Multi-function devices (such as a combination LAN/modem add-in board) may use multiple INTx# lines. A single function device uses INTA#. A two function device uses INTA# and INTB#, etc. All PCI device drivers must be capable of sharing an interrupt level by chaining with other devices using the interrupt vector.

Read more »

PCI Bus Transactions

3. PCI Bus Transactions
Bus commands indicate to the target the type of transaction the master is requesting. Bus commands are encoded on the C/BE[3:0]# lines during the address phase. PCI bus command encodings and types are listed below, followed by a brief description of each.

C/BE[3:0]#	Command Types
0000	Interrupt Acknowledge
0001	Special Cycle
0010	I/O Read
0011	I/O Write
0100	Reserved
0101	Reserved
0110	Memory Read
0111	Memory Write
1000	Reserved
1001	Reserved
1010	Configuration Read
1011	Configuration Write
1100	Memory Read Multiple
1101	Dual Address Cycle
1110	Memory Read Line
1111	Memory Write and Invalidate

The I/O Read command is used to read data from an agent mapped in I/O Address space. AD[31::00] provide a byte address. All 32 bits must be decoded. The byte enables indicate the size of the transfer and must be consistent with the byte address.
The I/O Write command is used to write data to an agent mapped in I/O Address space. All 32 bits must be decoded. The byte enables indicate the size of the transfer and must be consistent with the byte address.
Reserved commands encoding are reserved for future use. PCI targets must not alias reserved commands with other commands. Target must not respond to reserved encoding. If a reserved encoding is used on the interface, the access typically will be terminated with Master-Abort.
The Memory read command is used to read the data from an agent mapped in the Memory Address Space. The target is free to do an anticipatory read for this command only if it can guarantee that such a read will have no side effects. Furthermore, the target must ensure the coherency (which includes ordering) of any data retained in temporary buffers after this PCI transaction is completed. Such buffers must be invalidated before any synchronization events (e.g. updating an I/O status register or memory flag) are passed through this access path.
The Memory Write command is used to write data to an agent mapped in Memory Address Space. When the target returns “ready,” it has assumed responsibility for the coherency (which includes ordering) of the subject data. This can be done either by implementing this command in a fully synchronous manner, or by insuring any software transparent posting buffer will be flushed before synchronization events (e.g. updating an I/O status register or memory flag) are passed through this access path. This implies that the master is free to create a synchronization event immediately after using this command.
The Configuration Read command is used to read the Configuration Space of each agent. An agent is selected during a configuration access when its IDSEL signal asserted and AD[1::0] are 00. During the address phase of a configuration transaction, AD[7::2] address one of the 64 DWORD registers ( where byte enables address the byte(s) Within each DWORD) in Configuration Space of each device and AD[31::11] or logical don’t cares to the selected agent. AD[10::08] indicate which device of a multi-function agent is being addressed.
The Configuration Write command is used to transfer data to the configuration Space of each agent. Addressing for configuration write transaction is the same for configuration read transactions.
The Memory Read Multiple command semantically identical to the memory Read command except that it additionally indicates that master may intend to fetch more than one cacheline before disconnecting. The memory controller continues pipelining memory requests as long as FRAME# is asserted. This command is intended to be used with bulk sequential data transfer where the memory system (and the requesting master) might gain some performance advantage by sequentially reading ahead one or more additional cacheline(s) when a software transparent buffer is available for temporary storage.
The Dual Address Cycle (DAC) command is used to transfer a 64- bit address to devices that supports the 64-bit addressing when the address is not in the low 4-GB address space. Targets that support only 32 bit address must treat this command as reserved and not respond to the current transaction in any way.
The Memory read line command is semantically identically to the Memory read command except that it additionally indicates that the master intends to fetch a complete cacheline. This command is intended to be used with bulk sequential data transfers where the memory system (and the requesting) might gain some performance advantage by reading up to cacheline boundary in response to the request rather than a single memory cycle. As with the memory read command, pre-fetch buffers must be invalidated before any synchronization events are passed through this access path.
The Memory write and invalidate command is semantically identical to memory write command except that it additionally graduates a minimum transfer of one complete cacheline i.e. the master intend to write all bytes within the addressed cacheline in a single PCI transaction unless interrupted by the target. Note: All byte enables must be asserted during each data phase for this command. The master may allow the transaction to cross a cacheline boundary only if it intends to transfer the entire next line also. This command requires implementation of a configuration register in the master indicating the cacheline size and may only be used with linear burst ordering. It allows a memory performance optimization by invalidation a dirty line in a write-back cache without requiring the actual write-back cycle thus shortening access time.

Read more »

4 PCI Bus Timing Diagrams

4 PCI Bus Timing Diagrams
4.1 Basic Read/Write Transactions
Figure 2 shows the timing of a typical read transaction — one that transfers data from the Target to the Initiator.
Let’s follow it cycle-by-cycle.

Figure 2: Timing diagram for a typical read transaction.

Clock1: The bus is idle and most signals are tri-stated. The master for the upcoming transaction has received its GNT# and detected that the bus is idle so it drives FRAME# high initially.
Clock 2: Address Phase: The master drives FRAME# low and places a target address on the AD bus and a bus command on the C/BE# bus. All targets latch the address and command on the rising edge of clock 2.
Clock 3: The master asserts the appropriate lines of the C/BE# (byte enable) bus and also asserts IRDY# to indicate that it is ready to accept read data from the target. The target that recognizes its address on the AD bus asserts DEVSEL# to acknowledge its selection. This is also a turnaround cycle: In a read transaction, the master drives the AD lines during the address phase and the target drives it during the data phases. Whenever more than one device can drive a PCI bus line, the specification requires a one-clock-cycle turnaround, during which neither device is driving the line, to avoid possible contention that could result in noise spikes and unnecessary power consumption. Turnaround cycles are identified in the timing diagrams by the two circular arrows chasing each other.
Clock 4: The target places data on the AD bus and asserts TRDY#. The master latches the data on the rising edge of clock 4. Data transfer takes place on any clock cycle during which both IRDY# And TRDY# are asserted.
Clock 5: The target deasserts TRDY# indicating that the next data element is not ready to transfer. Nevertheless, the target is required to continue driving the AD bus to prevent it from floating. This is a wait cycle.
Clock 6: The target has placed the next data item on the AD bus and asserted TRDY#. Both IRDY# and TRDY# are asserted so the master latches the data bus.
Clock 7: The master has deasserted IRDY# indicating that it is not ready for the next data element. This is another wait cycle.
Clock 8: The master has reasserted IRDY# and deasserted FRAME# to indicate that this is the last data transfer. In response the target deasserts AD, TRDY# and DEVSEL#. The master deasserts C/BE# and IRDY#. This is a master-initiated termination. The target may also terminate a transaction as we’ll see later.

Figure 3: Timing diagram for a typical write transaction.

Figure 4-3 shows the details of a typical write transaction where data moves from the master to the target. The primary difference between the write transaction and the read transaction detailed in Figure 2 is that write does not require a turnaround cycle between the address and first data phase because the same agent is driving the AD bus for both phases. Thus the master can drive data onto the AD bus during clock 3.

4.2 Transactions Terminations
4.2.1 Master initiated terminations
A transaction is “normally” terminated by the master when it has read or written as much data as it needs to. The master terminates a normal transaction by deasserting FRAME# during the last data phase. There are two circumstances under which a master may be forced to terminate a transaction prematurely
Master Preempted
If another agent requests use of the bus and the current master’s latency timer expires, it must terminate the current transaction and complete it later.
Master Abort
If a master initiates a transaction and does not sense DEVSEL# asserted within four clocks, this means that no target claimed the transaction. This type of termination is called a master abort and usually represents a serious error condition.

Figure 4: Master initiated terminations

4.2.2 Target initiated terminations
There are also several reasons why the target may need to terminate a transaction prematurely. For example, its internal buffers may be full and it is momentarily unable to accept more data. It may be unable to meet the maximum latency requirements of 16 clocks for first word latency or 8 clocks for subsequent word latency. Or it may simply be busy doing something else. The target uses the STOP# signal together with other bus control signals to indicate its need to terminate a transaction. There are three types of target-initiated terminations:
Retry: Termination occurs before any data is transferred. The target is either busy or unable to meet the initial latency requirements and is simply asking the master to try this transaction again later. The target signals retry by asserting STOP# and not asserting TRDY# on the initial data phase.
Disconnect:Once one or more data phases are completed, the target may terminate the transaction because it is unable to meet the subsequent latency requirement of eight clocks. This may occur because a burst crosses a resource boundary or a resource conflict occurs. The target signals disconnect by asserting STOP# with TRDY# either asserted or not.
Target-Abort: This indicates that the target has detected a fatal error condition and will never by able to complete the requested transaction. Data may have been transferred before the Target-Abort is signaled. The target signals Target-Abort by asserting STOP# at the same time as deasserting DEVSEL#.
Retry — The Delayed Transaction
Figure 5 shows the case of a target retry. The target claims the transaction by asserting DEVSEL# but, at the same time, signals that it is not prepared to participate in the transaction at this time by asserting STOP# instead of TRDY#. The master deasserts FRAME# to terminate the transaction with no data transferred. In the case of a retry the master is obligated to retry the exact same transaction at some time in the future.
A common use for the target retry is the delayed transaction. A target that knows it can’t meet the initial latency requirement can “memorize” the transaction by latching the address, command and byte enables and, if a write the write data. The latched transaction is called a Delayed Request. The target immediately issues a retry to the master and begins executing the transaction internally. This allows the bus to be used by other masters while the target is busy.

Figure 5: Target retry.

Later when the master retries the exact same transaction and the target has completed the transaction, the target replies appropriately. The result of completing a Delayed Request produces a Delayed Completion consisting of completion status and data if the request was a read. Bus bridges, particularly bridges to slower expansion buses like ISA, make extensive use of the delayed transaction.
Note that in order for the target to recognize a transaction as the retry of a previous transaction, the master must duplicate the transaction exactly. Specifically, the address, command and byte enable and, if a write the write data, must be the same as when the transaction was originally issued. Otherwise it looks like a new transaction to the target.
Typical targets can handle only one delayed transaction at a time. While a target is busy executing a delayed transaction it must retry all other transaction requests without memorizing them until the current transaction completes.
Note that there is a possibility that another master may execute exactly the same transaction after the target has internally completed a delayed transaction but before the original initiator retries. The target can’t distinguish between two masters issuing the same transaction so it replies to the second master with the Delayed Completion information. When the first master retries, it looks like a new transaction to the target and the process starts over.

Disconnect
The target may terminate a transaction with a Disconnect if it is unable to meet the maximum latency requirements. There are two possibilities — either the target is prepared to execute one last data phase or it is not.

Figure 6: Target disconnect — with data.

If TRDY# is asserted when STOP# is asserted, the target indicates that it is prepared to execute one last data phase. This is called a “Disconnect with data”. There are two cases as shown in Figure 6: Disconnect-A and Disconnect-B. The only difference between the two is the state of IRDY# when STOP# is asserted. In the case of Disconnect-A, IRDY# is not asserted when STOP# is asserted. The master is thus notified that the next transfer will be the last. It deasserts FRAME# on the same clock that it asserts IRDY#.
In Disconnect-B, the final transfer occurs in the same clock when STOP# is sampled asserted. The master deasserts FRAME# but the rules require that IRDY# remain asserted for one more clock. To prevent another data transfer, the target must deassert TRDY#. In both cases the target must not deassert DEVSEL# or STOP# until it detects FRAME# deasserted. The target may resume the transaction later at the point where it left off.

Figure 7: Target disconnect — without data.

If the target asserts STOP# when TRDY# is not asserted, it is telling the initiator that it is not prepared to execute another data phase. This is called a “Disconnect without data”. The initiator responds by deasserting FRAME#. There are two possibilities: either IRDY# is asserted when STOP# is detected or it is not. In the latter case, the initiator must assert IRDY# in the clock cycle where it Deasserts FRAME#. This is illustrated in Figure 4-7. Note that the Disconnect without data looks exactly like a Retry except that one or more data phases have completed.

Target Abort
As shown in Figure 8, Target Abort is distinguished from the previous cases because DEVSEL# is not asserted at the time that STOP# is asserted. Also, unlike the previous cases where the master is invited (or required) to retry or resume the transaction, Target Abort specifically says do not retry this transaction.

Figure 8: Target Abort.

Target Abort typically means that the target has experienced some fatal error condition. The master should probably raise an exception back to its host. One or more data phases may have completed before the target signaled Target Abort.

Read more »

Configuration space decoding

5 Configuration space decoding

PCI defines a third address space in addition to memory and I/O. This is called configuration space and every logical functiongets 256 bytes in this space. A function is selected for configuration space access by asserting the corresponding device’s IDSEL signal together with executing a Configuration Read or Configuration Write bus command.
Configuration Transactions
PCI-based systems require a mechanism that allows software to generate transactions to Configuration space. This mechanism will generally be located in the Host-to-PCI bridge. The specification defines an appropriate mechanism for x86 processors. The x86 configuration mechanism uses two DWORD read/write registers in I/O space. These are:
CONFIG_ADDRESS 0x3f8
CONFIG_DATA 0x3fc
The layout of CONFIG_ADDRESS is shown in Figure 9. Bit 31 is an enable that determines when access to CONFIG_DATA is to be interpreted as a configuration transaction on the PCI bus. When bit 31 is 1, reads and writes to CONFIG_DATA are translated to PCI configuration read and write cycles at the address specified by the contents of CONFIG_ADDRESS. When bit 31 is 0, reads and writes to CONFIG_DATA is simply passed through as PCI I/O reads and writes. Bits 30 to 24 are reserved, read-only, and must return 0 when read. Bits 23 to 16 identify a specific bus segment in the system. Bits 15 to 11 select a device on that segment. Bits 10 to 8 select a function within the device (if the device supports multiple functions). Bits 7 to 2 select a DWORD configuration register within the function. Finally, bits 1 and 0 are reserved, read-only, and must return 0 when read.
CONFIG_ADDRESS can only be accessed as a DWORD. Byte or word accesses to CONFIG_ADDRESS are passed through to the PCI bus.

Figure 9: configuration address.

Configuration Header — Type 0
Of the 256 bytes of configuration space allocated to every function, the first 64 bytes are defined by the specification and are called the Configuration Header. The remaining 192 bytes are available for device-specific configuration functions. Figure 10 shows the layout of the Configuration Header.

Header Type
Currently, three different header types are defined as indicated by the value in byte 0xE (14 decimal). The Type 0 header is for most devices. The Type 1 header describes a bridge device and the Type 2 header describes a PC Card device. In all cases, the first three DWORDS and the Header Type byte of the fourth DWORD are the same. The most significant bit of the Header Type is set to 1 if the device is a multi-function device.

Identification Registers
Several fields in the header are read-only and serve to identify the device along with various operational characteristics.

Figure 10: Type 0 configuration header.

Vendor ID:Identifies the vendor of the device. More specifically, it identifies the vendor of the PCI silicon. Vendor ID codes are assigned by the PCI SIG.
Device ID:Identifies the device. This value is assigned by the vendor.
Revision ID: Assigned by the device vendor to identify the revision level of the device.
Two additional registers allow makers of PCI plug in adapters to identify their devices.
Subsystem Vendor ID:Identifies the vendor of a functional PCI device.
Subsystem Device ID:Assigned by the vendor to identify a functional PCI
device, can also be used to identify individual functions in a multi-function device.
The Class Code is a 24-bit read-only register that identifies the basic function of the device. It is divided into three sections:

Base Class:Defines the basic functional category.
Sub-class:Identifies a device type or implementation within the Base Class. For example, a mass storage controller can be SCSI, IDE, floppy, etc. A network controller can be Ethernet, token ring and so on.
Programming Interface:Defines specific register-level implementations. For most classes this is simply 0, but it is used for IDE controllers and other traditional PC peripherals.
Command Register: The read/writable Command Register provides coarse control over a device’s ability to generate and respond to PCI cycles.
Status Register: The Status Register contains two types of information — Read only bits that convey additional information about a device’s capabilities and read/write bits that track bus related events.
Base Address Registers (BAR): The Base Address Registers provide the mechanism that allows configuration software to determine the memory and I/O resources that a device requires. Once the system topology is determined, configuration software maps all devices into a set of reasonable, non-conflicting address ranges and writes the corresponding starting addresses into the Base Address Registers. The Type 0 configuration header supports up to six Base Address Registers, allowing a device to have up to six independent address ranges.

Read more »

Arbitration process under PCI

6 Arbitration process under PCI:
Since the PCI Bus accommodates multiple masters — any of which could request the use of the bus at any time — there must be a mechanism that allocates use of bus resources in a reasonable way and resolves conflicts among multiple masters wishing to use the bus simultaneously. Fundamentally, this is called bus arbitration.

The Arbitration Process
Before a bus master can execute a PCI transaction, it must request, and be granted, use of the bus. For this purpose, each bus master has a pair of REQ# and GNT# signals connecting it directly to a central arbiter as shown in Figure 11. When a master wishes to use the bus, it asserts its REQ# signal. Sometime later the arbiter will assert the corresponding GNT# indicating that this master is next in line to use the bus.
Only one GNT# signal can be asserted at any instant in time. The master agent who sees his GNT# asserted may initiate a bus transaction when it detects that the bus is idle. The bus idle state is defined as both FRAME# and IRDY# de-asserted. Figure 12 is a timing diagram illustrating how arbitration works when two masters request use of the bus simultaneously.

Figure 11: Arbitration process under PCI.

Figure 12: Timing diagram for arbitration process involving two masters.

Clock

Clock -1. The arbiter detects that device A has asserted its REQ#. No one else
is asserting a REQ# at the moment so the arbiter asserts GNT#-A. In the meantime device B asserts its REQ#.
Clock 2. Device A detects its GNT# asserted, the bus is idle and so it asserts FRAME# to begin its transaction. Device A keeps its REQ#
asserted indicating that it wishes to execute another transaction after this one is complete. Upon detecting REQ#-B asserted, the arbiter
deasserts GNT#- A and asserts GNT#-B.
Clock 3. Device B detects its GNT# asserted but can’t do anything yet because a transaction is in process. Nothing more of interest happens until clock . .
Clock 6. Device B detects that the bus is idle because both FRAME# and IRDY# are deasserted. In response, it asserts FRAME# to start its transaction. It also deasserts its REQ# because it does not need a subsequent transaction.
Clock 7. The arbiter detects REQ#-B deasserted. In response it deasserts GNT#-B and asserts GNT#-A since REQ#-A is still asserted.

Arbitration is “hidden,” meaning that arbitration for the next transaction occurs at the same time as, or in parallel with, the current transaction. So the arbitration process doesn’t take any time. The specification does not stipulate the nature of the arbitration algorithm or how it is to be implemented other than to say that arbitration must be “fair.” This is not to say that there cannot be a relative priority scheme among masters but rather that every master gets a chance at the bus. Note in Figure 12 that even though Device A wants to execute another transaction, he must wait until Device B has executed his transaction.

Bus Parking:
A master device is only allowed to assert its REQ# when it actually needs the bus to execute a transaction. In other words, it is not allowed to continuously assert REQ# in order to monopolize the bus. This violates the low-latency spirit of the PCI spec. On the other hand, the specification does allow the notion of “bus parking.” The arbiter may be designed to “park” the bus on a default master when the bus is idle. This is accomplished by asserting GNT# to the default master when the bus is idle. The agent on whom the bus is parked can initiate a transaction without first asserting REQ#. This saves one clock. While the choice of a default master is up to the system designer, the specification recommends parking on the last master that acquired the bus.

Read more »

Error Detection and Reporting

7. Error Detection and Reporting
Parity Generation & Detection — PAR and PERR#
All bus agents are required to generate even parity over the AD and C/BE# busses. The result of the parity calculation appears on the PAR line. Even parity means that the PAR line is set so that the number of bus lines in the logical 1 state, including PAR, is even. All 32 AD lines are always included in the parity calculation even if they are not being used in the current transaction. This is another reason why the driving agent must always drive all 32 AD lines. All agents are required to have the ability to check parity.
The agent driving the AD bus during any clock phase computes even parity and places the result on the PAR line one clock cycle later. The receiving agent checks the parity and, upon detecting an error, may assert PERR#. So on a read transaction, PAR is driven by the target and PERR# is driven by the initiator. The target then senses PERR# and may take action if appropriate. On a write transaction, the opposite occurs.

Figure 13: Timing diagram for parity generation and detection.

Figure 13 illustrates the timing of parity generation and detection. The key point to note is that one clock cycle is required to generate parity and another is required to check it. Looking at it in more detail:
Clock
Clock 2. Address phase. The selected master places the target address and command on the bus. All targets latch this information.
Clock 3. Turnaround cycle for read transaction. The master places computed parity for the address phase on PAR.
Clock 4. If any agent has detected a parity error in the address phase it asserts SERR# here. This is the first read data phase and also a turnaround cycle for PAR.
Clock 5. Target places computed parity on PAR. Otherwise this is an idle cycle.
Clock 6. Master reports any parity error here by asserting PERR#.
This also happens to be the address phase for the next transaction.
Clocks 7 to 9 illustrate the same process for write transactions. Note that no turnaround is required on either AD or PAR.
Note that because SERR# is open-drain it may require more than one clock cycle to return to the non-asserted state.
Upon detection of a parity error, the agent that is checking parity must set the DETECTED PARITY ERROR bit in its Configuration Status Register. If the PARITY ERROR RESPONSE bit in its Configuration Command Register is a 1, then it asserts PERR#. Any error recovery strategies are the responsibility of the host attached to the agent that detects the error.
Although bus agents are required to generate parity, there is no requirement that they act on a detected parity error. The ability to detect parity errors and take action is controlled by bits in the device’s Configuration Control Register.
System Errors — SERR#
PERR# only reports parity errors during data phases. That is, it is intended to signal an error condition between a specific master/target pair. Parity is also generated and checked during the address phase. But if there is an error on the address bus, any target which detects a parity error during the address phase asserts SERR# and sets the SIGNALLED SYSTEM ERROR bit in its Status Register if the SERR# ENABLE bit in its Command Register is set. SERR# is an open-drain signal so it is permissible for more than one agent to assert it simultaneously.

Read more »

Introduction to PCI protocol

Today’s computer systems, with their emphasis on high resolution graphics, full motion video, high bandwidth networking, and so on, go far beyond the capabilities of the architecture that ushered in the age of the personal computer in 1982. Modern PC systems demand high performance interconnects that also allow devices to be changed or upgraded with a minimum of effort by the end user.

In response to this need, PCI (peripheral component interconnect) has emerged as the dominant mechanism for interconnecting the elements of modern, high performance computer systems. It is a well thought out standard with a number of forward looking features that should keep it relevant well into the next century. Originally conceived as a mechanism for interconnecting peripheral components on a motherboard, PCI has evolved into at least a half dozen different physical implementations directed at specific market segments yet all using the same basic bus protocol. In the form known as Compact PCI, it is having a major impact in the rapidly growing telecommunications market.

PCI offers a number of significant performance and architectural advantages over previous busses:
Speed:The basic PCI protocol can transfer up to 132 Mbytes per second, well over an order of magnitude faster than ISA. Even so, the demand for bandwidth is insatiable. Extensions to the basic protocol yield bandwidths as high as 512 Mbytes per second and development currently under way will push it to a gigabyte.
Configurability:PCI offers the ability to configure a system automatically, relieving the user of the task of system configuration. It could be argued that PCI’s success owes much to the very fact that users need not be aware of it.
Multiple Masters:Prior to PCI, most busses supported only one “master,” the processor. High bandwidth devices could have direct access to memory through a mechanism called DMA (direct memory access) but devices, in general, could not talk to each other. In PCI, any device has the potential to take control of the bus and initiate transactions with any other device.
Reliability:“Hot Plug” and “Hot Swap,” defined respectively for PCI and Compact PCI, offer the ability to replace modules without disrupting a system’s operation. This substantially reduces MTTR (mean time to repair) to yield the necessary degree of up-time required of mission-critical systems such as the telephone network.

PCI Slots and PCI card

1. PCI Protocol
PCI is a synchronous bus architecture with all data transfers being performed relative to a system clock (CLK). The initial PCI specification permitted a maximum clock rate of 33 MHz allowing one bus transfer to be performed every 30 nanoseconds. Later, PCI specification extended the bus definition to support operation at 66 MHz, but the vast majority of today’s personal computers continue to implement a PCI bus that runs at a maximum speed of 33 MHz.
PCI implements a 32-bit multiplexed Address and Data bus (AD[31:0]). It architects a means of supporting a 64-bit data bus through a longer connector slot, but most of today’s personal computers support only 32-bit data transfers through the base 32-bit PCI connector. At 33 MHz, a 32-bit slot supports a maximum data transfer rate of 132 MBytes/sec, and a 64-bit slot supports 264 MBytes/sec.
The multiplexed Address and Data bus allows a reduced pin count on the PCI connector that enables lower cost and smaller package size for PCI components. Typical 32-bit PCI add-in boards use only about 50 signals pins on the PCI connector of which 32 are the multiplexed Address and Data bus. PCI bus cycles are initiated by driving an address onto the AD[31:0] signals during the first clock edge called the address phase. The address phase is signaled by the activation of the FRAME# signal. The next clock edge begins the first of one or more data phases in which data is transferred over the AD[31:0] signals.
In PCI terminology, data is transferred between an initiator which is the bus master, and a target which is the bus slave. The initiator drives the C/BE[3:0]# signals during the address phase to signal the type of transfer (memory read, memory write, I/O read, I/O write, etc.). During data phases the C/BE[3:0]# signals serve as byte enable to indicate which data bytes are valid. Both the initiator and target may insert wait states into the data transfer by deasserting the IRDY# and TRDY# signals. Valid data transfers occur on each clock edge in which both IRDY# and TRDY# are asserted.
A PCI bus transfer consists of one address phase and any number of data phases. I/O operations that access registers within PCI targets typically have only a single data phase. Memory transfers that move blocks of data consist of multiple data phases that read or write multiple consecutive memory locations. Both the initiator and target may terminate a bus transfer sequence at any time. The initiator signals completion of the bus transfer by deasserting the FRAME# signal during the last data phase. A target may terminate a bus transfer by asserting the STOP# signal. When the initiator detects an active STOP# signal, it must terminate the current bus transfer and re-arbitrate for the bus before continuing. If STOP# is asserted without any data phases completing, the target has issued a retry. If STOP# is asserted after one or more data phases have successfully completed, the target has issued a disconnect.
Initiators arbitrate for ownership of the bus by asserting a REQ# signal to a central arbiter. The arbiter grants ownership of the bus by asserting the GNT# signal. REQ# and GNT# are unique on a per slot basis allowing the arbiter to implement a bus fairness algorithm. Arbitration in PCI is “hidden” in the sense that it does not consume clock cycles. The current initiator’s bus transfers are overlapped with the arbitration process that determines the next owner of the bus.
PCI supports a rigorous auto configuration mechanism. Each PCI device includes a set of configuration registers that allow identification of the type of device (SCSI, video, Ethernet, etc.) and the company that produced it. Other registers allow configuration of the device’s I/O addresses, memory addresses, interrupt levels, etc.
Although it is not widely implemented, PCI supports 64-bit addressing. Unlike the 64-bit data bus option which requires a longer connector with additional 32-bits of data signals, 64-bit addressing can be supported through the base 32-bit connector. Dual Address Cycles are issued in which the low order 32-bits of the address are driven onto the AD[31:0] signals during the first address phase, and the high order 32-bits of the address (if non-zero) are driven onto the AD[31:0] signals during a second address phase. The remainder of the transfer continues like a normal bus transfer.
PCI defines support for both 5 Volt and 3.3 Volt signaling levels. The PCI connector defines pin locations for both the 5 Volt and 3.3 Volt levels. However, most early PCI systems were 5 Volt only, and did not provide active power on the 3.3 Volt connector pins. Over time more use of the 3.3 Volt interface is expected, but add-in boards which must work in older legacy systems are restricted to using only the 5 Volt supply. A “keying” scheme is implemented in the PCI connectors to prevent inserting an add-in board into a system with incompatible supply voltage.
Although used most extensively in PC compatible systems, the PCI bus architecture is processor independent. PCI signal definitions are generic allowing the bus to be used in systems based on other processor families. PCI includes strict specifications to ensure the signal quality required for operation at 33 and 66 MHz. Components and add-in boards must include unique bus drivers that are specifically designed for use in a PCI bus environment. Typical TTL devices used in previous bus implementations such as ISA and EISA are not compliant with the requirements of PCI. This restriction along with the high bus speed dictates that most PCI devices are implemented as custom ASICs.
The higher speed of PCI limits the number of expansion slots on a single bus to no more than 3 or 4, as compared to 6 or 7 for earlier bus architectures. To permit expansion buses with more than 3 or 4 slots, the PCI SIG has defined a PCI-to-PCI Bridge mechanism. PCI-to-PCI Bridges are ASICs that electrically isolate two PCI buses while allowing bus transfers to be forwarded from one bus to another. Each bridge device has a “primary” PCI bus and a “secondary” PCI bus. Multiple bridge devices may be cascaded to create a system with many PCI buses.
Chapters: