Design Codesign of Embedded Systems Introduction to SystemLevel

  • Slides: 35
Download presentation
Design & Co-design of Embedded Systems Introduction to System-Level Modeling in System. C 2.

Design & Co-design of Embedded Systems Introduction to System-Level Modeling in System. C 2. 0 Maziar Goudarzi Fall 2005 Design & Co-design of Embedded Systems

Today Program z. A Brief Review of System. C 1. 0 z. Objectives of

Today Program z. A Brief Review of System. C 1. 0 z. Objectives of System. C 2. 0 z. Communication and Synchronization in System. C 2. 0 z. Models of Computation within System. C Reference: Stuart Swan, “An Introduction to System-Level Modeling in System. C 2. 0, ” Cadence Design Systems, 2001. Fall 2005 Design & Co-design of Embedded Systems 2

Brief Review of System. C 1. 0 z. A set of modeling constructs in

Brief Review of System. C 1. 0 z. A set of modeling constructs in RTL or Behavioral abstraction level z. Structural design using Modules, Ports, and Signals z. Rich set of data types including bit-true types y. Specially: Fixed-Point data types for DSP apps. Fall 2005 Design & Co-design of Embedded Systems 3

Brief Review of System. C 1. 0 (cont’d) z Concurrent Behavior is described using

Brief Review of System. C 1. 0 (cont’d) z Concurrent Behavior is described using Processes y. Processes can suspend and resume execution y. Limited control over awakening events x. Events and sensitivity list are static (specified at compile-time) z SC_THREAD and SC_CTHREAD processes y. Can suspend and resume execution y. Require their own execution stack y. Memory and Context-switching time overhead y. SC_METHOD gives best simulation performance Fall 2005 Design & Co-design of Embedded Systems 4

Brief Review of System. C 1. 0 (cont’d) z Hardware Signals are hard to

Brief Review of System. C 1. 0 (cont’d) z Hardware Signals are hard to model in software y. Initialization to X x. Used to detect reset problems xsc_logic, sc_lv data types y. Multiple drivers xresolved logic signals (sc_signal_rv) y. Not immediately change their output value x. Delay is essential x. Capability to swap two registers on clock edge Fall 2005 Design & Co-design of Embedded Systems 5

Brief Review of System. C 1. 0 (cont’d) z. Delayed assignment and delta cycles

Brief Review of System. C 1. 0 (cont’d) z. Delayed assignment and delta cycles y. Just like VHDL and Verilog y. Essential to properly model hardware signal assignments x. Each assignment to a signal won’t be seen by other processes until the next delta cycle x. Delta cycles don’t increase user-visible time x. Multiple delta cycles may occur Fall 2005 Design & Co-design of Embedded Systems 6

Introduction to System-Level Modeling in System. C 2. 0 Objectives of System. C 2.

Introduction to System-Level Modeling in System. C 2. 0 Objectives of System. C 2. 0 Fall 2005 Design & Co-design of Embedded Systems

Objectives of System. C 2. 0 z. Primary goal: Enable System-Level Modeling y. Systems

Objectives of System. C 2. 0 z. Primary goal: Enable System-Level Modeling y. Systems include hardware, software, or both y. Challenges: x. Wide range of design models of computation x. Wide range of design abstraction levels x. Wide range of design methodologies Fall 2005 Design & Co-design of Embedded Systems 8

Objectives of System. C 2. 0 (cont’d) z. Solution in System. C 2. 0

Objectives of System. C 2. 0 (cont’d) z. Solution in System. C 2. 0 y. Introduces a small but very general purpose modeling foundation => Core Language y. Elementary channels x. Other library models provided (FIFO, Timers, . . . ) x. Even System. C 1. 0 Signals y. Support for various models of computation, methodologies, etc. x. Built on top of the core language, hence are separate from it Fall 2005 Design & Co-design of Embedded Systems 9

Introduction to System-Level Modeling in System. C 2. 0 Communication and Synchronization in System.

