PCI Bus Target Controller Implementation Using a Lattice ispLSI CPLD

By Bertrand Leigh, Applications Manager, Lattice Semiconductor ("http://i.cmpnet.com/chipcenter/pld/bertrand_leigh@latticesemi.com")

Introduction
The Peripheral Component Interconnect (PCI) Local bus is a high bandwidth bus that provides a data path between the CPU and multiple high performance peripherals. Proposed as a total system solution, PCI provides interconnects to networks, disk drives, video and other high-speed peripherals. Processor independence allows the PCI bus to be optimized for I/O functions and enables concurrent operation of the local bus with the processor/memory subsystem. A 32-bit synchronous bus that provides data throughput of 132Mbytes/second, the PCI bus is expandable up to a 64-bit data path, which doubles the throughput. On account of its futuristic processor independent orientation, PCI allows manufacturers to significantly trim development costs by not having to completely redesign every product cycle.

This ties in elegantly with Lattice Semiconductor's ispLSI device families that are designed to implement high-integration functions, such as controllers, while delivering superior performance and the flexibility of In-System Programmability (ISPı). Basic PCI-compliant Master/Target state machines can be implemented in an ispLSI device, while the remaining glue logic can be modeled around a given peripheral/processor. The options become enormous when one has the ability to change the functionality of devices already soldered on the board. ISP continues to emerge as the design methodology of choice by providing reconfigurable systems with diagnostic capabilities, field upgradability and simplification of manufacturing flow.

PCI flexibility brings with it new design challenges for the system designer. This application note presents a Target-PCI interface design implemented in an ispLSI 2128E device. This application can also be implemented in the Lattice ispLSI 8000 device family.

Source code containing the basic PCI-compliant State machine is available from your local Lattice Field Applications Engineer or by e-mail from the Lattice Applications Engineering Group at ispgenapps@latticesemi.com or applications@latticesemi.com. This code is intended to be used as a guideline for basing a PCI bridge design on a specific interface.

PCI/Lattice ispLSI Interface
The following section presents the PCI interface based on the PCI Local Bus Specifications, Revision 2.1. A concise overview of the PCI bus and ispLSI architecture and the relevant electrical and timing characteristics are discussed. The Lattice Semiconductor Data Book or CD-ROM and the PCI Specification should be consulted to obtain more detailed information.

PCI Overview
PCI bus is a non-proprietary local bus solution, providing increased performance for Graphical User Interfaces and other high bandwidth functions such as SCSI, full motion video, LANs etc. The processor/memory subsystem is connected to PCI through a bridge, which provides a low latency path for the agent to directly access the PCI devices mapped onto the processor address space. The PCI specification defines both a Master and Target bridge implementation. Both can be implemented in one device, however each has to have an independent controller state machine. A minimum of 47 pins is needed for a Target only device and 49 pins for a Master.

PCI specification provides for both 5V and 3.3V signaling environments, but all components in a PCI design must use the same signaling environment. The PCI bus is a COMS bus, i.e., steady state currents are minimal (after transients have died out), with most of the current spent on pull-up resistors. PCI is based on reflective wave signaling, rather than incident wave, which implies that the bus drivers have to switch the bus halfway to the required high or low voltage. The fact that the bus is unterminated causes the reflected wave at the unterminated end of the transmission line to add to the incident wave to achieve the required voltage level. The PCI specification dictates that pins used for extended data path (64-bit) such as high order AD lines, C/BE lines and PAR (64-bit extension parity) have pull-ups in order to prevent oscillation or high power drain through the input buffer. In addition, the inputs are required to be clamped to ground.

Lattice ispLSI Overview
The Lattice ispLSI device families are ideally suited to high-speed controller, state machine intensive applications. Taking advantage of in-system programmability, wide input gating (18 input/20 product terms per register), hardware XOR gates on each register, low skew, input clamps and high speed, ispLSI devices are ideal for high performance PCI bridge implementation. The ispLSI device families have programmable pull-up resistors that may be used instead of the external resistors, saving board space. The ispLSI devices have an input clamp that turns on at -1.0v VIN. These clamps exist on each of the dedicated inputs and I/Os. In addition, the ispLSI devices are capable of operating under conditions of "excessive" overshoot or undershoot. The ispLSI 2000E Family, in particular, is PCI compatible and offers both 5V and 3.3V PCI compatible I/Os, making these devices more suitable for the PCI bridge implementation. Finally, with respect to input capacitance, the PCI specification stipulates that input capacitance should not exceed 10pF for an input pin and 12pF for the clock and I/O pin. With the input capacitance of Lattice ispLSI devices specified at 8pf and 10pF for inputs and I/Os respectively, an ispLSI single chip local bus solution meets the PCI loading specification.

PCI Timing Requirements
The PCI specification provides strict timing requirements in terms of setup time (7ns minimum) and tco (2ns minimum and 11ns maximum). The Lattice ispLSI 2128E has a minimum set up time of 4ns on the inputs and maximum tco of 3.5ns. Figures 1a and 1b show the VI characteristics of the ispLSI 2128E.

Fig1a. Vol Vs Iol (Vccio = 5v)

Fig1b. Voh Vs Ioh (Vccio = 5v)

