SoCs: IP Reuse -> Multiple processors vie for tight space

A system-level approach demands modeling tools and methods that consider the varied features and interfaces up front in the design process. In particular, the development environment itself should allow for an easy transition from system specification and modeling into a standard IC design flow, while testing and debug tools are fully integrated to ensure functionality of the final design.

Basically, a multiprocessor SoC consists of several processor blocks, memory, peripherals, a communications bus and an external systems-specific interface. The SoC achieves faster speeds and better performance through a single piece of silicon.

One advantage to a multiprocessor SoC is to exploit reuse of existing IP blocks and to provide an easy migration path within the SoC to upgrade to future generations of a particular processor family. However, there has been a gap between the desires and reality of IP reuse. The challenges include IP blocks that are not portable to new designs, no standard interfaces between IP blocks and the i nability to evaluate IP because of a lack of models that provide the appropriate level of detail.

Some core manufacturers have offered single-core platforms to develop with the core they offer. A few silicon vendors have developed application-specific-based platforms with multiple cores. However, these cores are fixed, with a fixed architecture that is not flexible enough to be changed in order to meet their needs in terms of performance, latency, peripherals and other factors.

The development of multiprocessor SoC systems involves many phases of design. The phases of design and the different considerations associated with a given design, require a wide range of design environments. These environments need to support the initial system-level design, as well as software and hardware development. In addition, an important goal is to maintain a consistent debugging interface across all environments, while providing the flexibility to support interfaces to many different industry-standard tools.

Initially, the designer needs a flexible system-level modeling environment that enables the exploration of the design space and an understanding of the related performance characteristics. The designer can then more easily determine which processor or processors to use, the architecture of the memory system, the configuration of peripherals and effects of partitioning. The models provided must consider the real-time flow of high-speed data, which will have specific bandwidth and latency requirements. Memory components should be modeled with a variety of programmable parameters, including size, latency and bandwidth. I/O should be modeled through statistical stimulus.

Dynamic, trace-driven and statistical models of the processors should be provided to support system-level modeling. A dynamic model allows the user to execute code on the simulated processor. Trace-driven and statistical models provide an alternate method of generating memory traffic to the system.

The ultimate goal of s ystem-level modeling is to prove in the architecture of the multiprocessor SoC. Once the basic architecture is defined, available models should address the requirements of detailed hardware and software design. For software development, instruction-accurate models allow the development of functional software on the processor while maintaining simulation performance. Cycle-accurate models allow for the benchmarking and optimization of software. Phase-accurate models add accurate bus models for the development of additional IP blocks. In our case, each of these simulation models is encapsulated within the Lucent LuxWorks' development environment.

It is important to maintain a consistent debug interface across all environments, including when running on actual hardware, while still offering the flexibility to support interfaces to many different industry-standard tools. This will help to ensure first-pass success when the design reaches the prototype stage. Additionally, the IP blocks should support eff icient reuse of the design tests, test benches and test vectors.

To help achieve first-pass success for its customers, Lucent has developed the SuperCore development suite, a solution set and tools to support a state-of-the-art design flow for processor-based SoCs. The solution set includes basic processor cores, local memory systems, standard bus interfaces, local peripherals and a standard system-level debug framework.

The suite enables designers to combine cores within their multiprocessor solution, or implement a single processor SoC. Designers can include selections from the ARM7, ARM9 and ARM10 families, as well as from Lucent StarCore DSP cores. ARM and DSP cores can be integrated on the same SoC for greater flexibility. This is made possible by the definition of standard processor SuperCore macrocells that interface to a high speed on-chip bus.

The high-speed on-chip bus provided with the SuperCore development suite is based on the Daytona bus technology developed by Bell Labs research. It supports a split transaction protocol across a data bus with a width up to 128 bits. The sustainable throughput across the bus is 4.8 Gbytes/second at full speed. This is necessary to support advanced communications applications in areas such as data networking and wireless infrastructure. Streamlined versions of the bus are also defined for lower cost applications with lower data rate requirements.

Support is also provided for the ARM AMBA bus standards, with direct interfaces to the ARM SuperCore macrocells and bridges to the Daytona bus. Included in the SuperCore development suite is an extensive list of peripheral functions that may be integrated through a standard AMBA interface.

The SuperCore development suite also includes LuxWorks, a high-level performance model framework providing C source code level debugging. LuxWorks supports C source level debugging of multiprocessor systems in both simulation and hardware modes. With it, the designer can define a set of debug-simul ation domains to be used for different aspects of the design, with support for standalone simulation within LuxWorks and co-verification through interfaces to Verilog and VHDL simulators and other third-party tools.