Simulator Generation Method of Configurable

Processors for MPSoCYoshinori Takeuchi

Osaka University

1MPSoC 2009

Osaka University

Expansion of multi-functional portable multimedia devices requires high performance and low power processing

MPSoC (Multi-Processor System-on-Chip) is a solution to achieve these requirementsMPSoC includes

Several processorsSeveral dedicated functional blocksCommunications on a chip

Background

MPSoC 2009 2

Osaka University

Optimal MPSoC design◦ Repeated evaluation of SoC◦ Selection from a lot of processors, a lot of dedicated

functional blocks and their communications Exploration of MPSoC requires extremely

long time◦ Multi or many-processors requires process

partitioning◦ Processor design itself requires a large design

time◦ MPSoC includes homogenous and heterogenous

MP System◦ Bus or other components affects the performance

Problem of MPSoC design

MPSoC 2009 3

Osaka University

Combination of configurable processor (ASIP) developing environment and high abstraction level description enables efficient SoC simulation◦ Considering process partitioning when generating

simulation model◦ Using configurable processor design environment◦ Using high level abstraction description on

communications

MPSoC 2009 4

Solution for MPSoC evalution

Osaka University

ASIPs, Buses, dedicated HWs

Dedicated HW◦ Memory, Semaphore

Communicationbetween ASIPs

◦ I/O Interface Communication between input/output

ports◦ Special HWs

MPSoC 2009 5

Architecture model of SoC

Memory

Semaphore

Bus A

Bus B

ASIP1

ASIP2

IOI/F

SpecialHW

Example of SoC

Osaka University

MPSoC Evaluation Flow

Processor specification

ASIP design

Simulations

Systemspecification

SystemC desc.of dedicated HW

SystemC desc.of ASIPSoftware

Process mappingto processors

SystemC desc.of bus

Bus modeling

Design Refinement

MPSoC 2009MPSoC 2009 66

Osaka University 7

Evaluation Flow 1/2

T1

T2T3

T4

SystemSpecification

DedicatedHWT3

ASIP1 ASIP2T1 T4 T2

Process mappingASIP specifications

I/OI/F

Memory

SystemC desc. Of HWs

MPSoC 2009MPSoC 2009

Osaka University 8

Evaluation Flow 2/2

DedicatedHWT3

ASIP1 ASIP2T1 T4 T2

Process mappingASIP specifications

I/OI/F

Memory

SystemC desc. Of HWs

Bus modelingASIP1

ASIP2

T1 T4

T2

I/OI/F

Memory Dedicated.HWT3

MPSoC 2009MPSoC 2009

Osaka University

Evaluation Results◦ Bus occupations◦ Execution cycles

Examples of refinements Bus collision

◦ Bus partitioningsoftware refinement

Execution cycles◦ Process remapping◦ Instruction enhancement

MPSoC 2009 9

Evaluation and refinement

Large Busconflicts Bus

partitionEx. Refinement

Osaka University

MPSoC includes many ASIPs◦ ASIP achieves low HW cost, high performance, and

low power using application specific instruction sets◦ Design of ASIP and its SW dev. Environment requires

large man-monthUse of ASIP Design Environment reduces man-

month◦ Input

Processor description◦ Output

Transaction Level Model of ASIP Collects execution information

Software development environment

Problem for MPSoC profiling information

ASIPSoft. Dev.Environment

10MPSoC 2009

ProcessorDescription

Osaka University

Target MPSoC ArchitectureASIPs, special purpose modules, and connections ASIP: Application Specific Instruction set

Processor◦ Enhanced by specific instruction sets

Special purpose module◦ Communication and processing

ex)Memory, IDCT Connections

◦ Arbitration between ASIP and modules◦ ex)Shared bus, crossbar switch modeld in Transaction Level

Ex. of MPSoC

Shared bus

ASIP0 ASIP1

MemoryIDCT

11MPSoC 2009

Osaka University

Our approach Requirements for simulator

◦ Evaluation of total system◦ High speed◦ Accurate evaluation

SystemC◦ Enables System level design◦ High level abstraction & cycle accurate simulation

Propose SystemC based simulator generation from processor ADL description and Bus TL model◦ Extension of HDL generator of ASIP Meister

12MPSoC 2009

Osaka University

ASIP development environment Quick Design Turn Around

◦ GUI based Parameterized Design Entry◦ Behavior Description at Clock Cycle Level◦ Component DB (FHM: Flexible Hardware Model)

Automatic Generation of Application Program Development Tools◦ Compiler, Meta-Assembler Supplied

More Freedom◦ Design from Scratch◦ Design Modification from Pre-Designed Instances◦ Inherit Legacy Processor IPs

Features of ASIP Meister

MPSoC 2009 13

Osaka UniversityMPSoC 2009 14

