Transaction-level modeling of bus-based systems with SystemC 2.0 - - PowerPoint PPT Presentation

transaction level modeling of bus based systems with
SMART_READER_LITE
LIVE PREVIEW

Transaction-level modeling of bus-based systems with SystemC 2.0 - - PowerPoint PPT Presentation

Transaction-level modeling of bus-based systems with SystemC 2.0 Ric Hilderink, Thorsten Grtker Synopsys, Inc. Efficient platform modeling Get to executable platform model ASAP Simulation speed >> 100k cycles/sec C DSP BUS


slide-1
SLIDE 1

Transaction-level modeling

  • f bus-based systems with

SystemC 2.0

Ric Hilderink, Thorsten Grötker Synopsys, Inc.

slide-2
SLIDE 2

2

Efficient platform modeling Get to executable platform model ASAP Simulation speed >> 100k cycles/sec

DSP µC MEM ASIC Arbiter BUS

Moving from pin-level to transaction-level models (TLM) is mandatory!

slide-3
SLIDE 3

3

Outline

Idea:

Based on an example show how SystemC 2.0

enables efficient platform modeling.

Introduce some key language elements in the

process.

slide-4
SLIDE 4

4

Example: Simple bus model Cycle-accurate transaction-level model. “Simple” =

– No pipelining – No split transactions – No master wait states – No request/acknowledge scheme – …

NB: Of course, these features can be modeled at the transaction level

slide-5
SLIDE 5

5

Interface Method Calls (IMC)

Modules communicate via channels. Channels implement interfaces. An interface is a set of methods (functions). Ports

– Modules have ports. – Ports are connected to channels. – Modules access channels through ports.

... some_port->some_method(some_data); ...

slide-6
SLIDE 6

6

Interface Methods Calls (cont’d)

module channel process port module::process() { ... port->some_method(42); ... }

slide-7
SLIDE 7

7

Hierarchical channels Channels can be hierarchical, i.e. they can

contain modules, processes, and channels.

A module that implements an interface is a

hierarchical channel.

module channel process port module process port hierarchical channel i/f

slide-8
SLIDE 8

8

Example system (napkin view)

M1 M2 S1 S2 Arbiter BUS M3 masters slaves

slide-9
SLIDE 9

9

SystemC 2.0 transaction-level model

M1 M2 S1 S2

Arbiter

BUS clock M3

slide-10
SLIDE 10

10

SystemC 2.0 transaction-level model

M1 M2 S1 S2

Arbiter

BUS clock M3

slide-11
SLIDE 11

11

M3

SystemC 2.0 transaction-level model

M1 M2 S1 S2

Arbiter

BUS clock The bus is implemented as a hierarchical channel! The bus is implemented as a hierarchical channel!

slide-12
SLIDE 12

12

M3

SystemC 2.0 transaction-level model

M1 M2 S1 S2

Arbiter

BUS clock Arbiter and slaves are implemented as channels too! Arbiter and slaves are implemented as channels too!

slide-13
SLIDE 13

13

M3

SystemC 2.0 transaction-level model

M1 M2 S1 S2

Arbiter

BUS clock Arbiter has been made a separate module to allow for customization! Arbiter has been made a separate module to allow for customization!

slide-14
SLIDE 14

14

M3

SystemC 2.0 transaction-level model

M1 M2 S1 S2

Arbiter

BUS clock Optionally, ports can be connected to multiple channels! Optionally, ports can be connected to multiple channels!

slide-15
SLIDE 15

15

M3

SystemC 2.0 transaction-level model

M1 M2 S1 S2

Arbiter

BUS clock Optionally, ports can be connected to multiple channels! Optionally, ports can be connected to multiple channels!

sc_port<class IF, unsigned n_channels = 1> sc_port<class IF, unsigned n_channels = 1>

slide-16
SLIDE 16

16

M3

Rising clock edge

M1 M2 S1 S2

Arbiter

BUS clock Masters request bus access. Masters request bus access.

slide-17
SLIDE 17

17

M3

Falling clock edge

M1 M2 S1 S2

Arbiter

BUS clock The bus has a process that is sensitive to the falling edge. The bus has a process that is sensitive to the falling edge.

slide-18
SLIDE 18

18

M3

Falling clock edge

M1 M2 S1 S2

Arbiter

BUS clock The arbiter is called. It will grant a single master access to the bus. The arbiter is called. It will grant a single master access to the bus.

slide-19
SLIDE 19

19

M3

Falling clock edge

M1 M2 S1 S2

Arbiter

BUS clock Then, a slave is accessed after consulting the memory map. Then, a slave is accessed after consulting the memory map.

slide-20
SLIDE 20

20

M3

Bus interfaces

M1 M2 S1 S2

Arbiter

BUS clock

slide-21
SLIDE 21

21

Master interfaces of the bus Blocking:

– Complete bursts – Used by high-level models

Non-blocking:

– Cycle-based – Used by processor models

Direct:

