Hardware / Software Partitioning Methodology for Systems on Chip (SoCs) with RISC Host and Configurable Microprocessors

by Shigeaki Takaki*, Atsushi Masuda*, Hans Eichel**, Goichi Otomo*, Takashi Miyamori*,
Kazuyoshi Kohno*,and Nobu Matsumoto*
* Toshiba Corporation, Kawasaki, Kanagawa, Japan
** Toshiba Electronics Europe GmbH, Duesseldorf, Germany

Abstract :

This paper presents a new hardware/software partitioning methodology for SoCs.  Target architecture is composed of a RISC host and one or more configurable microprocessors.  First, a system is partitioned globally, and only then it is partitioned locally.  In the local partitioning, the co-synthesis technique is used.  We have applied this methodology to an MPEG-2 decoder and obtained good results such as achieving a 36% performance improvement by co-synthesis.

1. Introduction
Recent advances in semiconductor technology facilitate the integration of many million gates on a single chip and result in the integration of Systems on Chip (SoC).  Typical examples of SoC applications can be found in the multimedia domain and in intelligent transport systems.  In those applications, generally, large amounts of data must be processed in parallel.  However, performing such processing by software running on a high-performance processor or only by hardware is not efficient except for a few specific cases.An optimal combination of hardware and software and an optimal system partitioning into hardware and software is most desirable.  

Studies of hardware/software co-design have been made for a long time.  The first methodology is the one of Intellectual Properties (IP) re-use.  As it¡¯s related technology, studies of interface synthesis which is required in building a system based on the IP have been made [1][2]. In this methodology, however, there is a limitation that data processing which is not covered by the existing IP is done only by software.  As another co-design methodology, a method of partitioning a system into hardware and software directly from its specification description, so called co-synthesis, has been studied [3][4][5].  In conventional co-synthesis performance degradation was observed, since the target-architecture was composed of general-purpose processors and a bus (see section 2 for further details).  As an attempt to overcome such problems, work on configurable processors [6][7][8], processor generation and retargetable compilers ([9][10][11]) has been made as well.  The issue of these studies must be how to achieve global optimization by avoiding ending up only in local optimization at the time of hardware/software partitioning.

This paper presents a new hardware/software partitioning methodology with a RISC host processor and one or more configurable embedded microprocessors for time critical tasks.  This methodology aims at unloading the software running on the host from compute intensive tasks by dedicated hardware accelerators.  The major part of the application runs on the host processor, while time critical data processing parts are executed on one or more deeply embedded heterogeneous processors based on a configurable architecture.  Since SoCs are often highly cost-sensitive, optimization of silicon area has the same level of importance as design efficiency to accelerate the SoC development process.  Conventional approaches for hardware-software partitioning focused mainly on EDA aspects, such as algorithm and design flow improvements, which are however not sufficient for the development of cost-efficient SoCs.  Therefore, we have developed a flexible hardware platform based on a configurable processor architecture with various hardware extensions and a hierarchical bus structure[12][13][14]. An EDA based partitioning methodology has been developed to support this platform.

Our methodology is composed of two stages, which we call ¡°global partitioning¡± and ¡°local partitioning¡±.  Although a co-synthesis methodology is used in the local partitioning phase, the problems mentioned earlier are solved by making the target hardware architecture configurable and by improving the scheduling of the compiler .

In Section 2, we explain related conventional studies, especially those of co-synthesis in more detail.  Section 3 discusses the presented partitioning methodology and its target architecture.  The application results of this methodology are described in Section 4 and Section 5 is the summary of this paper.

2. Related Work on Co-Synthesis

The need for co-designing  hardware and software has long been pointed out for the development of SoCs [15] and co-design tools have been developed by many projects.

Co-design can be roughly classified into two approaches, software oriented partitioning [4][16] and hardware oriented partitioning[3][5].  The difference between the two is whether the functional specification model is written as a software model or hardware model.

Most methods are focussing on hardware/software partitioning techniques to transform functional specifications into an optimal system architecture.  Studies of performing optimal hardware/software partitioning by applying proprietary algorithm or methodologies are under way. The method aiming at automatically generating a software model that can be cross-compiled and a hardware model that can be synthesized at a high level by applying the hardware/software partitioning algorithm is called co-synthesis [3][4][5].  One of the merits of co-synthesis is that a hardware model and a software model can be partitioned with little user¡¯s intervention.  However this feature reduces visibility to the designer and hence controllability.  Some co-synthesis methods take the phased approach, where certain  stages are defined in the process to create an optimal system architecture from functional specifications, in which designers can refine the functional specification [17][18].  The merit of this approach is that architectural limitations can be revealed at intermediate stages thus identifying specification problems early that would otherwise come to the surface only in later stages.

