IPC - TI Training

IPC - TI Training
Intro to: Inter‐Processor Communications (IPC)
Agenda
 Basic Concepts  IPC Services
IPC Services
 Setup and Examples
 IPC Transports
IPC T
t
 For More Information
Basic Concepts
 Basic Concepts  IPC Services
IPC Services
 Setup and Examples
 IPC Transports
IPC T
t
 For More Information
IPC – Definition
 IPC = Inter‐Processor Communication
 While this definition is rather generic, it really means:
“Transporting data and/or signals between threads of execution”
 These threads could be located anywhere:
These threads could be located anywhere:
Data
Thread 1
Thread 2
CorePac 0
CorePac 0
CorePac 0
CorePac 1
Device 0
Device 1
How would YOU solve this problem?
IPC – Possible Solutions
 How do you transport the data and signal?
 Manual: Develop your own protocol using device resources
Manual: Develop your own protocol using device resources
 Auto: Using existing RTOS/Framework Utilities (i.e., IPC)
Data
Thread 1
Thread 2
CorePac 0
CorePac 0
CorePac 0
CorePac 1
Device 0
Device 1
What solutions exist in TI’s RTOS to perform IPC ?
IPC – RTOS/Framework Solutions




SAME CorePac: TI’s RTOS (SYS/BIOS) supports several services for
SAME
C P
TI’ RTOS (SYS/BIOS)
t
l
i
f
inter‐thread communication (e.g. semaphores, queues, mailboxes, etc.).
DIFFERENT CorePac: The IPC framework supports communications
DIFFERENT CorePac: The IPC framework supports communications
between CorePacs via several transports.
DIFFERENT DEVICE: IPC transports can also be implemented
b
between devices.
d
KEY: Same IPC APIs can be used for local or remote communications.
Data
Thread 1
Thread 2
Solutions
CorePac 0
CorePac 0
SYS/BIOS (or IPC)
CorePac 0
CorePac 1
IPC + transport
Device 0
Device 1
p
IPC + transport
IPC – Transports

Current IPC implementation uses several transports:
Current
IPC implementation uses several transports:
• CorePac  CorePac (Shared Memory Model, Multicore Navigator)
• Device 
D i  Device (Serial Rapid I/O)
D i (S i l R id I/O)

Chosen at configuration; Same code regardless of thread location.
Device 1
TThread 1
TThread 1
IPC
MEM or
IPC
TThread 2
CorePac 1
TThread 2
CorePac 2
TThread 2
CorePac 1
TThread 1
Device 2
IPC
Multicore
Navigator
SRIO
SRIO
IPC Services
 Basic Concepts  IPC Services
IPC Services
•
•
•
•
Message Queue
N tif
Notify
Data Passing
Support Utilities
 Setup and Examples
Setup and Examples
 IPC Transports
 For More Information
F M
I f
ti
IPC Services



The IPC package is a set of APIs Th
IPC
k
i
f API
MessageQ uses the modules below …
But each module can also be used independently.
h
d l
l b
d d
d l
Application
MessageQ
g Q
Notify Module IPC Config and Initialization
Basic Functionality
(ListMP, HeapMP, gateMP, Shared Region)
Utilities
(Name Server, MultiProc, List)
Transport Layer
Transport
Layer
(Shared Memory, Multicore Navigator, SRIO)
IPC Services – Message Queue
 Basic Concepts  IPC Services
IPC Services
•
•
•
•
Message Queue
N tif
Notify
Data Passing
Support Utilities
 Setup and Examples
Setup and Examples
 IPC Transports
 For More Information
F M
I f
ti
MessageQ – Highest Layer API

SINGLE reader, multiple WRITERS model (READER owns queue/mailbox)
,
p
(
q
/
)

Supports structured sending/receiving of variable‐length messages, which can include (pointers to) data

Uses all of the IPC services layers along with IPC Configuration & Initialization
Uses all of the IPC services layers along with IPC Configuration & Initialization

APIs do not change if the message is between two threads:


