{"id":"d304759b-f7f0-4638-812c-348fef5e0025","arxiv_id":"2508.19665","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":5.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":1,"one_line_summary":"An automated open-source framework wraps SystemC RTL models as FMI 3.0 Functional Mock-up Units, with step, intermediate-update, and interrupt-driven execution modes.","lead":"This paper describes an automated tool that wraps SystemC hardware models as Functional Mock-up Units, so they can run in FMI-based co-simulation environments. It tests the tool on five designs, including industrial ones, and measures how much slower and memory-hungry the wrapped models are.","discovery_kind":"extension","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Central 'all RTL designs' claim breaks for sc_logic/sc_lv top-level ports: Table II maps four-valued sc_logic to two-valued fmi3Bool, losing X/Z states, so tri-state RTL designs such as the I2C case study cannot be faithfully wrapped without modification.","rationale":"The reader's verdict is CONDITIONAL, and this stress-test reinforces that condition: the framework may be genuinely useful for the five demonstrated designs, but the universal 'no limitation / all RTL designs / no accuracy impact' claim is undermined by a concrete, internal technical fact. The four-valued sc_logic mapping to fmi3Bool in Table II is not a matter of disagreement with external consensus; it is a lossy encoding that conflicts with the paper's own assertion that simulation accuracy is preserved. A single supported-but-unfaithfully-wrapped port type is enough to invalidate an 'any design' claim, even if every tested case happens to avoid tri-state top-level ports or fails to exercise X/Z states. The proposed check is minimal and directly executable because the repository and the I2C source are public. The paper's other weaknesses, such as the absence of output-equivalence verification and the dependence on FMI 3.0 EventMode support in the master, are real but secondary; the type-fidelity issue is more load-bearing because it is a definite limitation of the described mechanism rather than a missing measurement. I do not recommend rejecting the paper: the pipeline, case studies, and performance measurements give credible evidence that the approach works within its actual, narrower scope. The verdict should remain CONDITIONAL, with the condition being that the authors either explicitly restrict the supported top-level types to those representable losslessly in FMI 3.0 (e.g., no sc_logic/sc_lv unless encoded, including X/Z) or modify the mapping and demonstrate equivalence on tri-state designs.","tokens_in":12368,"tokens_out":7294,"duration_ms":92341,"concrete_test":"Re-wrap the public I2C model referenced as [32] (or a minimal SystemC design with a top-level sc_inout<sc_logic> port) using the released automation framework. Then drive identical stimulus sequences, including a bus-contention/high-Z scenario, into both the native SystemC model and the generated FMU under FMPy, and compare SDA/SCL waveforms and output values cycle-by-cycle. If the generated modelDescription.xml maps the sc_logic port to fmi3Bool, the Z/X state is lost and the FMU's behavior will diverge from native SystemC; if the I2C model happens not to expose tri-state lines at the top level, the same test on a minimal sc_inout<sc_logic> design will still settle whether the 'all RTL designs' claim holds.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The paper's central claim is that the methodology imposes no limitation on SystemC RTL designs and preserves simulation behavior without source modification. A concrete counterexample is the port-type mapping in Table II: sc_logic is mapped to fmi3Bool. SystemC sc_logic (and sc_lv) is a four-valued type with states 0, 1, X, and Z; FMI 3.0 Boolean has only true/false. Therefore any top-level port of type sc_in<sc_logic>, sc_inout<sc_logic>, or sc_in<sc_lv<N>> cannot be represented losslessly. In particular, tri-state buses—ubiquitous in RTL and explicitly present in the I2C case study as bidirectional SDA/SCL lines with 'tri-state control for arbitration'—cannot be faithfully exchanged through an fmi3Bool variable: high-impedance (Z) and unknown (X) states are silently coerced to Boolean values. The paper's assertion that 'any SystemC version and any design for which the source code is accessible can be directly integrated' is thus not supported by the described type mapping. This is not merely a question of coverage breadth; it is an internal inconsistency between the claimed preservation of simulation accuracy and the actual FMI type system used. The I2C case study is especially relevant because its protocol correctness relies on arbitration through tri-state behavior; if the FMU's top-level ports are sc_logic, the generated FMU cannot reproduce native SystemC behavior under bus contention. The paper also never compares output traces between native SystemC and the FMU in Table III, so even the five evaluated designs are only shown to run, not to produce equivalent results.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper presents a framework for automatically wrapping SystemC RTL designs as Functional Mock-up Units (FMUs) conforming to FMI 3.0, with the goal of enabling standardized co-simulation in Software-defined Vehicle design flows. The methodology parses the top-level SystemC interface, generates FMI glue code and a modelDescription.xml, compiles and packages the result as an FMU, and drives simulation through a master such as FMPy. Three execution modes are discussed: fixed-step, intermediate update, and interrupt-driven (using FMI EventMode). The approach is validated on five case studies (ALU, CRC, I2C, RISC processor, Delta-Sigma modulator), reporting execution-time slowdown and memory overhead relative to native SystemC. The paper claims the methodology imposes no limitation on SystemC RTL designs, preserves simulation behavior without source modification, and supports any SystemC version and any design with accessible source code.","tokens_in":12641,"tokens_out":3140,"duration_ms":39297,"significance":"If the central claim holds, the framework would be a useful open-source contribution: it addresses a real gap in co-simulation tooling, demonstrates FMI 3.0 support including EventMode, and evaluates on heterogeneous case studies including an industrial CRC and a Delta-Sigma modulator. The authors' decision to release the automation framework and to emphasize non-invasive wrapping is a strength. However, the significance is bounded by two issues: the type-mapping table is lossy for standard SystemC logic types, and the experimental section never verifies functional equivalence between native SystemC and the generated FMU. These are not cosmetic concerns; they affect whether the framework can be used with the broad class of RTL designs the paper claims to support.","major_comments":[{"comment":"The claim in §III-B that the methodology 'supports all designs written in SystemC at the RTL level' and preserves simulation behavior is internally contradicted by Table II. sc_logic is mapped to fmi3Bool, but sc_logic is a four-valued type (0, 1, X, Z) and sc_lv<N> is likewise four-valued per bit; FMI 3.0 Boolean has only two states. Any top-level port of type sc_in<sc_logic>, sc_inout<sc_logic>, or sc_in<sc_lv<N>> therefore cannot be represented losslessly. This is not a hypothetical edge case: tri-state buses are common in RTL, and the paper's own I2C case study (§IV-C) explicitly describes SDA and SCL as managed with 'tri-state control for arbitration'. If those ports are exposed at the FMU top level as sc_logic, bus contention and high-impedance states cannot be faithfully exchanged through an fmi3Bool variable. The authors should either restrict the scope claim to designs whose top","section":"§III-B, Table II"},{"comment":"The experimental evaluation reports only execution time and memory usage; no comparison of output signals or behavior between native SystemC and the wrapped FMU is provided. The conclusion (Section V) states that the approach avoids 'any negative impact on simulation accuracy and effectiveness', but nowhere do the experiments test whether the FMU produces the same results as the native design. This is load-bearing: a wrapper that is fast but functionally incorrect would not validate the method. For each case study there are natural equivalence checks — CRC vectors, I2C transaction traces and arbitration behavior, RISC instruction retirement, Delta-Sigma bitstreams — and at least one such check should be reported, along with any tolerance used.","section":"§IV, Table III"},{"comment":"The quantitative claims rest on averages of five runs with no variance, confidence intervals, or run-to-run spread. Given that the reported slowdown factors are sometimes close (e.g., ALU 15.98× at 100 ms vs 15.16× at 1 s, or RISC 11.78× vs 12.34×), the absence of dispersion measures makes it impossible to judge whether differences are meaningful. The same applies to memory overhead. Reporting standard deviations (or min/max) over the five runs would materially strengthen the performance assessment and is a straightforward addition.","section":"§IV, Table III"},{"comment":"The asynchronous interrupt mechanism relies on FMI 3.0 EventMode being implemented by the master. The experiments use only FMPy, and the paper does not demonstrate that the generated FMU works with other FMI 3.0 masters that claim EventMode support, nor does it state whether FMPy's EventMode support is complete. Since one of the stated advantages is tool independence, the dependency of the interrupt feature on a specific master capability should be made explicit and ideally validated with at least one additional master or by clearly labeling the feature as master-dependent.","section":"§III-D.c, §IV-C"}],"minor_comments":[{"comment":"Typographical and formatting issues: 'wrappped' (§III-B), 'as a mean' (§I), 'analize' (§V), 'Y AML' (§III-F), and the duplicate/erroneous 'Caption' in Figure 4. The table in Section III-C refers to 'Section II' for port mappings, but the mapping is in Section III-C; the cross-reference is wrong.","section":"Throughout"},{"comment":"The figures are described in the text but are hard to read from the captions alone. In particular, the dashed/solid annotation and the meaning of the labeled time intervals (e.g., '20ms step' in Figure 3) should be expanded so the reader does not need to infer the protocol from the prose.","section":"Figure 2 and Figure 3"},{"comment":"The RISC case study says instructions execute 'per millisecond' and 'one instruction per millisecond'. This is presumably a modeling timescale, but it reads oddly for an RTL design; please clarify the intended clock/instruction timing.","section":"§IV-D"},{"comment":"The I2C description mentions 'NACKsignal' without stating its type or whether it is an output, an interrupt line, or both; given the EventMode discussion, a precise port list would help the reader connect the type-mapping discussion to the experiment.","section":"§IV-C"}],"recommendation":"major_revision","confidential_remarks":"The central claim of universal RTL support is broader than the evidence and the type system allow. The lossy sc_logic-to-fmi3Bool mapping is a concrete, load-bearing counterexample, and the I2C case study — which the paper itself highlights for tri-state arbitration — makes the issue particularly salient. I do not think this requires rejection; the framework appears to work on the presented examples, and the problem can be fixed by qualifying the scope, adding functional equivalence checks, and reporting variance. I would ask the authors to compare output traces for at least the I2C and CRC cases in the revision. The paper's fit for FDL is good; with those changes it could be a solid short-paper contribution."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"The thing you should know: this is a practical engineering paper with a real artifact. It automates wrapping SystemC RTL designs as FMI 3.0 FMUs, including step, intermediate-update, and EventMode interrupt handling, and the code is on GitHub. That is a solid increment over prior FMI 1.0/2.0 wrappers, which mostly required proprietary tools or manual glue. Five case studies (ALU, CRC, I2C, RISC processor, Delta-Sigma) run end-to-end, and the reported slowdown/memory trends are plausible: fixed initialization overhead dominates short runs and amortizes on longer ones.\n\nThe soft spots are real, though not fatal. First, the paper never checks that FMU outputs match native SystemC. Table III only reports time and memory. For a wrapper whose point is behavioral equivalence, the absence of trace comparison is a genuine gap. Second, the \"supports all RTL designs\" claim is too strong and, more seriously, inconsistent with Table II. SystemC sc_logic and sc_lv are four-valued (0, 1, X, Z); Table II maps sc_logic to fmi3Bool, which is two-valued. So a top-level tri-state port cannot be represented faithfully. That is not a corner case: the I2C case study explicitly uses bidirectional SDA/SCL lines with tri-state arbitration, so if those top-level ports are sc_logic, the generated FMU cannot preserve native behavior under contention. The paper does not discuss this. Third, results are averages over five runs without variance; acceptable for a tool paper, but not enough to support the 'enhanced reliability' wording.\n\nOn the positive side, the central mechanism—embedding the SystemC simulation kernel inside the FMU and driving it via sc_start, sc_pause, and sc_spawn—is clearly described and seems to work for the demonstrated designs. The EventMode interrupt handling is a genuine novelty over the cited prior work, and the open-source automation pipeline is a credible contribution to the co-simulation community.\n\nThe paper deserves a serious referee. The authors should be pushed to add output-equivalence checks, report variance, narrow the scope claim to designs whose top-level ports are losslessly mappable, and address the X/Z problem explicitly. As it stands, it is a useful tool paper with an overstated generality claim.\n\nThe reader's conditional verdict is the right one. I'd bring it to a reading group focused on FMI or SystemC co-simulation, and I'd cite it as related work in that space. Send it to peer review, expecting moderate revision rather than acceptance as-is.","headline":"Useful open-source SystemC-to-FMI 3.0 wrapper with genuine EventMode support, but the universal claim breaks on four-valued sc_logic ports and the evaluation never checks output equivalence.","tokens_in":13270,"tokens_out":2015,"would_cite":true,"duration_ms":23210,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"Any SystemC RTL design with a top-level port list and accessible source can be turned automatically into an FMI 3.0 Functional Mock-up Unit, with no design changes, and the flow is demonstrated on five case studies.","keywords":["Functional Mock-up Interface","SystemC","co-simulation","software-defined vehicles","hardware-software co-design","register-transfer level","FMU generation","event-driven simulation"],"falsifier":"Take a SystemC RTL design whose top-level interface includes a type not in the paper's mapping table (e.g. sc_in<sc_lv<8>> or an sc_vector of ports) and run the automatic flow: if parsing fails, the FMU cannot be loaded, or fmi3Get returns wrong values, the 'supports all designs' claim fails. A second check: drive the interrupt example with an FMI master that does not implement FMI 3.0 EventMode and see whether the asynchronous interrupt handling path is exercised at all.","tokens_in":12212,"feed_emoji":"🚗","tokens_out":8019,"duration_ms":76682,"temperature":0.7,"pith_summary":"The paper claims that any SystemC model written at register-transfer level, as long as its top-level has input/output ports and its source is available, can be turned into an FMI 3.0 Functional Mock-up Unit automatically and without changing a line of the model. The wrapper generates a standard modelDescription.xml, maps each SystemC port to an FMI variable type, implements the FMI callback functions, and drives the embedded SystemC kernel through sc_start/sc_pause so that co-simulation masters can step and read the hardware model like any other FMU. The value is interoperability with IP protection: a hardware design can be handed to a third party as a binary FMU and still co-simulate with software and system tools. Five case studies — an ALU, a CRC engine, an I2C controller, a RISC processor, and a delta-sigma modulator — show slowdown between about 1.1x and 16x and memory overhead around 18x–28x depending on design and simulation length. The main caveat is that interrupt-driven execution in FMI Event Mode requires an FMI master that actually implements EventMode; a step-size-limited fallback handles synchronous interrupts without touching the design.","feed_headline":"Automatic wrapper turns SystemC RTL into FMI co-simulation units","feed_subtitle":"Five real designs - ALU, CRC, I2C, RISC, delta-sigma - use it with no source edits for IP-safe co-simulation.","key_machinery":"The load-bearing object is the generated wrapper container: a struct holding one FMI variable and one same-type SystemC signal per top-level port, plus a reference to the instantiated top-level entity. The signals bind the ports (as SystemC requires), and the FMI variables are written by fmi3SetXXX and read by fmi3GetXXX. Time control is the second mechanism: fmi3DoStep advances the embedded SystemC kernel with sc_start for one communication interval, optionally shrinking the interval for intermediate updates. Interrupt handling is the third: an sc_spawn-ed dynamic process watches for a condition (e.g. rising edge), enters FMI EventMode, calls sc_pause to break out of the step, runs the ISR,","core_discovery":"Any SystemC RTL design with a top-level port list and accessible source is claimed to wrap automatically as an FMI 3.0 FMU, with no model changes. Parsing extracts ports; a table maps each SystemC/C++ type to an FMI variable; generated glue implements the FMI callbacks; compilation and packaging produce the .fmu. Each port is bound to a same-type SystemC signal and mirrored in an FMI variable, so fmi3DoStep can call sc_start(step) and exchange values. For interrupts, an sc_spawn-ed monitor detects a condition, enters EventMode, calls sc_pause, runs the ISR, and resumes; an alternative polls signals at step boundaries. Five designs — ALU, CRC, I2C, RISC, delta-sigma — run through a Python-bas","pith_inferences":["The 'any design' claim is really a claim about the top-level interface: models using signal types outside the mapping table (e.g. custom interfaces, sc_vector, non-standard widths) will need new table rows, so the immediately wrappable set is wider than prior work but not literally unbounded.","The same wrapper logic should apply to SystemC designs outside automotive, such as networking, IoT, or digital signal processing; wrapping a non-automotive open-source model would be a cheap test of generality.","The measured memory overhead is dominated by the Python-based master and FMI runtime, so a C++ master could plausibly cut both slowdown and memory; the paper does not test that comparison.","If the EventMode monitor were extended to react to asynchronous events injected by the master, the approach could serve as a general discrete-event-to-FMI bridge beyond the interrupt scenario shown."],"forward_implications":["Any SystemC RTL block can be dropped into FMI 3.0 co-simulation workflows, so hardware models participate in the same standardized master environment as Modelica or Simulink models.","A hardware vendor can ship a compiled FMU instead of RTL source, giving the integrator simulation capability without exposing the design.","Because the wrapper does not touch the SystemC design, the same codebase remains valid for native SystemC simulation; only the FMU packaging is added.","Long-running or computation-heavy designs amortize the fixed FMI overhead (slowdown falls toward about 1.1x at 10 s), making the wrapper practical for vehicle-level simulations.","Interrupt-driven SystemC blocks can be co-simulated with full fidelity only when the FMI master implements EventMode; synchronous interrupts can be handled without it at step-size-limited accuracy."],"supporting_citations":[{"why":"Defines the FMI 3.0 interface, FMU archive layout, and Step/Event modes being implemented.","marker":"[10]"},{"why":"Defines the SystemC kernel, sc_start/sc_pause/sc_spawn primitives, and port/data types used by the wrapper.","marker":"[12]"},{"why":"Earliest SystemC-to-FMI bridge without interrupt support; the paper's baseline to extend.","marker":"[20]"},{"why":"Prior SystemC-FMI integration requiring a proprietary virtual-prototype tool, the dependency the flow removes.","marker":"[21]"},{"why":"Prior SystemC/AMS-to-FMU method requiring non-standard external functions, contrasted with the non-invasive flow.","marker":"[22]"},{"why":"Prior approach needing modifications inside the SystemC design, directly contrasted with the no-modification claim.","marker":"[23]"},{"why":"Prior CPS co-simulation tied to a particular virtual-prototyping environment, illustrating the portability gap.","marker":"[24]"},{"why":"Python-based FMU simulation library used as the FMI master in all experiments.","marker":"[28]"},{"why":"Open-source I2C model used as a hierarchical case study exercising interrupt handling.","marker":"[32]"},{"why":"Open-source pipelined processor model used as a hierarchy/computation case study.","marker":"[33]"}],"fun_headline_variants":["Auto-wrap SystemC to FMI co-sim with zero edits","SystemC to FMI: automatic wrapper, no model changes","Wrap SystemC RTL as FMI 3.0 FMUs automatically","SystemC models become FMI units without manual work"],"cache_read_input_tokens":2688,"weakest_assumption_plain":"The universal claim depends on the premise that every RTL SystemC design can be embedded as a library and stepped externally with sc_start/sc_pause without design-specific adaptation, which the paper demonstrates on five designs; interrupt fidelity also assumes an FMI master that actually implements EventMode.","fun_headline_variants_meta":{"raw":{"variants":["Auto-wrap SystemC to FMI co-sim with zero edits","SystemC to FMI: automatic wrapper, no model changes","Wrap SystemC RTL as FMI 3.0 FMUs automatically","SystemC models become FMI units without manual work"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000195,"raw_usage":{"total_tokens":1163,"prompt_tokens":685,"completion_tokens":478,"prompt_tokens_details":{"cached_tokens":256},"prompt_cache_hit_tokens":256,"prompt_cache_miss_tokens":429,"completion_tokens_details":{"reasoning_tokens":405}},"tokens_in":429,"tokens_out":478,"duration_ms":5079,"temperature":1.0,"reasoning_tokens":405,"cache_read_input_tokens":256,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-05T15:33:47.922906+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Take a SystemC RTL design whose top-level interface includes a type not in the paper's mapping table (e.g. sc_in<sc_lv<8>> or an sc_vector of ports) and run the automatic flow: if parsing fails, the FMU cannot be loaded, or fmi3Get returns wrong values, the 'supports all designs' claim fails. A second check: drive the interrupt example with an FMI master that does not implement FMI 3.0 EventMode and see whether the asynchronous interrupt handling path is exercised at all.","supporting_citations":[{"cited_title":"Modelica/fmi-standard: Specification of the functional mock-up interface (fmi)","cited_arxiv_id":null,"evidence_quote":"Defines the FMI 3.0 interface, FMU archive layout, and Step/Event modes being implemented."},{"cited_title":"IEEE Standard for Standard SystemC Language Reference Manual,","cited_arxiv_id":null,"evidence_quote":"Defines the SystemC kernel, sc_start/sc_pause/sc_spawn primitives, and port/data types used by the wrapper."},{"cited_title":"Using SystemC cyber models in an FMI co-simulation environment: Results and proposed FMI enhancements,","cited_arxiv_id":null,"evidence_quote":"Earliest SystemC-to-FMI bridge without interrupt support; the paper's baseline to extend."},{"cited_title":"Virtual hardware-in-the-loop co-simulation for multi- domain automotive systems via the functional mock-up interface,","cited_arxiv_id":null,"evidence_quote":"Prior SystemC-FMI integration requiring a proprietary virtual-prototype tool, the dependency the flow removes."},{"cited_title":"Standard compliant co-simulation models for verifi- cation of automotive embedded systems,","cited_arxiv_id":null,"evidence_quote":"Prior SystemC/AMS-to-FMU method requiring non-standard external functions, contrasted with the non-invasive flow."},{"cited_title":"Virtual electronic control unit as a functional mockup unit for heterogeneous systems,","cited_arxiv_id":null,"evidence_quote":"Prior approach needing modifications inside the SystemC design, directly contrasted with the no-modification claim."},{"cited_title":"Fast virtual prototyping of cyber-physical systems using SystemC and FMI: ADAS use case,","cited_arxiv_id":null,"evidence_quote":"Prior CPS co-simulation tied to a particular virtual-prototyping environment, illustrating the portability gap."},{"cited_title":"CATIA-Systems/FMPy: Simulate functional mockup units (FMUs) in python","cited_arxiv_id":null,"evidence_quote":"Python-based FMU simulation library used as the FMI master in all experiments."},{"cited_title":"hichem/I2C: SystemC design of a master/slave I2C","cited_arxiv_id":null,"evidence_quote":"Open-source I2C model used as a hierarchical case study exercising interrupt handling."},{"cited_title":"systemc/cpu,","cited_arxiv_id":null,"evidence_quote":"Open-source pipelined processor model used as a hierarchy/computation case study."}],"review_version":1}