SystemCoDesigner: Performance Modeling Tutorial

Transcription

1 SystemCoDesigner: Performance Modeling Tutorial Martin Streubühr Sebastian Graf Hardware/Software Co-Design Department of Computer Science University of Erlangen-Nuremberg Germany Version 1.4 Christian Haubelt Joachim Falk

2 Outline Introduction Installation Remarks Virtual Processing Components Configuration API Remarks Version 1.4 Martin Streubühr et al. FAU SystemCoDesigner: Performance Modeling Tutorial 2

3 Introduction

4 Introduction SysteMoC and Virtual Processing Components are the two modeling approaches used in SystemCoDesigner SysteMoC allows for functional modeling and simulation Virtual Processing Components (VPC) allow for performance modeling and simulation Together, SysteMoC and Virtual Processing Components allow for combined functional and performance simulation Both, SysteMoC and Virtual Processing Components are implemented as individual libraries on top of SystemC Version 1.4 Martin Streubühr et al. FAU SystemCoDesigner: Performance Modeling Tutorial 4

5 Introduction A Virtual Processing Component is an abstraction of a resource... models resource contention, scheduling, and arbitration A Virtual Processing Component is not an Instruction Set Simulator... is not an RTL simulator But, a Virtual Processing Component allows to model a Processor or a HW component... allows to model a communication resource Version 1.4 Martin Streubühr et al. FAU SystemCoDesigner: Performance Modeling Tutorial 5

6 SysteMoC out Source CPU queue Bus in Mem Sink SysteMoC VPC A functional model in SysteMoC is given by a set of actors (e.g., Source and Sink)... a set of communication queues connecting actors Version 1.4 Martin Streubühr et al. FAU SystemCoDesigner: Performance Modeling Tutorial 6

7 Virtual Processing Components out Source CPU queue Bus in Mem Sink SysteMoC VPC An architecture model in VPC is given by a set of components (e.g., CPU, Bus, and Mem )... a mapping of actors and queues to the set of components Version 1.4 Martin Streubühr et al. FAU SystemCoDesigner: Performance Modeling Tutorial 7

8 Installation Remarks

9 Installation Remarks Requirements VPC requirements: A SysteMoC library compiled with VPC support The application needs to be linked with the VPC library library dependencies: CoSupport library (included in the SysteMoC source distribution) Xerces-C++ XML Parser, (Version 2.8.0) Boost C++ library, (Version 1.35) SystemC library, (Version 2.2.0) note: Boost, SystemC, and CoSupport are required for SysteMoC Xerces-C++ is required by the VPC library Version 1.4 Martin Streubühr et al. FAU SystemCoDesigner: Performance Modeling Tutorial 9

10 Linux: From Source Code > cd systemoc - top/ > ls Support SystemC - VPC SysteMoC Testcases Examples configure... > mkdir obj > cd obj >../ configure -C > make > ( sudo make install) The source code distribution includes the subdirectories SysteMoC, Support, SystemC-VPC, and some Testcases and Examples Create an obj directory and change the working directory Run the configure script from the source directory Compile the software (and optionally install it) Version 1.4 Martin Streubühr et al. FAU SystemCoDesigner: Performance Modeling Tutorial 10

11 Virtual Processing Components

12 Functional Model SysteMoC Recap out Source CPU queue Bus in Mem Sink SysteMoC VPC Write a functional model in SysteMoC Two actors, Source and Sink, are connected via a FIFO queue cf. SystemCoDesigner: System Programming Tutorial Version 1.4 Martin Streubühr et al. FAU SystemCoDesigner: Performance Modeling Tutorial 12

