Modeling and Simulation of System-on. Platorms. Politecnico di Milano. Donatella Sciuto. Piazza Leonardo da Vinci 32, 20131, Milano

Transcription

1 Modeling and Simulation of System-on on-chip Platorms Donatella Sciuto 10/01/2007 Politecnico di Milano Dipartimento di Elettronica e Informazione Piazza Leonardo da Vinci 32, 20131, Milano

2 Key SoC Market Trends Introduction Continued reduction in time-to-market Fast changing specs, requirements Increasing cost of SoC platform design 10M$ to 100 M$ for today s 90nm SoC s Need to increase time-in-market Implies higher flexibility is needed Majority of all SoC s have 2 or more processors Leading edge (20%) have 6-10 processors Rising proportion SoC function in emb. S/W Currently 50% to 75% of design costs efpga RISC, efpga DSP 2

3 Key SoC Technology Trends Embedded processor speed wall ~1GHz More function requires more parallelism Introduction Parallelism favors lower power solutions Single 625 MHZ processor vs. Three 225 MHz processors 4X less power Homogeneous parallelism favors design for manufacturability, fault tolerance 365mW vs. 3 x 32mW = 96 mw 3

4 What is Next Paradigm Shift? Proc. Control Audio NoC I/O Mem Video Prog. Models Proc. H/W System Applications Video codecs Audio codecs Still image processing Communication stacks 2005: Platform "Insulation" Architecture Platforms Hard-disk drive platform Set-top box, DVD, HDTV Mobile multimedia Still Image processing platform 1995: RTL, ISA "Insulation" Component IP Value-add cores: ASIP, H/W IP Commodity cores: RISC, DSP, Bus Libraries: Cells, memories, I/O 1985: Cell Library "Insulation" months 2 years 2 years 4

5 SoC Programming Model Definition Introduction High-level abstraction of heterogeneous SoC Platform Abstracts Heterogeneity of components Heterogeneity of tools Low-level communication mechanisms Exposes High-level parallelism supported by platform Message passing, shared-memory, streaming Functions performed on all components S/W, H/W, communication, storage, I/O Audio Control RISC NoC I/O Mem Video Video Prog. Model DSP H/W 5

6 Programming Model Objectives Openness Define behavior in terms of components Standard, well-defined interfaces Examples: CORBA, DCOM, C#, Java Introduction Supports Platform Heterogeneity Heterogeneous processor ISA, HLL, O/S Hardware processing elements, I/O Supports multiple forms of Transparency 6

7 The MPSOC Design Problem Introduction Modeling MPSoC Require particular techniques to hide inherent complexity Models have to be flexible, simple yet accurate enough Simulation of MPSoC Fast and accurate simulation of both performance and power consumption are needed Traditional high-level techniques can be used only for functional verification Optimization of MPSoC Designs can be optimized both for power and performance Optimal parallelization of applications to achieve maximum performance improvements 7

8 Transaction-Level Modeling Transaction-Level Power Modeling It is a well-established methodology for modeling complex systems (like MPSOCs) at system level It separates communication from computation Modules: entities that model computation Channels: entities that model communication Modules communicate with the rest of the world by performing transactions A transaction is the operation with which two modules exchange data A word from a processor to a memory The transfer of data between two pipeline stages Etc. 8

9 Modules and Channels Transaction-Level Power Modeling A transaction has function call semantics Data is transferred as a data structure Actual pins and signals are not considered Communication media and protocols are considered separately in channels Module Function Call Port: starts a transaction Channel Module Function Interface: Call associated to a datatype 9

10 Gajski s Diagram Communication A. Specification Transaction-Level Power Modeling Cycle Accurate Approx. timed Untimed A Untimed D C B Approx. timed F E Cycle Accurate B. Component- Assembly C. Bus-Arbitration D. Bus-Functional E. Cycle-Accurate Computation F. Implementation Computation 10

11 Pros & Cons of TLM Transaction-Level Power Modeling Each component can be considered separately! The interaction between components is considered in the communication model Favours code reuse Easy refinement of models Gajski s diagram Combination of multiple abstraction-level models Fast simulation speed A transaction is modeled with function call semantics Easily implemented using imperative languages Hundreds of times faster than RTL simulation No notion of power modeling 11

12 Power Modeling with TLM Transaction-Level Power Modeling Standard approach to high-level power modeling: Define a set of activity indexes (e.g. number of accesses, number of packets routed, etc.) Define a set of parameters (e.g. process technology, capacitance, etc.) Create a relation between indexes and parameters, i.e. a power model Synthesize or implement system and back-annotate parameters into the model Usually performed ad-hoc for a system or component Cannot be easily reused Is this applicable to TLM? Yes, but can we do any better? 12

13 Power Modeling with TLM Transaction-Level Power Modeling As TLM separates communication and computation we can separate power and performance modeling This is particularly effective for MPSOC and platform based design Components are standard and so can be power models Power is a side-effect of model performance Plug-In PM Module PM Channel PM Module 13

14 Probes & Types Transaction-Level Power Modeling Let us assume that a PM is a black box A component c has a type t c and exports a set of variables P c The variables are probes in the component The PM uses P c to produce power data (remember indexes?) What is the applicability of a PM? To exploit multi-accuracy modeling we have to define a type hierarchy 14

