Very slow IPC.

Stein,

The one-way message latency should be on the order of 3-10usec, depending upon which Notify driver is being used. 

A first guess is that the timings for the shared memory region used for IPC are not properly configured.  Are you using DDR or L2 for IPC?  If DDR, are you using a GEL file or otherwise initializing timings properly?  

If this is not it, can you please provide more details of your memory and application configuration? (I don’t see any zipped attachment to your post.)

Scott

Here is the .zip file.

As you can see from the example application .cfg file, the only change was to change the cpu frequency to 250MHz.

The memory used is SL2.

Stein,

I'll give you a bit of an explanation as to why printf consumes so many cycles.

Here's how all of the CIO functions work.  (printf, scanf, fprintf, etc.).  When the application encounters one of these functions, it formats the data and stores it in memory.  This part probably takes tens of milliseconds, as you say.  The problem is what happens next.  When you run an application from CCS, it runs freely, and CCS periodically non-intrusively polls each of the devices on the scan chain to see if the processor has been halted (typically by a breakpoint).  If it has been, then CCS goes and reads enough memory to update all of it's windows and remains at the breakpoint.  The period of these polls is not a fixed one, but I would suspect that they happen at least 2-3 times per second (maybe more).  For these CIO functions, once the data is formatted on chip, they branch to a special breakpoint that has been set at the CIO symbol.  When CCS next polls and sees that the processor is halted at the CIO breakpoint, it then reads the data up through the emulator, displays it in the CCS window, and then automatically runs the processor again.  This is where all of these cycles come from.  Assume the formatting takes 20 milliseconds, but right as the formatting has been completed, CCS is finishing one of it's polls.  So, there's the potential to be sitting at that breakpoint until the next time CCS polls, which if you assume 2 polls per second, might be something like 500 ms.  So, the delay is not really how long it takes for the printf code to execute, it's mostly the time that the processor is halted waiting for the asynchronous poll from CCS.

Writing from more than one core does compound the problem.  The fastest emulators only run TCK at 35-50 Mhz.  Each time CCS polls and there is more than one core that has CIO data to push up, the emulator has to read that data in which is a serial process clocked at the TCK rate.  So, depending on how much data there is, there could be large delays here also.  And there could be worse cases.  If you assume that you have 8 cores, and they're all writing printf functions.  CCS polls the cores in order each time.  Assume that you have printf data on cores 1-7.  When CCS polls, it checks core 0, and finding nothing, moves on to pull the data from core 1, then core 2, etc.  What if, right after core 0 is polled, it gets some printf data.  Now it not only has to wait for the asynchronous poll, the poll won't even occur while CCS is busy getting the data from cores 1-7.  So, there might be cases where it takes seconds between time data is written to via printf, and the time that data is actually pulled up to the host.

Regards,

Dan