13 Functional Model // file vpc_source_sink. cpp #include < iostream > #include < systemoc / smoc_moc.hpp > static const std :: string MESSAGE = " Hello SysteMoC!"; class Source : public smoc_actor { public: smoc_port_out <char> out; Source( sc_module_name name) : smoc_actor ( name, start), count (0), size(message.size ()), message(message) { start = GUARD( Source :: hastoken ) >> out (1) >> CALL(Source :: src) >> start; } The Source actor has an output port with data type char A single FSM transition is used to produce one data token per actor firing Version 1.4 Martin Streubühr et al. FAU SystemCoDesigner: Performance Modeling Tutorial 13

14 Functional Model // file vpc_source_sink. cpp cont d private: smoc_firing_state start; // states unsigned int count, size; // variables ( functional state) const std :: string message; // bool hastoken () const { return count < size; } // guard void src () { std :: cerr << this-> name () << " " << sc_time_stamp () << "\tsend: \ " << message[count] << "\ " << std :: endl; out [0] = message[ count ++]; } // action }; A function src() is used to produce data tokens A guard hastoken() is used to check if the transition can be fired Version 1.4 Martin Streubühr et al. FAU SystemCoDesigner: Performance Modeling Tutorial 14

15 Functional Model // file vpc_source_sink. cpp cont d class Sink : public smoc_actor { public: smoc_port_in <char> in; Sink( sc_module_name name) // actor constructor : smoc_actor ( name, start) { start = in (1) >> CALL( Sink :: sink) >> start; } private: smoc_firing_state start; void sink () { std :: cout << this-> name () << " " << sc_time_stamp () << "\trecv: \ " << in [0] << "\ " << std :: endl; } }; The Sink actor receives and consumes the data token this->name() returns the entire hierarchical name of the actor Version 1.4 Martin Streubühr et al. FAU SystemCoDesigner: Performance Modeling Tutorial 15

16 Functional Model // file vpc_source_sink. cpp cont d class NetworkGraph : public smoc_graph { public: NetworkGraph ( sc_module_name name) : smoc_graph (name), source("source"), sink("sink") { smoc_fifo <char> fifo(" queue", 4); fifo.connect(source.out).connect(sink.in); // connect } private: Source source; // actors Sink sink; }; int sc_main(int argc, char ** argv){ NetworkGraph top(" top"); // create network graph smoc_scheduler_top sched( top); sc_start (); // start simulation ( SystemC) return 0; } Source and Sink are connected via a queue (queue size = 4) VPC usage is easier with (unique) symbolic queue names actors Version 1.4 Martin Streubühr et al. FAU SystemCoDesigner: Performance Modeling Tutorial 16

17 Functional Model Hierarchical Names // file vpc_source_sink. cpp cont d class NetworkGraph : public smoc_graph { public: NetworkGraph ( sc_module_name name) : smoc_graph (name), source("source"), sink("sink") { smoc_fifo <char> fifo(" queue", 4); fifo.connect(source.out).connect(sink.in); // connect } private: Source source; // actors Sink sink; }; int sc_main(int argc, char ** argv){ NetworkGraph top(" top"); // create network graph smoc_scheduler_top sched( top); sc_start (); // start simulation ( SystemC) return 0; } Actors have hierarchical names reproducing the nesting of graphs E.g. actors top.source and top.sink are used by the graph top actors Version 1.4 Martin Streubühr et al. FAU SystemCoDesigner: Performance Modeling Tutorial 17

18 Functional Model >./vpc -src -sink SystemC Dec :19:05 Copyright (c) by all Contributors ALL RIGHTS RESERVED top.source 0 s send: H top.sink 0 s recv: H top.source 0 s send: e top.sink 0 s recv: e top.source 0 s send: l top.sink 0 s recv: l top.source 0 s send: l top.sink 0 s recv: l top.source 0 s send: o top.sink 0 s recv: o... [ VPC] overall simulated time: 0 s Compile source code and run functional simulation No timing is simulated in the functional model Version 1.4 Martin Streubühr et al. FAU SystemCoDesigner: Performance Modeling Tutorial 18

