The industry shift toward design reuse is now progressing from block-level to system-level design. To improve system-on-a-chip (SoC) productivity, many organizations are turning to SoC reuse platform solutions. These application-specific reference designs take advantage of previously created SoC architectures. This approach allows designers to reuse major portions of entire chips instead of just a few components.
The goal of the SoC reuse platform is to improve the time-to-market of multimillion-gate SoC designs by facilitating the reuse of design architectures, components, and verification suites at the chip level. This greatly increases the impact of design reuse and promotes better system solutions. SoC platforms enable design reuse productivity by changing the focus of SoC design from block-level design creation to system-level design composition.
An SoC reuse platform is a reference design that defines all or part of the architecture for a particular application. One defining aspect of a platform design is that it's at least architecture specific, if not application specific. As an SoC design, the platform will include at least one microprocessor core, one DSP core or more, and on-chip memory, as well as a number of pre-existing IP peripherals. Platform designs typically contain only a small amount of new logic that's specifically designed for the system.
Bus connections are the most important structures in a platform design, not the processor. All blocks in the design are built to communicate with each other as well as with a library of extensible components. The platform design is intentionally modular. That allows for the swapping of configurable blocks in order to quickly produce similar—but unique—SoC derivatives.
The experience of those from Mentor Consulting has shown that to attain the most value from an SoC reuse platform, the reference design should support an application or architecture that's expected to become the basis for many SoC designs. A platform design requires from three to ten derivative SoC designs to return the initial investment. The actual break-even point depends on the application and the level of automation built into the SoC reuse platform.
Not every design warrants this type of investment. But applications requiring many versions of similar SoC solutions can greatly benefit from this approach. There are many good examples of appropriate applications for platform designs in wireless telecommunications, networking, and consumer electronics.
A typical SoC derivative built from a reuse platform might have over 70% of its design content coming from reuse (Fig. 1). This includes the design architecture, the bus connection schemes for the components, and the functional verification suite for the design. To meet performance and size goals, the memory blocks as well as the processor and DSP cores are normally included in hardened form. As such, it's the availability of these cores that determines the silicon technology used by the SoC design.
Soft cores provide the standard functions for the application and the device peripherals. In the creation of a platform design, these soft cores must be modified to communicate via a common bus interface. This investment ensures that the reusable components can be easily integrated.
The remaining 30% (or less) of the SoC derivative is comprised of logic that's either created from scratch, adapted from legacy components, or else acquired from third-party providers. This new logic has to also be modified to connect to the design and bus standards dictated by the platform design.
The strength of the SoC reuse platform is in the known value of the architecture. In any design-reuse scenario, the reusable components must adhere to the requirements of the SoC. For typical SoC design, though, these requirements change greatly from design to design depending upon the needs, experiences, and whims of the engineering team. As a result, making a block "reusable" is normally associated with making it work in any possible combination of design styles and tool flows. This is an unrealistic goal for most components, and a terrible time sink for any design organization that goes down that path.
By contrast, the requirements for SoC designs remain constant in a platform design. The reusable components are modified to meet the standards set for the reference design, and only those standards. Reusing design standards, bus connectivity requirements, verification suites, and tool flows allows the platform environment to be tuned to maximize design productivity.
Many design standards support reuse. For the soft cores in the platform, the standards must define guidelines that support synchronous, RTL design implementation. Plus, standards have to define the deliverables required for both the soft and hard cores. These standards should be based on data formats rather than specific tool requirements so that the platform will survive past the obsolescence of a single tool.
Also, the importance of defined documentation standards for reusable components shouldn't be underestimated. The details of these standards will vary between companies and between platforms. It's required that the subset of reusable components adopt a set of common rules for a given SoC reuse platform in a given application.
Of all the necessary standards, the choice of bus structure for the platform design is the most important. Mentor Consulting recommends using standard bus architectures throughout the system. All reusable blocks are then modified to adhere to this bus structure in order to help shorten the SoC integration time.
In most cases, the best choice for the peripherals is a low-speed bus. The lower-performance bus facilitates the use of soft cores by reducing the timing constraints for synthesis. Typically, the peripherals have no performance issues on the low-performance bus. These soft cores can be easily modified to the bus requirement by adding glue logic bridges to the component bus interfaces. The use of external logic to modify the operation of reusable components is preferred to modifying the existing code. This is especially important when using third-party components or legacy designs where designers are less familiar with the existing component code.
A higher performance bus is used to connect the CPU to the memory. Keeping the CPU bus separate from the peripherals allows maximum flexibility when selecting a microprocessor. For the few peripherals that require a higher performance bus, a configurable FIFO and DMA may be added. The CPU bus connects the memories and DMA in the platform. The choice of CPU determines which bus will be used in the system.
By the dual bus structure, the lower-performance peripherals are kept independent from the choice of CPU. This modularity in the design allows the SoC reuse platform to easily swap in and out components as required for the application. All of the components must be modified to interface with their given bus. They are then capable of being easily integrated with other modules on that bus.
Well-defined standards and bus structures constrain the problem space for design reuse. Because of this strategy, the capabilities of the SoC reuse platform may be extended to create a design environment for judicious auto-mation of the SoC design process. A fully configured SoC reuse platform needs to include the platform reference design. Plus, it should offer an infrastructure to support the components that can be connected to the platform (Fig. 2). This will include a library of soft cores for peripherals and standard functions, and hard cores for processors and high-performance components.
A single implementation design flow is used to simplify the deliverables required for design reuse. This design flow is consistent between components and between the SoC derivatives. It allows the integration and verification of the SoC design to be automated too.
Divide And Conquer
Because it's one of the longest segments in the SoC design cycle, verification stands out as a prime opportunity for design reuse to improve productivity. The company utilizes a "divide and conquer approach" to platform verification. First, every component in the design has to work independently before it's assembled. The platform environment might include automated qualification to ensure that all of the elements in the SoC design meet the required standards for integration and verification. The second step is functional verification at the system level.
A complete system-level test for an SoC design will include many milliseconds of simulation time and thousands of lines of stimulus. The focus of this simulation should be on the operation of the system as a whole, rather than specific components. If possible, the simulation should load the boot code for the processor and use software drivers that are identical to those which will be used in the final product. Hardware-software coverification can help speed up the simulations. Aside from creating test scenarios that mimic application code, this methodology has the added benefit of debugging software drivers.
In a platform design, the reusable components and much of the software will have been preverified. Existing tests can be run intact from the platform design environment with automated scripts selecting the verification suites to match the selected components. Engineering time can then focus on providing additional test scenarios and corner cases for the minimal new functionality that's added for the SoC derivative.
By facilitating the reuse of verification suites, embedded software, and hardware design components, platforms can drastically shorten the design cycle for even the largest SoC designs. Successful platforms should include a design environment and infrastructure that allows swapping out existing components for other reusable blocks, or the addition of new circuitry. The known value of the architecture and the bus structure of the platform design help reap the advantages of high-level system design automation. Design reuse will become more prevalent as SoC reuse platforms change the level of engineering decisions from the creation of design components to the composition of system functionality.