modelling, simulation, and advanced tracing for extra ... · i modelling, simulation, and advanced...

I Modelling, simulation, and advanced tracing forextra-functional properties in SystemC/TLM

Philipp A. Hartmann

[email protected]

OFFIS Institute for Information TechnologyR&D Division Transportation

September 24, 2013

ESCUG’28Paris, France

Philipp A. Hartmann Modelling extra-functional properties in SystemC September 24, 2013

http://www.offis.de

mailto:[email protected]

http://www.offis.de

I 1 Motivation

ProblemI Power consumption becomes increasingly

important for (mobile) embedded systems

BackgroundI Limited increase in battery capacity

I Improved power management needed1G

2G

2.5G

3G

4G

1

10

100

1.000

10.000

1.000.000

10.000.000

100.000

Performance Shannon‘s law2x in 8.5 months

Moore‘s law2x in 18 months

1980 1984 1988 1992 1996 2000 2004 2008 2012 2016 2020

Memory accesstime2x in 12 years

Eveready`s law(Battery energydensity)2x in 10 years

Powerreduction

Algorithmiccomplexity

CPU-memorybandwidth

Source: Jan M. Rabaey

ChallengesI Complex, distributed HW/SW systems

I Heterogeneous hardware platforms

I Optimization needs real usage scenarios

Virtual Prototype based solutionI Full system simulation at high speed

I Block level power tracing

I Verification of power intent

Goal: Power-aware Virtual Platforms for Analysis and Optimisation


http://www.offis.de

http://www.offis.de

I 2 Outline

1 COMPLEX Power-Aware Virtual Prototyping

2 Scalable System-Level Power Model

3 Advanced tracing for TLM Virtual Platforms

4 Medium-term standardisation

5 Conclusion


http://www.offis.de

http://www.offis.de

I 3 OutlineCOMPLEX Power-Aware Virtual Prototyping

1 COMPLEX Power-Aware Virtual PrototypingBasic Approach / Enabling Technologies




5 Conclusion


http://www.offis.de

http://www.offis.de

I 4 COMPLEX projecthttp://complex.offis.de

COdesign and power Management inPLatform-based design-space EXploration

I European Integrated Project (2010–2013)

I Goal: Highly efficient and productive designmethodology and a holistic framework for iterativelyexploring embedded HW/SW applications based onpower-aware virtual prototyping in SystemC.

executableSystemC™ model

powercontroller

HW/SW task separation &testbench generation

custom HWestimation

custom SWestimation

virtual system generator withTLM2 interface synthesis

power & timing awareSystemC simulation

model

BAC++

BAC++

HW

task

s

Sys

tem

C

es

tim

ati

on

& m

od

el g

ene

rati

on

sim

ula

tio

n

SW

task

s

ex

ecu

tab

les

pe

cif

ica

tio

n

architecture/platform

description

IPcomponents

Sys

tem

C

IP-X

AC

T


http://www.offis.de

http://www.offis.de

I 5 Basic Approach / Enabling TechnologiesCOMPLEX Power-Aware Virtual Prototyping

I Extra-functional model for timing and powerI Explicit separation of functional and extra-functional modelI Activity model for (dynamic) powerI Scalable physical/technology power model

for frequency, supply voltage, and temperature

I Automatic timing and power annotation techniquesI Embedded Software: Annot. from cross-compiled binaryI Custom Hardware: Annot. from power aware HL-synthesisI Black-Box Hardware IP: Power State Machines

I Scalable Timing and Power Tracing infrastructureI Timing and Power Tracing Streams per observable VP blockI Processing with filters (e.g. aggregation, averaging, selection)I Dynamic granularity (e.g. area of interest)

executableSystemC™ model

powercontroller

HW/SW task separation &testbench generation

custom HWestimation

custom SWestimation

virtual system generator withTLM2 interface synthesis

power & timing awareSystemC simulation

model

BAC++

BAC++

HW

task

s

Sys

tem

C

es

tim

ati

on

& m

od

el g

ene

rati

on

sim

ula

tio

n

SW

task

s

ex

ecu

tab

les

pe

cif

ica

tio

n

architecture/platform

description

IPcomponents

Sys

tem

C

IP-X

AC

T


http://www.offis.de

http://www.offis.de

I 6 OutlineScalable System-Level Power Model


2 Scalable System-Level Power ModelRequirementsSystem-level Parameters



5 Conclusion


http://www.offis.de

http://www.offis.de

I 7 RequirementsScalable System-Level Power Model

I Define set of relevant parameters for system-level modelling ofextra-functional properties (power, temperature)

I Simplicity: Only use those (dynamic) parameters needed for current use case(e.g. ignore area, when not looking for thermal behaviour)

I Composability: Derive combined values from physical relations between individual contributors(total power, temperature-dependent power, capacitance-based power)

I Hierarchy: Put parameters on “correct” geometric level,inherit parameters from context/environment

I Adaptivity: Changing parameters during run-time,→ support for dynamic power management

I Integration with common extra-functional tracing/introspectionI Hierarchical recording of power informationI Flexible adaptation to granularity of selected power modelI Strongly typed (C++) physical units support, to avoid composition errors


http://www.offis.de

http://www.offis.de

I 8 System-level ParametersScalable System-Level Power Model

System

- Technology- Process Variation- IR Drop- … ??

Design param.

Die

Power Domain

Module

DynamicActivity

Power Domain

Module

Module

Die

Position (x,y,z)

Geometry

Area [m²]Neighbourhood

Thermal- Ambient temperature [°C]- Module temperature [°C]

Power DomainPower Domain

Module

Module

Power ModesSupply voltage [V]Clock frequency [Hz]

Switchedcapacitance [F]

Leakingconductance [G]Module

DynamicActivity

Dynamic power- Annotation- PSM

Static power- Leakage [W]


http://www.offis.de

http://www.offis.de

I 9 System-level ParametersScalable System-Level Power Model

I Building blocks for an application-specificpower modelI Design ParametersI Dynamic annotation sources

I Parameters and value sources attached tostructural elements (modules)I Parameters inherited from surrounding hierarchy,

if not in local scope

I Physical units supported via Boost.Units

System

- Technology- Process Variation- IR Drop- … ??

Design param.

Die

Power Domain

Module

DynamicActivity

Power Domain

Module

Module

Die

Position (x,y,z)

Geometry

Area [m²]Neighbourhood

Thermal- Ambient temperature [°C]- Module temperature [°C]

Power DomainPower Domain

Module

Module

Power ModesSupply voltage [V]Clock frequency [Hz]

Switchedcapacitance [F]

Leakingconductance [G]Module

DynamicActivity

Dynamic power- Annotation- PSM

Static power- Leakage [W]

I Hierarchical processing of derived values by subscribing to value sources, e.g.

Pdyn(t) =1

2V 2

ddf · C(t)

C(t) average switched capacitance per cycle (dynamic annotation)Vdd , f supply voltage, frequency (static parameters)

Pdyn(t) processed function for dynamic power dissipation


http://www.offis.de

http://www.offis.de

I 10 OutlineAdvanced tracing for TLM Virtual Platforms



3 Advanced tracing for TLM Virtual PlatformsStream-based Trace RecordingHierarchical Tracing & ProcessingConfigurable Backends


5 Conclusion


http://www.offis.de

http://www.offis.de

I 11 Advanced tracing for TLM Virtual PlatformsGeneral overview

I Problem: Flexible tracing of physical quantities not directly possible in SystemCI sc_core::sc_trace not flexible enough (tied to simulation time)I sca_core::sca_trace is SystemC AMS-specific and not widely supportedI SCV transaction recording not really appropriateI Advanced instrumentation partly available in commercial tools

I Goal: Enable flexible and configurable tracing of extra-functional propertiesin TLM-2-based virtual platforms

I Integration with temporal-decouplingI Independence of current simulation time needed!

I Hierarchical (pre-)processingI Compute derived quantities (→ power model)I Filtering and data reduction (aggregation, averaging, selection)I Collection of user-defined performance metricsI Run-time configurable granularity (Region of Interest)


http://www.offis.de

http://www.offis.de

I 12 Stream-based tracing of extra-functional propertiesAdvanced tracing for TLM Virtual Platforms

I Tracing is based on (time,value) streams per componentI A timed_stream<T> is a hierarchically named SystemC objectI Strongly-typed values for type safety with support for physical units (Boost.Units)I Fine granular control over (local) time offset, synchronisation with a local clock

I push APIs for both absolute (start, value, [duration]), or relative (value,duration) tuplesvoid push( value_type const & value

, time_type const & duration = sc_core::SC_ZERO_TIME ) = 0;void push( time_type const & offset, value_type const & value

, time_type const & duration = sc_core::SC_ZERO_TIME ) = 0;

I Non-overlapping tuples enforced by MergePolicy (e.g. accumulate, overwrite, error)

I Explicit commit/sync API to advance stream clocksvoid commit(); // commit all pending pushesvoid commit( time_type const & offset ); // commit until offset

time_type sync(); // commit & synchronisetime_type sync( time_type const & offset ); // ... until offset

I Caveat: Determine efficiently, when all requests at a particular time have been completed!)!


http://www.offis.de

http://www.offis.de

I 13 Hierarchical Tracing & ProcessingAdvanced tracing for TLM Virtual Platforms

I Hierarchy of (user-defined) stream processors & sinksI Streams can be processed by an extensible set of

(pre-)processorsI Hierarchically connected during simulationI Combine / convert / reduce values during simulationI Sinks can write streams to storage backends for offline analysisI Stream processors are triggered by stream updates

I A power model is just a specific stream processor,combining activity information with physical parameters

I Automatic stream separation and merging of multipleinitiators optionally supported for temporal decouplingwith overlapsI Example: Accumulate overlapping power consumptions due to

loss of time resolution→ retains total energy consumption


http://www.offis.de

http://www.offis.de

I 14 Configurable BackendsAdvanced tracing for TLM Virtual Platforms

I Several backends are supportedI Statistics/metrics collection, report generationI sc_trace-based implementation (with limited decoupling support)→ (processed) streams may not lag behind simulation time

I Custom VCD file backend (with sc_trace compatibility)I Synopsys VP Explorer integration (based on vendor-specific instrumentation API)

I Custom backends can be added transparentlyI Traits classes for value types, providing conversion to

numeric values, bitvectors, and string representationsI Type registry for specialized output handling,

resolved at elaboration time


http://www.offis.de

http://www.offis.de

I 15 OutlineMedium-term standardisation




4 Medium-term standardisationExtra-functional parametersExtended Simulation Callbacks

5 Conclusion


http://www.offis.de

http://www.offis.de

I 16 Extra-functional parametersMedium-term standardisation

I (Extra-Functional) parametrisation of SystemC models is under standardisation inAccellera’s SystemC CCI Working Group

I Support for physical units is addressed, but may not be explicitly included in the standard

I Details and granularity of a standardised System-Level Power Modelis mostly a question of the methodology / design flow.I Align with UPF/CPF and the related effort towards ESL power modelling

I Path towards Standardisation

I Collect existing practices and requirements for potential futureExtra-Functional Base Model (c.f. TLM-2.0 base protocol)I Common set of parameters (names, units)I Rules for composing, using, (run-time) changing

I Postpone standardisation after completion of CCI configuration aspectsI Standardised parametrisation addresses most technical showstoppersI Parameter selection can be aligned between model providers/integrators


http://www.offis.de

http://www.offis.de

I 17 Extended Simulation CallbacksMotivation

I SystemC’s capabilities for adding custom introspection code(like a power-model) are limited

I In TLM-2.0 virtual platforms, events and transactions may arrive out-of-orderI Temporal decoupling required for today’s complex platformsI Difficult to determine, when all conflicting transactions from different initiators have arrived

I No safe state to extract model information availableI Process scheduling is implementation-definedI sc_trace updates are explicitly inserted in simulation loop internallyI Workarounds based on sc_pending_activity_* functions are inefficient and non-interoperable

I Proposed solution: Extended Phase Callbacks

Add callback mechanism to individual simulation phases:initialization, (evaluation), update, simulation time advance


http://www.offis.de

http://www.offis.de

I 18 SystemC simulation cycleExtended Simulation Callbacks

update

evaluate

initialization

R: runnableprocesses

D: deltanotifications

T: timednotifications

U: updaterequests

for channels

notify()

notify(0, SC_FS)

notify(>0, SC_FS)

information flow

control flow

next deltaD R R ≠ { }

R = { }

increase simulation timeT T(time) R

finished, return to sc_main()

R = { } ∨ time = end_timesc_stop()

R = { }

U = { }

sc_pause()

U

I

T

P

phase callback


http://www.offis.de

http://www.offis.de

I 19 Interface proposalExtended Simulation Callbacks

I Extend sc_status enum with new phasesSC_END_OF_INITIALIZATION, // (I)/∗ SC_END_OF_EVALUATION, // (E) [TBD] ∗/SC_END_OF_UPDATE, // (U)SC_BEFORE_TIMESTEP, // (T)

I Add new callback function to sc_object

virtual void simulation_phase_callback(){ /∗ warn, if base implementation is called ∗/ }

I Explicitly subscribe to specific phase(s)obj.register_simulation_phase_callback

( SC_BEFORE_TIMESTEP );

update

evaluate

initialization

R: runnableprocesses

D: deltanotifications

T: timednotifications

U: updaterequests

for channels

notify()

notify(0, SC_FS)

notify(>0, SC_FS)

information flow

control flow

next deltaD R R ≠ { }

R = { }

increase simulation timeT T(time) R

finished, return to sc_main()

R = { } ∨ time = end_timesc_stop()

R = { }

U = { }

sc_pause()

U

I

T

P

phase callback

E

I Subscription to multiple phases (e.g. (SC_PAUSED|SC_STOPPED))→ determine current phase via sc_get_status within callback

I Definition of extended callback semantics for all simulation phases (consistency)

I Callback body may not call arbitrary notification functions (→ keep kernel scheduling stable)


http://www.offis.de

http://www.offis.de

I 20 Performance overheadExtended Simulation Callbacks

I Proof-of-concept implementation available, to be discussed in LWGI Performance overhead seems to be acceptable

I If feature is disabled in the kernel, no overhead visible (< 1%)I Without registered callbacks, but active infrastructure, overhead below 3% on all platforms

(64-bit seems to be slightly more affected)I Active callback significantly faster than additional SC_METHOD

I Artificial benchmarkI Two SystemC processesI 1 000 000 timed notificationsI 100 delta cycles per timestep

I Simple TLM-2.0Virtual PlatformI ISS, AT Interconnect,

Memory (with DMI),HW accelerator (DCT)


http://www.offis.de

http://www.offis.de

I 21 OutlineConclusion





5 Conclusion


http://www.offis.de

http://www.offis.de

I 22 ConclusionModelling extra-functional properties in SystemC

I Considering extra-functional properties is increasingly importantin early phases of the design flowI Trade-off: performance↔ power↔ design effortI Optimisation of power managementI Verification of power intent

→ COMPLEX simulation framework provides customizable infrastructure

I Existing approaches rely on custom/vendor-specific extensionsI Reduced model interoperability!I Start the standardisation process related to SystemCI Aligned with other activities at e.g. Si2 Low Power Coalition (CPF) and IEEE P1801 (UPF)

I But: Standardisation takes time!I Highly methodology/flow dependantI Long-term goal: Converging on a common, flexible Extra-Functional Base ModelI Next steps: Provide enabling infrastructure for custom extra-functional modellingI Target medium-term extensions to improve model expressiveness

and integration of custom introspection techniques (LWG+CCIWG)


http://www.offis.de

http://www.si2.org/?page=726

http://p1801.org

http://www.offis.de

I 23 That’s all, folks. . .Conclusion

Thank you! Any questions?Philipp A. Hartmann, <[email protected]>

http://complex.offis.de

This work has been partially supported by theCOMPLEX FP7 European Integrated Project, funded bythe European Commission under Grant Agreement247999, and the EnerSave project, funded by theGerman Ministry of Research (BMBF), registrationnumber 1BE1100.


http://www.offis.de

http://complex.offis.de

http://www.offis.de

modelling, simulation, and advanced tracing for extra ... · i modelling, simulation, and advanced...

Documents