Platform approach speeds MIPS-based SoCs

Platform approach speeds MIPS-based SoCs
By Alan Baillie and Simon Hatliff, Tality Corporation, EEdesign
October 19, 2001 (7:53 a.m. EST)
URL: http://www.eetimes.com/story/OEG20011012S0076

The Tality digital IC design team has used a platform design approach based around the industry-standard AMBA bus to tape out many complex systems-on-chip (SoC)s over the last three years. This approach has resulted in a significant reduction in development risk and time-to-market. In this article, we describe our platform approach and the MIPS processor based enhancements that we have developed.

As ICs increase in complexity, verification becomes increasingly difficult, time consuming and error prone. Ensuring that complex SoC designs are correct before they are committed to manufacturing is quickly becoming the major obstacle to effectively using the integration potential provided by advances in silicon technology. Lessons and techniques learned from our initial SoC designs have been applied to the development of a more generic verification infrastructure, and the resulting modular platforms are designed to ease the integration of IP blocks into n ew applications. The methodology acknowledges that an SoC design is not complete until its software is proven. Our solution thus provides an environment for software development as early as possible in the design cycle.

A major concern with SoC designs is that the intellectual property (IP) that is used often comes from many sources. A typical design may contain new RTL from an IP provider, RTL from earlier designs (some of which may have to be upgraded), hard macros (such as microprocessor and DSP cores) and software IP. Unless you have worked with these components before, it is natural that there will not be complete confidence in their correctness.

Accepting that an SoC design will contain some kind of processor, many of the modules will be controlled by software, which means that there is effectively no limit to the types of interaction. A related consideration is that compatible software and hardware are needed for correct device operation. To prove that this has been achieved, it is advisable t o perform at least some software verification before device tapeout.

In our original approach to the verification of SoC designs, we relied mainly on simulating blocks in the integrated environment. Furthermore, a specific simulation environment was developed for each project. Within this environment we developed complex scenarios to mimic system activity and generated random sequences to flush out any problems associated with contentions and other corner cases.

This approach led to long simulation times and large databases of results. Although this is highly inefficient, it is a tempting methodology - because it works. However, our development times were unacceptably long: on our first SoCs it took us eight to fourteen months to reach tapeout. Our target is to complete SoC designs in less than six months.

To enhance our competitiveness and to reduce SoC development time to less than six months, we realized that it was necessary to develop more efficient techniques based around a reusable verific ation platform. A key requirement for the platform was that it should be a suitable starting point for many of our future SoC designs. In addition, it had to be modular and easily extended to provide application-specific verification.

With these requirements in mind our team set about describing a modular and easily extended platform which would be based on leading edge industry standard technologies. Fundamental to the definition of an appropriate platform was the selection of a suitable processor -- and in this case we opted for an implementation based around the MIPS family of processors.

To meet the requirement for modularity and ease of extension, the platform also had to be built around a bus. Because the AMBA protocol has become the de facto standard for interfacing IP, all Tality IP is AMBA compatible. MacroPack is a set of Tality IP components that are usable in an example MIPS 4KC/AMBA 2.0 based design, which we call M4SoC.

Figu re 1: The M4SoC design

The Tality MacroPack includes the following components:

M2AHB - MIPS processor to AHB bridge

AHB2APB - AHB to APB bridge

AHBC - AHB bus controller, i.e. bus decoder and arbiter

SDMC - Synchronous Dynamic Memory Controller

SMC - Static Memory Controller

APIC - Programmable Priority Interrupt Controller

UART - Universal Asynchronous Receiver/Transmitter

SPI - Serial Peripheral Interface

GPIO - General Purpose Input Output Device

RTC - Real Time Clock

TTC - Triple Timer Counter

WDT - Watchdog Timer

PWM - Pulse Width Modulator

A major component in the M4SoC design is the M2AHB, a wrapper to connect the MIPS processor to the AMBA Advanced High-performance Bus (AHB). The M2AHB wrapper supports the MIPS EC 1.0 interface, and converts access to AMBA AHB 2.0, acting as a bus master. Working with a 32-bit data width, it supports single and 4-word burst read/write transfers as well as partial (byte, half-word, contiguous 3 -byte) writes. An address decoder is implemented so that writes to valid addresses give an instant response to the MIPS; the data is buffered and written to the AHB component when possible.

The IP development work was carried out by a Tality design team based on the public domain AMBA 2.0 specifications. The result of this work is that we now have a generic AMBA platform that can be used with any embedded processor. MacroPack is the MIPS-centric version.

Other generally useful functionality has been included in MacroPack. Wait state generation was added to the bridge to allow the Advanced Peripheral Bus (APB) peripherals to hold the bus if necessary. Bootstrap is implemented using flash memory - boot code is pre-loaded into flash before system start-up. This code can itself be a loader if a more complex boot sequence is required.

Verification hierarchy

