An FPGA-Based PCI Bus Interface

The design of a Logic Innovations PCI bus interface began with a comparison of available FPGAs.

By Frank Creede and Erick Cook

A possible solution to interface to the PCI bus could be a dedicated bus interface chip. This solution leaves logic designers with another problem; however, the need to resort to a second chip for the custom interface necessary for different applications at the back-end of the interface, whether it's a high-speed SCSI, Ethernet, or video controller, for example. A second device was what we wanted to avoid.

The end-product we designed is a fast PCI target that receives data directly over the PCI bus from an SCSI master device without CPU intervention. The SCSI master takes data off a four gigabyte disk drive and transfers it to our PCI target, which queues the data up into a local 128 kbyte synchronous SRAM, serializes it, and transmits it serially at up to 45 Mbits per second.

Custom/user interface logic for this application includes a controller for the dual-ported synchronous SRAM, and a 32-bit shift register that takes data from the SRAM and sends serial data out at up to 45 Mbits per second. A variety of different state machines and holding registers comprise the SRAM controller implementation.

We considered a PCI interface chip, gate array, and FPGA implementations at the outset. We ruled out the PCI interface chip immediately because we needed to integrate both the PCI bus interface and custom back-end user logic on the same chip. A PCI interface device would require both the device itself and an additional FPGA or significant additional logic to complete our intended function; this would prove to be too costly in both the short and long term. A cost-reduced version at a later date would not be possible.

Gate array propagation delays were certainly enticing, but the time-to-market and the inherent risk of having to re-do the design forced us to axe this approach.

We didn't consider small FPGAs or mega-PALs since at best only the PCI interface would fit within a single part. We would still require an additional device for our custom application circuitry. A mega-PAL design would undoubtedly yield a costly, multiple device implementation similar to the PCI interface chip and without an easy path for cost reduction.

There were three reasons why we felt large FPGAs offered the best solution. First, a PCI bus VHDL source design was available at low cost. Second, of the three approaches it had the fastest time-to-market. Third, a large-scale FPGA can be easily converted to a "hard array" or ASIC at a later date for a final cost-effective solution.

An FPGA also made debugging easier, faster, and more convenient. This is especially true at the internal level, since you can easily access internal logic by using an analyzer to look at signals routed out to external pins.

But the real beauty of using a high-density FPGA is you can design the PCI bus interface and custom circuitry all on the same chip. By doing so, a direct connection is made to the PCI bus without having to go through a local bus (see "FPGAs Lay Foundation for Customized PCI Interface" on page 32 of the August 1994 issue of ASIC & EDA ).

In our case, we opted for the AT&T Microelectronics (Allentown, PA) ORCA 2C15, a 15 kgate device, to design a PCI bus interface and custom interface logic using a VHDL implementation. We used only 35 percent of the chip for the PCI bus interface, leaving the remaining silicon for the custom interface.

The first step in our design methodology was to evaluate component candidates. This was a critical point for two major reasons: determining whether a chip's circuitry could accommodate the PCI bus interface and then have enough left over for a custom interface, and letting us know right away what design tools we'd be using.

In our case, we needed an FPGA that would allow a high-level design methodology such as VHDL. That criterion alone quickly eliminated some of the candidates implemented in such environments as PALASM or ABEL (see Table 1).

The next step in our methodology was creating the architecture for the datapaths and clearly targeting the PCI bus AC and DC requirements (current drive, loading, setup, hold, and I/V characteristics). That told us what connectivity our device would need to have with the PCI bus so that we could do our PCI bus compliance analysis. This necessitated a detailed comparison of the PCI bus component electrical checklist to the FPGA vendor's data sheets.

We then implemented the control structure and verified it against the PCI bus component protocol checklist. Our final step was implementing the user interface logic.

Evaluation process The component evaluation chart (Table 1) details the specific process used to select the PCI bus compliant FPGA essential to our design. Key questions included:

* Is the 15 kgate device available?

* Is it fast enough to meet setup
and hold and clock to output 
delay times on the PCI bus?

* Will it actually operate at the PCI bus specified clock rate of 
33MHz? 

* Does it meet PCI drive requirements, I/V curves, and 
capacitive load requirements?

* Will both PCI bus interface and custom user logic fit into 
the device?

* How routable is it? If we used up to 60 percent of the
gates, 
for example, could we route those signals and get the PCI 
bus specified performance?

* Will our development tools support the device?

* Will our final implementation be re-usable? What portions 
of this design can we carve out and use in future projects?

In particular, we needed assurance that the FPGA met the clock to output delay time of 11ns. This critical delay is the sum of the primary clock delay (CLK-DEL) of 5ns and the PFU clock to Pad Delay (DOUT-DEL(f)) of 5.7ns. We used a direct output of the 2C15 device's programmable function unit (PFU) directly out through the programmable input/output cell (PIC) to the pin, to meet the clock to output delay requirement of 11ns. The 2C15 met this key requirement (at 10.7ns), as well as all other PCI bus requirements.