PCI Target Controller Logic Implementation
This section briefly describes the implementation of the Target controller state machine. Expected waveforms and simulation results are provided for both read and write cycles in Appendix A. This design implementation is for reference purposes only, and may have to be modified to support specific design requirements. Lattice has made attempts for the design to be consistant with the specification. It is the user's responsibility to verify the final design's consistency to the specification.

Table 1. PCI Bus Interface Signals

Table 2. User Interface Signals

Figures 2 and 3 show the block diagram and the state machine for the PCI target controller. The following assumptions are made for the Back-end/Target device:

• The back-end device always acts as target and responds to the PCI host (PCI master).
• Assertion of the "usrreq" signal by the target controller indicates that the PCI host is requesting the beginning of a transaction.
• The back-end target device responds to "usrreq" by asserting a "usrgnt" signal, which means that the back-end target is willing to perform the read/write cycle requested by the PCI master.
• The PCI target controller device asserts the "datareq" signal, which indicates that valid data is present on the data bus in the case of a Write operation. The back-end target latches the data present on the PCI bus and asserts "dataack".
• In the case of a read cycle, assertion of the "datareq" signal means that the back-end device can put valid data on the PCI bus. The back-end device responds to it and puts valid data on the PCI bus and asserts "dataack".
• The back-end device is fully functional at 33MHz (PCI clock).
• The back-end device latches the address and data on the following rising edge of the clock cycle.

• Burst reads and burst writes
• Typically, burst length of 4
• Handles single data phase
• Takes care of wait states introduced both by the target device (user device) as well as initiator (PCI master)

Signal Description
Table 1 describes the PCI bus interface signals of the controller device. Table 2 provides descriptions of the User interface signals of the controller device.

Figure 2. Target Interface Controller Block Diagram

State Machine
When a PCI host/master intends to do a read/write cycle, it asserts a frame signal, drives the address on its AD bus (pciad) and drives the type of transaction on the C/BE # bus (here it is pcicbe). The address and the command that indicates the type of cycle are present for only one clock cycle. The target interface controller latches this address as soon as it sees a frame asserted and goes from the IDLE state to the ADDR state where it compares the latched addressed with its own address range. If the latched

Fig 3. Target Interface Controller State Machine.

address is within the address range, or if idsel is asserted, then it goes into the USR_REQ state and asserts devsel, usrreq and puts a valid address on usraddr bus. The target interface controller decodes the command and drives the w_r high (write cycle) or low (read cycle). Asserting the devsel indicates that the PCI master has recognized the address and will participate in the initiated transaction. Assertion of usrreq is an indication for the back-end target device that it is being addressed. The back-end device indicates its acceptance by asserting usrgnt. The target interface controller goes into the USR_GNT state after it sees usrgnt asserted. It remains in the USR_GNT State until the master indicates that it is ready for the data transfer which it does by asserting the irdy. The target interface controller goes to the DATA_REQ State as soon as it sees that the irdy is ready and asserts the datareq signal to the back-end device. The back-end device asserts the dataack signal, which indicates to the target controller that it drove valid data on the PCI AD bus (for a read cycle) or accepts the data present on the AD bus (for a write cycle). With the assertion of the dataack signal, the target controller goes into the DATA_ACK State and asserts trdy. Assertion of trdy indicates to the PCI host that valid data is present on the AD bus (for a read cycle) or it has accepted the data that is present on the AD bus (for a write cycle). If the initiator/master de-asserts its irdy during the transactions, the state machine goes into the WAIT_STATE and waits there until it sees irdy asserted, at which point it starts driving/accepting the data on the AD bus. Once the target sees the frame de-asserted or a usrstop signal asserted when in the DATA_ACK State, it goes into the EOT State and de-asserts its trdy and devsel before going into the IDLE state.

Conclusion
This controller logic was fit into an ispLSI 2128E (165MHz) device. The post-fit report file shows the implementation in three levels of GLB. This implementation made use of 118 macrocells with a maximum GLB utilization of 96%. A master interface controller state machine can easily replace the target implementation in the same device. The SuperFASTı ispLSI 2128E device at 165MHz operating frequency and four levels of GLB can still meet the speed requirements of the 33MHz clock requirements, provided that data is transferred on and off the PCI bus with pipelined registers.

With the popularity of non-proprietary, high performance and extremely flexible local bus, it is not surprising that designers are looking to programmable logic to meet the challenges offered by PCI. Low volume manufacturers avoid NRE and ASIC design by using programmable logic to obtain an efficient and cost-effective solution. While the sample design in this application note is specific enough to cover the required PCI protocol, it is adaptable and can be molded around any given peripheral of processor. In fact, it can even be reconfigured in the system from one peripheral to another, as long as the hardware interface provides this flexibility. Additional features can always be added either in the same device or using a larger ispLSI device such as the ispLSI 8840 which is also PCI compatible. This would make a plug-and-play based PCI solution feasible with some external memory used as the configuration space.

Appendix
Simulated Waveforms. (click the image to view the full-sized image)
1. Read Cycle With Burst Length =4

2. Write Cycle of Burst Length = 4.

3. Read Cycle with Initiator Introduced wait States

4.Write Cycle of Burst Length =2.