Design Feature: August 15, 1996

The PCI bus is perhaps today's most popular high-performance bus, finding use in many PCs and workstations plus a myriad other closed and open systems. The bus comes in a number of variations, such as CompactPCI, that target specific markets (Reference 1). However, designing for 33-MHz PCI taxes most PLDs to their limits. Nevertheless, manufacturers and designers of PLDs, including complex PLDs and FPGAs, using the 33-MHz PCI bus are stepping up to the design challenge of using PLDs for 33-MHz PCI designs. These features include operation from 0 to 33 MHz, a 32-bit data width and burst-mode transfers that let you potentially transfer data as fast as 132 Mbytes/sec. (A 64-bit-wide version doubles that data rate.) A 66-MHz version of PCI doubles the performance again and places it well beyond the capabilities of today's PLDs.

When considering programmable logic for PCI, first consider the alternatives: standard or custom chips. Many companies provide standard PCI-interface chips that may fit your needs. However, many designers don't use these devices because they can't find exactly what they need in a standard PCI chip (see box, "Why not use standard chips?"). In that case, designers have to use custom designs: mask-programmed ASICs, which find extensive use in high-volume applications, or programmable logic. Mask-programmed ASICs make sense from both cost and performance standpoints. ASICs are also attractive for PCI interfaces that connect to back-end applications requiring high gate counts. Even with the high gate counts available on some of today's PLDs, ASICs can offer more gates. However, many users cannot justify ASICs' NRE costs or longer design time.

Programmable logic, on the other hand, makes sense for lower volumes, and it provides shorter time to market and lower cost. Eliminating the NRE cost and avoiding the need to make large production commitments make PLDs an attractive choice for PCI applications compared with ASICs, but there is more to consider, according to Raj Raghavan, president of Virtual Chips (San Jose, CA), which provides two dozen PCI cores for ASIC applications. Raghavan cautions designers that they must fully understand PCI before they can make it work with FPGAs.

"Ironically, the most sophisticated customers are in the ASIC world," says Raghavan, "and they really don't have to be that sophisticated. The tools are there, and the processes are there. You can pretty much insulate the customer."

Yet another alternative to masked-programmed ASICs and standard PLDs are laser-programmed devices from such companies as Chip Express. The devices offer masked-gate-array speeds, gate densities as high as 200,000, one- to five-day prototype turnaround, and one-week production turnaround. The company sells 20,000-gate ASICs for $15 (10,000) without NRE charges and including three design iterations. This approach still provides a sizable production commitment compared with PLDs but much less than that of standard ASICs.

In addition to all these choices, designers face yet another roadblock: PCI compliance. Any company providing ICs for PCI should be able to provide designers with a PCI-compliance checklist. The checklist provides a summary of electrical and timing characteristics to meet the PCI specifications. A device that fails to meet the requirements of the checklist is not PCI-compliant, although the design may work in a closed-architecture system under less stringent requirements. For example, output buffers that don't exhibit the required drive over the full temperature range may operate over a more restricted range.

A device that meets all the requirements on the PCI checklist offers some level of PCI compliance, but meeting the requirements offers no guarantee that designers can design a PCI-compliant board with the device or that the board can operate without wait states in burst mode. Mike Dini, president of the Dini Group (La Jolla, CA), has designed four PCI systems with off-the-shelf PCI chips plus three with Quicklogic devices. He says that even operations such as parity-error checking, which requires the design to perform a 36-bit XOR in 30 nsec, may cause problems.

"I doubt whether anyone is actually meeting that timing," says Dini. "Using handcrafted design, you may actually get to the 30-nsec result, but you give up some flexibility in the design."

Another critical factor in PCI design is the delay through buffers. It takes data 11 nsec to get from the PCI clock to the bus. During that time, the clock from the outside must go through the buffer to the register, and the data at the input of the register must go from the register through the output buffer and onto the PCI bus. Raghavan says methods exist for fixing the delays on systems that are too slow, but any method takes two clock cycles instead of one. Most FPGA companies offer PCI-compliant buffers, according to Raghavan, but the companies "forget" to tell designers what the delay through these buffers is.

"People are looking for simple answers to complex problems," says Raghavan. "It's difficult to get accurate information."

Yet another critical part of PCI-compliant design is its requirement for a 7-nsec setup time and 0-nsec hold time. According to Raghavan, to satisfy that requirement, a design sometimes needs analog delays to compensate for the 0-nsec requirement.

"That issue is also a tough design challenge," he says. "If your design has a Verilog or VHDL core, you can synthesize that core to handle logic design. However, the core still cannot handle the analog delay. Some FPGA vendors avoid this problem with a handcrafted design. However, it may be difficult to synthesize a core to an FPGA and have the core operate. You may spend two months trying to fix the 0-nsec hold-time problem."

Users report success

Not every user is suffering from these difficult timing problems, however. Mark Santoro, president of Santoro Systems Engineering (Encino, CA), used Actel's CorePCI VHDL model for a PCI target and an Act 3 family device. The resulting design had no timing problems. The design supports burst-mode read and write transfers with zero wait states. Burst transfers for writes operate at a 3-1-1-1 rate, meaning that the first transfer requires three clock cycles and subsequent transfers each require a single clock cycle. A burst transfer of four 32-bit data words requires six clock cycles and provides a data rate of 89 Mbytes/sec. Longer bursts approach the maximum 132-Mbyte/sec data rate.

