Inria / Raweb 2004
Project-Team: DaRT

Search in Activity Report, year 2004:
HELP

INDEX

Project-Team : dart

Section: Scientific Foundations


Keywords: SystemC, TLM.

SoC Simulation

Participants: Ahmad-Chadi Aljundi, Pierre Boulet, Jean-Luc Dekeyser, Samy Meftali, SmaÔl Niar, MickaŽl Samyn, JoŽl Vennin.

Many simulations at different levels of abstraction are the key of an efficient design of embedded systems. The different levels include a functional (and possibly distributed) validation of the application, a functional validation of the application and and architecture co-model, and a validation of a heterogeneous specification of an embedded system (a specification integrating modules provided at different abstraction levels). SoCs are more and more complex and integrate software parts as well as specific hardware parts (IPs, Intellectual Properties). Generally before obtaining a SoC on silicium, a system is specified at several abstraction levels. Any system design flow consist in refining, more or less automatically, each model to obtain another, starting from a functional model to reach a Register Tranfert Level model. One of the biggest design challenge is the development of a strong, low cost and fast simulation tool for system verification and simulation.

The DaRT project is concerned by the simulation at different levels of abstraction of the application/architecture co-model and of the mapping/schedule produced by the optimization phase.

Abstraction levels

Design flow systems allow the description of system modules (IPs) mainly at four levels of abstraction (this is the case of SystemC [46]):

Untimed functional level (UTF):

a model is similar to an executable specification, but no time delays are present at this level. Shared communication links (buses) are not modeled either. The communications between modules are point to point, and usually modeled using FIFOs.

Timed Functional Level (TF):

it is similar to UTF but timing delays are added to processes within the design to reflect the timing constraints of the specification and also to process delays of the target architecture.

Transaction Level (TLM):

the communication between modules is modeled using function calls. At this level the communication model is accurate in term of functionality and often in term of timing (model the transaction on the buses but not the pins of the modules).

Register Transfert Level (RTL):

it is the lowest level in a SystemC design flow. The internal structure accurately reflects the registers and the combinatorial logic of the target architecture. The communications are described in details in terms of used protocols and timing. Each module's behaviour corresponds exactly to the behaviour of the physical module.

Contribution

The results of DaRT simulation package concerns mainly the UTF level and the TLM level. We also propose techniques to intercat with IPs specified at other level of abstraction (mainly RTL).

At the UTF level: we have developed a Distributed Kahn Process Network environment. The result of this simulation guarantees the functionality of the application model. By the observation of the FIFO sizes we are able to transform the application to improve the load balance of the system. The distributed aspect of this simulator permits to associate IPs from different builders available on different websites.

At TLM level: From the association model of our ``Y-model'', we are able to simulate the application and the architecture of the SoC in the same time. The results expected from this simulation cover the schedule of elementary tasks, the mapping of the data parallel structure on hierarchical and parallel memories, and the communications involved by this mapping. At this level, our models still PIM.

At RT level: In order to get physical implementations of our applications, we are developing an RTL metamodel. Models at this level will be obtained by transformation from those represented at TLM.

At SystemC level: we propose some generic wrappers to allow multilevel abstraction interoperability. A special effort was done to support distributed and heterogeneous simulation framework (see figure†6).

Figure 6. Distributed SystemC Simulation
distSC

Co-simulation in SystemC

From the association model, the Gaspard environment is able to produce automatically SystemC simulation code. The MDA techniques offer the transformation of the association model to the SystemC Gaspard model. During this transformation the data parallel components are unrolled and the data dependencies between elementary tasks become synchronisation primitive calls.

The SoC architecture is directly produced from the architecture model. A module in SystemC simulates the behaviour of tasks mapped to a particular processor. Other modules contain the data parallel structures and are able to answer to any read/write requests. The communications between tasks and between tasks and memories are simulated via communication modules in SystemC. These last modules produce interesting results concerning the simultaneous network conflicts and the capacity of this network for this application.

