Pith. sign in

REVIEW 4 major objections 5 minor 28 references

Integrating SystemC TLM into FMI 3.0 Co-Simulations with an Open-Source Approach

T0 review · 4 major / 5 minor · reviewed 2026-08-05 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read A non-intrusive, open-source method packages SystemC TLM components as FMI 3.0 co-simulation FMUs.

desk verdict Useful open-source tool that wraps unmodified SystemC TLM as FMI 3.0 FMUs; the generality claim needs a caveat about single-step transaction completion. read the letter →

arxiv 2508.20223 v1 pith:MKLRVKYE submitted 2025-08-27 cs.CL

Andrei Mihai Albu , Giovanni Pollo , Alessio Burrello , Daniele Jahier Pagliari , Cristian Tesconi , Alessandra Neri , Dario Soldi , Fabio Autieri
show 1 more author
Sara Vinco
This is my paper · ORCID
classification cs.CL
keywords SystemCTLMFMI3.0Co-SimulationFunctionalMock-upUnitCyber-physicalsystemsAutomotivevirtualprototypingInteroperabilityOpen-sourcetoolchain
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This paper tries to establish that the standard FMI 3.0 co-simulation interface can be used to wrap SystemC Transaction-Level Modeling (TLM) hardware components without changing their source code. It would matter because FMI is the common interchange for multi-domain vehicle and control co-simulation, while SystemC TLM is the standard way to simulate hardware and software at transaction level; today the two worlds barely connect. The authors build an automated, open-source pipeline that analyzes a TLM payload structure, generates a thin initiator and top-level bridge, maps fields to FMI variables, and packages the result as a compliant Functional Mock-up Unit. They validate the bridge on an I2C controller and an error-correction block, then show a wrapped SystemC TLM ECU driving a vehicle-dynamics FMU, demonstrating cross-domain interoperability. If the method holds, existing TLM peripheral models can be reused in co-simulations with control and plant models at the cost of moderate runtime and memory overhead.

What carries the argument

The load-bearing object is the auto-generated bridge: a top-level SystemC module with set_and_send and retrieve_result methods, plus a wrapper structure holding FMI variables and sc_time. fmi3DoStep is the synchronization point: it copies FMI inputs into the TLM payload, runs sc_start(step_size), retrieves outputs, and updates FMU time, including early-return handling.

What would settle it

Wrap a SystemC TLM target whose read transaction deliberately waits longer than communicationStepSize, run it through the proposed pipeline in a standard FMI 3.0 environment, and compare outputs to a native SystemC run; mismatched or lagging output values would show the synchronous fmi3DoStep assumption is false.

Watch

Extended reading notes

Core claim

The paper demonstrates that a SystemC TLM target module implementing b_transport or nb_transport_fw can be automatically wrapped as an FMI 3.0 Co-Simulation FMU without source modification. The wrapper generates a top-level module and an initiator, maps TLM payload struct fields to FMI variables via modelDescription.xml, and uses fmi3DoStep to call sc_start(step_size), so the SystemC kernel advances synchronously with the FMI master. Validation on an I2C controller and an ECC block shows correct behavior with moderate runtime overhead, and a SystemC TLM ECU co-simulated with a vehicle plant FMU over 35 seconds demonstrates that the generated FMUs interoperate with FMUs from other modeling en

Load-bearing premise

The whole approach assumes every hardware transaction started during a simulation step finishes and produces its answer before that step ends; if a component waits several cycles or answers later, the co-simulation would read stale data without warning.

Editorial extensions