A key step toward faster SoC development was the definition of a more streamlined simulation flow. This flow aims to ensure blocks are comprehensively tested before integration; use an existing generic simulation environment; and perform mainly structural tests in the integrated environment. Three verification levels have been defined in our methodology: Level 0, Level 1 and Level 2.

Figure 2: M4SoC verification hierarchy

Level 0 testing requires a dedicated testbench for the module under test and is run by the IP provider or block designer. The quality of the Level 0 test is critical - thorough testing must be demonstrated before integration. Code coverage analysis is applied to check test quality. Level 1 tests are register access tests, which run in the integrated environment and are implemented as MIPS code. Their purpose is to confirm that components are correctly integrated into the AMBA environment. An in-house tool has been developed to automatically generate the tests.

Figure 3: Level 1 test gener ator

Input of register details is via a simple definition file. It includes: Address in memory map, type (read-only, write-only, read/write), reset value, and read and write masks if necessary. Besides outputting tests in the form of assembly code, the tool creates header files with details of the memory map. Because these files are used in device and testbench code, this provides a means of easily reconfiguring the memory map.

The final verification stage that has been defined is Level 2. These tests are intended to verify correct operation of all interfaces - they are not an in-situ test of all functionality. Libraries of C functions are being developed for each piece of IP that can be called to initiate a test, check results and provide status. Modules with external interfaces are instantiated twice and connected to each other where possible (e.g. UART, GPIO). Test modules can also be hooked into the testbench where required. Toggle coverage analysis of module pins is used to verify that all i nterface pins are put into all possible states.

Testbench

Figure 4: Simulation environment

For Level 1 and 2 testing of the M4SoC, the above testbench was defined. It includes external memory and connections between modules which have external interfaces - UART, GPIO and SPI (two of each are included in the design).

The testbench is designed to match the emulation environment defined later, so that only a single set of tests need to be written which can be run in simulation or emulation. Maintaining a single set of tests cuts down on development time and makes for a faster time to market.

Test code is compiled and pre-loaded into a flash memory model from which it is executed by the MIPS cycle-accurate simulation model. Using this model gives a significant speed increase over simulating the full MIPS RTL. Output from the tests is delivered via the display, which is made to look to the software like the ASCII display on the emulation board. Its function is to provide meaningful error and status messages as simulation proceeds.

In the simulation model, when the processor writes to the ASCII display address, it is translated to the appropriate text message, then output to the screen and to a log file. This technique minimizes the number of processor simulation cycles required to output text, and retains the compatibility between the simulation and emulation environments. The testbench has been designed to be easily extended as the M4SoC is customized to provide customer solutions.

Emulation

There are many reasons for concluding that it is necessary to provide an emulation solution as part of an SoC platform.

High on the list is the common need to develop hardware and software at the same time. If this methodology can be adopted, it shortens the critical path in system design.

We would also strongly recommend that evidence of correct system operation be furnished before an SoC device is taped out. This means that at least some software should be run on a device model. A further consideration is that our hardware engineers still insist on exercising sequences of conflicts and random behavior before taping out a device.

It is simply not possible to satisfy all of the above using simulation alone - the performance limitations lead to unacceptably long run times and debug cycles. So we decided that we had to provide a facility for prototyping MIPS-based SoC devices.

Our prototyping environment is based on the SEAD-2 board from MIPS, which contains a bonded-out MIPS 4Kc core and a single high-capacity FPGA plus SDRAM, SRAM, flash memories and an 8-character ASCII display. There are also sockets to allow extension via a daughterboard. The achievable performance is obviously design dependent; by default the board is clocked at 12 MHz, and this is the frequency we are using with the M4SoC design.

For software development and FPGA programming, the board connects to a PC using a USB interface. Softw are is developed in the UNIX environment, cross-compiled targeting the MIPS, then pre-loaded into flash memory via this interface.

Platform enhancements

As we use our platforms for customer projects, we continuously improve their capabilities. New AMBA-compatible IP is constantly being developed and further components are regularly introduced. Examples of our current offerings are a configurable memory controller, encryption co-processors, Ethernet MACs, and the Tality Bluetooth, GPS and HPNA IP cores.

Our repertoire of verification techniques is also being extended. In particular we have carried out pilot projects to evaluate the transaction-based verification approaches being promoted by Cadence and others. We anticipate that the resulting reusable modules will make it easier to create testbenches, especially for Level 0 verification.

Summary

We have taken our generic platform and developed the necessary bus-to-bus bridge IP required to integrate the MIPS processor. Bund led with a number of general interfaces and functions typically required in SoC design, we now have a MIPS specific platform that enables a low risk, fast turn-around solution to SoC design.

Simon Hatliff and Alan Baillie are Senior Service Managers at Tality Corporation. Tality is the world's largest independent provider of engineering services and intellectual property (IP) for the design of complex electronics systems and ICs. MIPS Technologies, Inc. is a leading provider of industry-standard processor architectures and cores for digital consumer and network applications. MIPS Technologies (www.mips.com) and Tality (www.tality.com) have partnered to deliver SoC Solutions for MIPS-Based(tm) Technology.