For SOC

A System Level IP Integration Methodology For Fast SOC Design

M. Bocchi, C. Brunelli', C. De Bartolomeis, L. Magagni, F. Campi ARCES - University of Bologna, Bologna, Italy

*Tampere University of Technolow, Tampere, Finland

Email: (mbocchi, cdebartolomeis, lmagagni, fcampi)@deis.unibo.it,

Abstract

In the system-on-chip (SOC) era, the growing number of functionalities included on a single chip requires the de- velopment of new design methodologies to keep the design complexity under control. Intellectual property reuse has been commonly employed as

a

In this papec a SOC design plarform is proposed as a solution to this problem, pmviding a library o f I P reusable blocks and a high level tool for SOC design development.

An IP library based on AMBA bus architecture was built, featuring a collection of devices with homogeneous inter- faces described with VHDL language constructs that en- able hardware configurabiliiy A system-level assembler (SL4) was then developed to provide a hardware con$gu- ration tool and a suite of utilities to support the designer work. Once defrned the system structure, the SL4 allows automatic generation of the environments used for software development, simulation. synthesis and verification tasks.

1.

The outstanding growth of transistor count on a single chip, due to technology scaling, combined to market de- mand for low cost products with increasing functionalities leads to great complexity of SOC designs. The situation gets worse considering time to market requirements and the consequent strong reduction of the available time for devel- oping a new design.

In this scenario IP-Reuse is necessary, hut actual methodologies do not provide automatic support for IP blocks selection and mapping; in this sense, IP-Reuse methodologies should be considered as a starting point for developing new design technologies (DT), in order to avoid manual mapping of IP blocks. As suggested in [I], the key- word of this process is unification of the different DT ar-

eas; an integration between hardware system design area and software and verification areas is suitable for fast sys- tem design and verification.

Platform-based design is a good solution for automahog the SOC design process and IP cores descriptions can be more customizable using virtual cores representing IP com- ponents at a higher level of abstraction [2]. Automatic inte- gration of IP cores has been proposed in [3] to reduce error risks and time invested in SOC design.

Nevertheless, SOC platforms generally take care of hard- ware design aspects, not involving other areas of the design flow, such as logic synthesis, verification and software de- velopment. A valid solution to this second aspect has not yet been proposed and the adjustment of the environments at the hasis of these tasks continue to be a highly time coo- suming process. Configurahle processors can he used for speeding up simulation and development time [4], but also this solution is focused on RTL design improvement.

In this paper we propose a new methodology for au- tomating all the tasks run during the Front-End design of a SOC. Comparing to previous works we have developed an alternative method not only for automating the top-level RTL design composition hut also to face the second class of problems previously described.

2.

Design

The design of a new SOCs implies the investment of a considerable amount of time, since several activities need to be completed during the front-end design. These activi- ties include the selection of proper cores, their interconnec- tion through a bus architecture, functional verification, logic synthesis and software compilation to produce test vectors.

Our approach was developed considering that a good platform should unify and automate the greater number of these tasks; referring to figure 1, the entire design flow changes at the top level where a set of tools, named Sys- tem Level Assembler (SLA), allows automatic generation of the files needed to describe the SOC and to configure the previously cited tasks.

0-7803-8160-2/03/%17.00 02003 IEEE.

127

Figure 1. Automatic system level assembling step is included in design flow.

The key element of the entire methodology is the de- scription style of the cores included within the IP library.

Using the capabilities of Hardware Description Languages, in fact, the automation during the hardware selection and interconnection can be achieved changing only some con- stants in the VHDL configuration files. As a consequence, the top level SOC description will not change when config- uring the system, except for the extemal ports; all the com- ponents, in fact, are previously described in a general top level HDL file and their actual insertion will be controlled by several boolean constants contained in a set of config- uration files. This concept is applied hierarchically also to the description of the components, thus obtaining general models instead of fixed hardware functionalities.

Section 3 describes the hardware IP library; once the li- brary has been built, the real platform was obtained devel- oping the SLA, whose features are described in section 4.

3. Hardware IP library

One of the most important parameters conceming the definition of the IP library is the selection of a standard bus architecture to provide an easy and efficient interconnection scheme between the components located on the chip.

The SOC evolution produced the definition of various standards for on-chip communications'; the selection of an appropriate bus architecture is influenced by several factors depending also on the applications the SOC is intended for.

In this work, ARM AMBA [6] specification has been cho- sen to provide an interface between the on-chip devices.

3.1. XiRisc processor

To create a SOC description, at first designers have to choose the IP components to be integrated; this selection

'See [ 5 ] for an updated list of SOC interconnection bus.