On the same core 
On two different cores

On two different devices
APIs do NOT change based on transport – only the CFG (init) code

Shared memory

M li
Multicore Navigator
N i

SRIO
MessageQ and Messages
Q
How does the writer connect with the reader queue?
A
Q
What do we mean when we refer to structured messages with variable size?
A
Q
GateMP provides hardware semaphore API to prevent race conditions.
What facilitates the moving of a message to the receiver queue?
A
Q
List utility provides a double
List
utility provides a double‐link
link list mechanism. The actual allocation of the memory list mechanism. The actual allocation of the memory
is done by HeapMP, SharedRegion, and ListMP.
If there are multiple writers, how does the system prevent race conditions (e.g., two writers attempting to allocate the same memory)?
A
Q
Each message has a standard header and data. The header specifies the size of payload.
l d
How and where are messages allocated?
A
Q
MultiProc and name server keep track of queue names and core IDs.
MultiProc and name server keep track of queue names and core IDs.
This is done by Notify API using the transport layer.
Does the application need to configure all these modules?
A
N M t f th
No. Most of the configuration is done by the system. More details later.
fi
ti i d
b th
t
M
d t il l t
Using MessageQ (1/3)
CorePac 2 READER
CorePac 2 ‐
MessageQ_create(“myQ”, *synchronizer);
“myQ”


