SystemC System-Level Modeling Mehdi Mosaffa Abdurrahman Manian

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

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

Modeling Levels

System specification in SystemC Completely implementation independent.

Modeling Levels 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 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 Communication between modules modeled using function calls. Communication is not modeled in a structurally accurate manner.

Modeling Levels 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 Pin-accurate and cycle-accurate at its boundaries. Not necessarily internal structure that reflects the target implementation.

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

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.

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

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

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

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

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

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.

Register-Transfer Level (RTL)

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

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

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

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

Description of Controller REPOSMagnetXYREVERSEACTION 0000 X Forwards 0001 X Backwards 0010 Y Forwards 0011 Y Backwards 01-- Magnet On 11-- Magnet Off 100- Recalibrate X 101- Recalibrate Y

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

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

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; } };

SystemC Model of Controller (RTL processes) 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; 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: ……….

Behavioral-Level Modeling in SystemC

Behavioral VS RTL-level Modeling 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

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()

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

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;} }

Functional-Level Modeling in SystemC

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

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

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

Timed Dataflow Example 1 //Simple timed dataflow adder SC_MODULE(DF_ADDER) { sc_fifo_in input1, input2; sc_fifo_out 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); }

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

Transaction-Level Modeling in SystemC

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

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

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 (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

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” clock cycles per second Possible to apply a variety of realistic tests that include software parts of the system

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

References [1] System Design with SystemC, T.Grotker, S. Liao, G. Martin, S. Swan; Kluwer Academic Publishers. [2] /S04/Luennot/Lect10.pdf