SystemC System-Level Modeling

1. SystemC System-Level Modeling Mehdi Mosaffa Abdurrahman Manian

2. Requirements for a System-level Language? • Specification and design at various levels of abstraction • Creation of executable specifications of design • Creation of executable platform models, representing possible implementation architectures • Fast simulation to enable design-space exploration • Constructs for separating functionality from communication

3. Modeling Levels • Not all modules within a system are modeled at the same level of abstraction. • A design under test might be a very detailed implementation level model, while abstract models are used within the test-bench • With a detailed implementation-level model as a starting point, a designer might create a more abstract model for simulation, and IP protection • A designer might refine a module from high-level specification down to a RTL model, while other modules remain at higher levels of abstraction

4. Modeling Levels

5. System specification in SystemC Completely implementation independent. Modeling Levels

6. Similar to executable specification. No time delays at all present in the model. Communication between modules is point-to-point. No shared communication links such as buses are modeled. Modeling Levels

7. Still point-to-point communication. Timing delays are added to processes to reflect timing constraints of a specific target implementation. Early hardware-software trade-off analysis. Modeling Levels

8. Communication between modules modeled using function calls. Communication is not modeled in a structurally accurate manner. Modeling Levels

9. Pin-accurate and functionally accurate at its boundaries. Not clock cycle accurate. Does not reflect structure of target implementation. Input to behavioral hardware synthesis tools. Modeling Levels

10. Pin-accurate and cycle-accurate at its boundaries. Not necessarily internal structure that reflects the target implementation. Modeling Levels

11. Internal structure of an RT level model accurately reflects the registers and combinational logic of a target implementation. Modeling Levels

12. Models of Computation (MOC) • The model of time employed and the event ordering constraints within the system. • The supported method(s) of communication between concurrent processes. • The rules for process activation. • Traditional design languages (VHDL, Verilog) have single fixed MOC.

13. Models of Computation (MOC) • SystemC has base MOC that is extremely general • Customized MOCs can be efficiently layered on top of the base capabilities of SystemC • SystemC features for customized MOCs • Events (notify(), wait()) • Broad range of different channels without change in simulation engine can be implemented • specialized channels, interfaces, ports and modules

14. Models of Computation (MOC) • Some well-known MOCs that can be modeled in SystemC: • Static multi-rate dataflow • Dynamic multi-rate dataflow • Kahn process networks • Discrete event as used for • RTL hardware modeling • network modeling • transaction-based SoC platform modeling

15. Register-Transfer Level (RTL) MOC • Like in Verilog and VHDL • Communication between processes through signals • Sequential/combinatorial logic • Pin-and cycle-accurate • No gate delays

16. Kahn Process Networks (KPN) • An effective MOC for building algorithmic models of signal-processing applications • Blocks or processes execute concurrently and are connected by channels that carry data tokens • Infinite FIFO channels • Blocking read, nonblocking write • No concept of time

17. Static Dataflow (SDF) • Special case of KPN • Process functionality is separated into three stages • Reading input tokens • execution of computation • writing output tokens • The number of tokens that a process will read and write each time it is executed is fixed and known at compile-time • Tools build static execution schedules for processes and compute bounds for all FIFOs at compile-time • Faster than KPN

18. Transaction-Level Models (TLM) • Specific type of the discrete-event MOC • Communication between modules using function calls • Transactions (start time, end time, palyload data) • No sc_signal channels – instead data is exchanged between different processes by reading and writing shared data variables • Shared data variables • Synchronization is very important • TLM designs simulate much faster than corresponding RTL designs and are more concise.

19. Register-Transfer Level (RTL)

20. Module Ports RTL process Signals RTL process RTL process General structure of RTL

21. RTL Example: Robot Controller • A Robot which solves the Shuttle Puzzle SystemC….

22. Shuttle Puzzle • Goal • interchange the black and the red pegs • Rules • you can move to a hole that's next to a peg • you can jump, but only one peg and it must be of the other color • you can't move backwards

23. Description of Robot • Horizontal conveyer belt moves the base of puzzle back and forth • Vertical pulley moves and electromagnet that picks up and drops objects • Stepper motors move conveyer and pulley • In each dimension there is a micro switch providing an absolute reference point

