1. Winter-Spring 2001Codesign of Embedded Systems1 Introduction to System-Level Modeling in SystemC 2.0 Part of HW/SW Codesign of Embedded Systems Course (CE 40-226)

2. Winter-Spring 2001Codesign of Embedded Systems2 Topics A Brief Review of SystemC 1.0 Objectives of SystemC 2.0 Communication and Synchronization in SystemC 2.0 Models of Computation within SystemC

3. Winter-Spring 2001Codesign of Embedded Systems3 Introduction to System-Level Modeling in SystemC 2.0 A Brief Review of SystemC 1.0

4. Winter-Spring 2001Codesign of Embedded Systems4 Brief Review of SystemC 1.0 A set of modeling constructs in RTL or Behavioral abstraction level Structural design using Modules, Ports, and Signals Rich set of data types including bit-true types Specially: Fixed-Point data types for DSP apps.

5. Winter-Spring 2001Codesign of Embedded Systems5 Brief Review of SystemC 1.0 (cont’d) Concurrent Behavior is described using Processes Processes can suspend and resume execution Limited control over awakening events Events and sensitivity list are static (compile-time specified) SC_THREAD and SC_CTHREAD processes Can suspend and resume execution Require their own execution stack Memory and Context-switching time overhead

6. Winter-Spring 2001Codesign of Embedded Systems6 Brief Review of SystemC 1.0 (cont’d) Hardware Signals are hard to model in software Initialization to X Used to detect reset problems sc_logic, sc_lv data types Multiple drivers resolved logic signals Not immediately change their output value Capability of swapping two regs on clock edge

7. Winter-Spring 2001Codesign of Embedded Systems7 Brief Review of SystemC 1.0 (cont’d) Delayed assignment and delta cycles Just like VHDL and Verilog Essential to properly model hardware signal assignments Each assignment to a signal won’t be seen by other processes until the next delta cycle Delta cycles don’t increase user-visible time Multiple delta cycles may occur

8. Winter-Spring 2001Codesign of Embedded Systems8 Introduction to System-Level Modeling in SystemC 2.0 Objectives of SystemC 2.0

9. Winter-Spring 2001Codesign of Embedded Systems9 Objectives of SystemC 2.0 Primary goal: Enable System-Level Modeling Systems include hardware and software Challenge: Wide range of design models of computation Wide range of design abstraction levels Wide range of design methodologies

10. Winter-Spring 2001Codesign of Embedded Systems10 Objectives of SystemC 2.0 (cont’d) SystemC 2.0 Introduces a small but very general purpose modeling foundation => Core Language Support for other models of computation, methodologies, etc They are built on top of the core language, hence are separate from it Even SystemC 1.0 Signals are built on top of this core in SystemC 2.0 Other library models are provided: FIFO, Timers,...

11. Winter-Spring 2001Codesign of Embedded Systems11 Introduction to System-Level Modeling in SystemC 2.0 Communication and Synchronization in SystemC 2.0

12. Winter-Spring 2001Codesign of Embedded Systems12 Communication and Synchronization SystemC 1.0 Modules and Processes are still useful in system design But communication and synchronization mechanisms in SystemC 1.0 (Signals) are restrictive for system-level modeling Communication using queues Synchronization (access to shared data) using mutexes

13. Winter-Spring 2001Codesign of Embedded Systems13 Communication and Synchronization (cont’d) SystemC 2.0 introduces general-purpose Channels A container class for communication and synchronization They implement one or more interfaces Interfaces Specify a set of access methods to the channel Events Flexible, low-level synchronization primitive Used to construct other forms of synchronization

14. Winter-Spring 2001Codesign of Embedded Systems14 Communication and Synchronization (cont’d) Other comm & sync models can be built based on the above primitives Examples HW-signals, queues (FIFO, LIFO, message queues, etc) semaphores, memories and busses (both at RTL and transaction-based models)

15. Winter-Spring 2001Codesign of Embedded Systems15 Third Quiz Design a FIFO of 8 characters, along with a producer and a consumer process, communicating through the FIFO

16. Winter-Spring 2001Codesign of Embedded Systems16 Communication and Synchronization (cont’d) Channel Module1Module2 Events Interfaces Ports to Interfaces

17. Winter-Spring 2001Codesign of Embedded Systems17 A Communication Modeling Example: FIFO FIFO ProducerConsumer Write Interface Read Interface

18. Winter-Spring 2001Codesign of Embedded Systems18 FIFO Example: Declaration of Interfaces class write_if : public sc_interface { public: virtual void write(char) = 0; virtual void reset() = 0; }; class read_if : public sc_interface { public: virtual void read(char&) = 0; virtual int num_available() = 0; }; FIFO pc