As stated above, many methods for system development have been described in the literature. But applying those methods to actual SoC designs is still  difficult due to inherent limitations.

One limitation is that the design process is based on a target- architecture with general-purpose processors and a bus on which ROM, RAM, hardware accelerators, co-processors, etc. are allocated.  It is very hard to estimate execution cycles for the hardware units, because the bus is shared by various data transfers.

It is preferable to use a model that is executable on the target-architecture as specification, because reusability of existing specification models is improved.  Further, it is preferable that the specification model is a software model that can be cross-compiled.  The reason for that is that refinement of the software model will directly influence the performance of the final system.  In conventional co-design methods, a specification model cannot be cross-compiled because languages such as expanded C language or proprietary languages were used such that the specification model can be described in both a software model and hardware model.  Under critical conditions, the difference between the evaluation result where hardware/software partitioning of the specification model was done and the one where only an execution model was used is considerable, and it is very likely that a time consuming repetition of the partitioning process is required.

Finally, despite of recent remarkable developments of  EDA tools, hardware design is still a time-consuming task.  That is why it is important that a system simulation is fast and accurate.  To that end, not only the verification on the RTL (co-verification) level but also on a higher level model such as C-based (co-simulation) must be done.  However, in co-simulation methods, where basic blocks [19][20] of conventional co-design projects are used, the achievable accuracy is not quite satisfactory.

3. RISC Plus Configurable-Processor Platform Methodology

3.1. Top-Down Design Methodology for SoCs

To begin with, let us explain the top-down design methodology for SoCs that is the basis of this entire methodology.  In this top-down methodology the hardware/software partitioning of the system is performed in two stages :¡¡(1) globally and (2) locally.  Then the partitioned system is mapped and implemented on the hardware platform, which will be explained in the next section to obtain the desired SoC.  Fig. 1 illustrates the concept of this top-down design methodology.  The following is the detailed explanations of the global and local partitioning.  

 Fig 1. SoC Top-Down Design Flow

(1) The global partitioning

The global partitioning is done manually based on the heuristics described below.

SoC for digital consumer applications generally consists of two parts: (a) the data processing part, and (b) the application part that controls data processing and communicates with the outside.  Therefore, at first the entire function of the SoC is partitioned into the data processing and the application part.

In the application part, communication with the outside is usually done based on well defined standards, so it can be implemented by an optimised IP block that meets the given standard.  On the other hand, the application itself is usually software-oriented and it can be implemented by software running on a processor.  Usually, the data processing part is composed of multiple tasks.  By bringing those with common I/O data together, the tasks are partitioned into several groups, where each group of tasks is implemented on one processor.  In addition, there are generally tasks that require high throughput and therefore are obviously suited for hardware acceleration.  After having identified such hardware tasks they can be removed from the software model and implemented as hardware.  If done well this hardware can be shared among different tasks in a time-multiplexed manner.         

After partitioning the system based on the above heuristics, the system operation is verified by executing a system simulation.  For high-speed simulation, it is desirable to create a hardware model based on a highly abstractive API.

(2) The local partitioning

After the global partitioning, we partition each task locally based on the greedy heuristics shown below.  The procedure for the partitioning is shown in Fig. 2.

First, we describe the task as a C program (Step 1).  Then, we execute the program to evaluate if it achieves the required performance (Step 2).  If it does not, we obtain profile information (Step 3).  We then change the implementation of the part which was indicated by the profile information, that its processing is the heaviest to the hardware (Step 4).  The way of this change will be described in Section 3.3.  After that, we execute the program again and check if it meets the required performance (Step 5).  By repeating Step 3 to 5 until the required performance is achieved, the partitioning is accomplished.     

Generally, it is highly likely that only the partitioning based on the greedy heuristics ends up in the local optimum far from the global optimum.  In our chosen partitioning methodology, this problem is avoided by partitioning a system in a global manner first.     

Fig 2.  Local Partitioning Flow

3.2¡¡SoC Platform based on RISC Host and Configurable Microprocessor