24. Description of Controller

25. mrdy_proc MDRY CLRMRDY ctrl_fsm_state SETMRDY curr_state next_state ctrl_fsm RESET uSW_ZERO LDDIR LDINST LDDIST DONE LSB_CNTR REVERSE counter_proc XY inst_reg_proc MAGNET uSEQ_BUS CLOCK REPOS Structural Diagram of Robot Controller

26. SystemC Model of Controller • SC_MODULE(robot_controller) { • sc_in<bool> CLOCK; • sc_in<bool> RESET; • sc_in<sc_bv<8> > uSEQ_BUS; • sc_in<bool> CLRMRDY; • sc_in<bool> uSW_ZERO; • sc_inout<bool> MRDY; • sc_inout<bool> REPOS; • sc_inout<bool> MAGNET; • sc_out<bool> XY; • sc_out<bool> REVERSE; • sc_out<bool> LDDIR; • sc_out<bool> LSB_CNTR; • } • /* Internal variables and signals */ • enum ctrl_state { IDLE, INST, DIST, RECAL, DIR, MOVE }; • sc_signal<ctrl_state> curr_state, next_state; • sc_signal<bool> DONE, LDDIST, COUNT, LDINST, SETMRDY; • sc_uint<8> counter;

27. SystemC Model of Controller • void ctrl_fsm_state(); • void ctrl_fsm(); • void counter_proc(); • void inst_reg_proc(); • void mrdy_proc(); • /* Constructor */ • SC_CTOR(robot_controller) { • SC_METHOD(counter_proc); sensitive << CLOCK.pos(); • SC_METHOD(inst_reg_proc); sensitive << CLOCK.pos(); • SC_METHOD(mrdy_proc); sensitive << CLOCK.pos(); • SC_METHOD(ctrl_fsm_state); sensitive << CLOCK.pos(); • SC_METHOD(ctrl_fsm); • sensitive << RESET << REPOS << MAGNET • << DONE << uSW_ZERO << MRDY << curr_state; • } • };