Introduction to System-Level Modeling in System. C 2. 0 Communication and Synchronization in System. C 2. 0 Fall 2005 Design & Co-design of Embedded Systems

Communication and Synchronization z. System. C 1. 0 Modules and Processes are still useful

Communication and Synchronization z. System. C 1. 0 Modules and Processes are still useful in system design z. But communication and synchronization mechanisms in System. C 1. 0 (Signals) are restrictive for system-level modeling y. Communication using queues y. Synchronization (access to shared data) using mutexes Fall 2005 Design & Co-design of Embedded Systems 11

Communication and Synchronization (cont’d) z. System. C 2. 0 introduces general-purpose y. Channel x.

Communication and Synchronization (cont’d) z. System. C 2. 0 introduces general-purpose y. Channel x. A container for communication and synchronization x. They implement one or more interfaces y. Interface x. Specify a set of access methods to the channel • But it does not implement those methods y. Event x. Flexible, low-level synchronization primitive x. Used to construct other forms of synchronization Fall 2005 Design & Co-design of Embedded Systems 12

Communication and Synchronization (cont’d) z. Other comm. & sync. models can be built based

Communication and Synchronization (cont’d) z. Other comm. & sync. models can be built based on the above primitives y. Examples x. HW-signals, queues (FIFO, LIFO, message queues, etc) semaphores, memories and busses (both at RTL and transaction-level models) Fall 2005 Design & Co-design of Embedded Systems 13

Communication and Synchronization (cont’d) Interfaces Module 1 Module 2 Channel Events Ports to Interfaces

Communication and Synchronization (cont’d) Interfaces Module 1 Module 2 Channel Events Ports to Interfaces Fall 2005 Design & Co-design of Embedded Systems 14

System. C 2. 0 Language Architecture z All built on C++ z Upper layers

System. C 2. 0 Language Architecture z All built on C++ z Upper layers cleanly built on lower ones z Core language y Structure y Concurrency y Communication y Synchronization z Data types separate from the core language z Commonly used communication mechanisms and MOC built on top of core language z Lower layers can be used without upper ones Fall 2005 Design & Co-design of Embedded Systems 15

A Communication Modeling Example: FIFO Producer Write Interface Consumer FIFO Read Interface Problem definition:

A Communication Modeling Example: FIFO Producer Write Interface Consumer FIFO Read Interface Problem definition: FIFO communication channel with blocking read and write operations Source available in System. C installation, under “examplessystemc” subdirectory Design & Co-design of Fall 2005 Embedded Systems 16

p FIFO Example: Declaration of Interfaces c FIFO class write_if : public sc_interface {

p FIFO Example: Declaration of Interfaces c FIFO 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; }; Fall 2005 Design & Co-design of Embedded Systems 17

p FIFO Example: FIFO Declaration of FIFO channel class fifo: public sc_channel, public write_if,

p FIFO Example: FIFO 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() {…}; c void write(char c) { if ( fifo_full() ) wait(read_event); data[ <you say> ]=c; ++num_elements; write_event. notify(); } void read(char &c) { if( fifo_empty() ) wait(write_event); c = data[first]; --num_elements; first = <you say>; read_event. notify(); } public: SC_CTOR(fifo) { num_elements = first=0; } Design & Co-design of Fall 2005 Embedded Systems 18

Declaration of FIFO channel (cont’d) p c FIFO void reset() { num_elements = first

Declaration of FIFO channel (cont’d) p c FIFO void reset() { num_elements = first = 0; } int num_available() { return num_elements; } }; // end of class declarations Fall 2005 Design & Co-design of Embedded Systems 19

FIFO Example (cont’d) z. All channels must ybe derived from sc_channel class x. System.

FIFO Example (cont’d) z. All channels must ybe derived from sc_channel class x. System. C internals (kernelsc_module. h) typedef sc_module sc_channel; ybe derived from one (or more) classes derived from sc_interface yprovide implementations for all pure virtual functions defined in its parent interfaces Fall 2005 Design & Co-design of Embedded Systems 20

