Upload
agatha-golden
View
221
Download
0
Tags:
Embed Size (px)
Citation preview
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 ASIP
Software
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
DedicatedHW
T3
ASIP1 ASIP2
T1 T4 T2
Process mappingASIP specifications
I/OI/F
Memory
SystemC desc. Of HWs
MPSoC 2009MPSoC 2009
Osaka University 8
Evaluation Flow 2/2
DedicatedHW
T3
ASIP1 ASIP2
T1 T4 T2
Process mappingASIP specifications
I/OI/F
Memory
SystemC desc. Of HWs
Bus modeling
ASIP1
ASIP2
T1 T4
T2
I/OI/F
Memory Dedicated.HW
T3
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
ASIP
Soft. Dev.Environment
10MPSoC 2009
ProcessorDescription
Osaka University
Target MPSoC Architecture
ASIPs, 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
C
Inst.1
B
D
Inst.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 Definition
SC_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 bool
2 ≦ 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 process
3.Signal assignment Input
Signal 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 Generation
1.Goup assignments according to destination
2.Analyze input signals of each group
3.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] ← in0Signal 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
ASIP0DataMem.
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 Processors
33MPSoC 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
0
1000
2000
3000
4000
5000
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.36
1.04 1.021.16
1.03 1.03 1.02 1.01 1.03 1.13 1.13 1.181.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