19 Functional Model When compiled with VPC, the SysteMoC functional simulation forwards actor execution and communication events to the VPC library A performance simulation for those events will take place if an architecture model is given to the VPC simulation The architecture model is given by an XML configuration file A pure functional simulation without timing is performed if no architecture model is given Version 1.4 Martin Streubühr et al. FAU SystemCoDesigner: Performance Modeling Tutorial 19

20 Architecture Model <?xml version=" 1.0"? > <!DOCTYPE vpcconfiguration SYSTEM " vpc. dtd" > < vpcconfiguration > < resources >... </ resources > <mappings >... </ mappings > <topology >... </ topology > </ vpcconfiguration > Write a VPC configuration (XML file src-snk.vpc.xml).vpc.xml is the preferred file name suffix The document type definition is given in the file (vpc.dtd) Version 1.4 Martin Streubühr et al. FAU SystemCoDesigner: Performance Modeling Tutorial 20

21 Architecture Model <?xml version=" 1.0"? > <!DOCTYPE vpcconfiguration SYSTEM " vpc. dtd" > < vpcconfiguration > < resources >... </ resources > <mappings >... </ mappings > <topology >... </ topology > </ vpcconfiguration > <vpcconfiguration> is the XML root element of a VPC configuration It contains the elements <resources>, <mappings>, and <topology> Version 1.4 Martin Streubühr et al. FAU SystemCoDesigner: Performance Modeling Tutorial 21

22 Architecture Model < resources > <component name="cpu" scheduler ="FCFS"> < attribute type =" transfer_delay " value =" 20 ns" / > </ component > <component name="bus" scheduler ="FCFS"> < attribute type =" transfer_delay " value =" 80 ns" / > </ component > <component name="mem" scheduler ="FCFS"> < attribute type =" transfer_delay " value =" 20 ns" / > </ component > </ resources > The <resources> element contains nested <component> elements An element <component> defines a (Virtual Processing) Component Each Component has a name and a scheduler given by the XML attributes name and scheduler Version 1.4 Martin Streubühr et al. FAU SystemCoDesigner: Performance Modeling Tutorial 22

23 Architecture Model Attributes < resources > <component name="cpu" scheduler ="FCFS"> < attribute type =" transfer_delay " value =" 20 ns" / > </ component > <component name="bus" scheduler ="FCFS"> < attribute type =" transfer_delay " value =" 80 ns" / > </ component > <component name="mem" scheduler ="FCFS"> < attribute type =" transfer_delay " value =" 20 ns" / > </ component > </ resources > Components may have attributes (nested <attribute> elements) An attributes is defined by a type and a value (<attribute type="..."value="..."/>) E.g., an attribute transfer_delay refers to the communication time required for one token, if the communication route includes this component (cf. route) Version 1.4 Martin Streubühr et al. FAU SystemCoDesigner: Performance Modeling Tutorial 23

24 Architecture Model Mappings <mappings > <mapping source="top.source" target="cpu"> <timing dii="10 us" latency="10 us" /> <timing fname=" Source::src " dii="10 us" latency="10 us" /> </mapping > <mapping source="top.sink" target="cpu"> <timing delay="10 us" /> <timing fname=" Sink::sink " delay="10 us" /> </mapping > </ mappings > mapping elements are nested inside the mappings element Used to define the mapping of actors to components The attribute source defines the entire hierarchical actor name The attribute target defines the Component name (cf. <component>) Version 1.4 Martin Streubühr et al. FAU SystemCoDesigner: Performance Modeling Tutorial 24

25 Architecture Model Timing <mappings > <mapping source="top.source" target="cpu"> <timing dii="10 us" latency="10 us" /> <timing fname=" Source::src " dii="10 us" latency="10 us" /> </mapping > <mapping source="top.sink" target="cpu"> <timing delay="10 us" /> <timing fname=" Sink::sink " delay="10 us" /> </mapping > </ mappings > A timing element defines the execution times for a mapping The execution time is given either By a dii and latency attribute Or by a delay attribute Thereby delay="x" is a short cut for dii="x"latency="x" dii and latency are constraint to: (0 < dii lat) (0 = dii = lat) Version 1.4 Martin Streubühr et al. FAU SystemCoDesigner: Performance Modeling Tutorial 25