FIFO Example (cont’d) z. Note the following extensions beyond System. C 1. 0 ywait()

FIFO Example (cont’d) z. Note the following extensions beyond System. C 1. 0 ywait() call with arguments => dynamic sensitivity xwait(sc_event) xwait(time) // e. g. wait(200, SC_NS); xwait(time_out, sc_event) //wait(2, SC_PS, e); y. Events xare the fundamental synch. primitive in System. C 2. 0 x. Unlike signals, • have no type and no value • always cause sensitive processes to be resumed • can be specified to occur: – immediately/ one delta-step Design & Co-design of later/ some specific time later Fall 2005 Embedded Systems 21

The wait() function // wait for 200 ns. sc_time t(200, SC_NS); wait( t );

The wait() function // wait for 200 ns. sc_time t(200, SC_NS); wait( t ); // wait on event e 1, timeout after 200 ns. wait( t, e 1 ); // wait on events e 1, e 2, or e 3, timeout after 200 ns. wait( t, e 1 | e 2 | e 3 ); // wait on events e 1, e 2, and e 3, timeout after 200 ns. wait( t, e 1 & e 2 & e 3 ); // wait for 200 clock cycles, SC_CTHREAD only (System. C 1. 0). wait( 200 ); // wait one delta cycle. wait( 0, SC_NS ); // wait one delta cycle. wait( Fall 2005 SC_ZERO_TIME ); Design & Co-design of Embedded Systems 22

The notify() method of sc_event z. Possible calls to notify(): sc_event my_event; my_event. notify();

The notify() method of sc_event z. Possible calls to notify(): sc_event my_event; my_event. notify(); // notify immediately my_event. notify( SC_ZERO_TIME ); // notify next delta cycle my_event. notify( 10, SC_NS ); // notify in 10 ns sc_time t( 10, SC_NS ); my_event. notify( t ); // same Fall 2005 Design & Co-design of Embedded Systems 23