could be hard since the functionalities integrated on the chip are strictly dependent on the target application. Above all, defining the processor type is a fundamental issue, Using the platform object of OUT work, the designer can configure the main master of the system starting from XiRisc [7] pro- cessor model. This VHDL model represents a configurable RISC processor enhanced with data and instruction caches.

The basic architecture features a function unit model: each function unit can be inserted into the core simply setting a corresponding boolean constant in a VHDL configuration file. This solution has the big advantage of allowing the pro- cessor model to be tuned on the target application without affecting the external core interface.

XIRISC CORE. The version of XiRisc used in this work is similar to that presented in [7], but features some modifi- cations to improve its performance and reusability. XiRisc supports not only 16-bit and 32-bit datapaths, but also a 32- bit double datapath configuration, for VLIW elaboration.

The System Level Assembler operates on XiRisc allowing the customization of several parameters acting on the pro- cessor architecture. A floating-point unit, called Milk co- processor, can be used as XiRISC coprocessor. l t features a 32-bit data bus, 8 general purpose registers and single preci- sion IEEE 754-1985 computation capabilities. The device can he configured changing many parameters like the in- ternal parallelism and the number of general purpose regis- ters. Various function units, such a s a multiplier, a divider and other DSP-like units can be included in the processor datapath setting only some flags in a VHDL configuration file. Also the intemal parallelism and the number of inter- nal general purpose registers can be controlled hy the user configuration.

The processor configuration task is supported by the SLA, which provides a simplified interface for setting these flags, giving the designer a higher level perspective.

INSTRUCTION AND DATA CACHES. Both cache controllers included in this AHB master, feature high flex- ibility. Memory access policy can be defined at run-time, selecting write-back, write-through or bypass accesses; also cache memories sizes and line widths can be changed main- taining the right size for the tag memories. These features allow the definition of an optimal memory hierarchy, incre- menting the maximum clock speed and lowering the power consumption during memory accesses.

3.2. System Configuration

After XiRisc configuration, the platform generates the entire system structure, including the devices selected by the designer and the logic conceming AMBA AHB/APB communication protocol. Using standard VHDL language constructs, all the bus structure can be redefined affecting bus sizes, address space mapping and the number of mas-

128

t e n and slaves placed onto the bus. Some parameters are automatically generated by the SLA depending on the set of master and slaves to be included in the SOC. Figure 2 displays the devices connection in a typical system contain- ing all the IP library components.

Figure 2. Structure of the system containing all the IP-blocks.

4.

The SLA is a platfonn which allows a high degree of system configurability and customization, providing a user friendly interface; designers using this platform may over- look the system details, controlling only the system-level parameters. This purpose was obtained combining the con- figurable VHDL model of XiRisc, with a parametric system structure and some tools for automatic generation of simu- lation, synthesis and verification environments.

Figure 3 shows how the SLA works; system specifica- tion is the only information the designer has to provide. At a first stage the SLA links these information to the IP li- brary description, generating a list of devices used in the project and collecting a list of the main system parameters.

The second stage is composed by several generators using the previous lists to create the HDL output, the configura- tion files and the environment for software development and

hardware verification.

Figure 3. System-Level Assembler Structure.

4.1. Configuration Analysis

The conjguraiion analyzer is an interface for the selec- tion of several parameters concerning the global system and the single components. This interface is based on a general description of the IP library contained into the IPLD (IP Li-

b r a y Description) file.

IF'LD format allows the description of system parame- ters, including bus architecture and address space mapping.

In addition, each component has a dedicated section (figure 4) containing the list of parameters which can be set by the user and other information used by the SLA for inserting the component into the design, including the bus type (AHB or APB), the device type (master or slave) and the comments to be displayed by the configuration analyzer. A description of this kind simplifies the insertion of new components into the library, since the SLA can recognize them by inserting a new section for each component in the IPLD file.

