{"id":"2cd51ec6-5531-4afc-9ede-d260b31a17fe","arxiv_id":"2508.20223","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":5.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"Unmodified SystemC TLM target models can be automatically wrapped as FMI 3.0 FMUs and co-simulated with Simulink models using an open-source tool.","lead":"This paper presents an open-source toolchain that automatically wraps SystemC TLM hardware models into FMI 3.0 co-simulation units, so they can run alongside Simulink and other engineering tools. A generalist may care because this lowers a practical interoperability barrier in automotive cyber-physical system development.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Wrapper silently assumes every TLM transaction completes within one communication step; non-blocking or delayed responses yield stale outputs.","rationale":"The reader's weakest assumption precisely identifies the transaction-completion problem in fmi3DoStep. This is the most load-bearing issue because it directly threatens the paper's headline contribution: a non-intrusive, automated wrapper for arbitrary SystemC TLM models. If the wrapper silently corrupts results for common TLM behaviors like delayed or non-blocking transactions, the methodology is not generally applicable and the 'full compliance' claim is misleading. The paper presents two industrial case studies but does not report any test where a transaction spans multiple DoStep calls; both case studies apparently use simple payload structs and presumably complete within a single step. The internal inconsistency is visible in the code: Listing 6 unconditionally retrieves the result after sc_start, and the earlyReturn handling is only time bookkeeping. A concrete test with a delayed target would settle whether the wrapper detects the condition (e.g., by checking TLM completion status) or silently produces wrong data. This concern does not invalidate the demonstrated case studies, but it does confirm that the paper's general feasibility claim is conditional. The reader's verdict of CONDITIONAL is therefore appropriate; no adjustment is needed.","tokens_in":9934,"tokens_out":2393,"duration_ms":27302,"concrete_test":"Construct a minimal SystemC TLM target whose b_transport (or nb_transport_fw) intentionally waits longer than the configured communicationStepSize before producing the result. Wrap it with the proposed open-source tool, then co-simulate via FMPy using a step size smaller than that delay. Compare the FMU's output sequence to the native SystemC TLM simulation output. If the FMU reports stale or missing results without any FMI error, the concern is confirmed. Also inspect the generated initiator to verify whether nb_transport_bw callbacks are connected at all.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central feasibility claim — that unmodified SystemC TLM targets can be wrapped as FMI 3.0 FMUs with full standard compliance — rests on the correctness of fmi3DoStep in Listing 6. That function calls set_and_send, runs sc_start(step_size), and immediately calls retrieve_result (lines 10–15). This is only valid if every TLM transaction is completed and its result written back before sc_start returns. The paper's own prerequisites (Section III.A.1) state the target may implement nb_transport_fw, and the background describes non-blocking transport where responses arrive asynchronously via nb_transport_bw. Yet Listing 2 only demonstrates a blocking b_transport initiator, and neither the top-level module nor the wrapper implements any mechanism to wait for an asynchronous response. If a target uses non-blocking transport, wait states, or a blocking delay longer than communicationStepSize, retrieve_result reads the previous step's data_received, silently propagating stale values. The earlyReturn/lastSuccessfulTime logic (lines 17–21) only adjusts the recorded FMU time; it does not delay retrieval or extend sc_start to complete the transaction. Thus the methodology is not 'non-intrusive' and general for the class of TLM models it claims to support; it only works for targets that always respond within one FMI step, an unstated and untested constraint.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","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.","tokens_in":10228,"tokens_out":4869,"duration_ms":51094,"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":[{"comment":"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","section":"Section III.B.3, Listing 6"},{"comment":"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.","section":"Listing 6"},{"comment":"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.","section":"Section IV.A/IV.B, Tables II and III"},{"comment":"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.","section":"Abstract and Section IV.C"}],"minor_comments":[{"comment":"Typo: 'Y AML' should be 'YAML'.","section":"Section III.D"},{"comment":"Typo: 'invocate' should be 'invoke'.","section":"Section III.A.4"},{"comment":"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.","section":"Section IV.A"},{"comment":"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.","section":"Table I"},{"comment":"Typo: 'build around transaction level co-simulations' should be 'built around transaction-level co-simulations'.","section":"Section II.C"}],"recommendation":"major_revision","confidential_remarks":"The paper is a reasonable tools-and-methods contribution for a design and verification conference, and the open-source release is a plus. The main technical concern is the fmi3DoStep data-race/stale-data issue for non-blocking TLM transports, which should be addressed before acceptance. The performance comparison methodology and the overclaimed full FMI compliance also need attention, but these are fixable within the manuscript's scope."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Addresses a real gap: prior work either wraps plain SystemC with FMI 2.0 or adds an RTL-to-TLM translation stage. This is the first direct, automated wrapping of SystemC TLM targets into FMI 3.0 Co-Simulation FMUs. The tool is open-source, the two industrial case studies are genuine, and the Simulink co-simulation provides a solid end-to-end demonstration. The non-intrusive design—the target module is untouched, and the wrapper only instantiates an initiator and top-level—is clean and executed well.\n\nThe soft spots are real but not fatal. The most significant is the synchronization assumption in fmi3DoStep (Listing 6): it calls set_and_send, runs sc_start(step_size), then immediately retrieves the result. This only works if the TLM transaction completes within the communication step. The paper lists nb_transport_fw in its prerequisites but never demonstrates or handles asynchronous responses; the example initiator only uses b_transport. So a target with wait states, non-blocking transport, or a response arriving after the step would silently produce stale outputs. That means the method is not yet as general as the 'broad applicability' claim suggests.\n\nThe rest is smaller. The ECC performance text quotes 1.36x and 3.17x, but the table implies 1.14x and 4.17x; one of them is wrong. The 'full FMI compliance' statement is not backed by an official compliance checker, though FMPy and Simulink interop is decent evidence. And the performance numbers have no variance, with different profiling methods for the two versions.\n\nWho is this for? Practitioners building automotive co-simulation flows who need to connect SystemC TLM to the FMI ecosystem. It is an incremental engineering contribution, not a scientific breakthrough, but a useful one. The central feasibility claim holds up for the demonstrated class of models.\n\nI would send it to peer review, with a request to fix the ECC numbers, add variance or at least state the measurement method, and explicitly document the single-step transaction constraint. If the authors are honest about that limitation, the paper becomes a solid reference.","headline":"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.","tokens_in":10735,"tokens_out":5199,"would_cite":true,"duration_ms":47058,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"A non-intrusive, open-source method packages SystemC TLM components as FMI 3.0 co-simulation FMUs.","keywords":["SystemC TLM","FMI 3.0","Co-Simulation","Functional Mock-up Unit","Cyber-physical systems","Automotive virtual prototyping","Interoperability","Open-source toolchain"],"falsifier":"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.","tokens_in":9866,"feed_emoji":"🔌","tokens_out":6808,"duration_ms":72722,"temperature":0.7,"pith_summary":"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.","feed_headline":"Open-source tool wraps SystemC TLM as FMI 3.0 FMUs","feed_subtitle":"Chip-level TLM models co-simulate with car and control models through a standard interface—no source changes.","key_machinery":"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.","core_discovery":"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","pith_inferences":["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."],"forward_implications":["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."],"supporting_citations":[{"why":"FMI specification; defines the 3.0 Co-Simulation C-API and modelDescription.xml semantics the wrapper must implement.","marker":"[12]"},{"why":"IEEE SystemC language standard; supplies sc_start and the simulation kernel semantics the wrapper relies on for time advancement.","marker":"[9]"},{"why":"Earlier SystemC-as-FMU wrapping under FMI 2.0; the baseline that did not address TLM transactions.","marker":"[18]"},{"why":"Previous TLM-to-FMU approach that required translating RTL to TLM; the gap the new method removes.","marker":"[19]"},{"why":"OMSimulator, an FMI/TLM co-simulation tool without native SystemC TLM support; motivates the missing capability.","marker":"[20]"},{"why":"Open-source Python FMU simulation library used as the validation backend for the generated FMUs.","marker":"[24]"},{"why":"Tool used to export the vehicle-dynamics FMU for the cross-domain co-simulation test.","marker":"[28]"}],"fun_headline_variants":["Wrap SystemC TLM as FMI 3.0 FMUs automatically","Open-source bridge: SystemC TLM to FMI 3.0 co-sim","SystemC TLM meets FMI 3.0 with no source changes","Co-simulate chip and car models via FMI 3.0","Turn SystemC TLM into FMI 3.0 FMUs without edits"],"cache_read_input_tokens":2688,"weakest_assumption_plain":"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.","fun_headline_variants_meta":{"raw":{"variants":["Wrap SystemC TLM as FMI 3.0 FMUs automatically","Open-source bridge: SystemC TLM to FMI 3.0 co-sim","SystemC TLM meets FMI 3.0 with no source changes","Co-simulate chip and car models via FMI 3.0","Turn SystemC TLM into FMI 3.0 FMUs without edits"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000156,"raw_usage":{"total_tokens":1027,"prompt_tokens":692,"completion_tokens":335,"prompt_tokens_details":{"cached_tokens":256},"prompt_cache_hit_tokens":256,"prompt_cache_miss_tokens":436,"completion_tokens_details":{"reasoning_tokens":230}},"tokens_in":436,"tokens_out":335,"duration_ms":3277,"temperature":1.0,"reasoning_tokens":230,"cache_read_input_tokens":256,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-05T15:13:19.995555+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"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.","supporting_citations":[{"cited_title":"Modelica/FMI-standard: Specification of the functional mock- up interface (fmi),","cited_arxiv_id":null,"evidence_quote":"FMI specification; defines the 3.0 Co-Simulation C-API and modelDescription.xml semantics the wrapper must implement."},{"cited_title":"IEEE Standard for Standard SystemC Language Reference Manual,","cited_arxiv_id":null,"evidence_quote":"IEEE SystemC language standard; supplies sc_start and the simulation kernel semantics the wrapper relies on for time advancement."},{"cited_title":"Using SystemC cyber models in an FMI co-simulation environment: Results and proposed FMI enhancements,","cited_arxiv_id":null,"evidence_quote":"Earlier SystemC-as-FMU wrapping under FMI 2.0; the baseline that did not address TLM transactions."},{"cited_title":"Transaction-level functional mockup units for cyber-physical virtual platforms,","cited_arxiv_id":null,"evidence_quote":"Previous TLM-to-FMU approach that required translating RTL to TLM; the gap the new method removes."},{"cited_title":"OMSimulator - Integrated FMI and TLM-based Co- simulation with Composite Model Editing and SSP,","cited_arxiv_id":null,"evidence_quote":"OMSimulator, an FMI/TLM co-simulation tool without native SystemC TLM support; motivates the missing capability."},{"cited_title":"CATIA-Systems/FMPy: Simulate functional mockup units (FMUs) in python,","cited_arxiv_id":null,"evidence_quote":"Open-source Python FMU simulation library used as the validation backend for the generated FMUs."},{"cited_title":"Catia-Systems/FMIKit-Simulink,","cited_arxiv_id":null,"evidence_quote":"Tool used to export the vehicle-dynamics FMU for the cross-domain co-simulation test."}],"review_version":1}