Configuration of ASIP Meister

FHM-DBMS

Module A

Behavior

RT

GateReport

Compiler &Assembler

Logic Synthesis

Object Code

ArchitectureSpec.

ISS / HDL Simulator

Area, Delay, Power, etc.

Architecture Design Entry (GUI)

SimulationModel Gen

SynthesisModel Gen

Processor SynthesizerSW Development

Tool Generator

ApplicationProgram (C)

Osaka University

Inputs of ASIP Meister

15MPSoC 2009

Processor Description◦ Architecture Info.

Instruction length Pipeline stage length

◦ Used resources Type of resource Resource parameters

◦ Instruction Set Opcode and operand Behavior of each stage

◦ Interrupt Issue condition and its

behavior

Resource◦ Operation units and

memory elements◦ From resource

database Information about

resource◦ Operation type◦ Control signal value

for operations◦ I/O Information

Osaka University

Structure of generated processor

Pipeline Register

Data Path

State Machine

Ctrl.Sig

Ctrl.Sig

PipelineCtrl. Signal

InterruptCtrl. Signal

ControllerTop Level

Resource

MUX

Resource

Resource,MUX

Resource

Repeat stage #16MPSoC 2009

Osaka University

SystemC generation flow

Determine control signals and generate module definitions from processor description and resource database information

Processordesc.

ResourceDatabase

Ctrl. Signalinformation

Definitionof modules

Generationof

SystemCdesc.

SystemCdesc. of

resources SystemCdesc. Of

ASIP

17MPSoC 2009

Osaka University

1.Analyze resource connections and ctrl signals each instruction

2.Merge same resources3.Insert mux and pipeline

registers4.Generate control signals5.Generate module

definition according to types

6.Generate SystemC

SystemC generation from processor description (outline)

A

CInst.1

B

DInst.2

C

A B

DC

A B

DC

Ctl.Sig

Ctl.Sig

StateMachine

ContollerTop PipelineCtl. Sig.

Int.Ctl. Sig

1. 2.

3〜 5.

18MPSoC 2009

Osaka University

Input: Definition of Module Output: SystemC Description

Module name 1. Class definitionDefinition of type of module

Input/output port information Interface definition

2. Port definition Interface definition

Signal information 3. Signal definition

Sub module information Definition of connections

4. Sub module definition Definition of connections

Behavior State machine table Register update Signal assignment

5. Definition of processes

defined by concurrent processes

Module Definition andGenerated SystemC Description

MPSoC 2009 19

Osaka University

Input◦ Module name

Output◦ Definition of module type

using SC_MODULE◦ Initialization using

SC_CTOR

1.Generation of Class DefinitionSC_MODULE(module_name) {

Ports and signals,Definition of submodules

SC_CTOR(module_name) :Ports and signals,

Initilization of submodules

{Connections of

submodules}Process definition

};

20MPSoC 2009

Osaka University

Input◦ Input/output port info.◦ signal

Generation◦ Definition of data type

Bit width data type Simulation time largely

depends on data type Type and signal name

◦ Initialization Constructor with signal

name

2.Generation of Port Definition3.Geneartion of Signal Definition

Bit width W determines typeW = 1 bool2 ≦ W ≦ 64 sc_uint<W>65 ≦ W sc_biguint<W>

// Definitionsc_in< sc_uint<26> > sample;// Intializesample("sample")

21MPSoC 2009

Ex. of 26 bit input port

Osaka University

Input◦ Info. of Submodule

Generation◦ Declarations

Type and instance name◦ Initializations

Constructor(instance_name)

◦ Connections Assign signal to each port

4.Generation of sub module definition

// Declarationsub_module sub1;// Initializationsub1("sub1")// Connectionsub1.dout(signal);

Ex. sub_module type subwith port dout

22MPSoC 2009

Osaka University

1.State machine typeInput

State transition table

Generated processes State update process State control process

5.Generation of Process definition

2.Register type Generated Process

Register update process3.Signal assignment

InputSignal assignments

Generated ProcessSignal assignment

processes

23MPSoC 2009

Osaka University

Process Generation for State Update of State Machine

State update process1. Initialization of reset2. State update at rising clock

SystemC Descriptionvoid change_state() {

if( rst.read() == 1 ) {cur.write(ST_0);

} else if ( clk.event() && clk.read() == 1 ) {

cur.write( next.read() );}

}24MPSoC 2009

Osaka University

Process Generation for Control State Transition of State Machine

Input◦State Transition Table

Generate following descriptions for each state T1.Judgement of current

state2.Output signal3.State transitiona)Condition of transitionb)Next Transition

State: ST_0Output: out 0Condition: if (in=3) goto ST_1...

void manage_state { if(cur.read() == ST_0) { out.write(0); if(in.read() == 3) next.write(ST_1); } ...}

