Fast Models Reference Manual - ARM Information Center

Peripheral and Interface Components
5.9 SCADI
A Synchronous CADI (SCADI) interface for components offers direct synchronous, but
unsynchronized, register and memory read access. It enables you to request a synchronous stop
of the simulation. The intention is that this interface is used by code that is inherently
synchronized with the simulation, in particular from code that is part of the simulation itself
(simulation thread). Examples for code that would be allowed to use this interface is SystemC
or LISA peripheral device/bus access functions and MTI callback functions that are always
called synchronously by the simulation itself.
Note
The SCADI interface is not a replacement for CADI in any way. It is an additional interface with
clear semantics that differ slightly from CADI.
5.9.1 Intended use of CADI and SCADI
The design principles for CADI and SCADI are:
CADI
SCADI
Used by debuggers and simulation controllers to control the simulation.
Execution control functions are always asynchronous and are usually called from
a non-simulation thread, usually the debugger GUI thread. You can also use
CADI to read/write registers, memory and so on, but only from non-simulation
threads, for example only from the debugger thread.
Implements a specific subset of functions of CADI, that is, mainly read/write
registers and memory, set and clear breakpoints, and get disassembly. You can
only use SCADI from the simulation thread itself and from threads that can make
sure on their own that the simulation is currently blocked, for example a debugger
thread while it is sure that the simulation is in a stable state. SCADI is intended
to be used from within peripheral read/write accesses while the simulation is
running, or from within MTI callbacks that the simulation is running.
SCADI does not implement and execute control functions except CADIExecStop(),
because only stop makes sense from within the simulation thread. SCADI is the
Synchronous CADI interface. Asynchronous functions such as
CADIExecContinue() and CADIExecSingleStep() are not supported by SCADI, so
for these you must use CADI instead. The SCADI::CADIExecStop() is the
exception, because for CADI this means “stop when it is convenient for the
simulation”, which is asynchronous, but CADIExecStop() is synchronous and
means “stop now”, which you enable with the appropriate syncLevel >=2.
The guideline is:
• use CADI for execution control
• use CADI or SCADI for read/write registers and memory, depending on the situation.
That is:
— use SCADI if the caller can make sure that the accesses are (potentially inherently)
synchronized with the simulation
— use CADI if called from a debugger thread that does not know exactly whether the
simulation is running or is in a stable state.
ARM DUI 0423J Copyright © 2008-2011 ARM. All rights reserved. 5-167
ID051811
Non-Confidential