How to choose a CPU for your SoC design

Simple assessments of horsepower are just as misleading in CPU selection as they are in the automobile world. There is an optimal solution for the desired functionality. The same holds true for the CPU choice in an SoC. Many times the designer chooses the CPU based solely on the system architect's knowledge of, and past experience with, a particular CPU.

In deciding which CPU to use, the designer should consider the overall system metrics like: complexity of overall design, design reuse, protection, performance, power, size, c ost, tools and middleware availability.

The design's complexity helps determine which CPU to use. For example, if the design calls for the deployment of a single state machine with interrupts from a small set of peripherals, then a small CPU and/or microcontroller such as the 8051 or the Z80 could be the best choice. Many systems-a pager, for example-may fit this category initially. The memory footprint is small, the signal is slow and battery consumption must be extremely low.

The algorithms and their interaction will dictate the design's complexity and may also determine whether it requires a real-time operating system (RTOS). Typically, as the application complexity increases, the need for a greater bit-width processor increases.

Designs are being reused and are growing in complexity; that same pager of 2000 may need to play MP3s in 2003, so 8-bit CPUs may not be enough to keep up with the task at hand. The number of interfaces a design contains is a good indicator. In our pager ex ample, initially there are two main interfaces, the user interface and the radio link. In the design that adds an MP3 player, we will need to add a memory interface, for storing and transferring the data, and an audio interface for playing the data. In this example, the system complexity greatly increased from its initial conception, and if we consider where the design may be deployed in the future, we can reuse much of the same design.

Make sure that you leave room for growth. Today your 8-bit design may be good for the MP3 player. However, when the design is reused in, say, a set-top-box application that has a much higher bandwidth peripheral set, you may need to re-engineer the complete solution to migrate to an ARM-, MIPS- or PowerPC-based architecture to deal with the new constraints.

The system may need to protect itself from outside attack or even from itself, which means the CPU will likely need to contain memory management units (MMUs) to address this issue. Virtual memory allows tru sted programs access to the entire system, and untrustworthy ones, to access just the memory allocated to them. The 3G cell phone, a phone with Internet connectivity, is a prime example of the need for protection. Designers can no longer afford to use a CPU that lacks an MMU, since a rogue program will crash your phone. Although an MMU does not eliminate the potential for system failures, it reduces the number and frequency of hard-to-find system failures.

The three main CPU architectures are built around 8-, 16- and 32-bit data registers with 16-, 24- and 32- bit address buses. The main difference among these architectures is the amount of information one particular register can hold, and how much it can address directly, as seen here: With an 8-bit data register and a 16-bit address bus, a CPU can have 64k of address space; one with a 16-bit data register and a 24-bit address can have 16 megabytes of address space; and one with a 32-bit data, 32-bit address will have 4 gigabytes of address space. P>

Why would an embedded system ever need to access 4 Gbytes of address space? The answer is simple: As the system is asked to perform more complex tasks, the size and complexity of the code it runs increases. Early days of CPM on a Z80 used a process of banking memory and page swapping to run programs that are more-complex on an 8-bit machine. Since 64k was not enough space, designers made the system more complex by overlaying memory and pages to get more out of the CPU.

A 24-bit address bus would seem to be adequate for many designs. But several factors drive designers to a 32-bit address space, including protection and pointers. For protection, the CPU with virtual memory can use the entire address range to divide up the physical memory into separate virtual spaces, thus allowing for protection from bad pointers. The ability for any register to become a pointer to memory without the need for indexing simplifies the software.

The performance of the overall system will be greatly impacte d by the selection of CPU. Specifically, features like cache, MMU, pipelining, branch prediction and superscalar architecture all affect the speed of a system. Depending on the needs of the SoC, these features may be necessary to achieve the system's peak performance.

The end use of the SoC will determine how much power your design can consume. If your design is battery operated, the CPU will need to be as power-conscious as possible. For instance, some CPUs have the ability to sleep, doze or snooze. These modes allow the CPU, when idle, to suspend operation and consume less power by shutting downvarying amounts of the CPU. Different CPUs perform the same task with different results.

The cost of the CPU can be measured in several ways. First, there is the IP cost, which includes the cost to acquire the IP for your SoC, and any derivative products. Then there is the system-integration cost, which includes tools that are available for the design and implementation of your SoC. Finally, you must determine if the CPU variant is silicon-proven, and whether it's available on the bus architecture that the SoC uses.

The availability of an RTOS and middleware may dictate your choice, as well. For instance, in designing a PDA, you may want the middleware that is available for Linux, but the choice of a virtual operating system will dictate that you migrate away from small non-MMU CPUs.

Further, if the design calls for a graphics system or a file system, then the choice of RTOS will dictate the type of CPU. Many RTOS vendors target specific families, leaving others untouched. Most 8-bit CPUs have simple schedulers that, while adequate for small designs that consume little outsourced code, are not adequate for designs that consume any quantity of outsourced code. The outsourcing of the solution will determine which RTOS to use, which in turn dictates what CPUs will be supported.

Other considerations include: What tools do you need to do the design, and are they available for a standa rd ANSI C/C++ compiler that you may use? How will you debug your design, either in HW/SW co-simulation environment or on the SoC? Does a JTAG port exist, and is the CPU using this channel for debug or is a dedicated serial port necessary for debug? The choice of a higher-level language like C++ or code generated from a design in UML may also dictate that you need a higher bus width and clock frequency to deal with the code size and complexity.

The SoC may be better off if partitioned into several processor subsystems that communicate via a loosely connected FIFO or serial channel. Many designs incorporate a digital signal processor and a RISC CPU to share the workload and simplify the design of each processor domain.

Modern SoC design has presented new challenges for the system architect. No longer is the choice of CPU trivial. By using guides like complexity of overall design, design reuse, protection, performance, power, size, cost, tools and middleware availability, the designer can simpli fy the decision.

Stephen Olsen is senior engineering manager in the IP division of Mentor Graphics Corp. and co-chair of the VSIA Hardware-Dependent Software design working group.

See related chart