• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
3DD 1e Laura
 

3DD 1e Laura

on

  • 400 views

 

Statistics

Views

Total Views
400
Views on SlideShare
398
Embed Views
2

Actions

Likes
0
Downloads
7
Comments
0

2 Embeds 2

http://www.dresd.org 1
http://www.techgig.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

CC Attribution-NonCommercial LicenseCC Attribution-NonCommercial License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

3DD 1e Laura 3DD 1e Laura Presentation Transcript

  • 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:
      • Raise of the abstraction level
      • Mix of solutions targeted to hardware and software domains
      • Reuse of IPs
      • Development of new methodologies
    Efficiently fill the productivity gap
  • Introduction to hw/sw methodologies
    • 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
  • Introduction to hw/sw methodologies
    • 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
  • Introduction to hw/sw methodologies
    • 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
    • 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
    • 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
  • The present framework
    • 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.
  • The present framework
    • 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
  • The present framework
    • 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
    X Top-level X Module Variable X X Top-level X X Module Fixed VALUE Non-explorable Explorable PARAMETERS
  • The present framework
    • 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
  • The present framework
    • 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 , V isibility , Msb , Lsb, Description
    • Each META module has some CONCRETE modules that are implementations of a particular architecuture
    META module CONCRETE module
  • The present framework
    • Simple example: computation of
    • F(A, B, K) = sin (A+B) · 2 k
    • 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 present framework
    • 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_address]
      • Fabio Salice
        • [email_address]
      • Carlo Brandolese
        • [email_address]
      • Cristiana Bolchini
        • [email_address]