The Delay example describes how to delay the simulation startup of an EVS and setting an external reset signal from SystemC. There are two options to force the EVS to stop simulation until a certain condition is met. These are described in this section.
This solution implements a derived sc_sg_callback object
(see Example 5.8 and EVS_Callbacks_Cortex-R4 example), which waits
for the reset signal going low in it's overloaded wait callback
during the init phase. This is achieved by introducing an event
which is triggered by the reset signal going low. The first quantum
of the EVS starts immediately after the wait() callback
returns from waiting for the event. For example, the reset signal
was set to 0.
Example 5.7. Waiting for reset in ‘wait()’ callback
class callback : public sc::sc_sg_callbacks
{
public:
// overloaded callbacks from the EVS (Exported Virtual Subsytem)
void wait(double time, int mode);
}
void callback::wait(double time, int mode)
{
if (mode == SG_MODE_INIT)
{
sc_core::wait(reset_event);
}
sc_core::wait(sc_core::sc_time(time, sc_core::SC_SEC)); /* do normal wait */
}
The SystemC signal reset_event is triggered
in the example after 10 ns. At timestamp 11ns the signal is triggered
and the wait() callback returns from its call
allowing the EVS to start the simulation.
Upon simulation the wait() callback is
called which waits for an event to be set by some other component.
The EVS simulation does not advance until the callback returns.. Somewhere
within the quantum it sets the reset_event which
causes the wait() callback to return and unlock
the EVS. The next time the SystemC scheduler activates the EVS it
starts simulating its quantum.
Note
The advantage of this solution is that it effectively prevents the entire EVS from starting and there is no delay once the callback returns. The disadvantage is that for multicore systems all cores are halted. If only a single core is to be stopped then this solution is not applicable. In this case the reset port must be used .
The other solution is to connect a reset signal to the respective
port within the EVS. Figure 5.10 shows
the example system using an ARM Cortex-A8 where the reset port is
connected by an ambapvsignal2sgsignal component.
This example is based on the Dhrystone example with the difference
that the reset port is routed by this bridge to another SystemC
component.
Note
To drive the reset signal to ‘1’ from the
very beginning of the simulation, it is necessary to set this signal
in the simulation phase end_of_elaboration().
If that is not done, it depends on the scheduler which component
is activated first. This can result in a delay of one quantum before
the EVS recognizes the reset signal being active.
To activate this behavior in the example DELAY_WAIT in
the main.cpp file is required to be undefined.
The drawback of this solution is that setting the reset signal is
only recognized by the EVS at the end of its quantum. This is due
to the nature of temporal decoupling. In contrast to the solution
where the callback is overloaded this solution does not make use
of a simulation API and therefore suffers from the effects of temporal decoupling.
Figure 5.11 shows
the timing diagram for the reset example using the reset signal. Before
the simulation starts (end_of_elaboration())
the reset signal is set. Within the quantum of the SystemC Reset
component the reset signal is set back to ‘0’. The EVS recognizes
this change at the end of its quantum. This difference to the solution
which uses the wait() callback has to be taken
into account when choosing one or the other solution.
PDF version