MickaŽl Samyn is developping a PSM metamodel to allow automatic SystemC code generation. A PIM association model is first transformed into a model of this PSM metamodel and this model is then automatically transformed into SystemC code. This developpment is integrated in the Gaspard prototype and uses the MDA Transf tool (see the software section).

Multilevel distributed simulation in SystemC

A multilevel simulation model is an executable specification containing a set of modules described at different abstraction level (ex an UTF IP coupled with an RTL IP). Our contribution is the proposal of a new methodology to validate SoCs by simulation†[7]. With this new approach, we can perform a fast and low cost simulation of an assembly of IPs. At the opposite of existing solutions, we do not impose the usage of external libraries. Our solution is based on an internal SystemC library and a rule description language. We generate a simulation module adapter to encapsulate one of the two interconnected modules.

In the same idea of IP integration, we develop a distributed runtime for SystemC using sockets or Corba†[8]. With this first implementation of a distributed SystemC, it is now possible to create a SoC with IPs selected from different providers.

Both the multilevel† [14] of abstraction runtime and the distributed runtime offer to SystemC the possibility to support a real co-design from world distributed IP providers. JoŽl Vennin has started a Ph. D. with Prosilog on this suject.

TLM: Transactional Lavel Modelling

Transactional Level modelling (TLM) appeared during the very few last years. It consists in describing systems following defined specifications of some abstraction levels called TLM levels. In these later communication uses function calls (e.g. burst_read(char* buf, int addr, int len);). The major aims of TLM modelling are:

Now-a-days, this modelling style is widely used for verification and it is starting to be used for design at many major electronic companies. Recently, many actions and challenges have been started in order to help to proliferate TLM. Thus, several teams are working to furnish to designers standard TLM APIs and guidelines, TLM platform IP and tools supports. SystemC is the first system description language adopting TLM specifications. Thus, several standardization APIs have been proposed to the OSCI by all the major EDA and IP vendors. This standardization effort is being generalized now by the OSCI / OCP-IP TLM standardization alliance, to build on a common TLM API foundation. One of the most important TLM API proposals is the one from Cadence, distributed to OSCI and OCP-IP. It is intended as common foundation for OSCI and OCP-IP allowing protocol-specific APIs (e.g. AMBA, OCP) and describing a wide range of abstraction levels for fast and efficient simulations.

Due to all TLM's benefits, we defined a TLM meta model as a top level point for automatic transformations to both simulation and synthesis platforms. Our TLM meta model contains the main concepts needed for verification and design following the Cadence API proposal. But, as we are targeting multi-language simulation platforms, the meta model is completely independent from the SystemC syntax. It is composed mainly by two parts: architecture and application. This clear separation between SW and HW parts permits easy extensions and updates of the meta model.

The architecture part contains all necessary concepts to describe HW elements, of systems, at TLM levels. The SW part is composed mainly by computation tasks. They should be hierarchical and repetitive. A set of parameters could be attached to each task in order to specify mainly the scheduling dependently of the used computation model. Thus this meta model keeps hierarchies and repetitions of both the application and the architecture. This permits to still benefit from the data parallelism as far as possible in the design (simulation and synthesis flow). In fact, the designer can choose to eliminate hierarchies when transforming his TLM model into a simulation model, and to keep it when transforming into a synthesis model.

Network on Chip (NoC) design and performances estimation

Modern SoCs are very complex and integrate more and more heterogeneous IPs. Due to this complexity, designers need high performance interconnection components. These later have to be also, as much as possible, flexible to support new applications. This kind of interconnection IPs is unfortunately not available until today. In fact, designers still use buses and simple point-point connections in their designs.

Our contribution in this domain is the proposal of an open Network on Chip library for SoCs design. The NoCs will be mainly an adaptation, for embedded systems, of those proposed by Ahmad-Chadi Aljundi, and Isaac Scherson†[11], [12] for classical multiprocessor architectures. Performances of these networks have been proved, and we believe that such a library will permit the integration of more and more IPs on a chip in a systematic way. This library will be also a support and a completion of existing open SystemC IP libraries as SoCLib.


previous
next