26 Architecture Model Timing <mappings > <mapping source="top.source" target="cpu"> <timing dii="10 us" latency="10 us" /> <timing fname=" Source::src " dii="10 us" latency="10 us" /> </mapping > <mapping source="top.sink" target="cpu"> <timing delay="10 us" /> <timing fname=" Sink::sink " delay="10 us" /> </mapping > </ mappings > The attribute fname is optional, The default timing of an actor is given without fname Version 1.4 Martin Streubühr et al. FAU SystemCoDesigner: Performance Modeling Tutorial 26

27 Architecture Model Timing <mappings > <mapping source="top.source" target="cpu"> <timing dii="10 us" latency="10 us" /> <timing fname=" Source::src " dii="10 us" latency="10 us" /> </mapping > <mapping source="top.sink" target="cpu"> <timing delay="10 us" /> <timing fname=" Sink::sink " delay="10 us" /> </mapping > </ mappings > With fname individual timings are specified for the given function names (names given by SysteMoC s CALL(...) and GUARD(...) macros, cf. SystemCoDesigner: System Programming Tutorial ) The execution time (dii and latency) of a transition is the sum of function times for all guards and actions referred by this transition. Timing is simulated only if the transition is executed, i.e., the guards evaluate to true. Version 1.4 Martin Streubühr et al. FAU SystemCoDesigner: Performance Modeling Tutorial 27

28 Architecture Model Topology <topology > <route source="top.source" destination ="queue"> <hop name="cpu"> </hop > <hop name="bus"> </hop > <hop name="mem"> </hop > </route > <route source="queue" destination ="top.sink"> <hop name="mem"> </hop > <hop name="bus"> </hop > <hop name="cpu"> </hop > </route > </ topology > The <topology> section defines the multi-hop communication routes The <topology> is defined by nested <route> elements For each connection between an actor and a channel a <route> may be defined Version 1.4 Martin Streubühr et al. FAU SystemCoDesigner: Performance Modeling Tutorial 28

29 Architecture Model Route <topology > <route source="top.source" destination ="queue"> <hop name="cpu"> </hop > <hop name="bus"> </hop > <hop name="mem"> </hop > </route > <route source="queue" destination ="top.sink"> <hop name="mem"> </hop > <hop name="bus"> </hop > <hop name="cpu"> </hop > </route > </ topology > A <route> is defined by nested <hop> elements A route has a source and a target attribute Source and target form a pair (actor, channel) or (channel, actor) Suggestion: use symbolic queue names in the SysteMoC model Else: queue names are concatenations of connected actor names Version 1.4 Martin Streubühr et al. FAU SystemCoDesigner: Performance Modeling Tutorial 29

30 Architecture Model Hops out Source CPU queue Bus in Mem Sink SysteMoC VPC The <hop> elements of a route refer to Components (by name) E.g., the route for actor Source writing the queue involves the hops CPU, Bus, and Mem Version 1.4 Martin Streubühr et al. FAU SystemCoDesigner: Performance Modeling Tutorial 30

31 Performance Simulation > setenv VPCCONFIGURATION src - snk. vpc. xml >./vpc -src -sink SystemC Dec :19:05 Copyright (c) by all Contributors ALL RIGHTS RESERVED top. Source 0 s send: H top. Source 10 us send: e top. Sink ns recv: H top. Source ns send: l top. Source ns send: l top. Sink ns recv: e top. Source ns send: o top. Sink ns recv: l... [ VPC] overall simulated time: ns Set environment variable VPCCONFIGURATION to the configuration file and run simulation Timing is simulated and VPC reports overall simulation time Version 1.4 Martin Streubühr et al. FAU SystemCoDesigner: Performance Modeling Tutorial 31