If this is right

  • Existing, unmodified SystemC TLM target modules become reusable as standard FMI 3.0 FMUs, so hardware and software models can join control and plant co-simulations.
  • Co-simulation masters can run the generated FMU with a different step size than other FMUs; the demonstrated 0.1 s versus 1 s mismatch still produced correct coupled behavior.
  • FMU-based execution adds overhead that grows with the number of steps, roughly 1x to 10x for the I2C case and 1.4x to 3.2x for the ECC case, while memory overhead stays roughly flat at about 14x to 22x.
  • The generated FMUs are platform-specific shared libraries that run in any FMI-compliant environment, not only the Python-based one used for validation.
  • Early-return and interrupt-like behavior is handled by advancing FMI time with lastSuccessfulTime rather than the nominal step size.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • A natural next test is wrapping an initiator TLM module, a bus master, instead of a target; the paper says this is straightforward future work, and the same bridge pattern would likely let FMI inputs initiate transactions.
  • The regex-based parser will probably need a real C++ front end once payload structs contain nested structs, arrays, or templated SystemC types; feeding such a design to the tool would immediately reveal the limit.
  • The single-step synchronous assumption in fmi3DoStep is the main risk: a target that responds after a delay would need a timeout or a non-blocking handshake to avoid silently returning stale data.
  • Because memory overhead is dominated by the co-simulation runtime, a C-API master or direct in-process invocation may cut the slowdown more than optimizing the wrapper itself.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 5 minor

Summary. The paper presents an open-source methodology and toolchain for automatically wrapping SystemC TLM target modules as FMI 3.0 Co-Simulation FMUs. The approach analyzes the TLM payload struct, generates a top-level module and an initiator, implements the FMI C-API, and packages the result as a platform-specific FMU. The authors demonstrate the workflow on two industrial SystemC TLM designs (I2C and ECC) and a co-simulation between a generated SystemC TLM ECU FMU and a Simulink vehicle FMU exported with FMIKit, all orchestrated with FMPy. The central claim is that the integration is non-intrusive, automated, and achieves full FMI 3.0 standard compliance.

Significance. If the approach is correct, it fills a practical gap: SystemC TLM models are typically isolated from the FMI/co-simulation ecosystem, and the open-source tool (github.com/eml-eda/systemc-fmi) with no fitted parameters and external validation against FMPy and FMIKit is a valuable contribution. The paper's emphasis on reusing unmodified TLM targets and its automation pipeline are strengths. However, the significance is currently tempered by a load-bearing correctness gap in the fmi3DoStep implementation and by overclaimed standard compliance.

major comments (4)
  1. [Section III.B.3, Listing 6] fmi3DoStep calls set_and_send, sc_start(step_size), then retrieve_result immediately. This is only correct if every TLM transaction triggered by set_and_send completes within communicationStepSize and writes its result before sc_start returns. However, Section III.A.1 explicitly permits targets implementing nb_transport_fw, and Section II.A describes non-blocking transport where responses arrive asynchronously via nb_transport_bw. The wrapper contains no mechanism to wait for such a callback or to extend sc_start until transaction completion. For non-blocking targets, wait states, or blocking delays longer than the step size, retrieve_result reads the previous step's data, silently producing wrong co-simulation results. The earlyReturn/lastSuccessfulTime logic (lines 17-21) only adjusts the recorded FMU time; it does not delay data retrieval. This undermines the claimed generality and no
  2. [Listing 6] fmi3DoStep dereferences the output parameters earlyReturn and lastSuccessfulTime without initializing them. In the FMI 3.0 API, the FMU is responsible for setting these outputs. As written, the function reads an uninitialized *earlyReturn and, if that value happens to be true, an uninitialized *lastSuccessfulTime. This can lead to undefined behavior and incorrect time advancement. The function must set *earlyReturn = fmi3False at entry (or assign the correct value when returning early) and likewise set *lastSuccessfulTime only after an early return. This should be corrected and tested in both normal and early-return scenarios.
  3. [Section IV.A/IV.B, Tables II and III] Performance and memory overhead are central to the practicality claim, but the reported numbers are averages over five runs with no variance (standard deviation, min/max) and the two configurations are measured with different profiling methods: the TLM runs use a dedicated C++ profiling framework, while the FMU runs are monitored in Python via psutil. Differences in sampling overhead and measurement technique make the reported comparisons (e.g., 10x overhead for I2C at 10,000 steps) difficult to interpret. Please report all runs or at least variance, use the same measurement method for both configurations, and describe the host platform and tool versions.
  4. [Abstract and Section IV.C] The claim of 'full FMI standard compliance' is asserted based on successful execution with FMPy and a Simulink FMU exported via FMIKit. While these are encouraging interoperability results, they do not establish full compliance with the FMI 3.0 specification, which is a large API surface with mandatory and optional functions. Run the official FMI Compliance Checker on the generated FMUs or provide a detailed conformance statement, and soften the wording to 'interoperates with the tested FMI environments' unless full compliance is formally verified.
