Feedback System Analyser Tutorial 4D (analyse events from multiple cores)

Hi Clément

Thanks for your feedback!

Re:- it lacks an example of cfg file for multicore event correlation for jtagrunmode. In particular about sync points

Here's an example .cfg file snippet you can add to your project to a) enable uploading events over JTAG while the target is running and b) enabling sync point events:

(The full .cfg file and example application is in Tutorial4B_JTAGRunMode.zip.  In the code below I've changed the idle hook function API to call to take advantage of the built-in IdleHook function that is now part of the LogSync module in the ti.uia.runtime package):

/* ================ Logger configuration ================ */
/*
 * The target's Log records are read while the target is running. Note: this mode
 * is only supported for CPUs that support real-time JTAG accesses such as
 * those in the C6X family (e.g. C64X+ and C66 CPUs). 
 *
 * Configuration done by the application is still honored (e.g. setting
 * up the common$.diags mask).
 *
 * Please refer to the ti.uia.sysbios.LoggingSetup module for more
 * details and configuration options.
 */
var LoggingSetup = xdc.useModule('ti.uia.sysbios.LoggingSetup');
LoggingSetup.eventUploadMode = LoggingSetup.UploadMode_JTAGRUNMODE;
LoggingSetup.loadLoggerSize = 1024;
LoggingSetup.mainLoggerSize = 32768;
LoggingSetup.sysbiosLoggerSize = 32768;
LoggingSetup.disableMulticoreEventCorrelation = false; // this is false by default - just showing it for completeness.
LoggingSetup.sysbiosTaskLogging = false;

var LogSync = xdc.useModule('ti.uia.runtime.LogSync');
LogSync.enableEventCorrelationForJTAG = true;
var Idle = xdc.useModule('ti.sysbios.knl.Idle');
Idle.addFunc('&ti_uia_runtime_LogSync_idleHook');  // LogSync_idleHook introduced in UIA 1.1.1.14 and later

You can optionally periodically log a sync point event (e.g. if you are uploading events over Ethernet using
 ti.uia.sysbios.LoggerStreamer or LoggerStreamer2) by calling the LogSync module's built-in timer hook function:

 // Configure a Timer to interrupt every 100ms and call the LogSync_timerHook
 // function to log a sync point event
 var Timer = xdc.useModule('ti.sysbios.hal.Timer');
 var timerParams = new Timer.Params();
 timerParams.startMode = Timer.StartMode_AUTO;
 timerParams.period = 100000;        // 100,000 uSecs = 100ms
 var timer0 = Timer.create(Timer.ANY, '&ti_uia_runtime_LogSync_timerHook', timerParams);

Re: - if in jtagrunmode it's really necessary to use a specific GEL file with contains a LogSync script

No.   The LogSync script I was referring to previously (LogSync.xs)  is provided with the UIA package and is used automatically when you build your project.  Nothing special is required in terms of GEL.  However, in general, it is very important that you use the correct GEL script for your board in order to properly configure memory and peripherals.  This is especially true for the EVM6678 as there are a number of subsystems (QMSS, PA, etc) that are initialized by GEL. 

Re: - if it is necessary to add LogSync code in the code before sysbios start

It's good practice but not really necessary to call LogSync_writeSyncPoint() before sysbios start.  e.g. you could just let the idle hook function take care of logging it for you or, if you are building a library, put it in the library code instead of in the main application code.

What is important is that the call to LogSync_writeSyncPoint() occurs after main( ) has executed.   If you log it before main, then when the target automatically runs to main when you load the project, the timing alignment between the local CPU timestamp and the global timestamp will get messed up.   If you log it a long time after events have started being recorded AND you are using LoggerStreamer/LoggerStreamer2, then events that occur prior to the sync point will not be correlated properly.  (this is actually something we will be addressing in a later release)

Re: When it says "after a breakpoint is hit" does it mean only CCS breakpoints (the red dot) or also any CIO operation.

Both CCS breakpoints and CIO operations will cause a loss of synchronization between the local and global timestamps.  If you call printf...  instead of Log_print..., a hidden breakpoint will be executed in order to notify CCS that it needs to update the console.  Unfortunately, System Analyzer is not currently notified of these breakpoints so the idleHook function will not be notified by System Analyzer that it needs to log a new sync point event.  You will need to explicitly log a sync point event after you call printf in order to establish a new sync point.  Only events that occur AFTER the breakpoint and the new sync point event will be correlatable. 

Re: My question is : if I do a system_printf or a log_print does it break the multicore event correlation ?

A system_print call is handled differently than a normal stdio printf call.   If you use SysMin = xdc.useModule('xdc.runtime.SysMin'); in your code and do not call SysMin_flush(), then the console will only be updated when you exit your application and there will be no breakpoints executed.  If you use SysStd = xdc.useModule('xdc.runtime.SysStd'); or call SysMin_flush(), then a breakpoint will be executed in order to update the console and you will lose synchronization between the local CPU timestamp and the global timestamp.  Please see this post for more info.

If you call Log_print in your code, it logs a normal UIA event that System Analyzer will be able to receive and display.  There are no breakpoints involved, so there is no loss of sync.  This is the preferred way to output print statements from your application as it is thread safe and doesn't break your real-time performance.

Regards,

  Brian

Thank you very much Brian,

You cleared up everything in my questions.

I hope I'll have the time to try the multicore event correlation in my application soon.

I'll keep you posted about the results.

Clément

Brian,

Good news we managed to have multicore synchronisation for the system analyser in our example applications that uses Notify (hence HWIs), semaphores, SWIs and events, for 8 cores.

I think we'll have a couple questions more as we try to go deeper.

Thanks,

Clément

Brian,

Is it possible to use our own external clock as the Global timestamp (opposed to the CPU timestamp) ?
If yes, how ?
I haven't found much in the documentation how to do that.

In a multi-DSP environnement it'd be very helpful.

Thanks,

Clément

Hi Clément,

  Yes, you can log your own sync point events with your own custom parameters if you want.  You'll still need to include LogSync = xdc.useModule('ti.uia.runtime.LogSync'); in your .cfg file, but instead of calling the LogSync_writeSyncPoint method, you'll instead log the following two events:

#include <ti/uia/events/UIASync.h>

#include <xdc/runtime/Error.h>
#include <xdc/runtime/Gate.h>

#include <xdc/runtime/Types.h>
#include <xdc/runtime/Timestamp.h>

...

    IArg key;

    Types_Timestamp64 globalTStamp;
    Types_Timestamp64 cpuTStamp;
    Types_FreqHz globalFreq;
    Types_FreqHz cpuFreq;

    UInt32 globalTimestampCpuCyclesPerTick = 10;  // set to the number of CPU cycles per global timestamp tick.

// store your global timestamp frequency into globalFreq.lo and  globalFreq.hi

    globalFreq.lo = ...

    globalFreq.hi = ...

    key = Gate_enterSystem();  // prevent preemption

#ifndef xdc_target__isaCompatible_64P
    LogSync_CpuTimestampProxy_get64(&cpuTStamp);
#else
    cpuTStamp.lo = TSCL;
    cpuTStamp.hi = TSCH;
#endif

// store your global timestamp value into globalTStamp.lo and globalTStamp.hi

    globalTStamp.lo = ...

    globalTStamp.hi = ...

    Gate_leaveSystem(key);

    Log_write8(UIASync_syncPoint,cpuTStamp.lo, cpuTStamp.hi, globalTStamp.lo,globalTStamp.hi,
                LogSync_cpuTimestampCyclesPerTick,cpuFreq.lo,cpuFreq.hi);

    Log_write4(UIASync_globalTimerFreq,globalTimestampCpuCyclesPerTick, globalFreq.lo, globalFreq.hi);

I'm currently on vacation and won't be able to check this out in the lab until I get back in the office on August 12.   If it doesn't work, you may need to assign a custom logger instance for use by both the LogSync module and the Main module (e.g.  LogSync.setSyncLogger(myLogger); and LoggingSetup.mainLogger = myLogger;) just to generate the metadata that tells System Analyzer which logger to expect the sync point events in. 

One thing to note is that the accuracy of the correlation will depend on the clock period of your global timer - if it's a 1kHz clock, the accuracy will only be 1ms.  So try to use as high a clock frequency as you can for your global timestamp.

I hope this helps.

Regards,

  Brian

Brian,

Thank you for the detailled explanation.
I won't be able to test your suggestion soon but it'd be handy when we come to that stage of the development.

We'll get back to you if we run into issues.

Regards,

Clément