PSoC 6 Inter-Processor Communication (IPC)

[Anonymous]

Hi everyone!

Thought I'd give an update on the PSoC 6 Inter-Processor Communication (IPC) feature for the dual-core ARM Cortex architecture.

The PSoC 6 is a multi-core architecture with two processors CM0+ and CM4 on the same die, with all the memory and peripherals available for use by both the cores. This adds a lot of value to the user who wants to set up a system where the processing load is shared by the two cores. To make such a design possible the two cores must communicate with each other. There are different ways that can happen.

At the instruction-set level, you can use the send event instruction (SEV). This generates an interrupt event for each core in a multi-core system. Using the SEV gives you one channel of communication with another core, through the event signal. This means all communication would need to be through this one event. You need to set up a higher layer of code to deal with data transfer and multiplexing of different events.

PSoC 6 hardware implements a more capable solution. In addition to the SEV instruction, PSoC 6 has 16 hardware Inter-Processor Communication (IPC) channels. Each channel can be configured to be an exclusive communication medium between the two cores. Each IPC channel implements a hardware semaphore or mutex. You can use this to ensure exclusive access to shared resources. Each channel also has an associated 32-bit shared data register. You can use the register to pass a 32-bit value, or use it for a pointer to any data of arbitrary complexity.

In addition to the 16 IPC channels, PSoC 6 also provides 16 IPC interrupts. Each IPC interrupt can be used as event triggers from one core to another. This mechanism can be used in conjunction with an IPC channel to set up a messaging scheme with a notification event and acknowledgement.

The Peripheral Drive Library (PDL) implements an API to give you high-level access to the IPC hardware. The PDL implements a semaphore system which can be used to ensure exclusive access to shared resources or single bit flag communication between the two cores. The PDL uses a single IPC channel, but gives you the ability to set up an arbitrary number of semaphores on that channel (limited by available SRAM).

In addition, the PDL also provides communication pipe implementations for messaging between cores. Each processor has at least one “end point” structure. Messages are transferred between endpoints. The end point (among other things) has an array of “clients”. Each client has a client ID (the index into the client array and an associated callback function. ”. The messages sent to a specific endpoint can be addressed to a specific client at the end point. Thus each client can be handled differently when a message is sent to it. 

Feel free to leave comments and questions, we appreciate the feedback!

[Anonymous]

I have some questions related to the multi-core architecture:

1. Are the cores similar enough that the same object code could be run on either core?
2. What debugging tools are intended to help troubleshoot software when both cores are in use?

Thanks!

[BrMc_296271]

I don't have the PSOC6 books either, but from what I know the answer to (1) is No. The respective user instruction sets overlap, but the M4 set is much larger, and I have this recollection that the M0+ has a few instructions the M4 doesn't. Moreover, the CPU control and exception mechanisms are somewhat different. You would need to compile each image separately, though it appears Creator is built to automate this.

As to (2), the "Dual Core" book over at PSoC® 6 Dual-Core CPU System Design  seems to pretty much say that you have to debug the two cores separately.

[JamesT_21]

I'm a little late to this party, but...

Correct. The CM4 and CM0+ instruction sets are different. You build an executable intended for one or the other. Each executable resides in a defined location in the shared memory space. The CM0+ is the startup core, and it enables the CM4 core, so the CM4 application starts running 2nd. PSoC Creator does in fact automate that process - a single project contains both the per-core and the shared files, it builds both executables, programs them into memory, and starts it all running. That's pretty slick.

Third party tools, you have a separate project for each core, but you can keep them in the same workspace if you want. Not quite as slick, but definitely manageable. For supported IDEs the PDL includes linker and post-build scripts to automagically combine the executables and download them to the hardware. So it's all pretty transparent. The only "trick" is you must build the CM0+ executable first. The CM4 build process requires that executable be "in place" so it can do the magic.

For debugging...

PSoC Creator does not support dual core debugging. Some third party tools do, like IAR Embedded Workbench. I may build a code example using the IAR tools to show how it's done. Let me know if that would be useful. I've got a few other things on my plate for the moment, but I think that's going to be a pretty common use case.

[daloc_1304421]

Concerning dual core debugging: are there any plans to support this in PSoC Creator at a later time, or will we always have to use 3rd party tools for that?

[JamesT_21]

I'm not aware of plans for simultaneous dual core debugging in Creator, but I'm not on the tools team. I KNOW the product management people read these threads for insight and feedback, so I'm 100% confident this has been seen. And when anyone asks me.... I tell them this is a DUH.  

[Anonymous]

"In addition, the PDL also provides communication pipe implementations for messaging between cores." - that sounds cool! Can we debug the IPC as well in IAR?

[JamesT_21]

Yes. You can debug IPC code and operations. Most of the PDL will be provided as source code, and the IPC is no exception. 

[Anonymous]

A code example would be great.

[niwa_1296046]

has reference code now?

[JamesT_21]

CE216795 is a simple IPC example.

You can study the default cy_ipc_config.c and .h files in the <install directory>\drivers\peripheral\ipc. that sets up the default IPC communication for the system.