Embedded Systems: Programmable Logic -> Programming enters designer's core

Making accessible, easy-to-use intellectual pr operty (IP) soft cores that can be integrated easily within these designs is essential. These predesigned cores can be instantiated and simulated within an SoPC to speed the overall design process by eliminating the need for lengthy internal development or securing of third-party IP. Examples of commonly used soft IP cores include PCI bus interfaces, USB host controllers, 10/100 Ethernet media-access controllers, UARTs, and other DSP or networking communications functions.

In addition to providing the essential IP building blocks for system design, the architecture and bus structures linking these IP blocks with other functions on-chip must be defined in a manner that enables maximum system-level efficiency and performance.

For example, the bus architecture ideally should follow an industry standard to facilitate interfacing to third-party or customer-specific IP blocks. It should support multiple bus masters and slave modules and provide an arbitration scheme that prioritizes access to share d buses and peripheral resources to enable parallel processing or simultaneous execution of different tasks. Shared access to fast on-chip dual-port memory by multiple bus masters is useful in applications where streaming or temporary storage of data to and from external system memory is required.

The bus architecture should also support split transactions. This permits CPU read requests to slow peripherals such as flash memory to occur, but permits other bus masters access to a shared bus to perform other functions and not have to wait in serial fashion for the read operation to conclude.

Clock domains
The SoPC architecture should also support multiple clock domains across different functional blocks with bridge interface-synchronization logic linking these blocks within the device. This is helpful in situations where, for example, the on-chip embedded processor is operating at a different clock frequency than an SDRAM controller or bus masters implemented in programmable log ic. This permits the various functional blocks to operate at their own maximum speeds and not be constrained by lower operating frequencies of other functions on-chip.

An example of where an SoPC with an integrated embedded CPU can enable better system-level performance than equivalent discrete processors is in the case of standard MIPS ISA-based processors and system controller chip sets. These devices are commonly used in multifunction printers or as I/O processors in high-end networking switch applications.

The bandwidth of the MIPS SysAD bus, a multiplexed address and data bus with an upper limit of 133 MHz, constrains current MIPS processors. Any time the processor experiences a cache miss and must go to external system memory to fetch the data, it must pass through the SysAD bus.

System-controller chip sets available from companies like Galileo Technology or V3 Semiconductor typically support the MIPS SysAD bus interfaces and offer SDRAM controller and PCI bus support as w ell. However, many of these system controller chip sets support maximum SysAD bus speeds of only 125 MHz or have SDRAM controller support only up to 133 MHz.

In contrast, SoPC products, such as Altera's Excalibur EPXM product family, integrate a 200-MHz MIPS32 4Kc CPU core, and the MIPS system bus runs at the same maximum clock frequency as the processor (i.e., 200 MHz), thereby circumventing the 133-Hz MIPS SysAD-bus bottleneck. In addition, both Altera's ARM922 and MIPS-based Excalibur products support 266-MHz double-data-rate SDRAMs and can deploy different types of PCI bus support as a soft IP block in the adjacent PLD structure.

But having the right hardware feature set and architecture, along with a broad portfolio of IP building blocks, is only part of what's needed to implement SoPC designs effectively. Complete software support is also a necessity. So, too, is a design methodology that links the ability to develop system software in parallel with traditional PLD synthesis, simulation , and place and route. This methodology must also be able to model and debug embedded processors and other IP blocks.

In terms of software-tools support, several categories of tools are needed for doing SoPC design. These include conventional hardware design tools, embedded-software design tools, new system-level design tools, modeling support and debug tools. Hardware design tools generally include support for hardware description languages (HDLs) such as VHDL and Verilog.

Net conversions
Third-party HDL synthesis tools, such as Mentor Graphics' Leonardo Spectrum, Synopsys' FPGA Express and Synplicity's Synplify, are commonly used to convert the register-transfer level (RTL) of a design into a gate-level netlist. PLD design development tools, such as Altera's Quartus II, take the gate-level netlist and do the actual place and route within a PLD structure with optimized placement and timing. Providing a cycle-accurate simulation model of the embedded processor and integrated peripherals subsystem is necessary to simulate interaction with other functional blocks that are implemented in the PLD.

For embedded-system software development, an embedded-processor-based solution must be fully supported by a complete software-tools design suite, consisting of a compiler, debugger, assembler, linker, instruction-set simulator, trace analyzer, profiler and any nec-essary support libraries and utilities. Industry-standard architectures like MIPS and ARM offer a wide selection of both real-time operating-system support as well as software tool-chain support for embedded-system software development.

New system-design tools can consist of system-configuration tools and tools that determine the specific functionality of the embedded-processor subsystem. Being able to set parameters for such things as the clock frequencies of the different internal buses, the width and depth of on-chip dual-port memory and the speed of SDRAM controllers is useful for optimizing system perfo rmance.

Most systems consist of various IP modules that are interconnected via buses. An ideal system-builder tool would enable designers to choose the IP modules required, as well as determine the parameters for each module and set different clock domains for the individual modules.

Interface support
This type of functionality is supported by the MegaWizard GUI-based configuration interface within Quartus II. Tools like SoPC Builder actually generate the synthesizable code for each IP module, generate the buses, configure the processor subsystem parameters and provide a simulation model. Providing a broad range of IP modules with the appropriate bus interfaces supported by these system-builder tools is also essential.

Three levels of modeling support are usually provided. The first is system modeling, which refers to the behavioral modeling of a complete hardware/software system. Commonly referred to as co-simulation tools, products such as Mentor Graphics' Seamle ss or Synopsys' Eaglei support system modeling. These tools permit faster simulation than traditional hardware simulation but are still slower than using the actual hardware.

The second type of modeling support is system verification using the embedded-processor-subsystem simulation model. This is a cycle-accurate simulation model based on the same RTL as the design. The third type of modeling support is individual module verification, which is used prior to system integration. This verification supports bus-functional models for the processor that describe the particular system bus operations, timing and interface to the other blocks within an SoPC design. The bus-functional model permits hardware verification only.