The XC4010-4 failed the clock-to-output delay time, revealing a total delay of 13ns. Although its routability and repeatability were favorable, it failed to operate at the PCI bus-specified clock frequency of 33MHz, on-to-off chip. We questioned viability of the XC4010-4 and XC3195A meeting our PCI bus requirements as the capacitive load is 15pF, and this violates PCI specification maximum of 10pF.

Figure 1. The synthesizable PCI core can be combined with user defined logic to begin the process. Although Exemplar Logic tools were used, other vendors' tools could have been used as well.

The Intel FX8160 was fast enough; however, it was not large enough to hold both the PCI bus interface and our application specific logic.

PCI bus interface design Our PCI bus interface design was based on the 2C15 device and used 140 programmable function units (PFUs), or about 35 percent of the 400 available PFUs. In accordance with the PCI bus specification, our configuration space registers were device and vendor IDs, command register and status registers, class code, revision ID, memory base address, I/O base address, interrupt line, and interrupt pin.

Placement and routing of an FPGA is as important as its data sheet characteristics when determining whether it meets the PCI bus specification. With the NeoCAD (Boulder, CO) router we used with our PCI core, we specified the pin numbers and which registers needed to be placed next to those pins. The NeoCAD tools provided good placement and excellent routing.

As with all PCI bus signals, the C/BE[3::0]#, command/byte enable signal comes in from the bus and goes directly into a register because time is not available to go through logic. Due to setup time requirements, the signals are only on the bus 7ns before the rising edge of the clock. Our device had to meet this setup time requirement.

The registered version of C/BE[3::0]# goes into the XOR with outputs of the read data parity generator and byte enables, and then into an output register. The PCI bus specification requires data parity generation which calls for byte enables in that calculation. Byte enables define the type of command being performed on the bus.

Signals from the actual address/data bus, AD[31::0], on the PCI bus, come into an input register and then convert to ADIR[31::0] at the output. Read address and data parity checking are performed on the bus data. ADIR[31::0] is then routed internally to the configuration registers: memory base address, I/O space base address, interrupt line, and PCI command. These registers are written during configuration cycles, but are all readable, as well, per the PCI bus specifications.

During normal cycles, addresses are compared against base address registers. The result is either a memory or I/O hit to an access if it falls within the address range of the PCI target board. A read back multiplexer is used to select several sources, including configuration register and memory, etc. for presenting output data to the PCI bus.

The output register to the local bus and input register from the local bus would normally not go to pins, and instead would be used internally. In this example, they are used within the FPGA to hook up to local data buses.

