Institute for Communication Technologies and Embedded Systems

GRACE++ (NoC) - Methodology

System Level Design

A SystemC based Methodology for Function/Architecture Co-Design

One of the most challenging tasks in modern System-on-Chip design projects is to map a complex application onto a heterogeneous architecture in adherence to the specified performance and cost requirements. Under stringent cost constraints, the required flexibility and performance is best delivered by a heterogeneous system architecture employing standard as well as application specific programmable architectures and dedicated hardware blocks. As a result, the designer faces a huge design space and has to compose a system architecture from various kinds of building blocks in order to meet the constraints of the specific application.

The traditional design flow is subdivided into two decoupled phases. First the functionality of the system is defined during the algorithm exploration phase, which is usually performed with application specific tool and library support (e.g. SPW (Signal Processing Designer) and COSSAP for wireless communications or OPNET for networking). In the second phase of the design flow, which bases on the specification derived from the algorithm, the different IP blocks for the processing elements and the communication architecture are chosen and the NoC-aware MP-SoC protoype is implemented. This traditional approach is no longer feasible for the design of large heterogeneous systems on a single chip, because quantitative architectural considerations are not taken into account prior to the implementation phase. Due to the high level of detail of implementation models, they are only optimized locally and system architecture tradeoffs and optimizations are not exploited.

For that reason we propose a new design flow were an intermediate phase in the design flow, as depicted in the figure below, is added. On base of the GRACE++ extensions of the SystemC library first an NoC-aware MP-SoC prototype is implemented, which is used to determine the necessary IP blocks for the overall architecture. Later on the NoC-aware MP-SoC protoype is implemented by a refinement of the abstract exploration model of the MP-SoC platform.

The GRACE++ methodology covers the system level design domain in the figure above, i.e. after the algorithmic exploration is finished and when the optimal architecture executing the functionality is to be defined. Generally, the SoC architecture can be seen as a set of parallel communicating blocks. To capture the complete functionality and to enable abstract architecture mapping, the functionality is first to be partitioned into SystemC modules. According to our methodology the SystemC process network is constructed to fulfill the following requirements in system level design:

  • simulation speed and modeling efficiency is mandatory to handle the high complexity of SoC designs.
  • separation of interfaces and behavior enables successive refinement of communication and structure.
  • separation of timing and behavior allows efficient profiling of functional blocks mapped to alternative architectures.

In the next design step, the functional model is mapped to the intended target architecture in order to create a performance model of the resulting system architecture. The mapping is performed virtually by annotating the timing characteristics of the target architecture to the functional model, thus the methodology enables a very fast exploration of different design alternatives. The process of timing annotation is completely orthogonal to the functionality, hence the previously validated functional system behavior remains unchanged. Please refer to the AVALON case study for an exemplary description of the virtual architecture mapping procedure.

Due to GRACE++ methodology an iterative design flow is made available, which can be subsumed with the following:

  • Starting from the application model the functional tasks for the processing elements are extracted and implemented as pure functional tasks.
  • Together with the configuration of the architecture, like the architectural elements (processing & communication architecture) provided by the GRACE++ library , the mapping of the tasks to these processing elements and the timing configuration of the tasks a simulation performance model is gained.
  • After simulation the results are investigated if the specified MP-SoC achieves the requirements of the applications specification.
    1. If the requirements are met a possible MP-SoC architecture is found.
    2. If not the system architect can easily change the configuration files and specify a new architecture or a different application-to-architecture mapping and can evaluate this by running the simulation. This iterative loop can be done until the final architecture is found.

 

The final system architecture model also serves as an executable specification for the  hardware and software implementation, which are integrated into the system context via our co-simulation interface.