component XiRisc ( bus (AHB}

type (master)

parameter include-scc (type = boolean, default ⁼ true}

parameter {...}

comment {"This is Xirisc microcantroller model..."}

...

1

Figure 4. Component description within the IPLD file.

The configuration analyzer execution produces an output IPLD file containing, for each parameter, the corresponding value selected by the user.

4.2. Generators

The definition of the devices integrated in the SOC leads to the necessity of creating or changing not only the RTL description hut also the environments for software devel- opment and system verification, which are affected by the parameters fixed during the hardware configuration.

Using the information previously stored in the config- ured IPLD file, several generators have been created for developing the aforesaid environments. Their output con- sists of RTL code, mapping file, device drivers, hardware- dependent routines, simulation and synthesis scripts and test benches. This modular architecture is helpful if new tasks need to be automated, since the environment required by each task is produced by a dedicated generator. The gen- erators commonly use the configured IPLD description and additional information related to the specific environment to set. For example, the generation of simulation and synthesis scripts requires a HDL file list for each component.

129

Figure 5. Software development and hard- ware verification flow.

Figure 5 shows how software development and hardware verification tasks are structured these areas are not so dif- ferentiate, since software flow output is made up of the test vectors used during verification flow. Software devel- opment takes advantage of a suite derived from the open- source GNU-GCC tool chain and built in a joint-project with “Politecnico di Torino”, as described in 191. The main advantage of the entire flow is that all the design process is supported by automatic tools and, except for the software

1P

MAPPING FILE. Some parameters fixed during the hardware configuration, also affect the software environ- ment; in particular, linking the object files needs the correct memory locations to be specified in the mappingfile read by the the linker. These value are fixed by the SLA.

DEVICE DRIVERS AND ROUTINES. Several device drivers are created to control system peripherals; also in this case some adjustments may occur consequently to the ad- dress space definition. Other routines, like the ones used for cache initialization are often hardware-dependent and may change with the information provided by the designer.

SIMULATION AND SYNTHESIS SCRIPTS. The SLA generates automatically the scripts for the compilation and logic synthesis; some options can be set to use these script with different simulators and synthesis tools.

TEST BENCHES. Some modifications are required for test benches depending on the peripherals included in the SOC; for some devices an initialization phase should be provided and additional processes have to be inserted to model off-chip devices.

5.

The platform presented in this paper has been used to produce several SOCs targeted to different applications. A first example is a SOC synthesized on an Altera FPGA to

control a prototype chip [IO] for biological cells manipula- tion. Another recent project [ 111 is targeted to signal elaho- ration applications and consists of a SOC fabricated in 0. I 8 pm, 6 Metal, Standard Cell CMOS technology provided by STMicroelectronics.

In conclusion, the developed platform has been tested on real applications and the main improvements are related to the development time reduction. The platform supports automatic generation of the SOC RTL description through the combination of configurable VHDL constructs and an interface to collect all the necessary parameters. The whole methodology supports easy integration of new cores into the IP library; once the library description is modified, the new components will be inserted into the platform and config- ured automatically. Also the creation of the environments used for software development, functional verification and logic synthesis is automated by several generators contained in the platform.

References

[ I ] “Design, 2001 Edition”, ITRS, 2001, http://~ublic.i~s.net/

[2] Y. Onishi,M. Muraoka, M. Utsuki, N. Tsubaki, “VCore- based platform for SoC design”, Design Automation Con- ference, 2003. Proceedings of the ASP-DAC 2003, Asia and

South Pacific, 2003, pp. 453-458.

131 R. Bergamaschi, S. Bhattacharya, R Wagner, C. Fellenz, M. Muhlada, F. White, J.-M. Daveau, and W. Lee, “Au- tomating the design of socs using cores”, Design & Est of Computers, IEEE, Vo1.18, Iss.5, Sept-Oct 2001, pp. 3245.

[4] C. Rowen, “Reducing SoC simulation and development time”, Computer, Vo1.35, Iss. 12, Dec 2002, pp. 29-34.

[5] “Summary of soc interconnection buses”, Silicore Corpora- tion, http://www.silicorenet/uCbusum.htm

161 “Amba specification (rev. 2.0)”, ARM Ltd, 1999, http://www.arm.com.

[7] F. Campi, R. Canegallo, and R. Guerrien, “Ip-reusable 32- bit vliw risc core”, In Proceedings of the 27th European Solid State Circuits Conference, 2001, pp. 456459.

[8] F. Vahid and T. Givargis, “Platform tuning for embedded systems design”, Computer, Vo1.34, Iss.3, Mar 2001, pp.

112-114.

[9] A. L. Rosa, L. Lavagno, and C. Passerone, “A software development tool chain for a reconfigurable processor”, In Proceedings of the international conference on Compilers.

architecture, and synthesis for embedded systems, Atlanta, GA, November 2001.

[IO] G. Medoro, N. Manaresi, M. Tartagni, and R. Guerrieri,

“Cmos-only sensors and manipulators for microorganisms”, IEEE Inrernarional Electron Devices Meeting (IEDM)), Dec 2000, pp. 415418.

[ I l l E Campi, M. Toma, A. Lodi, A. Cappelli, R. Canegallo, and R. Guemeri, “ A vliw processor with reconfigurahle in- struction set for embedded applications”, In ISSCC Digest of TechnicolPapers, Feh 2003, pp. 25lL251.

130