Praktikum: SystemC SystemC-TLM Tutorial Joachim Falk ( - - PowerPoint PPT Presentation

praktikum systemc
SMART_READER_LITE
LIVE PREVIEW

Praktikum: SystemC SystemC-TLM Tutorial Joachim Falk ( - - PowerPoint PPT Presentation

Praktikum: SystemC SystemC-TLM Tutorial Joachim Falk ( falk@cs.fau.de ) Friedrich-Alexander-Universitt Erlangen-Nrnberg Joachim Falk 1 Agenda SystemC and TLM Transaction TLM 2.0 Overview Interfaces


slide-1
SLIDE 1

1

Praktikum: SystemC

SystemC-TLM Tutorial

Joachim Falk (falk@cs.fau.de)

Friedrich-Alexander-Universität Erlangen-Nürnberg Joachim Falk

slide-2
SLIDE 2

2

Agenda

  • SystemC and TLM
  • Transaction
  • TLM 2.0
  • Overview
  • Interfaces
  • Examples
  • Virtual Prototype

Friedrich-Alexander-Universität Erlangen-Nürnberg Joachim Falk

slide-3
SLIDE 3

3

SystemC/TLM

  • C++ library that allows for high-level system modeling
  • Provides
  • Concepts
  • Modules
  • Ports
  • Channels
  • Processes
  • Events
  • Data types
  • Simulation kernel
  • With it, modeling of communicating concurrently executed

modules is easy

  • SystemC TLM 2.0: Transaction level modeling
  • Even more abstract modeling possible

Friedrich-Alexander-Universität Erlangen-Nürnberg Joachim Falk

slide-4
SLIDE 4

4

Agenda

  • SystemC and TLM
  • Transaction
  • TLM 2.0
  • Overview
  • Interfaces
  • Examples
  • Virtual Prototype

Friedrich-Alexander-Universität Erlangen-Nürnberg Joachim Falk

slide-5
SLIDE 5

5

Transaction?

  • Transaction: Abstraction of communication
  • Not transaction level: C function or single process
  • Algorithmic model
  • TL requires multiple processes to simulate concurrent

execution and communication

  • Note: Some slides and phrases are taken from OSCI

documentation (available at www.systemc.org)

  • OSCI TLM2 User Manual
  • Slides from the TLM 2.0 kit

Friedrich-Alexander-Universität Erlangen-Nürnberg Joachim Falk

slide-6
SLIDE 6

6

Transaction on AHB Bus

  • Opt1: Encapsulate protocol in a SystemC channel
  • Opt2: Abstract timing to entire transactions: TLM 2.0

[http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dai0119e/index.html] Friedrich-Alexander-Universität Erlangen-Nürnberg Joachim Falk

slide-7
SLIDE 7

7

Agenda

  • SystemC and TLM
  • Transaction
  • TLM 2.0
  • Overview
  • Interfaces
  • Examples
  • Virtual Prototype

Friedrich-Alexander-Universität Erlangen-Nürnberg Joachim Falk

slide-8
SLIDE 8

8

TLM 2.0

  • Open SystemC Initiative (OSCI) standard (June 2008)
  • Mission: Standardize the way models communicate
  • Why use TLM 2.0 in system level modeling?
  • Standard for interoperability
  • Early available
  • High simulation speed
  • Use cases for TLM
  • Represents key architectural components of hardware

platform

  • Architectural exploration, performance modeling
  • Software execution on virtual model of hardware platform
  • Golden model for hardware functional verification

Friedrich-Alexander-Universität Erlangen-Nürnberg Joachim Falk

slide-9
SLIDE 9

9

9

The TLM 2.0 Classes

IEEE 1666™ SystemC TLM-1 standard TLM-2 core interfaces: Blocking transport interface Non-blocking transport interface Direct memory interface Debug transport interface Analysis interface Initiator and target sockets Analysis ports Generic payload Phases Utilities: Convenience sockets Payload event queues Quantum keeper Instance-specific extn

Friedrich-Alexander-Universität Erlangen-Nürnberg Joachim Falk

slide-10
SLIDE 10

10

Coding Styles

  • Guides to model writing
  • Chosen style depends on use case
  • Each style can support a range of abstraction across

functionality, timing, and communication

  • Loosely-timed
  • Processes are temporally decoupled from simulation time

(may run ahead)

  • Each transaction has two timing points (begin and end)
  • Approximately-timed
  • Processes run in lock-step with simulation time: Delays

annotated onto transactions cause waits or timed notifications

  • Each transaction has four timing points (phases)

Friedrich-Alexander-Universität Erlangen-Nürnberg Joachim Falk

slide-11
SLIDE 11

11

Example

Friedrich-Alexander-Universität Erlangen-Nürnberg Joachim Falk

MemHi yKB MemLo xKB CPU OpenRISC 1000 (TLM) Bus

slide-12
SLIDE 12

12

12

Initiators and Targets

CPU Bus MEM

Initiator socket Target socket Initiator socket Target socket

Forward path Backward path Forward path Backward path

Transaction

  • bject

References to a single transaction object are passed along the forward and backward paths

Initiator Target

Friedrich-Alexander-Universität Erlangen-Nürnberg Joachim Falk

slide-13
SLIDE 13

13

Agenda

  • SystemC and TLM
  • Transaction
  • TLM 2.0
  • Overview
  • Interfaces
  • Examples
  • Virtual Prototype

Friedrich-Alexander-Universität Erlangen-Nürnberg Joachim Falk

slide-14
SLIDE 14

14

Initiator and Target Sockets

  • Initiator and target are connected via sockets
  • Sockets
  • group transport, DMI, and debug transaction interfaces
  • bind forward and backward path with a single call
  • Convenience: “simple” sockets

14

Initiator Target Target socket nb_transport_bw() invalidate_direct_mem_ptr() Initiator socket b_transport () nb_transport_fw() get_direct_mem_ptr() transport_dbg()

Friedrich-Alexander-Universität Erlangen-Nürnberg Joachim Falk

slide-15
SLIDE 15

15

Blocking/Non-blocking Transport

  • Blocking transport
  • Typical usage: Loosely-timed coding style
  • Parameter: Transaction and timing annotation
  • Uses forward path only
  • Non-blocking transport
  • Typical usage: Approximately-timed coding style
  • Parameter: Transaction, timing annotation, and phase
  • Calls on forward- and backward-paths

BEGIN_REQ END_REQ BEGIN_RESP END_RESP

Friedrich-Alexander-Universität Erlangen-Nürnberg Joachim Falk

void b_transport(TRANS &, sc_time &); tlm_sync_enum nb_transport_fw(TRANS &, PHASE &, sc_time &); tlm_sync_enum nb_transport_bw(TRANS &, PHASE &, sc_time &);

slide-16
SLIDE 16

16

Transport Interfaces

  • TLM2 transport interfaces pass transactions from initiators

to targets

  • Forward path
  • Transaction is transported by b_transport()/

nb_transport_fw() calls from the initiator to the target

  • Traveling through interconnection network or fabric possible
  • Transaction is executed in the target
  • Backward path
  • Blocking: Transaction “returns” to initiator carried with the

return from the b_transport() calls as they unwind

  • Non-blocking: Passed back by making explicit

nb_transport_bw() calls in the opposite direction

Friedrich-Alexander-Universität Erlangen-Nürnberg Joachim Falk

slide-17
SLIDE 17

17

Blocking Transport

17

Initiator Target b_transport(t, 0ns)

Call Simulation time = 100ns Simulation time = 140ns

wait(40ns)

Initiator is blocked until return from b_transport Return

b_transport(t, 0ns) b_transport(t, 0ns)

Call Return

b_transport(t, 0ns)

Friedrich-Alexander-Universität Erlangen-Nürnberg Joachim Falk

slide-18
SLIDE 18

18

Blocking - Temporal Decoupling

18

Initiator Target b_transport(t, 0ns)

Call Simulation time = 100ns Simulation time = 140ns

wait(40ns)

Local time offset Return

b_transport(t, 5ns)

+5ns

b_transport(t, 20ns)

Call +20ns Return

b_transport(t, 25ns)

+25ns

b_transport(t, 30ns)

Call +30ns Return

b_transport(t, 5ns)

+5ns

Friedrich-Alexander-Universität Erlangen-Nürnberg Joachim Falk

slide-19
SLIDE 19

19

Generic Payload

  • Possible type of transaction
  • Appropriate for memory mapped buses
  • Attributes
  • Typical attributes of MMBs (command, address, pointer, …)
  • TLM specific (return status, DMI hint)
  • Extensions (ignorable for interoperability)
  • Most attributes are set by initiator and shall not be modified

by interconnect components or the target; exceptions are

  • Address (only interconnect, for example, a router)
  • Response status (only target)
  • If read command: data array by target

Friedrich-Alexander-Universität Erlangen-Nürnberg Joachim Falk

slide-20
SLIDE 20

20

Generic Payload

  • Payload (transaction object) is “transported” by reference
  • Memory management for the transaction object
  • Ad hoc by the initiator (static, dynamic, automatic, pool

strategy, etc.)

  • Provide memory manager
  • Initiators must not delete transactions until their lifetime

ends

  • Initiators are responsible for valid data pointers and

corresponding memory management

Friedrich-Alexander-Universität Erlangen-Nürnberg Joachim Falk

slide-21
SLIDE 21

21

Agenda

  • SystemC and TLM
  • Transaction
  • TLM 2.0
  • Overview
  • Interfaces
  • Examples
  • Virtual Prototype

Friedrich-Alexander-Universität Erlangen-Nürnberg Joachim Falk

slide-22
SLIDE 22

22

Example (Loosely-timed Coding Style)

Friedrich-Alexander-Universität Erlangen-Nürnberg Joachim Falk

struct Initiator: sc_module { tlm_utils::simple_initiator_socket<Initiator> socket; … }; struct Memory: sc_module { tlm_utils::simple_target_socket<Memory> socket; … }; SC_MODULE(Top) { Initiator initiator; Memory memory; Top(sc_module_name name) : sc_module(name), initiator(“initiator”), target(“target”) { initiator->socket.bind(memory->socket); } };

slide-23
SLIDE 23

23

Example - Initiator

Friedrich-Alexander-Universität Erlangen-Nürnberg Joachim Falk

int data; tlm::tlm_generic_payload trans; sc_time delay = sc_time(10, SC_NS); trans.set_write(); trans.set_address(0x100); trans.set_data_ptr(reinterpret_cast<unsigned char*>(&data)); trans.set_data_length(sizeof(data)); trans.set_streaming_width(sizeof(data)); trans.set_byte_enable_ptr(0); trans.set_dmi_allowed(false); trans.set_response_status(tlm::TLM_INCOMPLETE_RESPONSE); initiatorSocket->b_transport(trans, delay); // check response status, perform delay

slide-24
SLIDE 24

24

Example - Target

Friedrich-Alexander-Universität Erlangen-Nürnberg Joachim Falk

void Target::b_transport( tlm::tlm_generic_payload &trans, sc_time &delay) { addr_type addr = trans.get_address(); if (addr > mMaxAddr) { // set error response status and return } tlm::tlm_command cmd = trans.get_command(); unsigned char* ptr = trans.get_data_ptr(); unsigned int len = trans.get_data_length(); if (cmd == tlm::TLM_READ_COMMAND) memcpy(ptr, &mMemory[addr], len); else if (cmd == tlm::TLM_WRITE_COMMAND) memcpy(&mMemory[addr], ptr, len); else { // set error response and return } // add some delay delay = delay + sc_time(5, SC_NS); trans.set_response_status(tlm::TLM_OK_RESPONSE); }

slide-25
SLIDE 25

25

Agenda

  • SystemC and TLM
  • Transaction
  • TLM 2.0
  • Overview
  • Interfaces
  • Examples
  • Virtual Prototype

Friedrich-Alexander-Universität Erlangen-Nürnberg Joachim Falk

slide-26
SLIDE 26

26

Virtual Prototype

  • What do we have?
  • OpenRisc 1000 CPU with Harvard architecture

(That is, two TLM connections one for data and one for code)

  • Memory

(With only one TLM connection)

Friedrich-Alexander-Universität Erlangen-Nürnberg Joachim Falk

Mem OpenRisc 1000 CPU Today we implement a TLM connection