SoC Design. Prof. Dr. Christophe Bobda Institut für Informatik Lehrstuhl für Technische Informatik

Transcription

1 SoC Design Prof. Dr. Christophe Bobda Institut für Informatik Lehrstuhl für Technische Informatik

2 Chapter 3 SystemC

3 Outline 1. Introduction 2. SystemC Overview 3. System Abstraction Level 4. Program Structure Modules Interfaces Signals Composition The main()-function Processes Testbenches Data-Types Clocks and Timing Christophe Bobda 3

4 1. Introduction Standard Methodology for ICs o System-level designers write a C or C++ model Written in a stylized, hardware-like form Sometimes refined to be more hardware-like o C/C++ model simulated to verify functionality o Model given to Verilog/VHDL coders o Verilog or VHDL specification written o Models simulated together to test equivalence o Verilog/VHDL model synthesized Christophe Bobda 4

5 1. Introduction Designing Big Digital Systems o Every system company was doing this differently o Every system company used its own simulation library o Throw the model over the wall approach makes it easy to introduce errors o Problems: System designers don t know Verilog or VHDL Verilog or VHDL coders don t understand system design Christophe Bobda 5

6 1. Introduction Advantages of C/C++-Based Language for System Modeling o Specification between architects and implementers is executable o High simulation speed due to the higher level of abstraction (nativecode compilation) Most VHDL/Verilog simulators compile to an intermediate code (a byte code) which is then interpreted uses normal C++ compilers + library to compile to native code. o Refinement, no translation into HDL (no semantic gap ) o Testbench re-use Christophe Bobda 6

7 1. Introduction Advantages of Executable Specifications o Ensure the completeness of specification Even components (e.g. Peripherals) are so complex Create a program that behave the same way as the system o Avoid ambiguous interpretation of the specification Avoids unspecified parts and inconsistencies o IP customer can evaluate the functionality up-front o Validate system functionality before implementation Create early model and validate system performance o Refine and test the implementation of the specification Test automation improves Time-to-Market Christophe Bobda 7

8 1. Introduction Can traditional C++-standard be used? o C++ does not support Hardware style communication Signals, protocols, etc Notion of time Time sequenced operations Concurrency Hardware and systems are inherently concurrent Reactivity Hardware is inherently reactive, it responds to stimuli and is in constant interaction with its environments Hardware data types Bit type, bit-vector type, multi-valued logic type, signed and unsigned integer types and fixed-point types Christophe Bobda 8

9 1. Introduction Idea of SystemC o C and C++ are being used as ad-hoc modeling languages o Why not formalize their use? o Why not interpret them as hardware specification languages just as Verilog and VHDL were? o SystemC developed at Synopsys to do just this Christophe Bobda 9

10 2. SystemC overview What is SystemC? o A subset of C++ that models/specifies synchronous digital hardware o A library of C++ classes Processes (for concurrency) Clocks (for time) Hardware data types (bit vectors, 4-valued logic, fixed-point types, arbitrary precision integers) Waiting and watching (for reactivity) Modules, ports, signals (for hierarchy) Abstract ports and protocols (abstract communications) Using channel and interface classes o A compiler that translates the synthesis subset of SystemC into a netlist o Freely available implementation (2.0) available at Christophe Bobda 10

11 2. SystemC Overview Design Flow Christophe Bobda 11

12 2. SystemC Overview Language Architecture Christophe Bobda 12

13 3. System Abstraction Level Untimed Functional Level (UTF) o Refers to both the interface and functionality o Abstract communication channels o Processes executed in zero time but in order o Transport of data executed in zero time Timed Functional Level (TF) o Refers to both the interface and functionality o Processes are assigned an execution time o Transport of data is assigned a time o Latency modeled o Timed but not clocked Bus Cycle Accurate (BCA) o Transaction Level Model (TLM) o Model the communications between system modules using shared resources such as busses o Bus cycle accurate or transaction accurate No pin-level details Christophe Bobda 13

