In Simulink allow to export S-Function Blocks that support to run as Co-Simulation on Multiple Cores

[traversaro]

As documented in https://it.mathworks.com/help/simulink/ug/run-co-simulation-components-on-multiple-cores.html, in Simulink it is possible to run the update of different blocks in different threads, if the block respect some conditions for which they can be consider Co-Simulation slaves, the requirements, listed in https://it.mathworks.com/help/simulink/ug/run-co-simulation-components-on-multiple-cores.html under "S-Function Block Limitations", are:

• [ ] Must have a single rate — ssSetSampleTime(SimStruct *S, int_T st_index, time_T period) must be called to register only one discrete rate.
• [ ] Must have a fixed sample time — In time_T ssSetSampleTime(SimStruct *S, int_T st_index, time_T period), period cannot be VARIABLE_SAMPLE_TIME.
• [ ] Cannot have continuous states — In ssSetNumContStates(SimStruct *S, int_T n), n must be 0
• [ ] Must have no direct feedthrough ports — In ssSetInputPortDirectFeedThrough(SimStruct *S, int_T port, int_T dirFeed), dirFeed must be 0 for each input port.
• [ ] Must be thread safe — In ssSetRuntimeThreadSafetyCompliance(SimStruct *S, int_T val), val must be RUNTIME_THREAD_SAFETY_COMPLIANCE_TRUE.
• [ ] Must be exception-free — In ssSetOptions(SimStruct *S, uint_T options), options must include SS_OPTION_EXCEPTION_FREE_CODE.

Some of them are not dictated by BlockFactory itself, so we should find a way to be configurable from the developer develoing BlockFactory blocks. Furthermore, this mode seems to support natively FMI, so an alternative way to achieve this could be to work on https://github.com/robotology/blockfactory/issues/5 .

[traversaro]

The simulation runs on a single thread for accelerator and rapid accelerator modes.

If I understood correctly this sentence in https://it.mathworks.com/help/simulink/ug/run-co-simulation-components-on-multiple-cores.html, this may mean that https://github.com/robotology/blockfactory/issues/53 is a prerequisite for this.