15 The domain tree A PM can be connected to any component in its domain tree A PM can consider different levels of probes Transaction-Level Power Modeling Example: Processor Model ARM ARM7TDMI processor RISC DSP ucontroller... ARM9 CycleAccurate MicroBlaze Supported Components... GateLevel... 15

16 Example: assembly level estimation Transaction-Level Power Modeling Models that assign static costs to each assembly instruction executed by a processor The probes can be the current instruction and its execution time The parameters are the costs associated with each instruction Instruction ld [%r3 + %r2], %r4 Execution time Processor energy characterization Power Model Cost Many other models are available in literature that are suitable for this description 16

17 Quick simulation background Multi-accuracy TL Simulation Traditional simulation techniques work well at behavioral and architectural level However, they do not model performance or power consumption i.e. they are useful for functional correctness verification Simulations at register-transfer or gate-level fail in delivering fast results for system-level simulation The use of transaction-level modeling reduces simulation times considerably, maintaining sufficient accuracy TL simulation does not keep pace with increasing system complexity, such as for multi-processor systems-on-chip. 17

18 Basic Idea Multi-accuracy TL Simulation Goals: Speed Be 1 able to simulate as fast as possible Be able to extract probes from a running simulation 0.3 Be able to freely connect and disconnect power models Base idea: The introduction of a methodology to increase TL simulation time Accuracy 0 1 speed using multiple levels of accuracy The idea is that during design, many simulations are needed as 1 the parameters of a system are tuned 0.1 Run simulations at full speed for uninteresting sections of application code Simulation at full accuracy on interesting part Add power models on top of this time 18

19 Key issues Multi-accuracy TL Simulation We need a mechanism to perform control-and-view of the abstraction level at run-time for each entity We need to keep the system consistent Avoid data loss at the switching boundary Minimize the effect of the low-to-high accuracy transition We need a way to stream probe data to the PMs 19

20 Extending TLM with REFLECTION Multi-accuracy TL Simulation We consider each entity an object provided with reflection capabilities Each object exports its own internal state through a standard interface We implemented this via SIDL (SystemC Interface Definition Language), a CORBA-like IDL SIDL allows asynchronous external control of each entity A separate thread handles external requests execution This thread has to be synchronized with the simulation Implements Interface Description TLM Entity Routes Generates Interface Stub External events 20

21 Extending TLM simulators Multi-accuracy TL Simulation At the beginning of the simulation, each objects registers into an Object Request Broker (ORB) The ORB is synchronized with the simulation and routes external requests to all the objects in the system At the beginning it takes control of the simulation kernel running it in a separate thread We implemented the ORB as an extension of the SystemC kernel To allow free access to all variables of a TLM entity we redefine sc_signal as a probe 21

22 Extending the SystemC Kernel Request routing Interface Stub Registration Request Broker External events Implements Start, stop, pause... Multi-accuracy TL Simulation TLM Entity Control SystemC Kernel How do we use this to have multi-accuracy models? Our methodology distinguishes between computation and communication channels 22

23 Multi-level level channels A multi-level channel is a hierarchical channel, containing models of the same interconnect at different levels of accuracy The routing decision is assigned to switchers and mergers Consistency is maintained by keeping a table of the active transactions A transaction starting is always routed through the same channel Multi-accuracy TL Simulation Master0 Master1 Switcher Switcher Channel 1 Channel 2 Source Dest Channel M0T0 S1 1 M1T3 S Merger Merger Slave0 Slave1 23

24 Multi-level level modules Multi-accuracy TL Simulation The solution used for channels cannot be used for modules Module state can be significantly different at different levels of abstraction Keeping two instances of the same module is not useful: the high accuracy instance would be a bottleneck for the simulation However, it is possible to de-synchronize the module from the rest of the system Clocks are one of the main sources of event generation in event-driven simulation Allowing a component to run without generating events can increase simulation speed sensibly Global consistency is preserved by keeping synchronization at the transaction boundary 24

25 A multi-level level processor Multi-accuracy TL Simulation As an example, consider a processor modeled as an ISS A processor doesn t generate a transaction every clock cycle Clock can be shut off when not making transactions This reduces the events that have to be processed by the simulator Obtained inserting conditionals in the SystemC wait() statement In this way, we can have a multi-level processor (cycle-accurate and untimed functional) User Input Breakpoints Control ISS Synchronize Clock Channel 25

26 Adding Power Models Reflection can be exploited to extract probe data from performance models Association Power Models Probes Probes Data Registration Control Multi-accuracy TL Simulation Interface Stub Implements TLM Entity Probes Probes Probes Registration Control Request Broker SystemC Kernel Start, stop, pause... External events 26

27 Channel Experiments Some Examples Tests performed on several benchmarks, among which a full MPEG4 encoder developed at STMicroelectronics Results show a low overhead and speed increase up to 80% and 70% on average 27

28 Module experiments Results show zero overhead and speed increase up to 70% with 50% average Some Examples 28

29 More interesting, trade offs! Using simple or assembly power models for processors is not affected by simulation accuracy! Some Examples 29

30 More interesting, trade offs! Instead, memory models are affected by simulator accuracy Some Examples 30

31 Why MPSOC? Concluding Remarks Multi-level power/performance simulation allows Faster design space exploration Focus on critical application kernels It is very useful to apply the decoupling of TLM to power models Can be attached, detached, changed No effect on performance simulation These techniques are particularly effective for platform-based MPSoC design Standard components Many similar processing elements (many models available) Exploration usually consists of platform parameter changes 31