– Immediate slave access – Put SW debugger to work

slide-22
SLIDE 22

22

Blocking master interface

status burst_read(unique_priority, data*,

start_address, length=1, lock=false);

status burst_write(unique_priority, data*,

start_address, length=1, lock=false);

“Blocking” because call returns only after

complete transmission is finished.

Master is identified by its unique priority.

slide-23
SLIDE 23

23

Dynamic Sensitivity SystemC 1.0

– Static sensitivity

Processes are made sensitive to a fixed set of signals during elaboration

SystemC 2.0

– Static sensitivity – Dynamic sensitivity

The sensitivity (activiation condition) of a process can be altered during simulation (after elaboration) Main features: events and extended wait() method

slide-24
SLIDE 24

24

Waiting

wait(); // as in SystemC 1.0 wait(event); // wait for event wait(e1 | e2 | e3); // wait for first event wait(e1 & e2 & e3); // wait for all events wait(200, SC_NS); // wait for 200ns // wait with timeout wait(200, SC_NS, e1 | e2); wait(200, SC_NS, e1 & e2);

slide-25
SLIDE 25

25

Dynamic sensitivity

MASTER BUS clock

status bus::burst_write(...) { ... wait(transmission_done); ... }

Statically sensitive to clock activated every cycle

Master won’t be activated until transmission is completed! Master won’t be activated until transmission is completed!

slide-26
SLIDE 26

26

Dynamic sensitivity

MASTER BUS clock

status bus::burst_write(...) { ... wait(transmission_done); ... }

Statically sensitive to clock activated every cycle

Master won’t be activated until transmission is completed! Master won’t be activated until transmission is completed!

Advantages:

Easy-to-use interface (blocking interface) Simulation speed

slide-27
SLIDE 27

27

Non-blocking master interface status get_status(unique_priority); status read(unique_priority, data*,

address, lock=false);

status write(unique_priority, data*,

address, lock=false);

“Non-blocking” because calls return immediately. Less convenient than blocking API but caller remains

in control (needed e.g. for most processor models).

slide-28
SLIDE 28

28

Direct master interface status direct_read(data*, address); status direct_write(data*, address); Provides direct access to slaves (using the bus’

address map).

– Immediate access

  • simulated time does not advance

– No arbitration

Use for SW debuggers or decoupling of HW and SW. Use with care!

slide-29
SLIDE 29

29

M3

Slave interface

M1 M2 S1 S2

Arbiter

BUS clock

slide-30
SLIDE 30

30

Slave interfaces unsigned start_address(); unsigned end_address(); status read(data*, address); status write(data*, address); status direct_read(data*, address); status direct_write(data*, address);

address mapping regular I/O debug interface

slide-31
SLIDE 31

31

What’s so cool about transaction-level bus models?

They are …

relatively easy to develop and extend easy to use fast

– use of IMC

  • function calls instead of HW signals

and control FSMs

– use of dynamic sensitivity

  • reduce unnecessary

process activations

slide-32
SLIDE 32

32

Key language elements used in the example Interface method calls (IMC) Hierarchical channels Connecting ports to multiple channels Dynamic sensitivity / waiting

slide-33
SLIDE 33

33

Conclusions

SystemC 2.0 enables efficient platform modeling.

Ease of modeling

  • get to executable platform model ASAP

Simulation speed

Still not convinced?

Try it out! (see following slides)

slide-34
SLIDE 34

34

How to install

> cd <systemc_installation_directory>/examples/systemc > gtar zxvf simple_bus_v2.tgz This will create a directory 'simple_bus'. Go to this directory and build the executable, e.g. For gcc-2.95.2 on Solaris: > gmake -f Makefile.gcc … Now you can run the executable, e.g. > simple_bus.x

See README.txt for detailed information!

slide-35
SLIDE 35

35

The testbench

M1 M2 S1 S2

Arbiter

BUS clock M3 see simple_bus_test.h

slide-36
SLIDE 36

36

The testbench

M1 M2 S1 S2

Arbiter

BUS clock M3 Blocking master: uses blocking bus interface to read and write data Arbiter: Priority-based arbitration, supports bus locking

slide-37
SLIDE 37

37

The testbench

M1 M2 S1 S2

Arbiter

BUS clock M3 Non-blocking master: Uses non-blocking bus interface for data I/O Direct master: uses direct interface

  • f bus to print debug

information

slide-38
SLIDE 38

38

The testbench

M1 M2 S1 S2

Arbiter

BUS clock M3 Fast memory: zero wait states Slow memory: configurable number

  • f wait states
slide-39
SLIDE 39

39

The testbench (cont’d)

Most modules are configurable

– Masters

Priority (not direct master) Delay / timeout Bus locking on/off (not direct master)

– Slaves

Address ranges Number of wait-states (only slow memory)

– Bus, arbiter, direct master

Verbosity

Change parameter settings in simple_bus_test.h See README.txt for details

slide-40
SLIDE 40

That’s it!

Thank you and have fun trying it out!