System Analyzer Tutorial 4C

System Analyzer Tutorial 4C:

How to Communicate with Multicore Devices via Ethernet, with IPC communication between cores

Tutorial 3B covers how to use the NDK to provide an Ethernet Transport that could be used to send commands between the target and System Analyzer on the host, and to upload events from the target to System Analyzer. This arrangement can be extended to support multicore devices where one core acts as the master core (and runs the NDK stack), and the other cores act as slave cores, using MessageQ for inter-processor communication for the UIA commands and uploading events to System Analyzer via the master core.

We'll be using a different example project, called "MessageQ" to illustrate how you can use System Analyzer to see the interactions between processors that are working together. In this project, the master CPU logs a UIABenchmark_start event and then sends a message over the ti.ipc package's messageQ API to the first slave CPU. It then calls MessageQ_get to block until it another CPU sends it a message. When CPU 1 receieves the message, it forwards it on to the next CPU, and so on until the last CPU sends it back to the master CPU. This causes the MessageQ_get API call on the master CPU to unblock, and the master CPU then logs a UIABenchmark_stop event. For each new message that the master sends, it increments the message Id that is used and logs the message Id as a parameter for the start / stop events.

Here's what it looks like in System Analyzer's Execution graph:

If you hover over the various colors in the graph or click on each of the "C66XX labels on the y-axis, you would see that the red line segments represents the Idle task, the purple segment is the task that runs the tsk_func0 function (which is only run on the master CPU, CPU0, and sends the message to CPU1), and the aqua colored segment is the task that runs the tsk_func1 function on the slave CPUs and receives the message from one CPU and sends it to the next. The green line at the top shows the amount of time that elapsed between the UIABenchmark_start event and the UIABenchmark_stop event.

Note that all of the events from the various CPUs have been correlated with the same global timeline, which is why System Analyzer is able to show the proper timing relationship between the events logged by the various cores.

First, let's look at what additional code and configuration script is required to enable the IPC communication between the 'master' CPU and the 'slave' CPUs, using the TMS320C6472 as an example device:

C code: <syntaxhighlight lang='c'> /* --------- IPC module Headers --------- */

1. include <ti/ipc/Ipc.h>
2. include <ti/ipc/MessageQ.h>
3. include <ti/ipc/HeapBufMP.h>
4. include <ti/ipc/MultiProc.h>

...
Void main()
{
 ...

   /*
    *  Ipc_start() calls Ipc_attach() to synchronize all remote processors
    *  because 'Ipc.procSync' is set to 'Ipc.ProcSync_ALL' in *.cfg
    */
   Ipc_start();

   BIOS_start();
   
   /* Fall into BIOS idle loop */
   return;                 

} </syntaxhighlight>

.cfg script: <syntaxhighlight lang='javascript'> /* Configure the ServiceMgr to support Multicore. This enables the use of IPC for inter-processor communication */ ServiceMgr.topology = ServiceMgr.Topology_MULTICORE; /* Identify CPU 0 as being the 'master' CPU that will communicate with the host. */ ServiceMgr.masterProcId = 0; /*

*  Since this is a single-image example, we don't know (at build-time) which
*  processor we're building for.  We therefore supply 'null' 
*  as the local procName and use MultiProc_setLocalId to set the procId
*  at runtime.
*/ 

var MultiProc = xdc.useModule('ti.sdo.utils.MultiProc');

/* Modify the next line to have one "COREX" entry per CPU core on the device */

MultiProc.setConfig(null, ["CORE0", "CORE1", "CORE2", "CORE3", "CORE4", "CORE5"]);

/* ================ IPC Configuration ================ */ /* Modules explicitly used in the application */ var MessageQ = xdc.useModule('ti.sdo.ipc.MessageQ'); var Ipc = xdc.useModule('ti.sdo.ipc.Ipc'); var HeapBufMP = xdc.useModule('ti.sdo.ipc.heaps.HeapBufMP');

/* Synchronize all processors (this will be done in Ipc_start) */ Ipc.procSync = Ipc.ProcSync_ALL;

/*

• Need to define the shared region. The IPC modules use this
• to make portable pointers. All processors need to add this
• call with their base address of the shared memory region.
• If the processor cannot access the memory, do not add it.
• NOTE: On c6472, region 0 needs to be placed SL2 RAM because of the
• requirement that all GateMP created on this device use SL2 RAM
• shared memory.
• /

/* Shared Memory base address and length */ var SHAREDMEM = 0x200000; var SHAREDMEMSIZE = 0x48000; var SharedRegion = xdc.useModule('ti.sdo.ipc.SharedRegion'); SharedRegion.setEntryMeta(0,

   { base: SHAREDMEM, 
    len:  SHAREDMEMSIZE,
    ownerProcId: 0,
    isValid: true,
    cacheLineSize: 64, /* SL2 memory has a cache line size of 64 */
    name: "SL2_RAM",
  });    

</syntaxhighlight>

The ServiceMgr Module

The ServiceMgr module plays a key role in the communications infrastructure on the target.

• On the master CPU, the ServiceMgr is configured to interact with the host via TCP/IP command packets received via the NDK.

• Commands that are addressed to CPUs other than the master CPU are routed via IPC MessageQ to the appropriate slave CPU.
• Commands that are addressed to the master CPU are checked to see if the "Service ID" the command is addressed to has registered with the ServiceMgr and, if the service is found, is sent on to that service to be handled.

• On the slave CPU, commands are received via IPC MessageQ from the master CPU and are forwarded to the appropriate service on that CPU.

The Rta Service

The first 'service' that is provided by UIA is the "Rta" (Real-time Analysis) service, which supports the following commands:

• Rta_Command_START_TX:

• The Rta service logs a sync point event upon receiving this command from the host.
• It then starts uploading events from the logger memory buffers to the host in UDP event packets via the ServiceMgr
• The ServiceMgr takes care of sending the event packets via the appropriate transport: either via IPC MessageQ to the master CPU or, if running on the master CPU, via the NDK up to the host.

• Rta_Command_STOP_TX:

• The Rta service stops sending up event packets upon reception of this command from the host.
• It logs an additional sync point event at this time to ensure that there is an unread sync point in the loggers in case the target is halted (e.g. by hitting a breakpoint).

Because the Rta module logs sync points automatically, if you are only interacting with the target via Ethernet, you do not have to log any sync points in your application code. As in Tutorial 4B, if you halt a CPU, you should Remove System Analyzer, and then start a new System Analyzer session after the CPU has been restarted so that a new Start_TX command can be sent to all CPUs, causing them to log a new sync point event and thus re-establish event synchronization.

Building the MessageQ Example

• How to build the MessageQ project for the C6472 or C6474
• How to build the MessageQ project for the C66X

Next: Tutorial 4D: how to use System Analyzer to view and analyze events from multiple cores

Links

• Back up to the System Analyzer Tutorials page
• Back up to the System Analyzer Home