5.5.10. EVS_Delay_Cortex-A8 Example

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.

Overloading the wait() callback

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


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 .

Using the Reset port

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.


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.

Figure 5.10. Reset Example system

Reset Example system

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. Timing diagram for driving the reset signal

To view this graphic, your browser must support the SVG format. Either install a browser with native support, or install an appropriate plugin such as Adobe SVG Viewer.

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.

Copyright © 2007-2010 ARM Limited. All rights reserved.ARM DUI 0370K