Pith. sign in

REVIEW 4 major objections 4 minor 33 references

Automatic integration of SystemC in the FMI standard for Software-defined Vehicle design

T0 review · 4 major / 4 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 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.

desk verdict 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. read the letter →

arxiv 2508.19665 v1 pith:IBAEYELU submitted 2025-08-27 cs.CL

Giovanni Pollo , Andrei Mihai Albu , Alessio Burrello , Daniele Jahier Pagliari , Cristian Tesconi , Loris Panaro , Dario Soldi , Fabio Autieri
show 1 more author
Sara Vinco
This is my paper · ORCID
classification cs.CL
keywords FunctionalMock-upInterfaceSystemCco-simulationsoftware-definedvehicleshardware-softwareco-designregister-transferlevelFMUgenerationevent-drivensimulation
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

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.

What carries the argument

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,

What would settle it

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.

Watch

Extended reading notes

Core claim

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

Load-bearing premise

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.

Editorial extensions

If this is right

  • 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.

Reading between the lines

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

  • 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.
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 / 4 minor

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.

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 (4)
  1. [§III-B, Table II] 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
  2. [§IV, Table III] 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.
  3. [§IV, Table III] 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.
  4. [§III-D.c, §IV-C] 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.
minor comments (4)
  1. [Throughout] 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.
  2. [Figure 2 and Figure 3] 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.
  3. [§IV-D] 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.
  4. [§IV-C] 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.

Circularity Check

0 steps flagged · score 0.0 of 10

No circular derivation: constructive wrapper flow with external baselines; overgeneralized 'all designs' claim is a coverage limitation, not circularity.

full rationale

The paper presents a constructive engineering methodology rather than a derivation. It parses SystemC top-level ports, generates an FMI wrapper, compiles an FMU, and validates the result against native SystemC execution on five case studies, reporting slowdown and memory overhead. There is no fitted parameter renamed as a prediction, no quantity defined in terms of the quantity it claims to produce, and no load-bearing self-citation chain: the central mechanism (mapping ports to FMI types, driving sc_start/sc_pause from fmi3DoStep, and supporting step, intermediate-update, and event modes) is described and evaluated against external or independent designs. The only self-referential artifact is the linked GitHub repository, which is a code release, not an argument. The paper's stronger claim that 'any SystemC version and any design for which the source code is accessible can be directly integrated' is broader than the evidence: Table II maps sc_logic to fmi3Bool, which collapses the four-valued SystemC states (0, 1, X, Z) to two-valued Booleans, so tri-state RTL top-level ports such as the I2C SDA/SCL lines cannot be faithfully represented at the FMU boundary. This is a correctness and coverage limitation, and the paper does not compare output traces between native SystemC and the FMU; however, it is not circularity. No step in the paper's own reasoning reduces to its inputs by construction, so the circularity score is 0.

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

The central claim rests on the availability of SystemC source and toolchains, the assumption that SystemC simulation can be externally driven via standard kernel primitives, and that the FMI master supports the required execution modes. No fitted parameters or new physical entities are introduced.

free parameters (1)
  • CommunicationStepSize = 1 ms (fixed for all experiments)
    User-configurable simulation step size, not fitted to data, but it directly affects the measured slowdown factors and interrupt-detection accuracy.
assumptions (3)
  • domain assumption SystemC RTL designs can be compiled into shared libraries that are loadable by the FMI runtime.
    Invoked in Section III-C when the wrapper is compiled as a .dll or .so library.
  • domain assumption sc_start(duration), sc_pause(), and sc_spawn() preserve SystemC event semantics when called from FMI functions.
    Section III-D relies on these primitives to synchronize SystemC simulation with the FMI master without kernel modifications.
  • domain assumption The FMI master (here FMPy) correctly implements FMI 3.0 EventMode and IntermediateUpdate.
    Section III-E states FMPy supports all FMI 3.0 functions and the execution modes; the interrupt and intermediate-update mechanisms depend on this.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Automatic integration of SystemC in the FMI standard for Software-defined Vehicle design." pith.science (2026). https://pith.science/paper/IBAEYELU

@misc{pith2026250819665,
  author       = {Pith},
  title        = {Pith review of: Automatic integration of SystemC in the FMI standard for Software-defined Vehicle design},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/IBAEYELU}},
  note         = {Machine review of arXiv:2508.19665}
}
read the original abstract

The recent advancements of the automotive sector demand robust co-simulation methodologies that enable early validation and seamless integration across hardware and software domains. However, the lack of standardized interfaces and the dominance of proprietary simulation platforms pose significant challenges to collaboration, scalability, and IP protection. To address these limitations, this paper presents an approach for automatically wrapping SystemC models by using the Functional Mock-up Interface (FMI) standard. This method combines the modeling accuracy and fast time-to-market of SystemC with the interoperability and encapsulation benefits of FMI, enabling secure and portable integration of embedded components into co-simulation workflows. We validate the proposed methodology on real-world case studies, demonstrating its effectiveness with complex designs.

