Software development for SoCs involve partitioning the application among the various processing elements based on the most efficient computational model. This can require a lot of trial and error to establish the proper partitioning. At a high level the SoC partitioning algorithm is as follows:

Place the state machine software (those algorithms that provide application control, sequencing, user interface control, event driven software, and so on) on a RISC processor such as an ARM.

Place the signal processing software on the DSP, taking advantage of the application specific architecture that a DSP offers for signal processing functions.

Place high rate, computationally intensive algorithms in hardware accelerators, if they exist and if they are customized to the specific algorithm of consideration.

As an example, consider the software partitioning shown in Figure 11.7 below. This SoC model contains a general-purpose processor (GPP), a DSP, and hardware acceleration. The GPP contains a chip support library which is a set of low level peripheral APIs that provide efficient access to the device peripherals, a general-purpose operating system, an algorithmic abstraction layer and a set of API for and application and user interface layer.

The DSP contains a similar chip support library, a DSP centric kernel, a set of DSP specific algorithms and interfaces to higher level application software. The hardware accelerator contains a set of APIs for the programmer to access and some very specific algorithms mapped to the acceleration.

The application programmer is responsible for the overall partitioning of the system and the mapping of the algorithms to the respective processing elements. Some vendors may provide a "black box" solution to one or more of these processing elements, including the DSP and the hardware accelerators.

This provides another level of abstraction to the application developer who does not need to know the details of some of the underlying algorithms. Other system developers may want access to these low level algorithms, so there is normally flexibility in the programming model for these systems, depending on the amount of customization and tailoring required.

Figure 11.7 Software Architecture for SoC (courtesy of Texas Instruments)

Communication in an SoC is primarily established by means of software. The communication interface between the DSP and the ARM in Figure 11.7, for example, is realized by defining memory locations in the DSP data space as registers.

The ARM gains read/write access to these registers through a host interface. Both processors can asynchronously issue commands to each other, no one masters the other. The command sequence is purely sequential; the ARM cannot issue a new command unless the DSP has sent a "command complete" acknowledgement.

There exist two register pairs to establish the two-way asynchronous communication between ARM and DSP, one register pair is for the sending commands to ARM, and the other register pair is for the sending commands to DSP. Each register pair has:

a command register, which is used pass commands to ARM or DSP;
a command complete register, which is used to return the status of execution of the command;
each command can pass up to 30 words of command parameters;
also, each command execution can return up to 30 words of command return parameters.

An ARM to DSP command sequence is as follows:
ARM writes a command to the command register
ARM writes number of parameters to number register
ARM writes command parameters into the command parameter space
ARM issues a Nonmaskable interrupt to the DSP
DSP reads the command
DSP reads the command parameters
DSP executes the command
DSP clears the command register
DSP writes result parameters into the result parameter space
DSP writes "command complete" register
DSP issues HINT interrupt to ARM

The DSP to ARM command sequence is as follows:
DSP writes command to command register
DSP writes number of parameters to number register
DSP writes command parameters into the command parameter space
DSP issues an HINT interrupt to the DSP
ARM reads the command
ARM reads the command parameters
ARM executes DSP command
ARM clears the command register
ARM writes result parameters into the result parameter space
ARM writes "command complete" register
ARM sends an INT0 interrupt to the DSP

Communication between the ARM and the DSP is usually accomplished using a set of communication APIs. Below is an example of a set of communication APIs between a general-purpose processor (in this case an ARM) and a DSP: 

#define ARM_DSP_COMM_AREA_START_ADDR 0x80
 Start DSP address for ARM-DSP.
#define ARM_DSP_COMM_AREA_END_ADDR 0xFF
 End DSP address for ARM-DSP.
#define ARM_DSP_DSPCR (ARM_DSP_COMM_AREA_START_ADDR)
 ARM to DSP, parameters and command from ARM.
#define ARM_DSP_DSPCCR (ARM_DSP_COMM_AREA_START_ADDR+32)
 ARM to DSP, return values and completion code from DSP.
#define ARM_DSP_ARMCR (ARM_DSP_COMM_AREA_START_ADDR+64)
 DSP to ARM, parameters and command from DSP.
#define ARM_DSP_ARMCCR (ARM_DSP_COMM_AREA_START_ADDR+96)
 DSP to ARM, return values and completion code from ARM.
#define DSP_CMD_MASK (Uint16)0x0FFF
 Command mask for DSP.
#define DSP_CMD_COMPLETE (Uint16)0x4000
 ARM-DSP command complete, from DSP.
#define DSP_CMD_OK (Uint16)0x0000
 ARM-DSP valid command.
#define DSP_CMD_INVALID_CMD (Uint16)0x1000
 ARM-DSP invalid command.
#define DSP_CMD_INVALID_PARAM (Uint16)0x2000
 ARM-DSP invalid parameters.

Functions
STATUS ARMDSP_sendDspCmd (Uint16 cmd, Uint16 *cmdParams, Uint16 nParams)
 Send command, parameters from ARM to DSP.
STATUS ARMDSP_getDspReply (Uint16 *status, Uint16 *retParams, Uint16 nParams)
 Get command execution status, return parameters sent by DSP to ARM.
STATUS ARMDSP_getArmCmd (Uint16 *cmd, Uint16 *cmdParams, Uint16 nParams)
 Get command, parameters sent by DSP to ARM.
STATUS ARMDSP_sendArmReply (Uint16 status, Uint16 *retParams, Uint16 nParams)
 end command execution status, return parameters from ARM to DSP.
STATUS ARMDSP_clearReg ()
 Clear ARM-DSP communication area.