minor comments (5)
  1. [Section III.D] Typo: 'Y AML' should be 'YAML'.
  2. [Section III.A.4] Typo: 'invocate' should be 'invoke'.
  3. [Section IV.A] The reference to 'fig. 1.C' is unclear; Figure 1 does not appear to show a Software-in-the-Loop environment. Please correct the reference or add the figure.
  4. [Table I] The I2C case study includes enumerative types, but Table I does not specify how SystemC enumeration types are mapped to FMI variables. Also, sc_logic is a 4-valued type; mapping it to fmi3Bool loses Z/X states. Document these semantic choices.
  5. [Section II.C] Typo: 'build around transaction level co-simulations' should be 'built around transaction-level co-simulations'.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the paper's feasibility claim is supported by external validation, with no fitted inputs, no predictions-by-construction, and no load-bearing self-citation.

full rationale

The paper makes no derived quantitative predictions from fitted parameters. Its central claim is that unmodified SystemC TLM targets can be wrapped as FMI 3.0 Co-Simulation FMUs using an open-source automated tool. The supporting evidence is external: the generated FMUs are executed in FMPy and co-simulated against a Simulink FMU exported via FMIKit, i.e., validated against independent FMI tooling rather than against the authors' own prior results. The methodology's mapping from SystemC types to FMI types (Table I) and the wrapper code (Listings 2, 3, 5, 6) are explicit and self-contained; there is no equation that reduces to an input or a parameter that is fitted then renamed as a prediction. Citations of prior work ([18], [19], [22], [23]) are contextual related-work descriptions, not load-bearing justifications for the present result, and none is authored by the current paper's authors in a way that imports an unverified uniqueness theorem or ansatz. The skeptical concern about non-blocking TLM transactions possibly not completing within one communication step is a correctness limitation of the proposed wrapper, not a circularity: the paper asserts and demonstrates its approach on blocking, single-step-completing targets (I2C, ECC, ECU), and that assumption is not the same as the conclusion being derived from itself. Therefore no circular step can be exhibited, and the honest finding is a score of 0.

Assumptions & free parameters 0 free parameters · 3 assumptions · 0 invented entities

The method introduces no free parameters (CommunicationStepSize is a user input, not a fitted constant) and no new physical or conceptual entities; the initiator, top-level, and wrapper are generated software glue. The three axioms bound the method to target-style TLM designs with flattenable payloads and synchronous transaction completion.

assumptions (3)
  • domain assumption The SystemC TLM code is a target module implementing b_transport and nb_transport_fw.
    Stated as a design prerequisite in Section III-A1; if false, the generated initiator and top-level cannot drive the model.
  • domain assumption The TLM payload data field is a plain struct of basic SystemC types mappable to FMI variables.
    The parser extracts struct fields and Table I maps only scalar and binary SystemC types; pointers, dynamic containers, or complex protocol state fall outside the method.
  • domain assumption Each fmi3DoStep corresponds to one transaction that completes within the communication step.
    Listing 6 retrieves the output immediately after sc_start(step_size) without waiting for transaction completion; delayed or asynchronous responses would break output collection.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Integrating SystemC TLM into FMI 3.0 Co-Simulations with an Open-Source Approach." pith.science (2026). https://pith.science/paper/MKLRVKYE

@misc{pith2026250820223,
  author       = {Pith},
  title        = {Pith review of: Integrating SystemC TLM into FMI 3.0 Co-Simulations with an Open-Source Approach},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/MKLRVKYE}},
  note         = {Machine review of arXiv:2508.20223}
}
read the original abstract