Figures

Figures reproduced from arXiv: 2508.19665 by the authors.

Figure 1
Figure 1. Methodology Overview in three steps: input SystemC Design, gener [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. Step (orange) and intermediate update (blue) modes. [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗
Figure 3
Figure 3. Event-based/Interrupt-driven mode with the two proposed solutions. [PITH_FULL_IMAGE:figures/full_fig_p005_3.png] view at source ↗
Figures from the paper (3 more)
Figure 4
Figure 4. Figure 4: Caption Functional Mock-Up Unit modelDescription.xml binaries x86-linux model.so x86_64-windows model.dll resources extra FMPy clk op1 op2 result 0 0 0 5 2 7 4 9 3 7 5 3 8 1 2 3 4 5 6 Implementation of all FMI3 functions Simulation Bash CMAKE .dll .so Compile [PITH_FU…
Figure 5
Figure 5. Figure 5: CRC simulation performance: SystemC (blue) and FMI-wrapped SystemC (red). Initialization time is almost constant for both SystemC and FMI across [PITH_FULL_IMAGE:figures/full_fig_p007_5.png]
Figure 6
Figure 6. Figure 6: Configurations compared for the Delta Sigma case study. [PITH_FULL_IMAGE:figures/full_fig_p008_6.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

33 extracted references · 32 canonical work pages

  1. [1]

    A survey of autonomous driving: Common practices and emerging technologies,

    E. Yurtsever et al., “A survey of autonomous driving: Common practices and emerging technologies,” IEEE Access , vol. 8, pp. 58 443–58 469, 2020

    work page 2020

  2. [2]

    The digital twin,

    N. Crespi, “The digital twin,” The Digital Twin , vol. 1-2, pp. 1–1238, 1 2023

    work page 2023

  3. [3]

    Impact, challenges and prospect of software-defined vehicles,

    Z. Liu et al. , “Impact, challenges and prospect of software-defined vehicles,” Automotive Innovation, vol. 5, pp. 180–194, 4 2022

    work page 2022

  4. [4]

    Autonomy-driven emerging directions in software- defined vehicles,

    U. Bordoloi et al. , “Autonomy-driven emerging directions in software- defined vehicles,” in Proc. of DATE, 2023, pp. 1–6

    work page 2023

  5. [5]

    Hardware Software Co-design for Automotive CPS using Architecture Analysis and Design Language

    Y . Zhou et al., “Hardware software co-design for automotive CPS using architecture analysis and design language,” 2016. [Online]. Available: https://arxiv.org/abs/1603.05069

    work page Pith review arXiv 2016

  6. [6]

    Validating software-defined vehicles,

    T. Schulze, “Validating software-defined vehicles,” ATZ worldwide 2022 124:6 , vol. 124, pp. 64–64, 5 2022. [Online]. Available: https://link.springer.com/article/10.1007/s38311-022-0822-y

    work page doi:10.1007/s38311-022-0822-y 2022

  7. [7]

    Hardware, software and mechanical cosimulation for automotive applications,

    P. Le Marrec et al., “Hardware, software and mechanical cosimulation for automotive applications,” in Proceedings. Ninth International Workshop on Rapid System Prototyping (Cat. No.98TB100237) , 1998, pp. 202–206

    work page 1998

  8. [8]

    Simulink

    MATLAB, “Simulink.” [Online]. Available: https://it.mathworks.com/ products/simulink.html

    work page

Show all 33 references
  1. [9]

    Powerful co-simulation and integration platform

    ETAS, “Powerful co-simulation and integration platform.” [Online]. Available: https://www.etas.com/ww/en/products-services/ software-development-tools/cosym/

  2. [10]

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

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

  3. [11]

    A fmi-based approach for CAN bus simulation and Simulink model integration in vehicle simulation environment,

    H. Kim et al. , “A fmi-based approach for CAN bus simulation and Simulink model integration in vehicle simulation environment,” in Proc. of International Conference on Information and Communication Technol- ogy Convergence (ICTC), 2023, pp. 279–284

    2023

  4. [12]

    IEEE Standard for Standard SystemC Language Reference Manual,

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

    2023

  5. [13]

    SystemC-based co-simulation/analysis for system-level hardware/software co-design,

    V . Muttillo et al., “SystemC-based co-simulation/analysis for system-level hardware/software co-design,” Computers and Electrical Engineering , vol. 110, p. 108803, 9 2023

    2023

  6. [14]

    Virtual development of engine ECU by modeling technology,

    Y . Niimi et al. , “Virtual development of engine ECU by modeling technology,” SAE Technical Papers , 4 2012. [Online]. Available: https://saemobilus.sae.org/papers/ virtual-development-engine-ecu-modeling-technology-2012-01-0007

    2012

  7. [15]

    Automotive electric system level design methodologies with SystemC,

    H. Ishihara et al., “Automotive electric system level design methodologies with SystemC,” SAE Technical Papers , 4 2012. [Online]. Available: https://www.sae.org/publications/technical-papers/content/2012-01-0003/

    2012

  8. [16]

    Using FMI components in discrete event systems,

    W. Muller and E. Widl, “Using FMI components in discrete event systems,” in 2015 Workshop on Modeling and Simulation of Cyber- Physical Energy Systems (MSCPES) , 2015, pp. 1–6

    2015

  9. [17]

    A FMI-based approach for CAN bus simulation and Simulink model integration in vehicle simulation environment,

    H. Kim et al. , “A FMI-based approach for CAN bus simulation and Simulink model integration in vehicle simulation environment,” in 2023 14th International Conference on Information and Communication Tech- nology Convergence (ICTC), 2023, pp. 279–284

    2023

  10. [18]

    Timing-aware software-in-the-loop simulation of automo- tive applications with FMI 3.0,

    S. Ravi et al., “Timing-aware software-in-the-loop simulation of automo- tive applications with FMI 3.0,” in ACM/IEEE 26th International Confer- ence on Model Driven Engineering Languages and Systems (MODELS) , 2023, pp. 62–72

    2023

  11. [19]

    Co-simulation of hardware RTL and software system using FMI,

    M. H. Quraishi et al. , “Co-simulation of hardware RTL and software system using FMI,” in Winter Simulation Conference (WSC) , 2018, pp. 572–583

    2018

  12. [20]

    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 Euromicro Conference on Digital System Design (DSD) , 2016, pp. 318–325

    2016

  13. [21]

    Virtual hardware-in-the-loop co-simulation for multi- domain automotive systems via the functional mock-up interface,

    R. L. Bucs et al., “Virtual hardware-in-the-loop co-simulation for multi- domain automotive systems via the functional mock-up interface,” in Forum on Specification and Design Languages (FDL) , 2015, pp. 1–8

    2015

  14. [22]

    Standard compliant co-simulation models for verifi- cation of automotive embedded systems,

    M. Krammer et al., “Standard compliant co-simulation models for verifi- cation of automotive embedded systems,” in Forum on Specification and Design Languages (FDL) , 2015, pp. 1–8

    2015

  15. [23]

    Virtual electronic control unit as a functional mockup unit for heterogeneous systems,

    M. Safar et al. , “Virtual electronic control unit as a functional mockup unit for heterogeneous systems,” in Proc. of IEEE ISCAS), 2018, pp. 1–5

    2018

  16. [24]

    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,” in Proc. of International Workshop on Rapid System Prototyping (RSP’19) , ser. RSP ’19. New York, NY , USA: Association for Computing Machinery, 2019, p. 43–49

    2019

  17. [25]

    The functional mockup interface for tool independent exchange of simulation models,

    T. Blochwitz et al., “The functional mockup interface for tool independent exchange of simulation models,” 03 2011, pp. 105–114

    2011

  18. [26]

    Platform architect

    Synopsis, “Platform architect.” [Online]. Available: https://www. synopsys.com/verification/virtual-prototyping/platform-architect.html

  19. [27]

    Fast virtual prototyping for embedded computing systems design and exploration,

    A. Charif et al. , “Fast virtual prototyping for embedded computing systems design and exploration,” in Proceedings of the Rapid Simulation and Performance Evaluation: Methods and Tools , 2019

    2019

  20. [28]

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

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

  21. [29]

    FMI-standard: FMI Event Mode

    Modelica, “FMI-standard: FMI Event Mode.” [Online]. Available: https://fmi-standard.org/docs/3.0/#EventMode

  22. [30]

    FMI-standard: FMI Step Mode

    ——, “FMI-standard: FMI Step Mode.” [Online]. Available: https: //fmi-standard.org/docs/3.0/#StepMode

  23. [31]

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

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

  24. [32]

    hichem/I2C: SystemC design of a master/slave I2C

    H. Boussetta, “hichem/I2C: SystemC design of a master/slave I2C.” [Online]. Available: https://github.com/hichem/I2C.git

  25. [33]

    systemc/cpu,

    M. Barrett, “systemc/cpu,” 2018. [Online]. Available: https://github.com/ michaelbarrett/systemc/tree/master/cpu

    2018

Pith tools

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