GetSet Storage class SIL Error - Duplicate and Undefined references in xil_interface.c and GetSet.c file

Hello All,

I am currently facing an issue during Software-in-the-Loop (SIL) testing with Simulink. The problem arises due to duplicate and undefined references between the generated xil_interface.c file and my custom SCA_Intfc.c/SCA_Intfc.h implementation.

Here is the situation:

• In normal builds, SCA_Intfc.c provides definitions for getter and setter functions declared in SCA_Intfc.h.
• During SIL testing, xil_interface.c also generates definitions for the same getter/setter functions, leading to multiple definition errors.
• To resolve this, I attempted conditional compilation using #define SIL_MODE and #ifndef SIL_MODE to disable definitions in SCA_Intfc.c during SIL. However, this resulted in undefined reference errors.

For reference, my SCA_Intfc.h file contains function declarations such as: float get_f32SpoolSetPoint_z_elef32SpoolSetPoint_um(void); void set_sca_OutDataGrp_z_ele1f32DerivativeVal_z(float val); ... and similar getter/setter prototypes.

My questions are:

1. What is the recommended way to avoid duplicate definitions between xil_interface.c and SCA_Intfc.c during SIL testing?
2. Should xil_interface.c be the sole provider of these function definitions in SIL, or should SCA_Intfc.c remain the source of truth?
3. Is there a specific storage class configuration or code generation setting that ensures xil_interface.c only defines these functions in SIL mode instead of reading it from SCA_Intfc.c?

I would appreciate your guidance on the correct integration strategy to resolve this conflict.

Answer 1

[Samar]

Hi Sandip,

Yes, in SIL, 'xil_interface.c' should be the sole provider of the getter/setter implementations. Your application-side 'SCA_Intfc.c' must not define them during SIL. The correct pattern is:

• Always keep the prototypes in 'SCA_Intfc.h'.
• Provide implementations either from 'SCA_Intfc.c' (normal build) or from 'xil_interface.c' (SIL), never both.

Recommended integration strategy:

• Do not rely on ad‑hoc #define SIL_MODE guards in source files.
• Instead, use build-level separation:
• Exclude 'SCA_Intfc.c' from the SIL build entirely, or
• Split the file:
• 'SCA_Intfc_api.c' (always built, no definitions)
• 'SCA_Intfc_impl.c' (normal build only)
• Let SIL link only against 'xil_interface.c' for those functions.

Please refer the MathWorks documentation for better understanding: https://www.mathworks.com/help/ecoder/ug/about-sil-and-pil-simulations.html

Settings to check in Simulink:

• Configure signals/functions with ImportedExtern (Code Mappings / Storage Class) so SIL expects external symbols.
• Ensure no custom code files providing those symbols are compiled in SIL (Simulation Target > Custom Code).

For in-depth understanding, please refer the MathWorks Documentation: https://www.mathworks.com/help/rtw/ug/choose-a-built-in-storage-class-for-controlling-data-representation-in-the-generated-code.html

Please note: One build = one implementing object file. Let xil own implementations in SIL, and your SCA layer own them in normal builds.

Hope this helps!

Thanks,

Samar