SoC processing options


EE Times: SoC processing options
Gene Frantz (05/02/2005 9:00 AM EDT) URL: http://www.eetimes.com/showArticle.jhtml?articleID=161601588

Systems-on-chip with multiple processing elements are an important part of the design landscape, especially for portable systems that require the high level of integration and the mixed data and signal processing that SoC devices offer. But SoC design involves combining disparate elements — from programmable functions, such as general-purpose (usually RISC) microprocessors, DSPs, FPGAs and accelerators, to fixed-function accelerators. One of the biggest design decisions for complex portable systems is the mix of processing elements needed to optimize system performance, price and power consumption. The designer must closely evaluate the trade-offs to arrive at the most effective yield. The task of matching a particular system to a particular SoC is not always driven by technical considerations. In many cases, it has more to do with the resources available, how flexible the system needs to be, and how new features and new bugs will be handled. Having a procedure for partitioning system functions effectively will help exploit the tremendous advantages that SoCs offer. These do's and don'ts can help the savvy designer bring a successful SoC-based design to fruition. By Gene Frantz (genf@ti.com), principal Fellow, Texas Instruments Inc. (Stafford, Texas) DO Understand the processing options. The table below gives a quick overview of the various benefits and liabilities of the various SoC elements. Understand the procedure for making SoC choices. This translates into partitioning the system functions among the elements available. Mapping the requirements of a system on an existing multicore SoC is very similar to creating a new multicore SoC. Before mapping the system onto an existing SoC, understand the market requirements the SoC will address: the features and algorithmic components of the product, as well as the strategy for adding features and resolving bugs during design and over the product's life. Break down the procedure into the following steps: 1. Compile a list of final-system features and capabilities, including projected additions. 2. Partition the list into data- and signal-processing features and capabilities. 3. Separate the functions in each of these lists (data and signal) into three distinct categories: well-known functions that will remain unchanged; well-known but somewhat changeable functions; and uncertain, changeable or new functions. 4. Estimate the required performance and memory requirements for each item. 5. Assign: a. the appropriate functions to the available fixed-function accelerators; b. the remaining well-known functions to the available programmable accelerators; and c. the uncertain, changeable and new functions to the appropriate programmable elements (RISCs for data and DSPs for signals). The goal is to take advantage of the accelerators as much as possible and to leave flexibility and headroom for the programmable elements. Use the above procedure to make assignments for functions (step 5). The new design can be very definite about assigning the well-known features (5.a) to fixed-function elements; the somewhat changeable (5.b) features to programmable accelerators; and the uncertain, changeable and new features (5.c) to RISCs for data and DSPs for signals. Don't Assume an SoC device will have to be designed to meet your needs. Shoot instead for reuse of an existing design. Waste time trying to find the perfect device for the solution. A good rule of thumb is that to create a successful product, you should find a system-on-chip with: good enough performance; low enough power dissipation; low enough cost; and the ability to get you to market first with a road map to keep you competitive. Remember, good enough and first to market win. Handle the different processing tasks in the same way. System functions must be identified as signal- or data-processing tasks and then divided into the categories mentioned above (5.a, 5.b, 5.c): well-known functions that will remain unchanged; well-known but somewhat changeable functions; and uncertain, changeable or new functions. Assume that mapping a system onto a new SoC is easier than mapping to an existing SoC. The former is likely to involve longer-term product projections, perhaps including a series of products based on the new device. Forget to evaluate the development environment and development support. See related image
- -