32 Performance Simulation Simulation Trace $ timescale 1 ns $end $ scope module sc $ end $ var wire 8 aaa msg_top. Source_2_queue [7:0] $ end $ var wire 8 aab msg_queue_2_top. Sink [7:0] $ end $upscope $end $ enddefinitions $ end $ dumpvars b aaa b aab $end #10020 b aaa The simulation is traced in Value Change Dump files A VCD file is created for each component (cf. <resource>) VCD files can be visualized, e.g., using GTKWave or Modelsim Version 1.4 Martin Streubühr et al. FAU SystemCoDesigner: Performance Modeling Tutorial 32

33 Performance Simulation Simulation Trace Signal values represent ASCII coded characters (radix = ASCII) Each signal represents a task (an actor or a communication message) Version 1.4 Martin Streubühr et al. FAU SystemCoDesigner: Performance Modeling Tutorial 33

34 Performance Simulation Simulation Trace "R" or "r" means a task is executed (running) "W" or "w" means a task is ready for execution but preempted (waiting) "B" or "b" means a task is blocked during communication Version 1.4 Martin Streubühr et al. FAU SystemCoDesigner: Performance Modeling Tutorial 34

35 Performance Simulation Simulation Trace VCD traces have a major disadvantage: successive phases with identical signal values corespond to no signal change (no event) they are not included in the VCD file and not shown by any viewer VPC switches between lower and upper case letters ("R"/"r") to avoid identical valued successive phases Version 1.4 Martin Streubühr et al. FAU SystemCoDesigner: Performance Modeling Tutorial 35

36 Reference Manual Scheduler <component name="cpu" scheduler ="PS">... <mapping source="top.sink" target="cpu"> < attribute type =" priority " value ="1" / > VPC includes several different schedulers Most scheduler require additional attributes assigned to mappings and/or to components E.g., a priority scheduler requires priority values assigned to mappings <component name="cpu" scheduler ="RR"> <attribute type=" timeslice " value="10 ns" />... <mapping source="top.sink" target="cpu"> The round robin scheduler requires a timeslice attribute assigned to the component Version 1.4 Martin Streubühr et al. FAU SystemCoDesigner: Performance Modeling Tutorial 36

37 Reference Manual Scheduler Scheduler Required Attributes XML name Component Mapping First Come First Served FCFS Priority Scheduler PSNOPRE priority Preemptive Priority Scheduler PS priority Round Robin RR timeslice priority Time Division Multiple Access TDMA * FlexRay FlexRay * * TDMA and FleyRay scheduler require complex attribute structures Version 1.4 Martin Streubühr et al. FAU SystemCoDesigner: Performance Modeling Tutorial 37

38 Reference Manual Hop <route source="top.source" destination ="queue"> <hop name="cpu"> </hop > <hop name="bus"> <timing dii="1000 us" latency="1000 us" /> < /hop > <hop name="mem"> </hop > </route > Per default the timing of a hop is defined by the components attribute transfer_delay A nested <timing> element may be used to override the default Version 1.4 Martin Streubühr et al. FAU SystemCoDesigner: Performance Modeling Tutorial 38

39 Configuration API

40 Overview The API allows the configuration of the architecture model and mappings to be programmed in C++. Using the API may be used instead of a XML configuration file. Note: Mixing both, API and XML configuration, is not possible. Version 1.4 Martin Streubühr et al. FAU SystemCoDesigner: Performance Modeling Tutorial 40

41 Example API Header #include < systemoc / smoc_moc.hpp > #ifdef SYSTEMOC_ENABLE_VPC #include < vpc_api.hpp > #endif // SYSTEMOC_ENABLE_VPC class Source: public smoc_actor... class Sink: public smoc_actor... Using the configuration API requires to include the vpc_api.hpp header. Guarding configuration code using the preprocessor guard SYSTEMOC_ENABLE_VPC is recommended and allows to compile the code in absence of the VPC library for functional simulation. Version 1.4 Martin Streubühr et al. FAU SystemCoDesigner: Performance Modeling Tutorial 41

