systemc - modrpc/info GitHub Wiki
- Accellera SystemC: http://accellera.org/downloads/standards/systemc
- Papers:
- S. Liao et al. An Efficient Implementation of Reactivity for Modeling Hardware in the Scenic Design Environment, DAC'97
- J. P. Grossman et al. The Role of Cascade, Cycle-based Simulation Infrastructure, DAC'13
- Simple Bus Example slides (from SystemC 2.3.1 distribution)
- Simple Bus Example
- Existing: complex event-driven runtime kernel
-
IDEA:
- Verilog simulator
- It contains event-based simulation kernel (Which is hidden)
- User's Verilog code -> compiled into process-objects -> fed into simulation runtime kernel
- runtime kernel consists of "internal libraries" which will handle scheduling of "process-objects"
- SystemC simulator
- We'll provide runtime kernel in the form of "external libraries"
- You just provide the "C" code which will compiled into process-objects
- To facilitate the plugin of "process-objects" INTO kernel, we subclass predefined classes.
- Verilog simulator
- capability to build non-terminating hardware processes
- can be implemented using either threads or co-routines
- co-routines are better: threads create bottleneck at event-queue (insertion to queue)
- signal: stateful property on which events can be defined
- event: a temporal expression over signals (e.g. value change of signal)
-
waiting: blocking action that can be associated with an event
- code: 'wait until (expression)'
-
watching: regardless of the state of execution of p, whenever s occurs, p is terminated
- code: 'do p watch s'
- handle premeption
- See SystemC LRM for details.
- The scheduler can execute a spawned or unspawned process instance as a consequence of one of the following four causes, and these alone:
- In response to the process instance having been made runnable during the initialization phase
- In response to a call to function sc_spawn during simulation
- In response to the occurrence of an event to which the process instance is sensitive
- In response to a time-out having occurred
- Scheduling algorithms uses following four sets:
- set of runnable processes
- set of update requests
- set of delta notifications and time-outs
- set of timed notifications and time-outs
- Modules are basic building blocks for partitioning a design -- allows to break complex systems into manageable pieces, i.e. modules.
- (MVGO) Module is also a conceptually related set of functionalities to be deployed.
- A typical module contains:
- ports: through which the module communicates with the outside
- processes: that describes the functionality of module; either non-terminating-reactive (MVGO PROC) or request-based (MVGO FUNC)
- internal data for maintenance of states (for FSM) or temporary book keeping
- internal channels for internal communication between module's processes
- other module instances: imposes hierarchy
- CTOR: C++ 공간 내의 field, member function들을 runtime에 등록하는 역할
-
sc_module_init: registration of this module to runtime (engine)-
get_module_registry()->insert(*this)''': register this module instance
-
- registers C++ member functions to processes
- declares event sensitivities
-
- Can be instantiated: 즉, module is a blueprint from which instances are created:
- module (unix program): blueprint (in-disk) with enough information for "bringing-up/execution"
- module instance (unix process): in-memory transient object
- Higher system-level에서 볼때는, communication/synchronization between modules
- channel: workhorses for holding and transmitting data
- interface: window into a channel that describes the set of operations, or subset thereof, that the channel provides
- port: proxy objects that facilitate access to channels through interfaces
- An interface is a set of operations.
- An interface only specifies only the signature of each operation (name, parameters, return value).
- A module (and thus its processes) interacts with its environment, through ports.
- Ports correspond to interfaces.
sc_port<IF = sc_signal_inout_if<int> > p;
-
p->read()will callread()defined insc_singnal_inout_if
- Interfaces and ports together describe what functions are available in a communication package.
- We initiate operations through interfaces, but it is the channels that carry out these operations.
- A channel implements an intefrace if provides concrete definites of all of the interface's operations and is properly derived from that interface.
-
Primitive Channels,
sc_prim_channel: supports:-
request_update: instructs the scheduler to place the channel in an update queue -
update: THEN, later, scheduler will callupdate()for all channels in the update queue
-
- __Primitive channel examples__:
-
hardware signal,
sc_signal<T> -
FIFO channel,
sc_fifo<T> -
Mutual exclusion lock,
sc_mutex
-
hardware signal,
- __Hierarchical channels__:
- A process is the basic unit of functionality and it must be contained in a module.
- A process is defined as a member function of the module and declared to be a SystemC process (registered to a runtime) in the module's CTOR.
- When triggered, always executes its body from the beginning to the end. -- models combinational process.
- Does not keep an implicit execution state.
sc_in<int> a, b;
sc_out<int> c;
void compute() {
c = a + b;
}
SC_CTOR(Adder) {
SC_METOHD(compute);
sensitive << a << b; // creates event-subscription
}
- May have its execution suspended by calling
wait(). - The thread remembers the point of suspension, as it were, along with all local variables, so that when the execution is resumed, it will continue from that point, rather than from the beginning of the process.
- An event is an object, represented by
sc_event, that determines whether and when a process's execution should be triggered or resumed.
- SystemC class library includes a public shell consisting of predefined classes, functions, macros, and so forth that can be used directly by an application.
- Execution of SystemC application: elaboration followed by simulation
- Elaboration: creates module hierarchy
- Simulation: executes scheduler
- GOAL: create internal data structures within the kernel as required to support the semantics of simulation.
- parts of module hierarchy (modules, ports, primitive channels, and processes) are created
- ports and exports are bound to channels
-
class instancess are created during elaboration (and only during elaboration).
- sc_module: can be created within module or sc_main
- sc_prim_channel: can be created within module or sc_main
- sc_port: can be created within module
- sc_export: can be created within module
- An unspawned process instance is a process created by one of following three process macros.
- SC_METHOD
- SC_THREAD
- SC_CTHREAD
- Kernel-internal "process instance"
- SC_THREAD(my_action) expands to
::sc_core::sc_process_handle handle =
sc_core::sc_get_curr_simcontext()->create_thread_process(
"my_action",
false,
SC_MAKE_FUNC_PTR(SC_CURRENT_USER_MODULE, my_action),
this, 0);
this->sensitive.operator() (handle, edge);
- This effectively registers the associated function with the kernel s.t. the scheduler can call back that member function during simulation.
- Unspawned processes can be created during elaboration or from the end_of_elaboration callback.
- Spawned processes may be created by calling the function sc_spawn during elaboration or simulation.
- port instances can be bound to channel/port/export instances
- export instances can be bound to channel/export instances
- port bound to a channel does NOT mean the channel bound to the port