In this section, we explain the SoC design platform based on the top-down design methodology explained in section 3.1.  Fig. 3 shows an architecture block diagram which represents a general platform for SoCs supposed to  process digital audio and video.  This architecture is composed of two major blocks corresponding to the application part and data processing part explained in the previous section, and a memory shared by these two blocks.

The application part is composed of a RISC processor, which will act as a host, and peripheral IP.  The performance required for the RISC processor varies depending on the target SoC, therefore a suitable RISC  processor is chosen on a case by case basis.  For example, a 32-bit RISC processor was chosen for a low-end SoC for DVD playback and a 64-bit RISC processor was chosen for HDTV and PVR (Personal Video Recorder) SoCs.  Similarly, IPs for I/O  are chosen from USB1.1/2.0, IEEE1394, etc. according to the requirement of the target SoC.

¡¡Since high performance specific to each task is required for the data processing part, it has a heterogeneous architecture composed of customized processors which were designed based on configurable processors and hardware modules.  As a configurable processor, MeP (Media embedded Processor£©[12] is used.

Fig. 4 shows a block diagram which illustrates the basic architecture of MeP SoC.  In this processor, each MeP module in MeP SoC is customized for a specific task.  A MeP module is composed of a MeP core, which is a processor core, and extension units, and it allows optional instructions such as fast multiply-add instructions and modification of the size or configuration of instruction cache/RAM and data cache/RAM.  It also allows users¡¯ own instructions or hardware engines to be attached to the MeP core as extension units.  The local partitioning, to be explained in 3.3, is applied to the customization of MeP modules.  The feature of the MeP module is that it contains a DMA controller, which enables a MeP module to function as an independent functional block including data transfer.  The configuration of the data processing part can be changed module by module.  For example, in the case of the SoC for DVD, the data processing  part is composed of MeP modules for audio decoding and video decoding, and in the case of the SoC for PVR, it is composed of MeP modules for audio CODEC, video CODEC and motion prediction.

Fig. 3 Digital multi media platform

Fig. 4 MeP architecture

3.3. Local Partitioning -- Co-Synthesis Methodology

Now, let us further explain the local partitioning the outline of which was given in 3.1.  The methodology of the local partitioning is twofold: to make use of the addition of users¡¯ own instructions, and to make use of hardware engines.  Since the former has already been explained in [14], we focus on the latter here.  The co-synthesis technology is applied to the latter methodology.

The conventional co-synthesis had limitations mentioned in Section 2.  Therefore, we have developed a new co- synthesis  system in which the target-architecture itself is optimized.  We have prepared a dedicated bus for hardware extensions to the processor.  In the co-simulation phase, it is easy to estimate execution cycles of hardware extensions connected to the dedicated bus and the estimation results of our system have good accuracy.  

We took a software oriented approach and decided to describe the specification model in C language because the specification model can be used as a C program as it is. Also, the C compiler is modified to use latency of hardware units for code scheduling.   While the processings of the hardware unit are being executed, the processor executes instructions which are not related to those processings.

Finally, we determined to generate a C-based hardware model for verification from the C program to conduct verification on the C-level using Instruction Set Simulation (ISS).  This C-based hardware model becomes the hardware architecture specification and it is converted into RTL by our high-level synthesis tool.  This high-level synthesis tool is also able to automatically generate an interface to the bus of the target-architecture and a direct access interface to the local memory in the processor module if necessary.

With the combination of the direct access interface and the compiler¡¯s ability of code scheduling, our co-design system allows reducing the overhead generated during the communication between the hardware model and software model to a minimum.    

From here, we explain our co-synthesis system Hegen. Hegen is a tool which requires a software model written in C language as input, and  automatically generates a C-based hardware model from a part of the software model (to be specific, functions) based on the designer¡¯s simple instructions.  In addition to that, Hegen modifies the software model and incorporates the device driver to control the C-based hardware model automatically, which makes system design free from human error and more efficient.

As shown in figure 5, Hegen can be positioned as the support tool for conducting system design in a top-down style.  Also, it enables the re-design where part of a software model is transformed to a hardware model in the pursuit of further improvement of performance, since the specification model of a existing system can be used for input as it is.

 

 
Fig. 5 System structure.

A design flow with our Co-Design system is as shown in Figure 6

1. Preparation of the C program file to be applied on MeP