42 Example Source Sink Example class NetworkGraph : public smoc_graph { public: NetworkGraph ( sc_module_name name) // network graph constructor : smoc_graph (name), source("src",this), sink("snk",this) { smoc_fifo <char> fifo(" queue", 42); fifo.connect(source.out).connect(sink.in); // connect actors #ifdef SYSTEMOC_ENABLE_VPC... #endif // SYSTEMOC_ENABLE_VPC }... The network of actors is composed by a network graph. Configuration code using the API mechanism is added to the network graph constructor. Placing the code in the constructor is not mandatory, but eases access to the actor member variables (e.g., source). Version 1.4 Martin Streubühr et al. FAU SystemCoDesigner: Performance Modeling Tutorial 42

43 Example Error Reporting #ifdef SYSTEMOC_ENABLE_VPC try {... } catch ( std :: exception & e) { std :: cerr << " Caught exception wile configuring VPC :\ n" << e. what () << std :: endl; exit (-1); } #endif // SYSTEMOC_ENABLE_VPC The configuration API uses exceptions for error reporting. Therefore, the configuration code shall be placed in a try{} block. Note the preprocessor guard SYSTEMOC_ENABLE_VPC to enable compilation without VPC. Version 1.4 Martin Streubühr et al. FAU SystemCoDesigner: Performance Modeling Tutorial 43

44 Example Architecture Model try { // convenience namespace VC = SystemC_VPC :: Config; // create components VC:: Component :: Ptr cpu = VC:: createcomponent ("CPU", VC:: Scheduler :: StaticPriority_NP );... Here a namespace alias VC is used to ease access the SystemC_VPC::Config namespace. A function VC::createComponent is used to create a component. Here a component using a non-preemptive static priority scheduling policy is modeled. The VC::Component::Ptr CPA is a handle (smart pointer) to the modeled component. Version 1.4 Martin Streubühr et al. FAU SystemCoDesigner: Performance Modeling Tutorial 44

45 Example Task Mapping // mappings cpu ->addtask(source); cpu ->addtask(sink); // set priorities VC:: setpriority (source, 0); VC:: setpriority (sink, 1); The handle to the cpu is used to register the mapping of actors. Note: source and src are variables of type smoc_actor. Task priorities are configured using VC::setPriority. Version 1.4 Martin Streubühr et al. FAU SystemCoDesigner: Performance Modeling Tutorial 45

46 Example Timing Provider // timings VC:: DefaultTimingsProvider :: Ptr provider = cpu -> getdefaulttimingsprovider (); provider ->add(vc:: Timing("Source :: source", sc_time (10, SC_NS ), sc_time (10, SC_NS))); // dii, latency provider ->add(vc:: Timing("Sink :: sink", sc_time (10, SC_NS))); // delay provider ->add(vc:: Timing("Source :: source", sc_time (100, SC_NS))); provider ->add(vc:: Timing("Sink :: sink", sc_time (100, SC_NS))) ; Execution times for actors are configured via a TimingsProvider. A default provider is used to configure individual timings for individual actions of actors. Version 1.4 Martin Streubühr et al. FAU SystemCoDesigner: Performance Modeling Tutorial 46

47 Example Default Route // configure routing VC:: ignoremissingroutes (true); So far the architecture and the task mapping is configured only. The configuration of communication routes is still missing. Here the default behavior is changed to ignore missing routes for a first simulation without modeled communication routes. Version 1.4 Martin Streubühr et al. FAU SystemCoDesigner: Performance Modeling Tutorial 47

48 Example Simulation Output SystemC Jan :08:32 Copyright (c) by all Contributors ALL RIGHTS RESERVED Note: VCD trace timescale unit is set by user to e -09 sec. top. Source 0 s send: H top. Source 100 ns send: e top. Sink 100 ns recv: H... SystemC: simulation stopped by user. [ VPC] overall simulated time: 3 us Simulation output from the example configured without routes. Version 1.4 Martin Streubühr et al. FAU SystemCoDesigner: Performance Modeling Tutorial 48

49 Example Transfer Timing VC:: ignoremissingroutes (true); VC:: Component :: Ptr bus = VC:: createcomponent (" Bus"); VC:: Component :: Ptr mem = VC:: createcomponent (" Memory"); VC:: Timing transfer (sc_time (20, SC_NS), sc_time (20, SC_NS)); bus -> settransfertiming ( transfer ); mem -> settransfertiming ( transfer ); cpu -> settransfertiming ( transfer ); Additional components are created to model a bus and a memory. Components shall be configured with transfer timings. A transfer timing models the time required to transfer a single token via a component (one hop). Version 1.4 Martin Streubühr et al. FAU SystemCoDesigner: Performance Modeling Tutorial 49

50 Example Multi-Hop Communication VC:: Route :: Ptr writeroute = VC:: createroute ( getleafport (& source.out)); VC:: Route :: Ptr readroute = VC:: createroute ( getleafport (& sink.in)); VC::createRoute is used to model a communication route for actor ports. Note: geleafport is used to access the actors port in case of hierarchically nesting graphs. Version 1.4 Martin Streubühr et al. FAU SystemCoDesigner: Performance Modeling Tutorial 50

51 Example Mult-Hop Communication writeroute ->addhop(cpu); writeroute -> addhop( bus). setpriority (0). settransfertiming ( VC:: Timing(sc_time (10, SC_NS), sc_time (20, SC_NS))); writeroute ->addhop(mem); readroute ->addhop(mem); readroute ->addhop(bus); readroute ->addhop(cpu); A sequence of components is configured to represent multi-hop communication routes. For simulation all delays occurring along a route plus additional scheduling and arbitration delays contribute to the overall communication delay. Note: It is possible to configure communication timings and message priorities individually per hop in a route. Version 1.4 Martin Streubühr et al. FAU SystemCoDesigner: Performance Modeling Tutorial 51

52 Example Simulation Output SystemC Jan :08:32 Copyright (c) by all Contributors ALL RIGHTS RESERVED Note: VCD trace timescale unit is set by user to e -09 sec. Note: VCD trace timescale unit is set by user to e -09 sec. Note: VCD trace timescale unit is set by user to e -09 sec. top. Source 0 s send: H top. Source 100 ns send: e top. Sink 150 ns recv: H... SystemC: simulation stopped by user. [ VPC] overall simulated time: 3720 ns Having a configured route in the examples causes different simulated times. Version 1.4 Martin Streubühr et al. FAU SystemCoDesigner: Performance Modeling Tutorial 52

53 API Reference Component Component :: Ptr createcomponent ( std :: string name, Scheduler :: Type scheduler = Scheduler :: FCFS); Create a component with default or explicitly given Scheduler. Component :: Ptr getcomponent ( std :: string name); Get an already created a component by name. bool hascomponent ( std :: string name); Check existence of a component by name. Version 1.4 Martin Streubühr et al. FAU SystemCoDesigner: Performance Modeling Tutorial 53

54 API Reference Component class Component { public: void setscheduler ( Scheduler :: Type scheduler ); Scheduler :: Type getscheduler () const; void settransfertiming ( Timing transfertiming ); Timing gettransfertiming () const; void addtask( ScheduledTask & actor); bool hastask( ScheduledTask * actor) const; void settimingsprovider ( TimingsProvider :: Ptr provider ); TimingsProvider :: Ptr gettimingsprovider (); DefaultTimingsProvider :: Ptr getdefaulttimingsprovider (); } The Component class (Component::Ptr) has various public member functions to get and set scheduler, transfer timings, mappings and timings provider. Version 1.4 Martin Streubühr et al. FAU SystemCoDesigner: Performance Modeling Tutorial 54

55 API Reference DefaultTimingsProvider class DefaultTimingsProvider { virtual void adddefaultactortiming ( std :: string timing); virtual void add( Timing timing); actorname, Timing } The easiest way to configure task execution times used the Component s DefaultTimingsProvider It allows to add timings to actors or to individual functions. Version 1.4 Martin Streubühr et al. FAU SystemCoDesigner: Performance Modeling Tutorial 55

56 API Reference Route Route :: Ptr createroute (const sc_port_base * leafptr, Route :: Type type = Route :: StaticRoute ); Create a route using a leaf port of an actor. class Route { public: bool gettracing () const; void settracing (bool tracing_ ); Hop & addhop( Component :: Ptr component ); void addtiming ( Component :: Ptr hop, Timing); } The Route class has public member functions to add hops, configure individual timings, and enable message tracing. Version 1.4 Martin Streubühr et al. FAU SystemCoDesigner: Performance Modeling Tutorial 56

57 API Reference Hops class Hop { public: Hop & setpriority ( size_t priority_ ); Hop & settransfertiming ( Timing transfertiming_ ); Component :: Ptr getcomponent () const; size_t getpriority () const; Timing gettransfertiming () const; The Hop class has public member to get and set individual message priorities and timings. Furthermore getting the referenced Component is possible. Version 1.4 Martin Streubühr et al. FAU SystemCoDesigner: Performance Modeling Tutorial 57

58 API Reference Configuration void setpriority ( ScheduledTask & actor, size_t priority ); The API allows to set task priorities. void ignoremissingroutes (bool ignore); If required, not configured (missing) route are ignored for simulation. Version 1.4 Martin Streubühr et al. FAU SystemCoDesigner: Performance Modeling Tutorial 58

59 Remarks

60 Outline Introduction Installation Remarks Virtual Processing Components Configuration API Remarks Version 1.4 Martin Streubühr et al. FAU SystemCoDesigner: Performance Modeling Tutorial 60

61 Contact Contact Persons: Christian Haubelt, Jürgen Teich Address: Hardware/Software Co-Design Department of Computer Science University of Erlangen-Nuremberg Cauerstr Erlangen, Germany Version 1.4 Martin Streubühr et al. FAU SystemCoDesigner: Performance Modeling Tutorial 61

62 Credits SysteMoC Development Team: Joachim Falk, Jens Gladigau, Martin Streubühr, Christian Zebelein VPC Development Team: Martin Streubühr, Sebastian Graf SystemCoDesigner Contributors: Joachim Falk, Michael Glass, Jens Gladigau, Joachim Keinert, Martin Lukasiewycz, Felix Reimann, Thomas Schlichter, Thilo Streichert, Martin Streubühr, Christian Zebelein, Christian Haubelt, Jürgen Teich Version 1.4 Martin Streubühr et al. FAU SystemCoDesigner: Performance Modeling Tutorial 62

63 Document Info Authors: Martin Streubühr, Sebastian Graf, Christian Haubelt Document Release: July 3, 2012 Version History: July 3, 2012: Version 1.4 May 26, 2011: Version 1.3 January 17, 2011: Version 1.2 September 9, 2010: Version 1.1 August 25, 2010: Version 1.0 Version 1.4 Martin Streubühr et al. FAU SystemCoDesigner: Performance Modeling Tutorial 63

64 Index

65 Index <component>, 22, 23 fname, 26, 27 <hop>, 30 <hop>, 29, 38 <mapping>, 24 <mappings>, 24 <resources>, 21, 22 <route>, 28, 29 scheduler, 22, 36, 37 <timing>, <topology>, 28 <vpcconfiguration>, 21 Version 1.4 Martin Streubühr et al. FAU SystemCoDesigner: Performance Modeling Tutorial 65