3DD 1e Laura

Politecnico di MilanoDipartimento di Elettronica e Informazione

Laura Frigerio

[email protected]

A new framework for design and simulation of complex

hardware/software systems

Summary

Sections Contents

Introduction to hw/sw design methodologies

Features and limitations of methodologies for the design of mixed systems

The proposed flow Overview of a proposal for a new framework for hw/sw co-designs

The present framework

Work in progress and future works

Some details about the present hardware framework: the RoadRunner project

Some details about recent projects and ideas for future developments

Introduction to hw/sw methodologies

Present scenario for the development of digital systems: – Growing complexity– Increase of available silicon area – Stringent market requirements

Design flows should– Manage the complexity– Exploit the resources– Short the development time

Among the possible solutions:1. Raise of the abstraction level

2. Mix of solutions targeted to hardware and software domains

3. Reuse of IPs

4. Development of new methodologies

Efficiently fill the productivity gap


1) Raise of the abstraction level:– Could solve some problems of the classical flow

– Pros:• Uniform description• Quicker simulations• Possible exploration of the solution space

Specification

Partitioning

HW descript. SW descript.

Integration

Co-simulation

HW synth. SW gen.

Specification

HW/SW desc.

HW synth. SW gen.

Integration

Simulation

Partitioning

Co-simulation


1) Raise of the abstraction level– Examples:

• SystemC– Homogeneous environment for the description of software algorithms,

hardware architectures and interfaces – Different abstraction levels available – Increase of the simulation speed

• Matlab– Reliable and-well known environment for algorithmic descriptions– Several proposals for the use of Matlab in the design of digital systems

often based on Simulink toolset (e.g., Sinplify DSP)

– Drawbacks:– Poor results of high level synthesis


2) Mix of hw/sw solutions:– These approaches improve performance of the classical flow– Are based on:

• Integration of different languages• Integration of simulation environments

– Drawbacks:• Mixed simulations are still several order of magnitude slower than

those of single language approaches• Impose early system partitioning between hardware and software

3) Reuse of IPs:– Change the granularity at which a design is described– Drawbacks:

• Integration of complex blocks increases the complexity of system verification

• Mostly linked to hardware domain

4) New methodologies…

The proposed flow

The proposed methodology:– Raises the abstraction level in order to allow:

• A uniform description of the system

• The exploration of the solution space

• Faster simulations

– Obtains good synthesis results through a tight connection to hardware and software domains

– Uses back-annotations to allow faster design-loops and a closer control on the underlying architecture

The proposed flow

The proposed flow

Entry point: high-level structural description– The designer specifies which blocks compose the system and

how they are interconnected. Modules are only characterized in terms of their functionality.

The space analysis is performed exploiting a DB of figures for area, time and power consumption values of the blocks

To perform the simulation into a uniform environment, a SystemC model is built– Software encapsulation– VHDL translation– Interface generation

If the timing simulation is not satisfactory a new iteration is performed


Development of the hardware part of the proposed flow Simplified flow:

The framework is based on the RoadRunner toolset composed by:– RRCore: collection of parametric core generators– RRCache: database storing core characterization integrated with

an estimation engine for uncharacterized modules.


Modules composing the library– Atomic IP or atom: very simple module with no internal

hierarchy– Molecular IP or molecule: composite module constituted of

Atoms of Molecules

Hierarchy is obtained combining the generators and not the modules themselves


When structuring the system the designer must:– Instantiate atoms and molecules,– Connect them and– Assign values to parameters

A parameter can be explorable or non-explorable– Explorable parameters can be left unassigned in the design

phase and determined during exploration

The value of a parameter can be fixed or variable– A fixed value is assigned by the designer, a variable one is left

free for the exploration

A value can be defined at top level or at module level– For example the reset value is defined at top level and inherited

by all submodules

Parametric cores

Parameters and values properties

PARAMETERS

Explorable Non-explorable

VALUE

FixedModule X X

Top-level X X

VariableModule X

Top-level X


Three actions are related to the core usage:– Core development: implementation of a C++ class that

generates the VHDL code for the core– Core instantiation: selection of a core into the design. An initial

coarse definition is accepted in order to perform the exploration phase

– Core encapsulation: a core is instantiated in order to create a molecule

Cores are characterized by:– Parameters– Pins– Architectures


Modules have different views:– A coarse view that is exploited during the exploration

• Only the functionality is specified

– A fine view used for the implementation• All the details are defined

A parameter is defined by:– Name, Description, Type, Domain, Default value, Explorability,

Generality, Pin Influence

A pin is defined by:– Name, Direction, Visibility, Msb, Lsb, Description

Each META module has some CONCRETE modules that are implementations of a particular architecuture

META module

CONCRETE module


Simple example: computation of F(A, B, K) = sin (A+B) · 2k

The user specifies only module functionalities and interconnections Each functionality is a META module that is linked to CONCRETE

modules.– ADDER : ripple-carry, carry look-ahead– SINE: LUT, CORDIC pipelined, CORDIC iterative– SHIFTER: arithmetic or logarithmic


The choice of the concrete modules is performed exploiting an estimation engine that relies on a DB that contains module figures for:– Area– Time– Power

Possible solutions are obtained varying architectures and explorable-variable parameters

Finally the VHDL for the system is produced and could be simulated

Several technologies are available

Work in progress

Development of new core generators:– The library is actually based on about 50 generators:

• Adders

• Encoders/Decoders

• Cordic

• Functions approximation

• Memories

• Multipliers

• …

– The development of a new core requires to write a C++ generator for a VHDL module using the RR library. The VHDL is not parametric; parameters are managed by the C++ executable to produce a completely defined VHDL module.

Work in progress

Definition of the graphical interface – Based on QT libraries– Allows the visualization of cores, the setting of parameters, the

connection of cores Definition of the netlist

– Representation of the modules and their interconnection– Based on XML Schemas– Data stored in the netlist:

• Modules data: parameters and pinout• Topology data: connections• Geometry data: positions and colors

Definition of the cache:– DB structure and estimation engine: neural networks and

regression models to extract data for unknown configurations of parameters of technologies

Future work

Future work– Extension to the sw domain

• Managing of hw/sw interface

• Refinement of the SystemC simulation model

• …

– Definition of constraints related to error propagation

Any proposal?– Is this framework suitable for FPGA reconfiguration?– Are generator exploitable for this purpose?– …– What do you think about it?

People

Some references:– Laura Frigerio

• [email protected]

– Fabio Salice• [email protected]

– Carlo Brandolese• [email protected]

– Cristiana Bolchini• [email protected]

mailto:[email protected]




3DD 1e Laura

Business

Transcript of 3DD 1e Laura