Extending Peripheral Sets with FPGA Switched Fabrics

New technologies available for FPGA design come of age

By Joe Hanson

As the cost of new product development increases, new embedded processor development will produce either general-purpose solutions, or ones targeting specific high-volume applications. To adapt either type processor to a slightly different application, designers will need additional, often unique, peripherals. FPGAs and FPGA development tools now offer ways to adapt standard processors to meet new peripheral requirements without writing HDL, and in a fraction of the time of traditional system-on-chip (SoC) design methods. The key is a switched fabric interconnect structure.

General purpose processors in SoCs typically have only 80 percent of the peripherals needed for a given application, while devices targeting a specific application will have all the needed peripherals. Adapting peripherals to another application typically can create the need for additional peripherals. And neither of these two product types, SoCs or application-specific devices, will ever incorporate that unique custom peripheral that differentiates one product from another.

Unfortunately, adding a needed peripheral to a given processor is not always easy. Embedded processors today often come with complex interfaces such as PCI, PCI-X, PCI-Express, RapidIO, and Hypertransport. For many peripheral expansion needs, these interfaces add a level of complexity that is unwarranted when the peripheral itself is simple, an example of which would be a serial port.

Simple processor interfaces composed of address, data, and control signals such as those used to access external memory, are ideal for connecting simple peripherals because they add very little complexity. Furthermore, these types of interfaces are available on the vast majority of standard products. The biggest challenges in using these interfaces lies in dealing with the various interface standards, different data path widths, and varying number of bus cycles per transfer that the peripherals require. Standard peripherals seldom match the processor’s simple interface exactly.

Simplifying interconnects

Instead of trying to force a whole category of peripherals to fit the same bus standard, designers can take a different approach when using FPGAs to implement the peripheral. This approach involves the use of a switch fabric, optimized for the mix of peripherals used in a particular system. The switch fabric contains all of the decode logic, arbitration logic, interrupt control, wait-state control, and data-path matching logic for connecting the processors to the peripherals.

One such switch fabric design is available under the Avalon specification, available free from Altera Corp. (San Jose, CA) at www.altera.com. Avalon was designed specifically to accommodate peripheral development for the system-on-a-programmable chip (SOPC) environment.

The switch fabric approach eliminates the need to match a peripheral to a processor interface. Data transfers are between the peripheral or the processor and the switch fabric interconnect, with the fabric designed to match the devices. This interconnect strategy allows any type of processor, or other bus master, to be connected to any type of peripheral - for example, a slave without a priori knowledge of the interfaces.

Development of a switch fabric appropriate for the masters and slaves in use is not necessarily a difficult task. The Avalon specification, for instance, provides designers with a basis for describing a device’s address-based read/write port interface. This description is then used by Altera’s SOPC Builder tool (available free from Altera as part of its Quartus II development tool, web edition) to automatically implement the switch fabric interconnect strategy in an FPGA. The fabric and tool together move the burden of generating the appropriate logic for connecting the various devices from the engineer to the tool.

Given the wide variety of external memory interfaces on processors, the flexibility of a switch fabric makes it ideal for connecting standard processors to peripherals in or through an FPGA. The Avalon interface, for instance, supports asserted high- or asserted low-logic levels for any control signal. The product also supports masters with up to 128-bits of address and data paths of up to 128-bits wide. Internal to the FPGA, the read and write data paths are separate non-tri-state high performance data paths.

For most processor interfaces, connecting the FPGA and the Avalon switch fabric to the processor simply involves matching the processor signal types to the Avalon equivalent. The only logic required on the interface is the control logic that converts the processor’s bi-directional data bus into the separate read and write data paths used by Avalon. That control logic can be as little as a single logic element of the FPGA.

Importantly, performance is rarely an issue. FPGA I/O elements easily support toggle rates of 133 MHz, more than ample for the great majority of processor external memory interfaces. The system performance of FPGA logic does, however, depend on the FPGA family, the types of peripherals, and the number of peripherals connected to the Avalon switch fabric. Nonetheless, high-performance peripherals sub-systems are readily achieved with today’s FPGAs.

Connection example

To demonstrate, consider connecting the Variable Latency I/O (VLIO) Interface on the Intel PXA2xx processor to peripherals on an FPGA. The VLIO signals map directly to Avalon signal types. (see Figure 1)

Figure 1: Connecting a processor such as the Intel PXA255 to an FPGA-based switch fabric such as Altera's Avalon can be as simple as mapping the interface signals to each other.

The control signals nPWE and nOE map to the Avalon write_n and read_n signal types. Similarly, the address signals (MA[25:0]) map to the address. The nOE is also used with the CS (chip-select) signal to qualify a read from a write transaction to control the direction data (MD[31:0]) mapping on to the Avalon write data and read data paths. If support for addressing individual bytes is needed, the DQM[3:0] signals map to the Avalon byte-enable signals. A Verilog description of the interface can be quite simple. (see Figure 2)

Figure 2: Creating the interface logic between a processor and the FPGA requires only a few lines of hardware design code. The Verilog description shown here excludes the port and signal declarations.

Use of the switch fabric approach allows a hardware engineering team to design unique, custom peripherals that are independent of the processor selected. To connect that peripheral to the Avalon fabric, the designers simply map the module’s signal names to equivalent Avalon signal types.

Once the mapping is complete, the designers define the number of clock cycles and any setup and hold-time requirements for read and write transactions. With this information, tools such as SOPC Builder can create an appropriate switch fabric that allows any master device to exchange data with this custom peripheral. If the peripheral is published to a library of components, it becomes available for re-use in the same or new systems without the need to make any changes to the peripheral. (see Figure 3)

Figure 3: By defining a custom peripheral's interfaces and timing requirements using a tool like Altera's User Logic Wizard, a development team can publish a design to a library for re-use.

Using FPGAs and a switch fabric approach also makes it simple to add a soft-core processor, such as the Nios II processor, to off-load the host processor. Similarly, it becomes easy to add DMA controllers to move data around within the FPGA. Multiple bus master design becomes straightforward because the fabric controls which processors have access to which peripherals and prevents contention.

After integrating the hardware components, the software development begins. Even then, the FPGA design tools that supported fabric development have a role. Many components designed for a fabric interface will include software drivers and sample application code for exercising the peripherals, and that code is stored in a library along with the interface definitions and mapping. Tools such as SOPC Builder can copy this software into directories for usage. The tools can also generate standard C header files for each processor in the system, providing a memory map and register declarations.

Each time the hardware team changes a system design, the tools update the software files. This automatic hand-off to the software team of the latest parameters and declarations with each new hardware image accelerates the system development by maintaining hardware/software coherency.

Leveraging features

Switch-fabric interconnect leverages the density, features, and performance of today’s CPLDs and FPGAs, to expand the peripherals set for standard processors. The approach also provides opportunities to increase the system’s performance and add other capabilities into the system by marrying a standard processor to custom peripherals. Given the escalating cost of embedded processor development, developers need such new approaches to adapting standard products to meet exact design needs.

Joe Hanson is director of system-level tools at Altera Corp. in San Jose, CA., an Associate Member of the Intel® Communications Alliance.