State transition table

SystemC description

25MPSoC 2009

Osaka University

Process Generation for Register update

Register Update process1.Initialize register on reset2.Output signal is updated at rising clock

SystemC descriptionvoid process() {

if(rst.read() == 1) {dout.write(0);

} else if (clk.event()&& clk.read() == 1 ) {

dout.write(din.read());}

} 26MPSoC 2009

Osaka University

Input & Output◦ Input: signal assignment

statement◦ Output: Several processes

Point◦ Process # reduction

Generation1.Goup assignments according

to destination2.Analyze input signals of each

group3.Make processes which have

the same input signal

Process Generation for signal assignment

27MPSoC 2009

Signal assignments in process0

a[0] ← in0a(3,1)← in1

b ← in0

c[0] ← in0

Signal assignments in process1

Osaka University

Signal assignments in process0

SystemC descriptionvoid process0() {

sc_uint<5> tmp_a = a.read();tmp_a[0] = in0.read();tmp_a(3,1) = in1.read();a.write(tmp_a);

}void process1() {

bool tmp_in0 = in0.read();b.write(tmp_in0);sc_uint<3> tmp_c = c.read();tmp_c[0] = tmp_in0;c.write(tmp_c);

}

Examples of Process Generation for signal assignment

a[0] ← in0a(3,1)← in1

b ← in0

c[0] ← in0

28MPSoC 2009

Signal assignments in process1 Some assignmentsare combined for process reduction

Osaka University

Extension of ASIP Meister HDL Generator◦ SystemC description is generated from processor

specification◦ Buses and dedicated HWs are designed by

designer With profiling functions

For high speed simulation◦ Data type selection

Use data type which achieves high speed simulation◦ Reduction of the number of processes

MPSoC 2009 29

SystemC generation

Osaka University

Experiment 1: Confirm the behavior of SystemC description

compared with behavior of VHDL description Target ASIPs

◦ Three ASIPS with different instruction sets and pipeline stages

Simulator◦ Modelsim: VHDL description◦ OSCI Reference simulator: SystemC description

30MPSoC 2009

Osaka University

Objective: Speed check of generated SystemC

MPSoC 2009 31

Evaluation of Generated SystemC

ASIP(instructions,

Pipeline #)ModelSim

VHDLOSCI

SystemC

Speed ratio(SystemC/ VH

DL)ASIP0(6, 5) 174.19s 148.72s 117%ASIP1

(45, 4) 883.10s 526.76s 168%ASIP2(57, 5) 371.24s 291.60s 127%

Simulation time:10^7 cycle instructions

Osaka University

Objective◦ Design time overhead

Target ASIP◦ DLX_integer : 59 instructions, 5 stages, 1 delay

slot◦ Brownie : 45 instructions, 4 stages, 0 delay

slot◦ Brownie+added inst. : 46 instructions, 4 stages, 0

delay slot

Environment◦ Environment : CPU PentiumD 3.4GHz, Memory 2GB◦ Software : OSCI Reference Simulator on Fedora 8

Experiment 2:

MPSoC 2009 32

Osaka University

Single Processor◦ Data Memory

Single Processor+IDCT

Multi Processors◦ ASIPs have Inst. &Data

Memory◦ Communication:

Shared Memory & Semaphore

Target MPSoC Architectures

Global bus

ASIP0

ASIP0

Shared Mem. Semaphore

IDCTDataMem.

Inst. Mem.

Shared bus

ASIP0 DataMem.

Inst.Mem.

Shared bus

Local bus0

DataMem.0

Inst.Mem.0

ASIP N

Local bus N

DataMem.N

Inst.Mem.N

...

Single Processor Single Processor + IDCT

Multi Processors33MPSoC 2009

Osaka University

Evaluation of description

MPSoC 2009 34

Adding instructions

92%

New Design

DLX_integer Brownie0

5,000

10,000

15,000

DescriptionGenerated Model

010002000300040005000

Modified Lines

ProcessorDescription

GeneratedDescription

Osaka University

Evaluation of amount of descriptions excluding processors

MPSoC 2009 35

Single Processor Single P + IDCT Multi Processors0%

20%

40%

60%

80%

100%Reuse Design New Design

82% 66%

18%34%

Osaka University

Evaluation of profiling overhead

MPSoC 2009 36

S=Single Pr., D = DLX_integer, B = Brownie, M = Multi Pr.

0.0

0.5

1.0

1.5 1.361.04 1.02 1.16 1.03 1.03 1.02 1.01 1.03 1.13 1.13 1.18 1.08

1.321.15

Record TimeSimulation Time

Osaka University

Simulator generation method based on configurable processor developing environment and transaction level model bus

SystemC description is generated by extension of HDL generation of processor

Simulator overhead is not so large

MPSoC 2009 37

Conclusion