Santoro's design required little manual work. He synthesized most of the design from VHDL, although he used schematics for explicit control in some parts of the design.

Dini, meanwhile, uses macros on his PCI designs when they are available. Otherwise, he uses Verilog until he encounters speed problems and then uses schematics to solve the problems.

Designers would typically rather have a PCI-core design in VHDL or Verilog that they can customize for their applications. This scenario is sometimes impossible, however, for performance reasons. Xilinx's LogiCore PCI Target design, a preplaced macro for some XC4000E-family devices, lets you customize FIFO buffers and the back-end interface (Figure 1). The PCI interface end, however, is a carefully designed macro that accommodates few modifications. Another designer, Richard Lomas, president of Lomas Data Corp (Marlborough, MA), used Xilinx's LogiCore PCI Target core in an XC4013E for a PCI-based RAID (redundant array of inexpensive disks) 1 disk-mirroring application. Lomas successfully used the LogiCore Target design without encountering timing problems.

To help you develop PCI interfaces, PLD companies offer help ranging from often-free application notes and reference designs to the complete core designs with test vectors for verifying your design. Table 1 lists some representative products to help you design PCI interfaces. New product offerings are occurring rapidly, so contact the PLD companies directly for their latest offerings. The PLD companies can also let you know about third parties providing PCI cores and other products applicable to the vendors' devices.

With all the emphasis PLD manufacturers place on meeting the PCI front-end speed requirements, however, don't lose sight of the back-end interface to your application. If your PCI interface meets the burst-mode transfer rates without wait states, the back end of your design must also meet those same data rates unless it is just moving short bursts through a FIFO buffer. If performance for the high data rates is difficult for the PCI interface, then going off the PCI interface chip to another chip may also offer performance challenges.

Santoro notes that when you go on and off chip, buffer times become much longer than internal propagation times. In addition, some PLDs have space only for the target interface and none for the back-end logic. Going off-chip also adds latency.

Santoro got the PCI target interface and the extended-data-out DRAM controller he needed on a single Actel Act 3 device. Smaller PLDs, even though they may be fast enough for PCI compliance, may end up causing timing-related problems if you can't get your back-end application on the same chip. The higher density PLDs offer space for relatively large designs in addition to the PCI interface, but you must also consider the design details of your back-end application—not just space for the logic.

Most PLD companies offering designs for PCI concern themselves with having target, initiator, and bridge designs and with what level of support designs offer for functions such as burst-mode transfers. Virtual Chips offers two dozen PCI cores, because Ethernet, ATM, and communications customers have different needs in the control they need on the data flow, according to Raghavan. When people buy a PCI core or a PCI design, they need user-interface flexibility at the back end to fit their applications.

The requirements of your application can also affect how much work remains for you beyond the PCI interface. Even though you have a 32-bit-wide PCI-bus interface, your application may need a 64-bit-wide bus. Your application may operate synchronously or asynchronously with the PCI bus. Virtual Chips offers cores for ASICs that accommodate these design requirements without additional design work for the core user.

PCI cores that don't offer all these variations still save you work. However, think of PCI cores as a way to trade money to reduce design time and PCI-specific design knowledge. Cores that offer a less customized interface to your back-end application still offer value—just less value than those that provide a simpler back-end interface.

Verifying design compliance

Verifying that your design complies with the PCI specification is another important part of the design task and depends on the system you are designing. Designs for open use in PCI systems need full compatibility if these designs are to plug into any system and operate properly. If you use a free reference design or application note, you are usually on your own when it comes to verification. Cores or drop-in modules typically come with standard or optional testbenches, simulation models, and other means to verify that the design works.

Using the PCI bus in closed, or embedded, systems can significantly alter the verification process—and even the entire design requirements—because the design must be compatible only within the system. This use of PCI has grown into a major application of the bus. The bus's high performance and complete documentation allow its use in these closed systems. Companies can also eliminate or alter parts of the PCI standard that do not suit the application.

To verify his design, Santoro did not check compliance with PCI because the application was a closed system; thus, the design did not require compliance. Santoro's company used gate-level simulation of the design and then functional simulation of various modes. Santoro claims that, if he were using the simulation in an open system, he'd want a full test suite in VHDL or Verilog and then he would simulate the design.

In Lomas' case, Xilinx provided the PCI simulation, and Lomas used a Viewlogic simulator to verify as much of the design as possible. Lomas needed good verification, because the board targeted open PCI use. The designers tried the board on as many systems as possible, including 166-MHz Pentiums and 486 systems, to ensure that no problems existed. In Dini's case, the designers used simulation to verify that the designs worked. Virtual Chips also extensively tests the PCI cores that it sells.

"We have tests that run for a full week testing everything we can think of," Raghavan says. "You need a large set of tests to verify operation for all conceivable situations."

Take all these design issues into consideration if you plan to begin a PCI design using PLDs. Know your performance requirements and thoroughly research the programmable logic you plan to use.

You can reach Technical Editor Doug Conner at (805) 461-9669; fax (805) 461-9640; e-mail edndconner@mcimail.com

References

1. Quinnell, Richard A, "The Mighty Morphin' PCI bus," EDN, April 25, 1996, pg 58.