14 3. System Abstraction Level Pin Cycle Accurate (PCA) o Fully described by HW signals and the communications protocol o Pin-level details o Clocks used for timing Register Transfer Accurate o Fully timed o Clocks used for synchronization o Complete functional details Every register for every cycle Every bus for every cycle Every bit described for every cycle o Ready to RTL HDL Christophe Bobda 14

15 4. Program Structure A SystemC program consists of module definitions plus a toplevel function that starts the simulation Modules contain processes (C++ methods) and instances of other modules Ports on modules define their interface o Rich set of port data types (hardware modeling, etc.) Signals in modules convey information between instances Clocks are special signals that run periodically and can trigger clocked processes Rich set of numeric types (fixed and arbitrary precision numbers) Christophe Bobda 15

16 4.1 Modules The basic building blocks for partitioning a design Declared with the SystemC keyword SC_MODULE Typically contain o Ports that communicate with the environment o Process that describe the functionality of the module o Internal data and communication channels for the model o Hierarchies (other modules) SC_MODULE(mymod) { /* port definitions */ /* signal definitions */ /* clock definitions */ /* storage and state variables */ /* process definitions */ SC_CTOR(mymod) { /* Instances of processes and modules */ ; Christophe Bobda 16

17 4.2 Ports Define the interface to each module Channels through which data is communicated Port consists of a direction o input sc_in o output sc_out o bidirectional sc_inout and any C++ or SystemC data type SC_MODULE(mymod) { sc_in<bool> load, read; sc_inout<int> data; sc_out<bool> empty, full; /* rest of the module */ ; In VHDL Entity module_name( port_name: Dir type;. ); End entityssd Christophe Bobda 17

18 4.3 Signals Convey information between modules and within a module Directionless: module ports define direction of data transfer Type may be any C++ or built-in type SC_MODULE(mymod) { /* port definitions */ sc_signal<sc_uint<32> > s1, s2; sc_signal<bool> reset; /* */ SC_CTOR(mymod) { /* Instances of modules that connect to the signals */ ; Christophe Bobda 18

19 4.4 Composition Hierarchy is enforced through the use of low-level modules Each instance is a pointer to an object in the module SC_MODULE(mod1) { ; SC_MODULE(mod2) { ; SC_MODULE(foo) { mod1* m1; mod2* m2; sc_signal<int> a, b, c; SC_CTOR(foo) { m1 = new mod1( i1 ); (*m1)(a, b, c); m2 = new mod2( i2 ); (*m2)(c, b); ; Connect instance s ports to signals Christophe Bobda 19

20 4.4 VHDL vs SystemC Instantiation VHDL Entity module_name( port_name: Dir type;. ); End entity Architecture XXX of module_name component adder(. ); End component Adder1: adder Port map(a1 => a, a1 =>b, res=> c) SystemC #include systemc.h #include adder.h. Int sc_main(in argc, char* agr[]) Sc_signal<bool> a1, b1, ; Adder u1( u1 ); U1<<a1<<b1<<. U1.res(out); U1.a(a); U1.b(b); sc_start(-1) Return(0); Christophe Bobda 20

21 4.5 The main() function Top-level module instiation #include systemc.h #include adder.h. Int sc_main(in argc, char* agr[]) Sc_signal<bool> a1, b1, ; Adder u1( u1 ); U1<<a1<<b1<<. int sc_main(int argc, char **argv[]) { sc_signal<int> sig_a, sig_b, sig_c; Adder adder_1( adder_1 ); // Signal mapping adder_1.a(sig_a); adder_1.b(sig_b); adder_1.c(sig_c); U1.res(out); U1.a(a); U1.b(b); sc_start(-1) Return(0); // Other modules and testbench // which drive the input signals // Run for 10 seconds of simulation time sc_start(10, SC_SEC); return EXIT_SUCCESS; Christophe Bobda 21

22 4.6 Processes Only thing in SystemC that actually does anything Various behavior o Can be pure procedural o Can be called only once, suspended and wait for one or more conditions to become through to resume No notion of hierarchy Process have sensitivity list to trigger the process activation Three Types of Processes o METHOD Models combinational logic o THREAD Models testbenches o CTHREAD Models synchronous FSMs Christophe Bobda 22

23 4.6 METHOD Processes Triggered in response to changes on inputs Cannot store control state between invocations Designed to model blocks of combinational logic Invoked once every time input in changes Runs to completion: should not contain infinite loops Christophe Bobda 23

24 4.6 METHOD Processes Example SC_MODULE(onemethod) { sc_in<bool> in; sc_out<bool> out; void inverter(); Process is simply a method of this class SC_CTOR(onemethod) { ; SC_METHOD(inverter); sensitive(in); Instance of this process created and made sensitive to an input void onemethod::inverter() { bool internal; internal = in; out = ~internal; Read a value from the port Write a value to an output port Christophe Bobda 24

25 4.6 THREAD Processes Triggered in response to changes on inputs Can suspend itself and be reactivated o Method calls wait() to relinquish control o Scheduler runs it again later Designed to model just about anything SC_MODULE(onemethod) { sc_in<bool> in; sc_out<bool> out; void toggler(); Process is simply a method of this class SC_CTOR(onemethod) { ; SC_THREAD(toggler); sensitive << in; Instance of this process created alternate sensitivity list notation Christophe Bobda 25

26 4.6 THREAD Processes Reawakened whenever an input changes State saved between invocations Infinite loops should contain a wait() void onemethod::toggler() { bool last = false; for (;;) { last = in; out = last; wait(); last = ~in; out = last; wait(); Relinquish control until the next change of a signal on the sensitivity list for this process Christophe Bobda 26

27 4.6 CTHREAD Processes Triggered in response to a single clock edge Can suspend itself and be reactivated o Method calls wait to relinquish control o Scheduler runs it again later Designed to model clocked digital hardware SC_MODULE(onemethod) { sc_in_clk clock; sc_in<bool> trigger, in; sc_out<bool> out; Instance of this process created and relevant clock edge assigned void toggler(); SC_CTOR(onemethod) { SC_CTHREAD(toggler, clock.pos()); ; Christophe Bobda 27

28 4.6 CTHREAD Processes Reawakened at the edge of the clock State saved between invocations Infinite loops should contain a wait() Relinquish control until the next clock cycle in which the trigger input is 1 void onemethod::toggler() { bool last = false; for (;;) { wait_until(trigger.delayed() == true); last = in; out = last; wait(); last = ~in; out = last; wait(); Relinquish control until the next clock cycle Christophe Bobda 28

29 4.6 CTHREAD Processes Memory-Bus- Interfacing // bus.h #include "systemc.h" SC_MODULE(bus) { sc_in_clk clock; sc_in<bool> newaddr; sc_in<sc_uint<32> > addr; sc_in<bool> ready; sc_out<sc_uint<32> > data; sc_out<bool> start; sc_out<bool> datardy; sc_inout<sc_uint<8> > data8; sc_uint<32> tdata; sc_uint<32> taddr; void xfer(); ; SC_CTOR(bus) { SC_CTHREAD(xfer, clock.pos()); datardy.initialize(true); // ready to //accept //new address Christophe Bobda 29

30 4.6 CTHREAD Processes // bus.cc #include "bus.h" void bus::xfer() { while (true) { // wait for a new address to appear wait_until( newaddr.delayed() == true); // got a new address so process it taddr = addr.read(); datardy = false; // cannot accept new //address now data8 = taddr.range(7,0); start = true; // new addr for memory // controller wait(); // wait 1 clock between data transfers data8 = taddr.range(15,8); start = false; wait(); data8 = taddr.range(31,24); wait(); // now wait for ready signal from memory // controller wait_until(ready.delayed() == true); // now transfer memory data to databus tdata.range(7,0) = data8.read(); wait(); tdata.range(15,8) = data8.read(); wait(); tdata.range(23,16) = data8.read(); wait(); tdata.range(31,24) = data8.read(); data = tdata; data8 = taddr.range(23,16); wait(); datardy = true; // data is ready, new addresses ok Christophe Bobda 30

31 4.6 Watching A CTHREAD typically has an infinite loop continuous execution Watching construct allows the designer to: o Initialize the loop-behavior o Jump out of the loop according to a given condition The watching construct monitors a specified condition and transfer execution to the begin of the process that will handle #include "datagen.h" the condition Ex: reset-like behavior SC_MODULE(data_gen) { sc_in_clk clock; sc_inout<int> data; sc_in<bool> reset; void gen_data(); SC_CTOR(data_gen) { SC_CTHREAD(toggler, clock.pos()); watching(reset.delayed() == true); ; void gen_data() { if (reset == true) { data = 0; while (true) { data = data + 1; wait(); data = data + 2; wait(); data = data + 4; wait(); Christophe Bobda 31

32 4.6 Local Watching In normal case, a watching is global cannot be disable o Can be avoided through the use of local watching constructs Allows the designer to specify which section of the process is watching which signals Specified with 4 macros, which define the boundary of each areas void mymodule::myprocess() { W_BEGIN // put the watching declarations here watching(...); watching(...); W_DO // This is where the process functionality goes... W_ESCAPE // This is where the handlers for the watched events go if (..) {... W_END Christophe Bobda 32

33 4.7 Testbenches Use to provide stimulus to a design under test and check design result Various implementations o The stimulus can be generated by one process and the result checks by another one o The stimulus can be embedded in the main program and the result check by a process o The checking can be embedded in the main program o Etc. o Typical testbench Christophe Bobda 33

34 4.7 Testbenches The stimulus can be read from a file or can be generated by an SC_THREAD process or a SC_CTHREAD process the same for the checking modules Example: Counter testbensch // count_stim.h #include "systemc.h" SC_MODULE(count_stim) { sc_out<bool> load; sc_out<int> din; // input port sc_in<bool> clock; // input port sc_in<int> dout; ; void stimgen(); SC_CTOR(count_stim) { SC_THREAD(stimgen); sensitive_pos (clock); // count_stim.cc #include "count_stim.h" void count_stim::stimgen() { while (true) { load = true; // load 0 din = 0; wait(); // count up, value = 1 load = false; wait(); // count up, value = 2 wait(); // count up, value = 3 wait(); // count up, value = 4 wait(); // count up, value = 5 wait(); // count up, value = 6 wait(); // count up, value = 7 Christophe Bobda 34

35 4.8 SystemC Types SystemC programs may use any C++ type along with any of the built-in ones for modeling systems SystemC Built-in Types o sc_bit, sc_logic Two- and four-valued single bit o sc_int, sc_unint 1 to 64-bit signed and unsigned integers o sc_bigint, sc_biguint arbitrary (fixed) width signed and unsigned integers o sc_bv, sc_lv arbitrary width two- and four-valued vectors o sc_fixed, sc_ufixed signed and unsigned fixed point numbers Christophe Bobda 35

36 4.8 Fixed and Floating Point Types Integers o Precise o Manipulation is fast and cheap o Poor for modeling continuous real-world behavior Floating-point numbers o Flexible in range and precision o Better approximation to real numbers o Good for modeling continuous behavior o Manipulation is slow and expensive Fixed-point numbers o Worst of both worlds o Used in many signal processing applications Decimal ( binary ) point 2 Christophe Bobda 36

37 4.8 Using Fixed-Point Numbers High-level models usually use floating-point for convenience Fixed-point usually used in hardware implementation because they re much cheaper SystemC provides signed and unsigned fixed-point to model hardware Bit-level accurate and supports various features for proper modeling o Quantization, overflow, etc 4 basic fixed-point types: o sc_fixed: use static arguments must be known at compile-time o sc_ufixed: use static arguments o sc_fix: may use non-static arguments can be variables o sc_ufix: may use non-static arguments Christophe Bobda 37

38 4.8 SystemC s Fixed-Point Types Fixed-point declaration: sc_fixed<wl, iwl, q_mode, o_mode, n_bits> fpn; o wl is the total word length (number of bits in the type) o iwl is the number of bits to the left of the decimal point o q_mode defines the quantization mode: Behavior, when the result generates mode precision in the LSB than specified o o_mode defines the behavior when an overflow occurs o n_bits: number of saturated bits. Used in overflow mode to specified the number of saturated bit, if saturation behavior is defined and overflow occurs Example: sc_fixed<8, 1, SC_RND, SC_SAT, 1> fpn; Christophe Bobda 38

39 4.9 Time Model Using an integer-valued time model 64-bit unsigned integer Can be increase to more than 64 bits if necessary o Same as in Verilog and VHDL Time resolution o Must be specified before any time objects (e.g sc_time) are created o Default value is one pico-second ( s) Time unit Christophe Bobda 39

40 4.9 Clocks Special object in SystemC Generate timing signals used to synchronize event in the simulation Declaration: sc_clock clock1( myclock, 20, 0.5, 2, false); Time Zero Initial value is false of 20 Christophe Bobda 40

41 4.10 Transaction-Level Modelling Definition o High level approach to modeling digital systems o Details of communication among modules separated from details of implementation of the functional units or of the communication Architecture Emphasis more on the functionality of the data transfers, less on their actual protocol implementation Communication channels that are easier to use Higher simulation speed due to suppressing uninteresting details Christophe Bobda 41

42 4.10 Transaction-Level Modelling Example: A simple bus that supports burst read and write transactions Interface definition: class very_simple_bus_if : virtual public sc_interface { public: virtual void burst_read(char *data,unsigned addr,unsigned length) = 0; virtual void burst_write(char *data,unsigned addr,unsigned length) = 0; ; virtual void burst_read(char *data, unsigned addr, unsigned length) { _bus_mutex.lock(); // Bus contention modeled using a mutex wait(length * _cycle_time); // Block caller memcpy(data, _mem + addr, length); // Copy the data to requester _bus_mutex.unlock(); // Allow the others to access the bus Christophe Bobda 42

43 4.10 Transaction-Level Modelling class very_simple_bus: public very_simple_bus_if, public sc_channel { public: very_simple_bus(sc_module_name nm, unsigned mem_size, sc_time cycle_time) : sc_channel(nm), _cycle_time(cycle_time) { _mem = new char [mem_size]; // Bus memory access modeling with internal array memset(_mem, 0, mem_size); // Initialize array ~very_simple_bus() { delete[] _mem; virtual void burst_read(char *data, unsigned addr, unsigned length) { _bus_mutex.lock(); // Bus contention modeled using a mutex wait(length * _cycle_time); // Block caller memcpy(data, _mem + addr, length); // Copy the data to requester _bus_mutex.unlock(); // Allow the others to access the bus // Write method the same apart from the parameters of memcpy Christophe Bobda 43

44 4.10 Transaction-Level Modelling protected: char* _mem; sc_time _cycle_time; sc_mutex _bus_mutex; ; TLM models can accurately model different aspects without resorting to pin-accurate models o Contention o Arbitration o Interrupts o Cycle-accuracy Faster simulation o Speed ~100k cycles/sec compared to RTL cycle-accurate o simulation speed of ~1k cycles/sec Christophe Bobda 44

45 Synthesis Subset of SystemC At least two Behavioral Subset o Implicit state machines permitted o Resource sharing, binding, and allocation done automatically o System determines how many adders you have Register-transfer-level Subset o More like Verilog/VHDL o You write a +, you get an adder o State machines must be listed explicitly Christophe Bobda 45

46 Do People Use SystemC? Not as many as use Verilog or VHDL Growing in popularity People recognize advantage of being able to share models Most companies were doing something like it already Use someone else s free libraries? Why not? Christophe Bobda 46