28. SystemC Model of Controller (RTL processes) • case INST: • if (MAG.read()) { • SETMRDY.write(true); • ns = IDLE; • } else if (REPOS.read()) { • LDDIR.write(true); • ns = RECAL; • } else { • SETMRDY.write(true); • ns = DIST; • } • break; • case RECAL: • ………. • Void robot_controller::ctrl_fsm_state() • { • curr_state.write(next_state.read()); • } • void robot_controller::ctrl_fsm() • { • ctrl_state ns = curr_state; • LDDIST.write(false); • COUNT.write(false); • LDINST.write(false); • SETMRDY.write(false); • ….. • if (RESET.read()) { • ns = IDLE; • } else { • switch (curr_state.read()) { • case IDLE: • if (! MRDY.read()) { • LDINST.write(true); • ns = INST; • } • break;

29. Behavioral-Level Modeling in SystemC

30. Behavioral-level Don’t care about states, registers etc. Use I/O-cycles Think your design as program flow RTL-level Map different states, registers etc. Use clock-cycles Think your design as finite- state-machine Behavioral VS RTL-level Modeling

31. SC_CTHREAD • Sensitivity is restricted to a single edge of a clock • Two useful constructs: watching() and wait_until() • watching()watches some specific action • wait_until() is almost same as wait() • wait_until() allows to specify condition that must take place to resume process • Clock cycles are separated using wait() or wait_until()

32. Behavioral Example • SC_MODULE(euclid_gcd) { • sc_in_clk clk; • sc_in<bool> rst; • sc_in<unsigned> a,b; • sc_out<unsigned> c; • sc_out<bool> ready; • void compute(); • SC_CTOR(euclid_gcd) { • SC_CTHREAD(compute, clk.pos()); • watching(rst.delayed()== true); • } • }

33. Behavioral Example • void design::compute { // Reset sectionunsigned • tmp_a = 0, tmp_b; • while (true) { • // IO cycle #1 • c.write(tmp_a); // place output on c • ready.write(true); // and assert READY • wait(); • // Another IO cycle • tmp_a = a.read(); // sample inputs • tmp_b = b.read(); • ready.write(false); // lower READY • wait(); • // No IO takes place during the computation of GCD. • // Computation and communication are separated • while (tmp_b != 0 ) { // Euclid’s algorithm • unsigned r = tmp_a; • tmp_a = tmp_b; • r = r % tmp_b; // compute remainder • tmp_b = r; • } } • }

34. Functional-Level Modeling in SystemC

35. Untimed Functional Modeling • Model of computation is KPN • Communication is handled through limited size FIFO-channels with blocking read() and write() operations • Algorithmic delays are represented by initial values stored in FIFOs • Use modules that contain SC_THREAD processes • No time will be present, everything advances in delta cycles • Synchronization is implicit • Write access block until space is available • Read access block until data is available • Caution • Provide initial values of FIFOs prior simulation • Make sure that data is produced before it is consumed

36. Un-timed Dataflow Example • //simple dataflow adder • SC_MODULE(DF_ADDER) { • sc_fifo_in<int> input1, input2; • sc_fifo_out<int> output; • void process() { • while (1) output.write(input1.read() + input2.read()); • } • SC_CTOR(DF_ADDER) { • SC_THREAD(process); • } • }

37. Timed functional models • Notion of time is needed when functional models are used on lower level of abstraction • Processing delays are done with wait(sc_time) • Timed and untimed models can peacefully coexist and interact • It is even possible to mix FIFO-and signal-based communication

38. Timed Dataflow Example 1 • //Simple timed dataflow adder • SC_MODULE(DF_ADDER) { • sc_fifo_in<int> input1, input2; • sc_fifo_out<int> output; • void process() { • while (1) { • int data = input1.read() + input2.read(); • wait(200, SC_NS); • output.write(data); • } • } • SC_CTOR(DF_ADDER) { • SC_THREAD(process); • } • }

39. Timed Dataflow Example 2 • // Mixed FIFO-and signal-based communication • SC_MODULE(DF_CoeffMul) { • sc_fifo_in<int> input; • sc_fifo_out<int> output; • sc_in<int> coefficient; • void process() { • while(1) { • output.write(input.read() * coefficient.read()); • } • } • SC_CTOR(DF_CoeffMul) { • SC_THREAD(process); • } • };

40. Transaction-Level Modeling in SystemC

41. Transaction Level Modeling • High-level approach to modeling digital systems • Details of communication separated from the details of the implementation of functional units or of the communication architecture • Emphasis more on the functionality of the data transfers, not so much their actual implementation protocol • In behavioral-level modeling there are still synchronization details; in transaction-level modeling those are abstracted into the categories blocking and non-blocking I/O

42. Transaction Level Modeling • Transaction-level modeling allows faster simulations than pin-based interfaces • e.g. large burst-mode transfer may take many actual clock cycles, here we can use burst_read and burst_write methods • Use transaction-level modeling when it is beneficial • functional modeling (untimed and timed) • platform modeling • test benches

43. The Simple Bus Design • The simple_bus design is an example of a high performance, cycle-accurate, platform transaction-level model in SystemC • The complete code and detailed documentation can be downloaded from www.systemc.org (the amount of code is about one thousand lines) • Why TLM models similar to simple_bus are so important ? • Relatively easy to develop, understand, use and extend • Model accuracy (both HW and SW) • Early construction, design space exploration, tradeoff analysis • Fast and accurate enough to validate SW before HW models or implementations are available

44. The Simple Bus Design • Key point: • very high simulation speed to allow meaningful amounts of software to be executed along with the hardware model • Additionally, the models need to be capable of being fully cycle-accurate • “agreed-upon contract” between HW and SW teams • “Very high simulation speed” • 100 000 clock cycles per second • Possible to apply a variety of realistic tests that include software parts of the system

45. Structure of the Simple Bus Design • The simple_bus design contains the following types of blocks: • Masters (e.g. CPU, DSP) • Bus • Slaves (e.g. ROM, RAM, I/O device, ASIC) • Arbiter (selects a request to execute) • Clock generator • Masters can initiate transactions on the bus and slaves respond to bus requests they receive

46. References • [1] System Design with SystemC, T.Grotker, S. Liao, G. Martin, S. Swan; Kluwer Academic Publishers. • [2] www.tkt.cs.tut.fi/kurssit/ 8404129/S04/Luennot/Lect10.pdf