The clock (CLK) and reset (RST#) signals from the PCI bus are brought into the PCI control generation block directly. Also, FRAME# and IRDY# signals go into the bus state tracker, while TRDY#, STOP#, and DEVSEL# signals enter the target ready cycle termination device selected. As with all PCI bus signals in this design, each signal represents one pin, one load to the PCI bus.

The frame bus signal (FRAME#) is an active low framing indicator. It indicates that the bus is active and whether or not it's doing a burst. The falling edge of the frame indicates the start of an address phase and then the bus conventions take over from there. I-ready (IRDY#) indicates whether data is on the bus during writes and whether the target is ready to accept read data during reads.

The initiator presents the address. The PCI target then has to present read data or accept write data. There's a turnaround cycle, for example, on read data to eliminate bus contention. That's one example where the framing indicator is used. Another is to indicate the start of the cycle and also whether a burst is in progress. As long as the frame is low and both readies are on, a burst occurs on every clock.

The I-ready signal then indicates the initiator either is ready to accept data on reads or has placed valid write data on the PCI AD pins. The T-ready (TRDY#), or target ready indicator, shows whether the target is ready to accept write data or whether it's ready to present read data onto the AD[31::0] lines.

PCI control logic accepts signals from the bus, including the 33MHz clock line. The system master can stop that clock or take clocks out if it wants.

Stop tells the initiator to terminate a burst. There are different ways to do that, such as target disconnect or target abort. There are combinations of all four signals: FRAME#, IRDY#, TRDY#, and STOP#. Therefore, different cases involving these signals need to be analyzed and properly handled when doing a PCI bus design.

Device select (DEVSEL#) line indicates back to the initiator that responsibility has been accepted for terminating the bus cycle that's in process. It is a bus cycle that hits in the base address register, in the memory, or the I/O base address registers.

Device select line also indicates that the address being placed on the bus has been accepted. In other words, the target drives that line low after it has been decoded and determines that the address falls within the address ranges set by the base address registers.

At the top of the PCI control generation block, there are controls for the different datapaths. This block controls the output enables and select inputs into multiplexers or enables. For example, on the bus address registers, there is a clock enable which is controlled by a flip-flop in the control generation block.

By eliminating clock gating, we were able to do a fully synchronous design. Instead, there is a flip-flop with an enable pin on it. We did that throughout our VHDL design so that clocks don't need to be gated.

Inside the control unit is a bus state tracker that monitors the state of FRAME# and IRDY#. It's used to time the assertion of TRDY#. Signals are received from the local side stating that data is present and that it can be sent to the bus, or that data coming from the bus is ready to be accepted. This generates TRDY# and/or STOP#.

If no further data can be accepted or if enough is present, a disconnect can occur. A few clocks later, the bus state tracker will again be ready to accept the data. If TRDY# is not present, the data will be erroneous. The cycle then undergoes a target abort to terminate the application. The last data transfer is deterministic, however, and data leaves the bus in a known state.

A PCI bus requirement is that all functions hooked to the bus must monitor the bus to assure it doesn't interfere with operations of other bus cycles. That also makes certain it doesn't generate bus cycles which are not valid or not compliant with the specification.

VHDL Implementation Figure 1 shows our VHDL design flow. The Logic Innovations synthesizable PCI core (VHDL source) can be combined with additional user-specific logic to allow customization as required for a PCI application. User-specific logic can also be implemented in schematic capture and then linked with the PCI core.

Functional and timing simulation that permits making modifications to the PCI core is then performed with a set of test vectors Logic Innovations makes available. A PCI test suite is also available for the logic designer to tailor the simulation of the PCI bus to the user's custom interface logic.

After completion of the source code, the design then undergoes logic synthesis. We used tools from Exemplar Logic (Berkeley, CA); however, tools from Synopsys .com/isdweb/&lf=isd-sendtolog"> Synopsys (Mountain View, CA) or other vendors could have been used as well. The netlist of the VHDL source's logical interconnection was produced and entered into placement and routing using NeoCAD, and then into a bitstream generator. As mentioned earlier, the NeoCAD tools provided the best compromise between placement and routing, and was chosen for place and route.

Timing back-annotation includes the compilation of a database involving routed timings, logic delays, and internal routing delays. The result goes back into timing simulation. The objective here is to use the same set of test vectors for functional and timing simulation.

It works We have shown the evaluation process among different possible solutions to our PCI bus interface needs. Once this evaluation was finished, we then showed how we implemented both the PCI bus interface and the back-end product into a single FPGA, the AT&T ORCA 2C15. The final step in this process was system prove-in, which has provided us with a working device in a timely manner, with the device currently functioning in PCI bus applications. One of these is a high-speed server video application, rapidly pulling compacted data off a disc.

Frank Creede is president of Logic Innovations (San Diego, CA). Erick Cooke is Logic Innovations' vice president.

Table 1
A comparison of PCI bus interface ICs based on vendor-supplied specifications current as of October 1994
Vendor	Device	Availability	Denisty	Routability	Technology	PCI VHDL Availability	Tools	Input Setup Time (7ns)	Input Hold Time (0ns)	V/I Specs	CIN (10pF max)	Frequency (33 MHz)	Data to Bus Valid(11ns)
AT&T	ATT2C15-3	yes (4k-26k gates)	very large	good	SRAM	yes Neocad	VHDL,	4.7ns	Ons	yes	yes	yes	10.7ns*
Cypress	CY7C386A	yes	medium	good	Antifuse	no	Warp3 VHDL	1.6ns	Ons	maybe	20pF	yes	8ns*
Cypress	CY7C388A	Q1 95	large	good	Antifuse	no	Warp3 VHDL	1.6ns	Ons	yes	10pF	yes	8ns*
Xilinx	XC3195	yes	large	poor	SRAM	no	VHDL, XACT	4.7ns	-	maybe	10pF	maybe	10ns
Altera	FX8160	samples 10/94	small	poor	Mega-PAL	no	PLDShell, Viewlogic , Mentor ,Cadence	6ns	Ons	yes	yes	yes	6ns*
Altera	EPF8452A-3	Q1 95	medium	fair	Mega-PAL	no	Max Plus	4.6ns	5.4ns	maybe	-	maybe	10ns
Altera	EPM7192E-10	yes	small	fair	Mega-PAL	no	Max Plus	8ns	Ons	maybe	12pF	yes	7ns
Lattice	iSPLS13256	Q4 94	medium	fair	Mega-Pal	no	pPDS	9ns	-1ns	maybe	-	yes	8ns
Cypress	CY7C375-7	yes	small	good	Antifuse	no	Warp3 VHDL	7ns	Ons	maybe	12pF	yes	7ns
Xilinx	XC4010-4	yes	large	good	SRAM	no	VHDL,XACT	12ns	Ons	prob. not	15pF	yes	13ns
Actel	A144o1-1	yes	medium	good	Antifuse	no	VHDL,ALS, Viewlogic	3ns	Ons	no spec	-	maybe	10.7ns
Xilinx	73000	yes	small	good	SRAM	no	XACT	5ns	Ons	yes	yes	yes	10ns
Intel	FX780	yes	small	poor	Mega-PAL	no	PLDShell, Viewlogic	6ns	Ons	yes	-	yes	6ns
AMD	MACH4	yes	medium	fair	Mega-PAL	no	MACHXL,ABEL	10ns	Ons	yes	yes	yes	10ns
QuickLogic	QL16X24B	yes	small	good	Antifuse	no	pASIC VHDL	7ns	Ons	mabye	12pF	yes	7ns

To voice an opinion on this or any Integrated System Design article, please e-mail your message to: michael@asic.com.

integrated system design  April 1995