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 will start straight away after the wait() callback returns
from waiting for the event (e.g. 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 will return from its
call allowing the EVS to start the simulation.
Figure 5.10 shows
the EVS quantum on the left side. Upon simulation the wait() callback
is called which waits for an event to be set by some other component. The
EVS simulation will not advance from here until the callback returns.
The SystemC component setting this signal is depicted on the right
side of the diagram. Somewhere within the quantum it will set the reset_event which
causes the wait() callback to return and unlock
the EVS. The next time the SystemC scheduler activates the EVS it
will start simulating its quantum.
Note
The advantage of this solution is that it will effectively prevent the entire EVS from starting and there is no delay once the callback returns. The disadvantage is that for multicore systems all cores will be 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.11 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 will depend on the scheduler which component
is activated first. This can result in a delay of one quantum before
the EVS will recognize 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 will
only be 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.12 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 will recognize
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