MessageQ_get(“myQ”, &msg, timeout);
MessageQ transactions begin with READER creating a MessageQ.
READER’ attempt to get a message results in a block (unless
READER’s
tt
tt
t
lt i bl k ( l
timeout was specified), since no messages are in the queue yet.
What happens next?
Using MessageQ (2/3)
CorePac 1 WRITER
CorePac 1 ‐
CorePac 2 READER
CorePac 2 ‐
MessageQ_open (“myQ”, …);
MessageQ_create(“myQ”, …);
msg = MessageQ_alloc (heap, size,…);
“myQ”
MessageQ_get(“myQ”, &msg…);
MessageQ_put(“myQ”, msg, …);
Heap



WRITER begins by opening MessageQ created by READER.
begins by opening MessageQ created by READER.
WRITER gets a message block from a heap and fills it, as desired.
WRITER puts the message into the MessageQ.
puts the message into the MessageQ
How does the READER get unblocked?
Using MessageQ (3/3)
CorePac 1 WRITER
CorePac 1 ‐
CorePac 2 READER
CorePac 2 ‐
MessageQ_open (“myQ”, …);
MessageQ_create(“myQ”, …);
msg = MessageQ_alloc (heap, size,…);
“myQ”
MessageQ_get(“myQ”, &msg…);
MessageQ_put(“myQ”, msg, …);
*** PROCESS MSG ***
MessageQ_close(“myQ”, …);
MessageQ_free(“myQ”, …);
MessageQ_delete(“myQ”, …);
Heap




Once WRITER puts msg in MessageQ, READER is unblocked.
READER can now read/process the received message.
READER frees message back to Heap.
g
p
READER can optionally delete the created MessageQ, if desired.
MessageQ – Configuration



All API calls use the MessageQ module in IPC.
User must also configure MultiProc and SharedRegion modules.
All th
All other configuration/setup is performed automatically
fi
ti / t i
f
d t
ti ll
by MessageQ.
User APIs
MessageQ
Notify
ListMP
HeapMemMP +
Uses
MultiProc
Uses
Cfg
Shared Region
GateMP
NameServer
Uses
MessageQ – Miscellaneous Notes

O/S independent:

If one CorePac is running LINUX and using SysLink,
If
one CorePac is running LINUX and using SysLink
the API calls do not change.

SysLink is runtime software that provides connectivity
SysLink
is runtime software that provides connectivity
between processors (running Linux, SYSBIOS, etc.)

Messages can be allocated statically or dynamically.
Messages can be allocated statically or dynamically.

Timeouts are allowed when a task receives a message.

User can specify three priority levels:
User can specify three priority levels:

Normal

High

Urgent
More Information About MessageQ

All structures and function descriptions can be found within the release:
\ipc_U_ZZ_YY_XX\docs\doxygen\html\_message_q_8h.html
IPC Services ‐ Notify
 Basic Concepts  IPC Services
IPC Services
•
•
•
•
Message Queue
N tif
Notify
Data Passing
Support Utilities
 Setup and Examples
Setup and Examples
 IPC Transports
 For More Information
F M
I f
ti
Using Notify – Concepts
In addition to moving MessageQ messages, Notify:

Can be used independently of MessageQ

Is a simpler form of IPC communication

Is used ONLY with shared memory transport
IPC
Thread 2
CorePac 2
Thread 2
CorePac 1
Thread 1
Device 1
Device 1
Thread 1

IPC
MEM
Notify Model

C
Comprised of SENDER
i d f SENDER and RECEIVER.
d RECEIVER

The SENDER API requires the following information:

Destination (SENDER ID is implicit)

16‐bit Line ID 
32‐bit Event ID

32‐bit
32
bit payload (For example, a pointer to message handle)
payload (For example, a pointer to message handle)

The SENDER API generates an interrupt (an event) in the destination.

Based on Line ID and Event ID, the RECEIVER schedules a pre‐
defined call‐back function.
Notify Model
Sender
Receiver
During initialization, link the Event ID and Line ID with call back function.
Void Notify_registerEvent(srcId, lineId, eventId, cbFxn, cbArg);
During run time, the Sender sends a notify to the Receiver.
Void Notify_sendEvent(dstId, lineId, eventId, payload, waitClear);
INTERRUPT
Based on the Sender’s Source ID, Event ID, and Line ID,
,
,
,
the call‐back function that was registered during initialization is called with the argument payload.
Notify Implementation
Q
How are interrupts generated for shared memory transport?
A
Q
How are the notify parameters stored?
A
Q
List utility provides a double‐link list mechanism. The actual allocation of the memory is done by HeapMP, SharedRegion, and ListMP.
ListMP
How does the notify know to send the message to the correct destination?
A
Q
The IPC hardware registers are a set of 32‐bit registers that generate The
IPC hardware registers are a set of 32 bit registers that generate
interrupts. There is one register for each core.
MultiProc and name server keep track of the core ID.
Does the application need to configure all these modules?
A
No. Most of the configuration is done by the system.
Example Callback Function
/*
* ======== cbFxn ========
* This
Thi fxn
f was registered
i
d with
ihN
Notify.
if IIt iis called
ll d when
h any event is
i sent to this
hi CPU.
CPU
*/
Uint32 recvProcId ;
Uint32 seq ;
void cbFxn(UInt16 procId, UInt16 lineId, UInt32 eventId, UArg arg, UInt32 payload)
{
/* The payload is a sequence number. */
recvProcId = procId;
seq = payload;
Semaphore_post(semHandle);
}
More Information About Notify

All structures and function descriptions can be found within the release:
\ipc_U_ZZ_YY_XX\docs\doxygen\html\_notify_8h.html
IPC Services ‐ Data Passing
 Basic Concepts  IPC Services
IPC Services
•
•
•
•
Message Queue
N tif
Notify
Data Passing
Support Utilities
 Setup and Examples
Setup and Examples
 IPC Transports
 For More Information
F M
I f
ti
Data Passing Using Shared Memory (1/2)

When there is a need to allocate memory that is accessible by multiple cores, shared memory is used.

However, the MPAX register for each core might assign a different logical address to the same physical shared memory address.

The Shared Region module provides a translation look‐up table that resolves the logical/physical address issue without user intervention.
Data Passing Using Shared Memory (2/2)


Messages are created and freed, but not necessarily in consecutive order:

HeapMP provides a dynamic heap utility that supports create H
MP
id
d
i h
tilit th t
t
t
and free based on double link list architecture.

ListMP provides a double link list utility that makes it easy to ListMP
provides a double link list utility that makes it easy to
create and free messages for static memory. It is used by the HeapMP for dynamic cases.
To protect the above utilities from race conditions (e.g., multiple cores try to create messages at the same time):

GateMP provides hardware semaphore protection.

GateMP can also be used by non‐IPC applications to assign y
pp
g
hardware semaphores.
Data Passing – Static




Data Passing uses a double linked list that can be shared Data
Passing uses a double linked list that can be shared
between CorePacs; Linked list is defined STATICALLY.
ListMP handles address translation and cache coherency.
GateMP protects read/write accesses.
ListMP is typically used by MessageQ not by itself.
User APIs
Notify
ListMP
Uses
Uses
MultiProc
Cfg
Shared Region
GateMP
NameServer
Now, the dynamic version...
Data Passing – Dynamic



Data Passing uses a double linked list that can be shared bl l k l
h
b h
between CPUs. Linked list is defined DYNAMICALLY (via heap).
Same as previous except linked lists are allocated from Heap
Same as previous, except linked lists are allocated from Heap
Typically not used alone – but as a building block for MessageQ
User APIs
Notify
ListMP
HeapMemMP +
Uses
Uses
MultiProc
Cfg
Shared Region
GateMP
NameServer
Uses
Data Passing: Additional Transports

Multicore Navigator

M
Messages are assigned to descriptors.
i dt d
i t

Monolithic descriptors provide a pointer to the message.

SRIO Type 11 has a TI‐developed message protocol that moves data and interrupts between devices.

Implementation of these transports will be discussed later.
IPC Services – Support Utilities
 Basic Concepts  IPC Services
IPC Services
•
•
•
•
Message Queue
N tif
Notify
Data Passing
Support Utilities
 Setup and Examples
Setup and Examples
 IPC Transports
 For More Information
F M
I f
ti
IPC Support Utilities (1/2)

IPC contains several utilities, most of which do NOT need to be
IPC
contains several utilities most of which do NOT need to be
configured by the user.

Here is a short description of each IPC utility:
Here is a short description of each IPC utility:
IPC
MultiProc
SharedRegion
• Initializes IPC subsystems:
Applications using IPC must call IPC_start().
IPC start().
• Applications using IPC must call • In the configuration file, setupNotify and setupMessageQ specify whether to set up these IPC modules.
• Manages processor IDs and core names
• Manages shared memory using HeapMemMP allocator
Manages shared memory using HeapMemMP allocator
• Handles address translation for shared memory regions
More utilities…
IPC Support Utilities (2/2)

IPC contains several utilities, most of which do NOT need to be
IPC
contains several utilities most of which do NOT need to be
configured by the user.

Here is a short description of each IPC utility:
Here is a short description of each IPC utility:
ListMP
GateMP
HeapMemMP
• Provides linked list in shared memory
• Uses multi‐processor gate (GateMP) to prevent collisions
Uses multi processor gate (GateMP) to prevent collisions
on lists
• Multi‐processor gate that provides local (against other
threads on local core) and remote context protection
• Traditional heap; Supports variable‐sized alloc/free
• All allocations are aligned on cache line boundaries.
Setup and Examples
 Basic Concepts  IPC Services
IPC Services
 Setup and Examples
 IPC Transports
IPC T
t
 For More Information
IPC – Tools/Setup Required

IPC is a package (library) that is installed with the MCSDK.
k
(l b
) h
ll d
h h
Note: Installing IPC independent of MCSDK is strongly discouraged.

IPC also requires SYS/BIOS (threading) and XDC tools (packaging) IPC
also requires SYS/BIOS (threading) and XDC tools (packaging) –
installed with the MCSDK (supported by SYS/BIOS ROV and RTA).

IPC is supported on the latest KeyStone multicore devices (C667x, C665x),
as well as C647x and ARM+DSP devices.
ll C647
d ARM DSP d i
What IPC examples exist in the MCSDK?
IPC – Examples

IPC examples are installed along with the MCSDK in the PDK folder
IPC examples are installed along with the MCSDK in the PDK folder.

Simply import these projects into CCS and analyze them.

Some users start with this example code and modify as necessary.
• QMSS – Multicore Navigator
(Queue Manager Subsystem)
• SHM – Shared Memoryy
• SRIO – SRIO (loopback)
• SRIO – Chip to Chip
IPC Transports
 Basic Concepts  IPC Services
IPC Services
 Setup and Examples
 IPC Transports
 For More Information
For More Information
IPC Transports – Intro
 An IPC TRANSPORT
An IPC TRANSPORT
is a …
is a …
“combination of physical H/W and driver code that allows two
threads to communicate on the same device or across devices.”
 IPC supports three different transports:
Shared Memory
Multicore Navigator
SRIO
• This
This is the default transport.
is the default transport
• Uses on‐chip shared memory resources and interrupt
lines to signal the availability of data
• Available on all KeyStone SoC devices
• Uses queues and descriptors plus built‐in signaling
to transmit/receive data and messages between threads
to transmit/receive data and messages between threads
• Hardware serial peripheral that connects two or more DEVICES together
 For MessageQ, only the configuration (init) code changes.
All h
All other code (e.g., put/get) remains unchanged.
d (
/ )
i
h
d
Let's look briefly at the Multicore Navigator first...
Data Passing Using Multicore Navigator
The Multicore Navigator:

Is an innovative packet‐based infrastructure that Is
an innovative packet based infrastructure that
facilitates data movement and multicore control

Provides a highly efficient inter‐core communication Provides
a highly efficient inter‐core communication
mechanism

Provides H/W queues and packet DMA that are the Provides
H/W queues and packet DMA that are the
basic building blocks for IPC
Examples of required init/CFG code are provided with the p
q
/
p
MCSDK.
Now consider the Multicore Navigator implementation …
IPC Transports – Multicore Navigator (1/3)



MessageQ_alloc allocates a heapMP buffer for the MessageQ_msg MessageQ
alloc allocates a heapMP buffer for the MessageQ msg
from MSMC
The buffer contains the MessageQ_Header plus the data.
g _
p
When MessageQ_Put is called with the MessageQ_msg, it also calls the TransportQmss function NotifyQmss_sendEvent.
TX Core
RX Core
msg = MessageQ_alloc
“get the pointer to Msg”
MessageQ_put
MessageQ_get
NotifyQmss_sendEvent
QMSS‐received descriptor
Get a descriptor
p
NotifyDriverQmss
y
Q
_isr
Attach ptr/msg to descriptor
Qmss q e eP sh
Qmss_queuePush
(pushes descriptor directly to
RxQueue of remote core)
IPC Transports – Multicore Navigator (2/3)

The TransportQmss
The
TransportQmss function NotifyQmss_sendEvent
function NotifyQmss sendEvent
 gets a descriptor
 Adds the pointer to the MessageQ_msg (located in MSMC and Adds the pointer to the MessageQ msg (located in MSMC and
containing the data) to the descriptor.
 Qmss_queuePush pushes the descriptor into a queue.
TX Core
RX Core
msg = MessageQ_alloc
“get the pointer to Msg”
MessageQ_put
MessageQ_get
NotifyQmss_sendEvent
QMSS‐received descriptor
Get a descriptor
p
NotifyDriverQmss
y
Q
_isr
Attach ptr/msg to descriptor
Qmss q e eP sh
Qmss_queuePush
(pushes descriptor directly to
RxQueue of remote core)
IPC Transports – Multicore Navigator (3/3)

The Interrupt generator queue calls notifyDriverQmss_isr.

The ISR schedules a QMSS receive descriptor that sends a message The
ISR schedules a QMSS receive descriptor that sends a message
to the queue of Receiver.
TX Core
RX Core
msg = MessageQ_alloc
“get the pointer to Msg”
MessageQ_put
MessageQ_get
NotifyQmss_sendEvent
Get a descriptor
p
Attach ptr/msg to descriptor
Qmss q e eP sh
Qmss_queuePush
(pushes descriptor directly to
RxQueue of remote core)
QMSS‐receive descriptor
NotifyDriverQmss
y
Q
_isr
IPC Transports – SRIO (1/3)

The SRIO (Type 11) transport enables MessageQ to send data
between tasks, cores and devices via the SRIO IP block.

Refer to the MCSDK examples for setup code required to use
MessageQ over this transport.
Chip V CorePac W
Chip X CorePac Y
msg = MessageQ_alloc
M
Q ll
“ M f
“get Msg from queue”
”
MessageQ_put(queueId, msg)
MessageQ_get(queueHndl,rxMsg)
TransportSrio_put
Srio_sockSend(pkt, dstAddr)
SRIO x4
SRIO x4
MessageQ_put(queueId, rxMsg)
TransportSrio_isr
SRIO x4
SRIO x4
IPC Transports – SRIO (2/3)

From a messageQ standpoint, the SRIO transport works the same as the QMSS d
h
k h
h
transport. At the transport level, it is also somewhat the same.

The SRIO transport copies the messageQ message into the SRIO data buffer.
The SRIO transport copies the messageQ message into the SRIO data buffer.

It will then pop a SRIO descriptor and put a pointer to the SRIO data buffer into the descriptor.
Chip V CorePac W
Chip X CorePac Y
msg = MessageQ_alloc
M
Q ll
“ M f
“get Msg from queue”
”
MessageQ_put(queueId, msg)
MessageQ_get(queueHndl,rxMsg)
TransportSrio_put
Srio_sockSend(pkt, dstAddr)
SRIO x4
SRIO x4
MessageQ_put(queueId, rxMsg)
TransportSrio_isr
SRIO x4
SRIO x4
IPC Transports – SRIO (3/3)

The transport then passes the descriptor to the SRIO LLD via the Srio_sockSend API.

SRIO then sends and receives the buffer via the SRIO PKTDMA.

The message is then queued on the Receiver side.
Chip V CorePac W
Chip X CorePac Y
msg = MessageQ_alloc
M
Q ll
“ M f
“get Msg from queue”
”
MessageQ_put(queueId, msg)
MessageQ_get(queueHndl,rxMsg)
TransportSrio_put
Srio_sockSend(pkt, dstAddr)
SRIO x4
SRIO x4
MessageQ_put(queueId, rxMsg)
TransportSrio_isr
SRIO x4
SRIO x4
Configure the Transport Layer

Most of the transport changes are in the CFG file.

The XDC tools build the configuration and initialization code. User involvement is only in changing the CFG file.

Some additional include and initialization is needed in the code.
Now consider the differences between shared memory
and Navigator transport from the application perspective …
Configuration: Shared Memory CFG File
var MessageQ
= xdc.useModule('ti.sdo.ipc.MessageQ');
var Notify
= xdc
xdc.module('ti.sdo.ipc.Notify');
module('ti sdo ipc Notify');
var Ipc
= xdc.useModule('ti.sdo.ipc.Ipc');
Notify.SetupProxy
=
xdc.module(Settings.getNotifySetupDelegate());
MessageQ.SetupTransportProxy=
xdc.module(Settings.getMessageQSetupDelegate());
/* Use shared memory IPC */
MessageQ.SetupTransportProxy =
xdc.module('ti.sdo.ipc.transports.TransportShmSetup');
Program.global.TRANSPORTSETUP =
MessageQ.SetupTransportProxy.delegate$.$name;
Configuration: Navigator CFG File
var MessageQ = xdc.useModule('ti.sdo.ipc.MessageQ');
var Ipc
= xdc.useModule('ti.sdo.ipc.Ipc');
var TransportQmss = xdc.useModule('ti.transport.ipc.qmss.transports.TransportQmss');
/* use IPC over QMSS */
MessageQ.SetupTransportProxy = xdc.useModule(Settings.getMessageQSetupDelegate());
var TransportQmssSetup =
xdc.useModule('ti.transport.ipc.qmss.transports.TransportQmssSetup');
MessageQ.SetupTransportProxy = TransportQmssSetup;
TransportQmssSetup.descMemRegion = 0;
Program.global.descriptorMemRegion = TransportQmssSetup.descMemRegion;
Program.global.numDescriptors
g
g
p
= 8192;
Program.global.descriptorSize = cacheLineSize; // multiple of cache line size
TransportQmss.numDescriptors
p
Q
p
= Program.global.numDescriptors;
g
g
p
;
TransportQmss.descriptorIsInSharedMem = true;
TransportQmss.descriptorSize = Program.global.descriptorSize;
Configuration: SRIO CFG File
var MessageQ = xdc.useModule('ti.sdo.ipc.MessageQ');
var Ipc = xdc.useModule('ti.sdo.ipc.Ipc');
var TransportSrio = xdc.useModule('ti.transport.ipc.srio.transports.TransportSrio');
/* use IPC over SRIO */
MessageQ.SetupTransportProxy = xdc.useModule(Settings.getMessageQSetupDelegate());
var TransportSrioSetup =
xdc.useModule('ti.transport.ipc.srio.transports.TransportSrioSetup');
MessageQ.SetupTransportProxy = TransportSrioSetup;
TransportSrioSetup.messageQHeapId = 1; /*
*
*
TransportSrioSetup.descMemRegion
p
p
g
= 0;
TransportSrioSetup.numRxDescBuffs = 256;
Sized specifically to handle receive side packets.
Heap should
not be used by any other application or module */
/* Should be sized large enough so that multiple
* packets can be queued on receive side and still
* have buffs available for incoming packets */
Configuration: Navigator Initialization (1/2) Additional Include:
/* QMSS LLD*/
#include <ti/drv/qmss/qmss_drv.h>
#include <ti/drv/qmss/qmss
<ti/drv/qmss/qmss_firmware.h>
firmware h>
/* CPPI LLD */
_
#include <ti/drv/cppi/cppi_drv.h>
#include <ti/transport/ipc/examples/common/bench_common.h>
#include <ti/transport/ipc/qmss/transports/TransportQmss.h>
Configuration: Navigator Initialization (2/2) Add an initialization routine:
Int main(Int argc, Char* argv[])
{
if (selfId
( lfId == 0)
{
/* QMSS, and CPPI system wide initializations are run on
this
s co
core
e */
/
* t
result = systemInit();
if (result != 0)
{
System_printf("Error (%d) while initializing QMSS\n", result);
}
}
//
Note that systemInit is provided by TI
IPC Transport Details
Throughput (Mb/second)
Message Size
(B t )
(Bytes)
Shared
Memor
Memory
Multicore
Navigator
48
23.8
34.6
4.1
256
125 8
125.8
184 4
184.4
21 2
21.2
1024
503 2
503.2
737 4
737.4
B
Benchmark
h
kD
Details
t il
•
•
•
•
•
IPC Benchmark Examples from MCSDK
CPU Clock – 1 GHz
Header Size– 32 bytes
SRIO – Loopback Mode
Messages allocated up front
SRIO
-
IPC Transport Pros/Cons
PROS
CONS
• Simplest to implement
d
throughput
h
h
• Moderate
• Single device only
• Requires Notify module and API call
i
if
d l
d
ll
if doorbell required
• Possible contention with other tasks
using the same shared memory
i th
h d
Shared
Memory
• Highest throughput
• Dedicated resources
Multicore • Consumes least CPU cycles
Navigator • Interrupt generated when
d
data is available
i
il bl
• Can be used across devices
be used across devices
SRIO
• Single device only
• Lowest throughput
Lowest throughput
For More Information
• For more information, refer to the BIOS MCSDK User G ide on the Embedded MCSDK User Guide
on the Embedded
Processors Wiki.
• For questions regarding topics covered in this training, visit the support forums at the
training, visit the support forums at the
TI E2E Community website.
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertising