System C

1
System C

• By
• Brendan Leddy
• Ken Seto
• Darren Stone
• Gordon Vuong

2
Introduction

• SystemC History
• Early development done at Synopsys, CoWare/IMEC,
  UC Irvine
• Open SystemC Initiative (OSCI) formed in 2000
• OSCI LWG developed SystemC 2.0 specification and
  implementation in
• 2000-2001, greatly extending the language
  capabilities
• SystemC Organization Today
• Open SystemC Initiative (OSCI) is incorporated as
  a California non-profit
• organization with formal bylaws, a significant
  budget, etc.
• Licensing model is Open Community Licensing.
  (Unlike GNU, it is OK to
• build proprietary products from SystemC code.)
• Well-organized public relations efforts for
  SystemC are on-going (e.g.
• SystemC Tech Forum at DAC 2002).
• Website and source code maintenance for
  reference implementations are
• located on SourceForge, and key developers from
  different companies
• can access/modify code.

3
SystemC Alternatives

• Raw C
• All hardware support has to be built manually
• IP exchange is difficutl
• SpecC
• Lack of support
• No RTL modeling
• Neither C or C
• Seems to be dropping off

4
SystemC Alternatives

• Superlog, SystemVerilog
• Good RTL support
• Similar to C/C but not quite
• Lacks standardization

5
Why SystemC

• Provides system level and HDL modeling
  capabilities
• Controlled by a board which including ARM,
  Fujitsu, NEC, and Sony
• OpenSource
• Used by many major companies

6
What is SystemC

• Not a separate language
• Essentially a C library
• Gives a notion of timing and event driven
  simulations
• Sequential in Nature
• Allow description and integration of complex
  hardware and software

7
System on Chip
8
System on Chip

• An SOC is literally a system on a chip,
  consisting of both silicon and embedded software
• Having the whole system embedded into a die

9
Old methodology

• Functional model is divided into 3 parts for
  separate development/ test/ verification

10
System Design Methodology

• System hardware are modelled on block and signal
  (RTL) level
• test software/ firmware on simulation CPUs (eg.
  FPGA) with
• Instruction Set Simulator (ISS) or cycle-accurate
  CPU models

11
Old Methodology
12
Disadvantages

• Productivity aspect
• Specification between architect and
  implementer
• Manual simulation and prototyping
• Refinement requires translation into hardware
• System level aspect
• Limiting the design scale of system requires
  engineers being familar with the whole system
  hardware and software
• cannot Co-design, co-simulation,
  co-verification, co-debugging, ...
• Re-use aspect
• firmware are hardware customized and difficult
  for re-use
• need to rewrite the testbench

13
Single Modeling Platform

• System behaviors are designed in the early stage.
• System engineers co-design with RTL development
• Define hardware in modules Isolate unnecessary
  hardware details in early system design
• Integrated platform for high simulation speed
• One environment for both hardware and software
• design
• development
• debug
• Support for hardware/software testing scenarios
• Repository/ archive for all parts of a simulation
  scenario
• Modeling on architecture level

14
SystemC Core Language
15
Core Language Features

• Structure defined by modules, ports, interfaces
  and channels
• Interfaces and ports also describe communication
• Simulation dictated by results of events and
  process interacting

16
Overview

• Modules base unit of structure
• Channels describe a method of communication for
  modules
• Ports used by modules to access channels in
  other modules
• Interface describes the features a channel must
  implement
• Processes concurrent threads of execution
• Events control the timing of processes

17
Modules

• The basic unit of SystemC
• Contains ports, channel instances, internal data,
  member module instances, additional helper
  functions
• Can only be constructed during the elaboration
  phase
• Sealed unit communication by ports

18
Modules

• Module instantiation

19
Modules

• Macro recommended but not required

20
Channels

• Connecting unit for modules
• Specified by an interface
• Two types
• Primitive
• sc_signal, sc_fifo, sc_mutex, sc_semaphore
• Hierarchical
• Actually a module (modules, ports, channels
  contained within)

21
Channels
22
Interfaces

• Rigidly define what channels must implement
• Like Java implement all of the functions to
  implement interface
• Abstraction for the channels (OO Design)
• Channels can implement multiple interfaces
• Multiple channels can be defined by the same
  interface

23
Ports

• Provide access to channels across modules
• Port specifies which interfaces are required by a
  module
• sc_inltboolgt A, B // input signal ports
• sc_outltboolgt F // output signal ports

24
Processes

• Pseudo-concurrent threads
• Processes are sensitive to events
• Static sensitivity
• Dynamic sensitivity
• Two types of processes
• sc_thread
• sc_method

25
Processes

• sc_thread
• Used for processes not expected to halt
• To facilitate fair time sharing, wait() is called
• wait() waits for default event before continuing
  execution
• wait() can be called with an argument to override
  default sensitivity (dynamic sensitivity)

26
Processes

• sc_method
• Much like other languages, sc_methods run
  completely then return
• sc_methods cannot be terminated
• Dynamic sensitivity with next_trigger() function
• sc_event single
• sc_event_or_list multiple any may notify
• sc_event_and_list multiple, all must notify
• sc_time timed event

27
Events

• Events can do two things
• wait
• fire
• Examples positive clock edge, negative edge etc.
• Custom signals possible
• Example wait(data_read_event).

28
Simple Example

• include "systemc.h"
• SC_MODULE(nand2) // declare nand2
  sc_module
• sc_inltboolgt A, B // input signal ports
• sc_outltboolgt F // output signal ports
•  
• void do_nand2() // a C function
• F.write( !(A.read() B.read()) )
•  
• SC_CTOR(nand2) // constructor for
  nand2
• SC_METHOD(do_nand2) // register do_nand2
  with kernel
• sensitive ltlt A ltlt B // sensitivity list

29
SystemC Data Types
30
SystemC Data Types

• C Built-in Types
• bool
• char
• int
• float
• strings
• pointers / references

not synthesisable
31
SystemC Data Types

• bit and bit vector
• sc_bit, sc_bvltNgt
• four-state logic
• sc_logic, sc_lvltNgt
• 0 Logical 0
• 1 Logical 1
• Z High Impedance
• X Unknown

• Fixed Precision ints
• 64 Bits
• sc_intltNgt
• sc_uintltNgt
• Arbitrary Precision
• Up to 512 Bits
• sc_bigintltNgt
• sc_biguintltNgt

32
SystemC Data Types

• Fixed Point Types
• Useful in DSP applications
• Specify Quantization and Saturation Behavior
• sc_fixedltwl, iwl, q_mode, o_mode, n_bitsgt
• wl Total WorD Length
• iwl Integer Word Length
• q_mode Quantization Mode
• o_mode Overflow Mode
• n_bits Number of Saturated Bits

33
SystemC Data Types

• Common Characteristics
• Native C types (int, float, string) and SystemC
  types may be mixed.
• Equality and bitwise operators (, ltlt, gtgt)
• All SystemC Data Types
• Arithmetic and relational operators (, -, lt, gt)
• Numeric data types only
• Overloaded assignment operators
• Provides conversion between different data types.
• Conversion may truncate data when necessary.
• e.g. myInt myFloat

33
34
SystemC Data Types

• Utility Methods
• Bit Select get and set specific bits
• Range Select get and set a range of bits
• Concatenation join bits
• Bitwise Reduction
• Integer Conversion
• String input and output

34
35
SystemC Data Types

• Bit Select
• Read or write to a specific bit in a variable.
• C operator overloaded to provide read/write
  access.
• e.g.

sc_intlt4gt myInt // 4-bit signed
integer myInt1 true // Set bit 1 to
true.bool myBool bool b1 myInt0.to_bool() //
Read bit 0
35
36
SystemC Data Types

• Part Select
• Read/write a contiguous subset of bits within the
  variable.
• Available methods
• range(int, int)
• C operator()
• e.g.

sc_intlt8gt myInt 2 //
00000010 myInt.range(3, 2) myInt.range(1, 0)
// 00001010
36
37
SystemC Data Types

• Concatenation
• Concatenate the bits of two variables together.
• Available methods
• concat(arg0, arg1)
• C comma operator operator,

sc_intlt8gt U1 2 // 00000010 sc_intlt2gt U2 1
// 01 sc_intlt8gt U3 (true, U1.range(3,0), U2,
U20) // U3
10010011 (U20, U10, U1.range(7,6))
U1.range(3, 0)
37
38
SystemC Data Types

• Bitwise Reduction
• Performs bitwise operation on all bits in integer
  or vector.
• Returns bool.
• Operations
• and_reduce() - Bitwise AND between all bits
• nand_reduce() - Bitwise NAND between all bits
• or_reduce() - Bitwise OR between all bits
• nor_reduce() - Bitwise NOR between all bits
• xor_reduce() - Bitwise XOR between all bits
• xnor_reduce() - Bitwise XNOR between all bits

38
39
SystemC Data Types

• Integer Conversion
• All SystemC data types
• accept C integer assignment.
• convert to C interger types
• Conversion Methods
• to_int() - Convert to native int type
• to_uint() - Convert to native unsigned type
• to_long() - Convert to native long type
• to_ulong() - Convert to native unsigned long type
• to_uint64() - Convert to native 64-bit unsigned
  integer
• to_int64() - Convert to native 64-bit signed
  integer

39
40
SystemC Data Types

• String input and output
• All SystemC data types
• can be set by reading from a C input text
  stream
• can print their value to a C output text stream

