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

1. 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#.
2. 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.
3. 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 . .
4. 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.
5. 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:

1. Introduction to PCI protocol
2. PCI Signal Descriptions
3. PCI Bus Transactions
4. PCI Bus Timing Diagrams
5. Configuration space decoding
6. Arbitration process under PCI
7. Error Detection and Reporting

Read more »

Format Short Message Service

At command for communications with SMS-CENTER.
At hand phone GSM there is facility to data access applies serial connection, for data access is required by instruction sequence at interface hand phone. ETSI (European Telecommunication Standard Institute) that is the instruction standard in technical specification GSM. instruction phone is started with character AT and terminated with enter or 0Dh. Command received will be response with receiving of data ‘OK’ or ‘ Errors’. Applying AT Command important for SMS is:
AT+CMGS : to send SMS
AT+CMGL : to verify SMS
AT+CMGD : to vanish SMS
AT COMMAND for SMS usually followed by I/O started by units PDU. Streaming data or from SMS-CENTER must be in the form of PDU (Protocol Data Unit). PDU contains hexadecimal number what express language I/O. PDU consisted of some Header. Header to send SMS to SMS-CENTER differs from SMS received from SMS-CENTER. PDU send SMS to SMS-CENTER. There is eight header to send SMS, that is:
1. Number SMS CENTER
This first header divided to become three sub header
a. Number of couples hexa decimal SMS-CENTER in number hexa.
b. International Code and national code, header for national it is 81 and international is 91.
c. Number SMS-CENTER itself in couple hexa is turned over repeatedly.
example:
if number SMS-CENTER 0875400000
hence, writing national.
for writing of Heksa from SMS-CENTER 0875400000 becoming –>
80-57-04-00-00
so that writing as complete this is:
06818057040000 ==> value 06 showing there is 6 value tide
that is Code National(1 tide) + number SMS-CENTER(5 tide).
writing international
for writing of Hexsa from SMS-CENTER 62875400000 becoming –>
26-78-45-00-00-F0
so that writing as complete his is:
07912678450000F0 ==> value 07 showing there is 7 tide value that is Code International(1 tide) + number SMS-CENTER(6 tide).
2. Type SMS
Type AS OF neodymium SMS : 1 thus its a hexsa number is 01.
3. Number Reference SMS
Reference number gives value 0, causing the heksa value 00. Because later automatically will be given value by SMS-GATEWAY
4. Number Phone Acceptor
Writing of PDU at writing of phone number as follows:
a. Number of number decimal phone numbers gone to in number hexsa.
b. National or international Code. For National with code: 81. And international with code: 91
c. Number phone gone to in couple heksa is turned over repeatedly.
Example:
If phone number gone to be 081227153432.
For National Code :
at number gone to National is 081227153432 ==> the numbers 12 numbers ==> value hexsa 0C, and couple heksa from phone number gone to 80-21-72-51-43-23, hence writing is : 0C81802172514323
For International Code:
at number gone to International is 6281227153432 ==> number of numbers there are 13 numbers ==> value heksa 0D, and couple hexsa from phone number gone to 26-18-22-17-35-34-F2, hence writing it is : 0D91261822173534F2
5. form of SMS
0 ==> 00 –> SMS is sent in the form of SMS.
1 ==> 01 –> SMS is sent in the form of telex.
2 ==> 02 –> SMS is sent in the form of fax.
6.Scheme Encoding Data I/o
This time there are many the SMS Gateway in marketing applies 7 bit so that we apply code : 00, if there are still SMS Gateway which applies code bigger than 0 changed to Hexsa.
7. Duration Before SMS EXPIRED
If part of this skip, meant we are to derestricted time implementation of SMS.
8. Contents Of SMS
at part contents of SMS there are two sub Header.
a. Bulk length or number of contents of SMS
for example: to say ” Hi..” ==> there is 5 letter –> 05
b. Contents of in the form of number pair heksa phone or SMS-GATEWAY is having scheme encoding 7 bit to mean if we are etic a letter from key pad we make 7 successive I/O number, applies convertion ASCII to Heksa can. Or applies convertion itself that is:
first step : changes it becomes code 7 bit.
second step : changes code 7 bit to become 8 bit, what represented by couple hexsa.
so conclusion from writing of this PDU by writing down all sequences as follows :
Number SMS-CENTER – Type SMS – Reference number SMS – Number phone acceptor – Form Of SMS – Scheme Encoding Data I/O – duration before SMS expired – Contents Of SMS

Read more »