Tools For Reprogrammability -> Programmables suit platform approach
Programmables suit platform approach
By Cary Ussery, President and CEO, Oz Levia, Chief Technology Officer, Improv Systems, Beverly, Mass., EE Times
November 20, 2000 (11:35 a.m. EST)
URL: http://www.eetimes.com/story/OEG20001120S0033
Chip design is undergoing a major change. Design techniques and methodologies that worked for last-generation chips are no longer sufficient for the competing demands from deep-submicron technology and consumer-oriented markets. So new approaches are beginning to emerge throughout the design community, chiefly the move toward "platforms," predefined chip architectures that provide a structure for designers to create new chips. Platform means a variety of things, but there is a growing consensus that to deliver the desired benefits a platform must be programmable, it should be scalable and, for that extra performance and silicon efficiency, configurability is increasingly sought. In order to provide flexibility through a product life cycle, platforms must be programmable. This means that all of them contain some form of embedded processor. Increasingly, more and more of the platform content is moving onto the programmable p rocessor. This transition is having a fundamental effect on the design process: Chip design is becoming software-centric rather than hardware-centric. Scalability is another desirable quality. In many markets the same applications are used in the low end through the high end-for instance, in the voice-over-packet segment, there are home devices that require a few channels of speech compression and echo cancellation. The same speech-compression and echo-cancellation techniques are also used in back-office and central-office equipment, but an increasing number of channels must be supported. Platforms that provide scalability, usually through multiprocessing, allow companies to address different points in the market with a consistent and highly leveraged hardware and software approach. Since scalability means multiprocessing, this too will have a real impact on the design process. Finally, successful platforms give the designer flexibility to configure the platform to the specific needs of the p roduct or application domain. The level of flexibility and the technology for enabling customization varies widely over different platforms. It can be as simple as selecting a set of peripherals to include with the platform through adding custom logic blocks to completely configuring all aspects of the platform. The common thread, however, is to allow a design team to add its own value to the platform to create differentiation in the marketplace. Supporting configurability in the design process is a new and very challenging hurdle that design flows must address and support. From a platform perspective, configuration means defining the set of components to include in the platform. These include embedded processors (both microprocessors and DSPs), embedded memories and peripheral (IO) blocks for handling off-chip communication. In a scalable solution, like Improv's Jazz PSA Platform, the designer can also choose the number and types of processors to include in the platform. From a processor per spective, configuration opens up possibilities. At its essence, configuring a processor means defining a set of resources inside the processor that can be accessed through instructions. Very long instruction word (VLIW) processors like Improv's Jazz processor offer unique opportunities for configuration that enable a bridge between custom logic and general-purpose processors. The introduction and growing success of platforms in SoC design are redefining the design process itself. The design flow for SoC will have to evolve to adjust to a very different approach and emphasis for design flow as well as meet some very real and difficult technical requirements. Today's SoC methodologies take a bottom-up approach. The design team starts with the hardware and determines what cores are required in the architecture, then selects an integration scheme and takes responsibility for integrating the system. Using this approach, designers must address system partitioning, integration and hardware-software partitioning up front. It is extremely difficult to make any changes to the base architecture once these decisions have been made. Platform-based design stands this notion on its head; it is best supported by a top-down philosophy that is software-centric. Platforms provide a macro-level architecture for the chip where the integration approach is set and the problems of combining different components (or cores) on the chip have been worked through ahead of time, and the components are designed to work together optimally. Using platforms, the design team first focuses on the system application software and then drops down to configuring a platform for executing that application software that meets the needs of its product or application domain. This fundamental shift in philosophy has major implications for design methodologies in general and for types of tools that are required to best support the set of activities required in platform-based SoC design. The shift to platforms away from HDL-based design to a software-centric platform development methodology means designers need a new class of tools and techniques. Throughout the 1990s, the dominant technology for front-end design was logic synthesis. For the new decade, the critical technology for front-end design is compiler technology. Compilers have always been critical for embedded processors. However, even with existing processors, compilers have not been able to take full advantage of target architectures. This has been especially true in the DSP arena, where developers consistently drop into assembly-level programming for critical algorithms. Compilers have to make major leaps to address a number of trends in SoC. Three of them are especially important. First, SoC designs contain multiple processors, not just a single processor. This creates a need for "platform compilation," where the compiler automatically allocates different processing tasks on the multiple processors contained on the chip. Second, there is a shift from RISC technology to VLIW techniques as the primary architecture for advanced signal processing. Finally, the emergence of configurable processors, which let designers create variations of a processor, poses significant challenges for today's compilers. New approaches to compilation must be taken that integrate multiprocessor compilation, VLIW scheduling, and software pipeline and retargetability to heterogeneous platforms and processors. To handle configurable platforms and processors, compilers have to be retargetable. There are different approaches to retargetable compilation. In some solutions, a custom set of tools is generated for a specific target processor. This solution is more common in the RISC processor space, since the primary focus of customization is to add a set of new instructions into the processor. The disadvantage with this approach is that different versions of tools need to be maintained for each cu stom processor; this can create significant support and management concerns. Another approach is to design the tools at the outset to be driven by a file that defines the specific target configuration. This is the approach Improv has taken in its Solo Compiler. A resource configuration file can be created (using the graphical Jazz PSA Composer tool) and then the compiler (as well as all the support tools) are simply given the target file as one of the inputs. With most platforms moving to multiple processors, compilers must take on a larger role in the design process. In particular, if a compiler can target only a single processor the designer must partition his or her application among multiple processors by hand, generally requiring a major reworking of the software architecture. To address this, new compilers should automate the process of partitioning an application and allocating different tasks to different processors in the target platform. In Improv's Solo Compiler, this stage of comp ilation is called coarse-grained allocation, or CGA. The elaborator extracts a structural object graph of the application that defines the different tasks and their data and control dependencies. The CGA allocates the tasks onto different processors and allocates the data onto different memories in the platform. This allocation is done based on constraints defined by the user (by default, the CGA optimizes for performance). Clearly, the industry is at a significant crossroads in chip design. Platforms are quickly becoming the design methodology of choice for anyone in advanced SoC design. This means that the success of configurable platforms will depend on the excellence and robustness of the compilation technology provided.
Related Articles
- Tools For Reprogrammability -> SoC platform needs system approach
- Tools For Reprogrammability -> Platform-based design ups productivity
- Distribution: An approach for Virtual Platform scalability
- Why platform-based design works better than a discrete IP approach (by David Fritz, ARC International)
- Tools For Reprogrammability -> ASIPs: Get ready for reconfigurable silicon
New Articles
Most Popular
E-mail This Article | Printer-Friendly Page |