void scan(istream input) void print(ostream
output)
40
41
Debugging
42
Text-based Debugging

• C printf debugging

printf(Hello World) cout ltlt Hello World ltlt
endl
42
43
Text-based Debugging

• Constructor Debugging
• Find out how your design is built up when the
  simulation starts.
• Use the name() method to identify SystemC classes

SC_CTOR(nand2) cout ltlt Constructing nand2
ltlt name() ltlt endl ... ... OUTPUT Construc
ting stim Constructing nand2 exor2.N1 Constructung
nand2 exor2.N2
43
44
Text-based Debugging

• Debugging methods available on all SystemC
  objects
• const char name()
• Returns the name of the object
• const char kind()
• Returns the objects sub-class name
• void print(ostream out)
• Prints the objects name to the output stream
• void dump(ostream out)
• Prints the objects diagnostic data to the output
  stream.

44
45
Text-based Debugging

• Debugging threads and methods
• All SystemC data types can be printed to cout.
• e.g. print inputs A, B, and F to cout in a table

OUTPUT Time A B F 10 ns 1 0 0 20 ns
1 1 0 30 ns 1 1 1 40 ns 0 0 1
45
46
Text-based Debugging
SC_MODULE(mon) sc_inltboolgt A,B,F
sc_inltboolgt Clk void monitor() cout
ltlt "Time A B F" ltlt endl while (true)
cout ltlt sc_time_stamp() ltlt ", "
cout ltlt A.read() ltlt ", " cout ltlt
B.read() ltlt ", " cout ltlt F.read() ltlt
endl wait() // wait for 1 clock cycle
SC_CTOR(mon)
SC_THREAD(monitor) sensitive ltlt Clk.pos()

46
47
Advanced Debugging

• Standard C debugging tools
• GDB, etc...
• SystemC-specific debuggers and visualizers.

47
48
Advanced Debugging
49
Wave-form Debugging

• Requires adding additional SystemC statements to
  sc_main()
• Wave-form data written to file as simulation
  runs.
• Sequence of operations
• Declare and create the trace file
• Register signals or events for tracing
• Run the simulation
• Close the trace file

49
50
Wave-form Tracing
int sc_main(int argc, char argv)
sc_signalltboolgt ASig, BSig, FSig sc_clock
TestClk("TestClock", 10, SC_NS,0.5, 1, SC_NS)
// Set up simulation ... // Set up trace
file sc_trace_file Tf Tf
sc_create_vcd_trace_file("traces") //
Create Trace File ((vcd_trace_file)Tf)-gtsc_set_
vcd_time_unit(-9) // Set time unit
sc_trace(Tf, ASig , "A" ) // Register
signals sc_trace(Tf, BSig , "B" )
// and variables. sc_trace(Tf, FSig ,
"F" ) sc_trace(Tf, DUT.S1, "S1")
sc_trace(Tf, DUT.S2, "S2") sc_trace(Tf,
DUT.S3, "S3") sc_start() // run
forever // Start the simulation
sc_close_vcd_trace_file(Tf) // Close the trace
file return 0
50
51
Wave-form Tracing

• Sample Output

51
52
Hardware Software Codesign
53
Introduction

• Hardware used for performance
• Software used for flexibility
• Almost everything consist of both hardware and
  software
• Hardware and software designed separately

54
Introduction

• Lack of a unified hardware-software
  representation
• A priori definition of partitions
• leads to sub-optimal designs
• Lack of a well-defined design flow
• makes specification revision difficult

55
Traditional Design Path

• Hardware designed first
• Software designed after completion of HW
• Designed completely by separate teams

56
HW/SW Design Path

• HW SW designed simultaneously
• Allow the evaluation of tradeoffs

57
How SystemC helps

• HW and SW exist in a homogenous environment
• Allow stepwise refinement of HW design without
  language barrier
• HW syntheses can be done directly
• Verification can be done early and frequent

58
How SystemC Helps

• Describe HW in higher level of abstraction
• Provides library for describing HW
• Create fast prototype of the HW

59
Module

• Encapsulates a HW/SW description
• Same as Verilog modules
• Describes input and output ports

60
Compositions

• Allows for hierarchical design
• Allows creation of complex systems

61
Simulation

• Sim instructions usually located in main function
  (sc_main)
• Set resolution, channels, etc

62
Questions?
63
References

• http//embedded.eecs.berkeley.edu/Respep/Research/
  hsc/abstract.htmlmotivation
• http//www.esperan.com/pdf/Esperan_SystemC_tutoria
  l.pdf
• http//www.doulos.com/knowhow/systemc/tutorial/
• http//www.comelec.enst.fr/hdl/sc_docs/systemc_qui
  ckreference.pdf
• http//www.ecsi-association.org/ecsi/projects/odet
  te/files/6.systemc.pdf