19. Winter-Spring 2001Codesign of Embedded Systems19 FIFO Example: Declaration of FIFO channel class fifo: public sc_channel, public write_if, public read_if { private: enum e {max_elements=10}; char data[max_elements]; int num_elements, first; sc_event write_event, read_event; bool fifo_empty() {…}; bool fifo_full() {…}; public: fifo() : num_elements(0), first(0); void write(char c) { if (fifo_full()) wait(read_event); data[ ] = c; ++num_elements; write_event.notify(); } void read(char &c) { if (fifo_empty()) wait(write_event); c = data[first]; --num_elements; first = …; read_event.notify(); } FIFO pc

20. Winter-Spring 2001Codesign of Embedded Systems20 Declaration of FIFO channel (cont’d) void reset() { num_elements = first = 0; } int num_available() { return num_elements; } };// end of class declarations FIFO pc

21. Winter-Spring 2001Codesign of Embedded Systems21 FIFO Example (cont’d) Any channel must be derived from sc_channel class be derived from one (or more) classes derived from sc_interface provide implementations for all pure virtual functions defined in its parent interfaces

22. Winter-Spring 2001Codesign of Embedded Systems22 FIFO Example (cont’d) Note the following extensions beyond SystemC 1.0 wait() call wait(sc_event) => dynamic sensitivity wait(time) wait(time_out, sc_event) Events are the fundamental synchronization primitive have no type, no value always cause sensitive processes to be resumed can be specified to occur: immediately/ one delta-step later/ some specific time later

23. Winter-Spring 2001Codesign of Embedded Systems23 Completing the Comm. Modeling Example SC_MODULE(producer) { public: sc_port out; SC_CTOR(producer) { SC_THREAD(main); } void main() { char c; while (true) { out.write(c); if(…) out.reset(); } } }; SC_MODULE(consumer) { public: sc_port in; SC_CTOR(consumer) { SC_THREAD(main); } void main() { char c; while (true) { in.read(c); cout<< in.num_available();} } }; FIFO pc

24. Winter-Spring 2001Codesign of Embedded Systems24 Completing the Comm. Modeling Example (cont’d) SC_MODULE(top) { public: fifo afifo; producer *pproducer; consumer *pconsumer; SC_CTOR(top) { pproducer=new producer(“Producer”); pproducer->out(afifo); pconsumer=new consumer(“Consumer”); pconsumer->in(afifo); }; FIFO pc

25. Winter-Spring 2001Codesign of Embedded Systems25 Completing the Comm. Modeling Example (cont’d) Note: Producer module sc_port out; Producer can only call member functions of write_if interface Consumer module sc_port in; Consumer can only call member functions of read_if interface Producer and consumer are unaware of how the channel works just aware of their respective interfaces Channel implementation is hidden from communicating modules

26. Winter-Spring 2001Codesign of Embedded Systems26 Completing the Comm. Modeling Example (cont’d) Advantages of separating communication from functionality Trying different communication modules Refine the FIFO into a software implementation Using queuing mechanisms of the underlying RTOS Refine the FIFO into a hardware implementation Channels can contain other channels and modules Instantiate the hw FIFO module within FIFO channel Implement read and write interface methods to properly work with the hw FIFO Refine read and write interface methods by inlining them into producer and consumer codes

27. Winter-Spring 2001Codesign of Embedded Systems27 Introduction to System-Level Modeling in SystemC 2.0 Models of Computation within SystemC

28. Winter-Spring 2001Codesign of Embedded Systems28 Models of Computation within SystemC Many different models The best choice is not always clear Basic topics in a computation model The model of time, and event ordering constraints Time model: real valued, integer-valued, untimed Event ordering: globally ordered, partially ordered Supported methods of communication between concurrent processes Rules for process activation

29. Winter-Spring 2001Codesign of Embedded Systems29 Models of Computation within SystemC (cont’d) SystemC 2.0 Generic model of computation The designer is to implement his desired model (Virtually) all discrete-time models are supported Static Multi-rate Data-flow Dynamic Multi-rate Data-flow Kahn Process Networks Communicating Sequential Processes Discrete Event as used for RTL hardware modeling network modeling (e.g. stochastic or “waiting room” models) transaction-based SoC platform-modeling

30. Winter-Spring 2001Codesign of Embedded Systems30 Models of Computation within SystemC (cont’d) Proof of generic usage of SystemC 2.0 primitives Signals are realized on top of channels, interfaces, and events SystemC 2.0 is not suitable for continuous- time models (e.g. analog modeling)

31. Winter-Spring 2001Codesign of Embedded Systems31 What we learned today SystemC 2.0 new features vs. SystemC 1.0 SystemC 2.0 approach to system-level modeling Separation of communication from functionality Providing designer with basic tools to implement his desired model of computation

32. Winter-Spring 2001Codesign of Embedded Systems32 Complementary notes: Assignments Take Assignment 7 Due Date: Saturday, Khordad 5th