ARM® RealView® ESL API v2.0 Developer’s Guide 1.5.4. Synchronous and asynchronous communication

1.5.4. Synchronous and asynchronous communication

The CASI signal interfaces always use synchronous communication that is accomplished by a single call to driveSignal(). The signal value is passed as a parameter. If a complex interconnection such as a bus is implemented with signals, there must be multiple distinct calls by the components to the driveSignal() functions of each individual signal.

The CASI transaction interface can perform a read or write in a single transaction call. Also, the CASI transaction interfaces are not restricted to single reads and writes. The interface supports protocols that perform burst or block reads of multiple memory locations through a single transaction. For a given communication protocol, AHB or AXI for example, the details are user-defined and must be documented as part of the protocol.

The communication schemes that can be used for a transaction model are user defined:

synchronous
asynchronous
asynchronous with shared memory.

Synchronous transaction communication

The read() and write() functions enable synchronous access between different models by specifying the control information in the fields:

addr: is the address for the read or write
value: is the value read or to be written
control: is control field for the read or write.

The read() and write() functions are expected to return in the same cycle that they were initiated. The return value indicates the status of the transaction. If they return CASI_STATUS_OK, the transaction has finished successfully.

The read() and write() functions can implement multi-cycled transactions. If in the first cycle they return, for example, CASI_STATUS_WAIT, then the initiating model calls the read() and write() function again in subsequent cycles, until it receives the CASI_STATUS_OK representing the end of this transaction.

The readDbg() and writeDbg() functions provide debug accesses and enable debuggers to read the desired information without advancing the simulation.

Figure 1.10. Synchronous communication example

Asynchronous transaction communication with callback

The asynchronous readReq() and writeReq() functions enable a communication model where the initiator master model provides a callback function pointer to the slave model. When the slave model is ready to serve the transaction, it calls the callback function and notifies the master that the data is ready.

Figure 1.11. Asynchronous communication with callback example

Asynchronous transaction communication with shared memory

The shared-memory asynchronous functions provide a communication model where the initiating master model calls driveTransaction() providing to the slave a shared-memory data structure. This data structure is used throughout the life of the transaction to communicate the information between the master and the slave models. After the first driveTransaction() function call, no other function calls are required through the transaction, unless a cancelTransaction() is called to cancel the respective transaction. The shared data structure is stored in CASITransactionInfo.

An optional notification callback from a slave to the connected master can be implemented through a CASINotifyHandlerIF object. The notifyEvent() function can be called by the slave to inform the master that the contents of the transaction info data structure has changed. This enables the master to react to the changes in the same cycle.

Figure 1.12. Asynchronous communication with shared memory example

The CASI implementation of the AHB protocol

CASI provides a general framework for model inter-communication, but the details of the communication protocol must be customized to match the actual protocol used. This is done by mapping the protocol fields to the CASI access functions parameters.

For instance, an AHB protocol implemented using the CASI synchronous model assigns AHB-related semantics to the parameters of the read/write functions of the casi_transaction_if interface. A example mapping is given in Table 1.1.

For details of the AHB protocol implementation for CASI, see the AHB CASI model documentation. Table 1.1 provides some guidance but must not be used as a reference for the AHB transactions description.

Table 1.1. Example AHB to CASI mapping

Parameter	Use	Example values
`Addr`	Address	`0x1A00000000000000` (64-bit unsigned)
`Value`	Data	`0xFFFF0001` (32-bit unsigned)
`ctrl[0]`	Transfer type	`BYTE`, `HWORD`, `DWORD`
`ctrl[1]`	Phase	`ADDR`, `DATA`
`ctrl[2]`	ACC	`HBURST`, `HSIZE`, `HTRANS`
`ctrl[3]`	Acknowledge	`DONE`, `WAIT`, `ABORT`

A typical communication sequence is listed in Table 1.2.

Table 1.2. Example AHB implementation

Cycle	Phase	Bus	Peripheral
0	ADDR	port->read(...)	AHB_ch::read(addr,val,ctrl) … if(ctrl[1] == ADDR_PHASE) { //decode read/write type (burst/…) return OK; }
1 to N	DATA	port->read(...)	AHB_ch::read(addr,val,ctrl) … if(ctrl[1] == DATA_PHASE) { if(waitCount < DELAY) { ctrl[3] = WAIT; } else { val = getData(addr,ctrl); ctrl[3] = DONE; } return OK; }

Cycle

Phase

Bus

Peripheral

ADDR

port->read(...)

AHB_ch::read(addr,val,ctrl) 
… 
if(ctrl[1] == ADDR_PHASE)
{
   //decode read/write type (burst/…)
  return OK; 
}

1 to N

DATA

port->read(...)

AHB_ch::read(addr,val,ctrl) 
… 
if(ctrl[1] == DATA_PHASE) 
   {
   if(waitCount < DELAY) 
     {
        ctrl[3] = WAIT; 
     }
   else 
     {
        val = getData(addr,ctrl);
        ctrl[3] = DONE; 
     }
    return OK; 
}

Copyright © 2007 ARM Limited. All rights reserved.	ARM DUI 0359B
Non-Confidential
PDF version