The growing complexity of cyber-physical systems, particularly in automotive applications, has increased the demand for efficient modeling and cross-domain co-simulation techniques. While SystemC Transaction-Level Modeling (TLM) enables effective hardware/software co-design, its limited interoperability with models from other engineering domains poses integration challenges. This paper presents a fully open-source methodology for integrating SystemC TLM models into Functional Mock-up Interface (FMI)-based co-simulation workflows. By encapsulating SystemC TLM components as FMI 3.0 Co Simulation Functional Mock-up Units (FMUs), the proposed approach facilitates seamless, standardized integration across heterogeneous simulation environments. We introduce a lightweight open-source toolchain, address key technical challenges such as time synchronization and data exchange, and demonstrate the feasibility and effectiveness of the integration through representative case studies.

Figures

Figures reproduced from arXiv: 2508.20223 by the authors.

Figure 1
Figure 1. High-level overview of the proposed workflow [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. Simulink model of a single-pedal electric vehicle [PITH_FULL_IMAGE:figures/full_fig_p006_2.png] view at source ↗
Figure 3
Figure 3. Cosimulation of the SystemC TLM ECU with the Simulink model in [PITH_FULL_IMAGE:figures/full_fig_p006_3.png] view at source ↗

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

28 extracted references · 28 canonical work pages

  1. [1]

    Co-simulation framework for design of time-triggered cyber physical systems,

    Z. Zhang et al. , “Co-simulation framework for design of time-triggered cyber physical systems,” Simulation Modelling Practice and Theory , vol. 43, p. 16–33, 04 2014

    work page 2014

  2. [2]

    Embedded system design: Modeling, synthesis, and verifi- cation,

    G. Martin, “Embedded system design: Modeling, synthesis, and verifi- cation,” Design & Test of Computers, IEEE , vol. 27, pp. 82 – 83, 05 2010

    work page 2010

  3. [3]

    High-level synthesis: Past, present, and future,

    G. Martin and G. Smith, “High-level synthesis: Past, present, and future,” IEEE Design & Test of Computers , vol. 26, no. 4, pp. 18–25, 2009

    work page 2009

  4. [4]

    A systematic mapping study on SystemC/TLM modeling capabilities in new research domains,

    A. Mahmoudi et al. , “A systematic mapping study on SystemC/TLM modeling capabilities in new research domains,” ACM Transactions on Design Automation of Electronic Systems , vol. 30, no. 4, Jun. 2025

    work page 2025

  5. [5]

    P. A. Fritzson, Principles of object-oriented modeling and simulation with modelica 3.3, 2nd ed. Nashville, TN: John Wiley & Sons, Nov. 2014

    work page 2014

  6. [6]

    FMI-based co-simulation of hybrid closed-loop control system models,

    E. Widl et al. , “FMI-based co-simulation of hybrid closed-loop control system models,” in Proc. of ICCSE , 2015, pp. 1–6

    work page 2015

  7. [7]

    Modeling and simulation of automotive FMCW RADAR sensor for environmental perception,

    A. Haider et al. , “Modeling and simulation of automotive FMCW RADAR sensor for environmental perception,” IEEE Open Journal of Intelligent Transportation Systems, vol. 6, pp. 433–455, 2025

    work page 2025

  8. [8]

    Multiphysics modeling and co-simulation of ship electric power and propulsion systems for virtual testing and ver- ification,

    F. Perabo and M. Zadeh, “Multiphysics modeling and co-simulation of ship electric power and propulsion systems for virtual testing and ver- ification,” IEEE Transactions on Transportation Electrification , vol. 11, no. 1, pp. 5108–5121, 2025

    work page 2025

Show all 28 references
  1. [9]

    IEEE Standard for Standard SystemC Language Reference Manual,

    “IEEE Standard for Standard SystemC Language Reference Manual,” IEEE Std 1666-2023 (Revision of IEEE Std 1666-2011) , pp. 1–618, 2023

    2023

  2. [10]

    accellera.org,

    “accellera.org,” https://www.accellera.org, July 2009

    2009

  3. [11]

    Gr ¨otker et al., System Design with SystemC

    T. Gr ¨otker et al., System Design with SystemC . Springer, 01 2002

    2002

  4. [12]

    Modelica/FMI-standard: Specification of the functional mock- up interface (fmi),

    Modelica, “Modelica/FMI-standard: Specification of the functional mock- up interface (fmi),” https://fmi-standard.org/

  5. [13]

    The FMI 3.0 standard interface for clocked and scheduled simulations,

    S. Hansen et al. , “The FMI 3.0 standard interface for clocked and scheduled simulations,” Electronics, vol. 11, p. 3635, 11 2022

    2022

  6. [14]

    Silver: Software in the loop for virtual ecus — syn- opsys,

    Synopsys, “Silver: Software in the loop for virtual ecus — syn- opsys,” https://www.synopsys.com/verification/virtual-prototyping/silver. html#features, 2025

    2025

  7. [15]

    Altair twin,

    Altair, “Altair twin,” https://altair.com/twin-activate, 2025

    2025

  8. [16]

    Simcenter amesim,

    Siemens, “Simcenter amesim,” https://plm.sw.siemens.com/en-US/ simcenter/systems-simulation/amesim/, 2025

    2025

  9. [17]

    Beamng.tech,

    BeamNG, “Beamng.tech,” https://beamng.tech/, 2025

    2025

  10. [18]

    Using SystemC cyber models in an FMI co-simulation environment: Results and proposed FMI enhancements,

    S. Centomo et al., “Using SystemC cyber models in an FMI co-simulation environment: Results and proposed FMI enhancements,” in Proc. of Euromicro DSD, 2016, pp. 318–325

    2016

  11. [19]

    Transaction-level functional mockup units for cyber-physical virtual platforms,

    ——, “Transaction-level functional mockup units for cyber-physical virtual platforms,” in Proc. of FDL , 2018, pp. 5–8

    2018

  12. [20]

    OMSimulator - Integrated FMI and TLM-based Co- simulation with Composite Model Editing and SSP,

    L. Ochel et al. , “OMSimulator - Integrated FMI and TLM-based Co- simulation with Composite Model Editing and SSP,” in International Modelica Conference, 02 2019, pp. 69–78

    2019

  13. [21]

    Openmodelica,

    Open Source Modelica Consortium, “Openmodelica,” https: //openmodelica.org/

  14. [22]

    Fast virtual prototyping of cyber-physical systems using SystemC and FMI: ADAS use case,

    S. E. Saidi et al. , “Fast virtual prototyping of cyber-physical systems using SystemC and FMI: ADAS use case,” 10 2019, pp. 43–49

    2019

  15. [23]

    VCML Virtual Platform: Open-Source SystemC TLM-2.0 Library - machine-ware.de — machineware.de,

    “VCML Virtual Platform: Open-Source SystemC TLM-2.0 Library - machine-ware.de — machineware.de,” https://www.machineware.de/ products/vcml-virtual-platform, 2025

    2025

  16. [24]

    CATIA-Systems/FMPy: Simulate functional mockup units (FMUs) in python,

    “CATIA-Systems/FMPy: Simulate functional mockup units (FMUs) in python,” https://github.com/CATIA-Systems/FMPy

  17. [25]

    Available: https://github.com/giampaolo/psutil

    psutil, “psutil.” [Online]. Available: https://github.com/giampaolo/psutil

  18. [26]

    Group, “Silsim,” https://www.dumarey.com/solution/ virtual-prototyping/, 2025

    D. Group, “Silsim,” https://www.dumarey.com/solution/ virtual-prototyping/, 2025

    2025

  19. [27]

    Driving towards safety: The role of ECUs and IMUs in advanced driver-assistance systems (ADAS),

    A. Tadimarri et al., “Driving towards safety: The role of ECUs and IMUs in advanced driver-assistance systems (ADAS),” International Journal For Multidisciplinary Research, vol. 6, 04 2024

    2024

  20. [28]

    Catia-Systems/FMIKit-Simulink,

    T. Sommer et al., “Catia-Systems/FMIKit-Simulink,” https://github.com/ CATIA-Systems/FMIKit-Simulink, 2024

    2024

Pith tools

Reviewed August 5, 2026 · model on record in the stance chip above.