Completing the Comm. p Modeling Example SC_MODULE(producer) { public: sc_port<write_if> out; c FIFO SC_MODULE(consumer)

Completing the Comm. p Modeling Example SC_MODULE(producer) { public: sc_port<write_if> out; c FIFO SC_MODULE(consumer) { public: sc_port<read_if> in; SC_CTOR(producer) { SC_THREAD(main); } SC_CTOR(consumer) { SC_THREAD(main); } void main() { char c; while (true) { out->write(c); if(…) out->reset(); } } void main() { char c; while (true) { in->read(c); cout<< in->num_available(); } } }; Fall 2005 }; Design & Co-design of Embedded Systems 24

Completing the Comm. p FIFO Modeling Example (cont’d) c SC_MODULE(top) { public: fifo *afifo;

Completing the Comm. p FIFO Modeling Example (cont’d) c SC_MODULE(top) { public: fifo *afifo; producer *pproducer; consumer *pconsumer; SC_CTOR(top) { afifo = new fifo(“Fifo”); pproducer=new producer(“Producer”); pproducer->out(afifo); pconsumer=new consumer(“Consumer”); pconsumer->in(afifo); }; Fall 2005 Design & Co-design of Embedded Systems 25

Completing the Comm. Modeling Example (cont’d) z Note: y. Producer module xsc_port<write_if> out; •

Completing the Comm. Modeling Example (cont’d) z Note: y. Producer module xsc_port<write_if> out; • Producer can only call member functions of write_if interface y. Consumer module xsc_port<read_if> in; • Consumer can only call member functions of read_if interface • e. g. , Cannot call reset() method of write_if y. Producer and consumer are xunaware of how the channel works xjust aware of their respective interfaces y. Channel implementation is hidden from communicating modules Fall 2005 Design & Co-design of Embedded Systems 26

Completing the Comm. Modeling Example (cont’d) z. Advantages of separating communication from functionality y.

Completing the Comm. Modeling Example (cont’d) z. Advantages of separating communication from functionality y. Trying different communication modules y. Refine the FIFO into a software implementation x. Using queuing mechanisms of the underlying RTOS y. Refine the FIFO into a hardware implementation x. 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 of Design & Co-design Fall 2005 Embedded Systems 27

Introduction to System-Level Modeling in System. C 2. 0 Models of Computation within System.

Introduction to System-Level Modeling in System. C 2. 0 Models of Computation within System. C Fall 2005 Design & Co-design of Embedded Systems

Models of Computation within System. C z. Many different models y. The best choice

Models of Computation within System. C z. Many different models y. The best choice is not always clear z. Basic topics in a computation model y. The model of time, and event ordering constraints x. Time model (real valued, integer-valued, untimed) x. Event ordering (globally ordered, partially ordered) y. Supported methods of communication between concurrent processes y. Rules for process activation Fall 2005 Design & Co-design of Embedded Systems 29

Models of Computation within System. C (cont’d) z System. C 2. 0 y. Generic

Models of Computation within System. C (cont’d) z System. C 2. 0 y. Generic model of computation x. The designer can (and is to) implement his desired model y(Virtually) all discrete-time models are supported x. Static Multi-rate Data-flow x. Dynamic Multi-rate Data-flow x. Kahn Process Networks x. Communicating Sequential Processes x. Discrete Event as used for • RTL hardware modeling • network modeling (e. g. stochastic or “waiting room” models) • transaction-based So. C platform-modeling ynot suitable for continuous-time models (e. g. analog modeling) Fall 2005 Design & Co-design of Embedded Systems 30

Models of Computation within System. C (cont’d) z Proof of generic usage of System.

Models of Computation within System. C (cont’d) z Proof of generic usage of System. C 2. 0 primitives y. Signals are realized on top of channels, interfaces, and events Fall 2005 Design & Co-design of Embedded Systems 31

Future Evolution of System. C z Expected to be System. C 3. 0 y.

Future Evolution of System. C z Expected to be System. C 3. 0 y. Support for RTOS modeling y. New features in the core language x. Fork and join threads + dynamic thread creation x. Interrupt or abort a thread and its children x. Specification and checking of timing constraints x. Abstract RTOS modeling and scheduler modeling z Expected to be System. C 4. 0 y. New features in the core language x. Support for analog mixed signal modeling Fall 2005 Design & Co-design of Embedded Systems 32

Future Evolution of System. C (cont’d) z Extensions as libraries on top of the

Future Evolution of System. C (cont’d) z Extensions as libraries on top of the core language y Standardized channels for various MOC (e. g. static dataflow and Kahn process networks) y Testbench development x. Libraries to facilitate development of testbenches • data structures that aid stimulus generation and response checking • functions that help generate randomized stimulus, etc. y System level modeling guidelines xlibrary code that helps users create models following the guidelines y Interfacing to other simulators x. Standard APIs for interfacing System. C with other simulators, etc. Fall 2005 Design & Co-design of Embedded Systems 33

Today Summary z Communication and synchronization primitives introduced in System. C 2. 0 sc_channel

Today Summary z Communication and synchronization primitives introduced in System. C 2. 0 sc_channel sc_interface sc_event z The language architecture is changed y Small, general-purpose core y => support various system-level design methodologies and MOCs z Minor other new additions exist y Reference: “Functional Specification for System. C 2. 0, ” available in the System. C distribution Fall 2005 Design & Co-design of Embedded Systems 34

Assignments z Assignment 5 1. Develop a design consisting of two modules communicating through

Assignments z Assignment 5 1. Develop a design consisting of two modules communicating through a channel. One module reads a file and sends it to the other module who saves it in another file. 2. Refine the design such that the channel is replaced with a hardware FIFO y Due Date: Tuesday (next week), Azar 8 th Fall 2005 Design & Co-design of Embedded Systems 35