Research Literature, University Projects, Open-Source Ecosystems, and Commercial Tools for Hardware–Software Co-Design

An expanded section for the IAS-Research.com white paper: Finding the Hidden Questions in Hardware–Software Co-Design Using The Craft of Research

1. Purpose and research approach

Hardware–software co-design (HW/SW co-design) is not simply the process of designing a circuit and then writing the software that controls it. It is a multidisciplinary engineering activity in which system requirements, hardware architecture, software architecture, performance, power consumption, timing, safety, security, verification, manufacturing constraints, and lifecycle costs must be considered together.

The central research question is:

How can an engineering team determine which hardware and software functions should be implemented in silicon, programmable logic, firmware, real-time operating systems, embedded Linux, or higher-level software—and what evidence is required to justify that allocation?

Applying Booth, Colomb, Williams, Bizup, and FitzGerald's The Craft of Research changes how the team approaches the problem. Instead of starting with a preferred tool or platform, researchers begin by identifying:

  • The practical engineering problem.
  • The unanswered technical question.
  • The assumptions behind the current architecture.
  • The evidence needed to compare alternatives.
  • The consequences if an assumption proves false.
  • The research contribution that would make the work valuable to industry, academia, or a commercial product.

The literature, university projects, open-source projects, and commercial products discussed below form a research landscape for answering these questions. They should be treated as complementary sources of evidence, not as interchangeable solutions.

2. How to classify the literature and engineering resources

Books and textbooks

Provide foundational concepts, established terminology, design methods, mathematical models, and worked examples. They help establish what is already known and identify where a new research question begins.

Research papers and university projects

Demonstrate proposed methods, experimental designs, benchmarks, and results. Their limitations, experimental conditions, and reproducibility matter as much as their conclusions.

Open-source projects and tools

Provide inspectable implementations, test suites, simulation environments, reference designs, and reproducible experiments—subject to the project's license, hardware availability, and documentation quality.

Commercial engineering tools

Provide integrated design environments, vendor-supported workflows, optimization, verification, simulation, and deployment support. Their value must be evaluated against licensing costs, target compatibility, portability, and vendor dependency.

A useful research discipline is to distinguish five kinds of claims:

  1. Established theory: supported by textbooks and peer-reviewed literature.
  2. Tool capability: supported by official documentation and demonstrated features.
  3. Experimental result: supported by measured results under specified conditions.
  4. Engineering inference: a conclusion drawn from multiple sources and the project's constraints.
  5. Unverified hypothesis: a proposition that the project must test.

This distinction prevents a common research error: assuming that because a tool can model, simulate, or generate an implementation, the final system is therefore correct, safe, or commercially viable.

3. Books and textbooks: the core reading programme

The following books are useful because they address different layers of the co-design problem. No single textbook covers the entire journey from stakeholder needs to verified silicon and deployed software.

3.1 Foundational hardware–software co-design

1. Patrick R. Schaumont — A Practical Introduction to Hardware/Software Codesign, 2nd edition

Springer, 2012/2013 editions and listings

A strong starting point for understanding hardware/software partitioning, embedded-system design, and the interaction between hardware implementations and software execution.

Hidden question: Which computations genuinely need dedicated hardware, and which are better implemented as software?

Apply it to: Comparing a CPU implementation, an FPGA accelerator, and a mixed implementation using identical functional requirements and measurable performance criteria.

Find publisher information

2. Soonhoi Ha and Jürgen Teich (eds.) — Handbook of Hardware/Software Codesign

Springer reference work, 2017

A broad reference for the discipline, with coverage of methods and technical topics across hardware/software co-design. It is especially useful for building a literature review and identifying research subfields.

Springer Nature Link

+1

Hidden question: Which established co-design methods apply to this system, and what assumptions do they make about models, scheduling, communication, or implementation costs?

Apply it to: Literature mapping, architectural trade-off studies, and defining the state of the art.

Publisher page

3. Jørgen Staunstrup and Wayne Wolf (eds.) — Hardware/Software Co-Design: Principles and Practice

Kluwer Academic Publishers, 1997

A foundational reference for the historical development of co-design methods and the relationship between hardware and software design decisions.

Hidden question: Which partitioning and coordination problems remain fundamental even when processors, languages, and design tools change?

Apply it to: Comparing traditional co-design principles with modern SoC generators, virtual platforms, and automated design flows.

Find library records

4. Peter Marwedel — Embedded System Design: Embedded Systems Foundations of Cyber-Physical Systems

Springer; second edition published in 2011

Helps connect embedded software, processors, resource constraints, models of computation, and system-level design.

Hidden question: How do real-time, memory, energy, and physical-environment constraints change the architecture?

Apply it to: Automotive electronics, IoT devices, embedded AI, smart inverters, and industrial control.

Find publisher information

5. Edward A. Lee and Sanjit A. Seshia — Introduction to Embedded Systems: A Cyber-Physical Systems Approach

An important source for reasoning about time, concurrency, system models, and the interaction between computation and physical processes.

Hidden question: Does the system satisfy its requirements under the timing and environmental assumptions of the model?

Apply it to: Control systems, event-driven software, sensor processing, power electronics, and safety-critical embedded applications.

Author-maintained book website

3.2 SystemC, transaction-level modelling, and virtual prototyping

These resources are particularly important when the team must explore architecture before all hardware details are available.

Book or resource

Why it matters

Research question it helps answer

David Black, Jack Donovan, Bill Bunton, and Anna Keist, SystemC: From the Ground Up

Introduces SystemC modelling and simulation concepts.

Can we represent the proposed system at an abstraction level suitable for early experiments?

Frank Ghenassia (ed.), Transaction-Level Modeling with SystemC: TLM Concepts and Applications for Embedded Systems

Develops transaction-level modelling concepts.

How much simulation speed can be gained by abstracting signal-level detail while preserving relevant behaviour?

Vladimir Herdt, Daniel Große, and Rolf Drechsler, Enhanced Virtual Prototyping Featuring RISC-V Case Studies

Connects virtual prototyping and RISC-V examples.

How can virtual platforms support software development and architectural exploration before physical hardware is ready?

Soonhoi Ha et al., “Introduction to Hardware/Software Codesign”

A concise entry point into the broader co-design discipline.

What are the core methods, abstractions, and research challenges?

The official SystemC resource library lists these and other SystemC books.

systemc.org

Important distinction: transaction-level simulation, cycle-accurate simulation, RTL simulation, and physical measurements answer different questions. A fast transaction-level model may be suitable for architectural exploration, but it does not automatically establish cycle-level timing, signal integrity, or physical correctness.

3.3 Model-based systems engineering and architecture

The following works complement specialist co-design texts:

  • Friedenthal, Moore, and Steiner — A Practical Guide to SysML. Useful for requirements, structural and behavioural models, interfaces, constraints, and system verification planning.
  • Martin Fowler — UML Distilled. Useful for software structure and behaviour where UML provides a clear communication mechanism.
  • Eric Evans — Domain-Driven Design. Useful for defining software domain boundaries, especially where embedded systems integrate diagnostics, telemetry, maintenance, and business services.
  • Dan North, Gojko Adzic, and related BDD literature. Useful for translating stakeholder expectations into executable or reviewable behavioural scenarios. For practical BDD implementation, the official Cucumber documentation is a starting point.

These books do not replace electronics, digital design, or real-time systems references. Their contribution is to make assumptions, interfaces, responsibilities, and verification obligations explicit.

For IAS-Research.com, a useful combined reading sequence is:

  1. Read The Craft of Research to formulate a defensible question.
  2. Read a foundational co-design text to understand partitioning and design-space exploration.
  3. Read embedded-systems and cyber-physical-systems material to expose timing and environmental constraints.
  4. Use SysML/UML and BDD to document architecture, requirements, and observable behaviour.
  5. Use SystemC/TLM, an instruction-set or system emulator, RTL tools, and physical instrumentation to gather the appropriate evidence.

4. Research papers, theses, and technical reports

Books establish the conceptual foundation. Papers and theses help identify current methods, specific experimental techniques, and gaps that can become research contributions.

4.1 Recommended research starting points

A. “Introduction to Hardware/Software Codesign”

Soonhoi Ha, Jürgen Teich, Christoph Haubelt, et al. — 2017

This chapter in the Handbook of Hardware/Software Codesign gives a broad orientation to HW/SW co-design as part of electronic system-level design. It is a useful starting point for constructing a literature review before narrowing the project to a particular architecture or application.

Tampere University Research Portal

Read for: terminology, design methods, abstraction levels, and the broader research landscape.

Read the chapter record

B. A Methodology for Hardware-Software Codesign

Myron Decker King — MIT thesis, 2013

This thesis addresses the difficulty of integrating special-purpose hardware accelerators with software running on a processor, including coordination between parallel hardware and software execution. It is especially relevant to accelerator interfaces and early partitioning decisions.

dspace.mit.edu

Read for: the cost of committing to a partition too early, interface contracts, and coordinating hardware/software development.

MIT thesis repository

C. Agile Hardware/Software Co-Design for Hyperscale Cloud Systems

Sagar Karandikar — UC Berkeley EECS technical report, 2024

This research connects the Chipyard and FireSim ecosystems with the development and evaluation of specialized system-on-chip architectures. It illustrates how workload profiling, hardware architecture, and system-level simulation can be combined to investigate new designs.

EECS at UC Berkeley

Read for: workload-driven architecture, simulation at scale, specialized accelerators, and end-to-end evaluation.

Read the UC Berkeley report

D. Fast and Efficient Floating-Point Computation for RISC-V Architectures: A Hardware-Software Codesign Approach

Matteo Perotti — ETH Zurich doctoral thesis, 2025

An open-access thesis focused on floating-point computation and RISC-V hardware/software co-design. It offers a targeted example of the interplay between arithmetic requirements, processor architecture, and implementation choices.

research-collection.ethz.ch

Read for: numerical workloads, architecture-specific optimizations, and performance/efficiency trade-offs.

Open-access thesis

E. “PEak: A Single Source of Truth for Hardware Design and Verification”

Caleb Donovick, Jackson Melchert, Ross Daly, et al. — ACM Transactions on Embedded Computing Systems, 2026

This paper describes an open-source hardware design and specification language intended to connect functional models, formal specifications, and RTL. The authors report use in academic projects and fabricated accelerators. It is a useful example of research into reducing divergence between design intent and implementation.

theory.stanford.edu

Read for: executable specifications, formal verification, design-space exploration, and maintaining consistency between models and RTL.

Read the paper record and abstract

The listed papers and theses are a starter bibliography, not a claim to be an exhaustive systematic review. Before publication, the research team should verify the final bibliographic details, inspect the full text where available, and record the precise claims and limitations relevant to its project.

4.2 How to read a paper critically using The Craft of Research

For each paper, do not stop at the abstract or reported performance improvement. Extract its reasoning in a structured way.

Research element

Questions for the reader

Problem

What practical or scientific problem does the paper address?

Research question

What is not known or adequately solved?

Claim

What does the author argue the method or design achieves?

Warrant

Why should the evidence support that claim?

Evidence

Are there measurements, benchmarks, proofs, simulations, or case studies?

Baseline

What competing approach was used for comparison?

Assumptions

What workload, target hardware, compiler, clock, memory, or environment is assumed?

Limitations

What is not demonstrated or remains outside the scope?

Reproducibility

Are the code, configurations, data, and test instructions available?

Transferability

Do the results apply to our target device and workload?

For example, a paper might report a 10× acceleration using a custom hardware accelerator. The hidden questions include: Was the comparison against optimized software? Was data-transfer time included? Was power measured at the system level or only for the accelerator? Was the workload representative? Can the accelerator be integrated with the actual processor, operating system, memory, and peripherals?

These questions turn literature review into engineering decision support.

5. University research projects and academic engineering ecosystems

University projects are valuable not simply because they produce papers, but because they often publish working frameworks, architectural models, generators, benchmarks, verification methods, and experimental infrastructure.

5.1 UC Berkeley: Chipyard and FireSim

Chipyard — open-source SoC design framework

UC Berkeley SLICE Lab and associated research projects

Chipyard brings together hardware-generation infrastructure, RISC-V processor designs, peripherals, accelerators, simulation, and implementation workflows. It is designed to support experimentation with SoC architectures rather than only configuring a fixed commercial processor.

UC Berkeley SLICE Lab

Hidden questions to investigate: Should the design use an existing processor core, a custom accelerator, or a modified memory/interconnect architecture? What changes when the workload is run on the complete SoC rather than on an isolated accelerator?

FireSim — FPGA-accelerated computer-system simulation

FireSim uses FPGA-based acceleration to run large-scale, cycle-accurate simulations derived from hardware designs. It supports architectural research involving systems larger than can practically be explored through conventional software simulation alone.

RISE Lab

Hidden questions to investigate: Does the proposed hardware improve full-system performance? How does it behave with realistic workloads, memory, and communication? Is simulation throughput adequate for exploring many design alternatives?

Limitation: Cycle accuracy in a simulation model is not equivalent to proof of physical timing closure, power consumption, or correctness of the fabricated device.

These projects are particularly useful for studying the connection between software workload analysis, architectural design, and hardware implementation. The UC Berkeley research record describes the combination of Chipyard and FireSim in an end-to-end co-design methodology.

EECS at UC Berkeley

5.2 Stanford University: Agile Hardware Project

The Stanford Agile Hardware Project develops approaches to hardware generation, domain-specific languages, coarse-grained reconfigurable arrays (CGRAs), SoC infrastructure, and verification. Its research includes tools such as PEak, Lake, Canal, CoreIR, Magma, Gemstone, and formal-validation projects.

AHA Agile Hardware Project

Why this matters:

  • It illustrates how a higher-level language or domain-specific representation can encode architectural intent.
  • It provides examples of generators that produce hardware structures from more abstract specifications.
  • It connects productivity improvements with verification and modular design.
  • It raises the question of how to keep the specification, generated implementation, and verification model consistent.

Research opportunity: Compare conventional RTL-first design with a generator-based workflow for one small accelerator. Measure development effort, resource utilization, timing, verification effort, and the ability to explore architectural alternatives.

5.3 MIT: hardware/software integration methodology

The MIT thesis repository contains A Methodology for Hardware-Software Codesign, a study of integration difficulties when special-purpose hardware accelerators cooperate with software executing on a processor.

dspace.mit.edu

The research issue is broader than accelerator arithmetic. The team must determine:

  • How the processor and accelerator exchange data.
  • Whether the interface contract is stable enough for parallel development.
  • How concurrency, interrupts, buffers, and synchronization affect performance.
  • Whether the measured acceleration survives communication and integration overhead.

This is a strong example of how a hidden assumption—“accelerating the computation accelerates the whole application”—can be turned into a measurable research question.

5.4 ETH Zurich: RISC-V and arithmetic co-design

The ETH Zurich research repository provides an open-access doctoral thesis on efficient floating-point computation for RISC-V architectures.

research-collection.ethz.ch

Its relevance extends to any project where numerical representation and computational architecture affect performance:

  • Floating-point versus fixed-point arithmetic.
  • Software libraries versus hardware execution units.
  • Precision requirements versus latency and resource use.
  • Numerical correctness versus performance optimization.

For an inverter controller, for example, an arithmetic optimization cannot be judged solely by execution time. Its numerical error must also be assessed against the control system's requirements and stability analysis.

5.5 Stanford's broader hardware/software research

Stanford's Hardware / Software Systems research area covers embedded systems, efficient hardware, integrated circuits, power electronics, and other connected disciplines.

ee.stanford.edu

This broader perspective is important because real co-design projects rarely fit neatly within one department. They may require computer architecture, control engineering, electronics, software engineering, verification, and application-domain knowledge.

5.6 How to use university projects in an IAS-Research study

A university repository should be assessed on six dimensions:

  1. Research relevance: Does it address the project's actual question?
  2. Reproducibility: Can the team reproduce a published result?
  3. Target compatibility: Does it support the required processor, FPGA, or peripheral architecture?
  4. Maturity: Is the project maintained and documented?
  5. Licensing: Are the code, hardware designs, and generated outputs usable for the intended purpose?
  6. Evidence quality: Are performance, accuracy, and limitations documented?

A research project can be scientifically valuable even if it is not production-ready. Conversely, a mature tool may be useful in production without being the best platform for investigating a novel architecture.

6. Open-source tools and engineering projects

Open source gives researchers the ability to inspect implementations, reproduce experiments, automate tests, and avoid making every research question dependent on a commercial licence. It does not eliminate the need to check hardware support, maintenance, licences, or verification quality.

6.1 Open-source tool landscape

The following is a practical selection of projects for hardware/software co-design. The capabilities described are the projects' intended roles; exact support should be checked against the version, target architecture, and required workflow.

Project or tool

Main role

Useful research questions

Key limitation or caution

SystemC

System-level modelling and simulation

How should functions be partitioned and how should subsystems interact?

Results depend on model abstraction, fidelity, and validation.

QEMU

Processor/system emulation and virtual-machine execution

Can software boot and run before target hardware is available?

Emulation does not automatically provide cycle-accurate hardware timing.

Renode

Embedded and multi-node system simulation

Can firmware, peripherals, and connected devices be tested reproducibly?

The model must represent the target peripherals and timing closely enough for the test.

gem5

Computer architecture simulation

How do processor, cache, memory, and software choices affect performance?

Results depend on configuration and model assumptions.

Verilator

High-performance RTL simulation and model generation

Does the RTL behave as specified across test cases?

It is not a substitute for every commercial simulator or analogue/mixed-signal workflow.

Yosys

RTL synthesis

How does a design map into logic and what resources does it use?

Supported language constructs and target flows matter.

nextpnr

FPGA place-and-route for supported devices

Can the implementation meet device-specific resource and timing constraints?

Device support and implementation results vary by target.

OpenROAD

Open RTL-to-GDS physical-design flow

Can a design proceed through synthesis and physical implementation in an open toolchain?

Results depend on the process-design kit, constraints, libraries, and flow configuration.

Zephyr RTOS

Embedded real-time operating system

Does firmware meet resource, concurrency, and device-integration needs?

Hardware support and timing behaviour must be validated on the actual target.

Yocto Project

Custom embedded Linux distribution and build infrastructure

Can the project build reproducible, tailored Linux images for its product?

It is a distribution-building framework, not a substitute for system architecture or real-time analysis.

Cocotb

Python-based hardware verification

Can tests be expressed at the interface and system-behaviour level?

Test quality depends on coverage, assertions, and verification strategy.

Renode test framework

Automated testing of simulated embedded systems

Can software and system scenarios be repeated automatically?

A simulated pass does not guarantee a physical hardware pass.

The official SystemC description specifically identifies system partitioning, hardware/software allocation, and interaction between functional blocks as intended uses.

systemc.org

Renode describes support for running unmodified embedded software on virtual platforms, including systems with processors and peripherals.

GitHub

The gem5 project identifies computer architecture, system software, and workload optimization as its main research areas.

GitHub

OpenROAD documents an open-source digital chip-design flow.

OpenROAD

6.2 SystemC and TLM: explore before committing

SystemC is particularly useful when an engineering team wants to compare architecture options before committing to detailed RTL. Transaction-Level Modeling (TLM) allows communication between components to be represented at a higher abstraction level than individual signal transitions.

A typical research sequence is:

  1. Define the system's externally observable behaviour.
  2. Build a functional model of the main components.
  3. Define communication paths and transaction behaviour.
  4. Estimate latency, throughput, buffering, and contention.
  5. Compare alternative component allocations.
  6. Refine the model where evidence shows that additional detail matters.
  7. Implement selected components in RTL or software.
  8. Compare implementation measurements against model predictions.

The key hidden assumption is that the abstraction preserves the properties that matter to the research question. A TLM model may be adequate for comparing throughput and communication architectures while being inadequate for proving cycle-level behaviour.

Official starting points:

Accellera lists SystemC 3.0.2 in its releases page, dated October 31, 2025, and identifies IEEE Std 1666-2023 as the SystemC language standard. Check the current release and any project dependencies before selecting a version.

Accellera Systems Initiative

6.3 QEMU, Renode, and gem5 are not interchangeable

QEMU — software execution and system emulation

Use when the question is: “Can our operating system or application run in a virtualized target environment?”

Useful for early software bring-up, operating-system work, and testing supported processor and peripheral models.

Renode — embedded systems and multi-node scenarios

Use when the question is: “Can firmware and interacting embedded devices be tested in repeatable simulated scenarios?”

Particularly relevant to MCU-based systems, IoT, sensor nodes, and networked embedded applications. Its source repository documents support for multiple processor architectures and a virtual-platform workflow.

GitHub

gem5 — computer architecture research

Use when the question is: “How do architectural changes affect execution, caches, memory, and workload performance?”

Suitable for architecture experiments where simulation configuration and the chosen model's assumptions can be documented and controlled.

GitHub

A project may use more than one of these tools. For example, gem5 may investigate a processor or memory architecture, QEMU may support software development, and Renode may exercise a firmware and peripheral integration scenario. The team should avoid treating agreement between simulators as proof of correctness unless their independence and modelling assumptions are understood.

6.4 Open-source digital design and FPGA implementation

A possible open-source digital-design chain is:

Specification and functional model

Requirements, interface contracts, test scenarios

RTL implementation

Verilog / SystemVerilog / VHDL, where supported

Verification and synthesis

Verilator, Cocotb, Yosys and compatible tools

Device implementation

nextpnr or another supported place-and-route flow

Physical measurement

Board tests, timing checks, power and interface measurements

This is a conceptual workflow, not a guarantee that every tool combination supports every FPGA. Before choosing a target, verify the device's support status, available timing libraries, programming flow, and constraints.

For ASIC research, OpenROAD provides an open-source physical-design path from RTL towards layout. Its existence lowers some barriers to research and education, but it does not remove the need for suitable process-design kits, design rules, and foundry-specific sign-off.

OpenROAD

6.5 Open source is a governance and licensing question too

Before incorporating an open-source tool into a commercial deliverable, IAS-Research.com and KeenComputer.com should record:

  • The software licence and version.
  • The licence of dependent libraries and hardware descriptions.
  • The terms governing generated code, IP blocks, and design outputs.
  • The availability of security fixes and maintainers.
  • The method for pinning versions and reproducing builds.
  • The boundary between research prototypes and production-supported components.

“Open source” does not mean “free of all obligations,” nor does it automatically mean that a project is safe, supported, or appropriate for a safety-critical product.

7. Commercial hardware–software co-design tools

Commercial tools become valuable when a project needs advanced device support, integrated design flows, specialist verification, vendor IP, technical support, or an established route to production. They should be selected against a documented engineering need rather than because a vendor offers a large feature set.

7.1 Commercial tools by engineering task

1. MathWorks — MATLAB, Simulink, Stateflow, HDL Coder

System modelling and algorithm-to-hardware

Best suited to algorithm development, control-system modelling, simulation, fixed-point exploration, model-based design, and generating synthesizable HDL from supported MATLAB, Simulink, and Stateflow models.

Research questions: Can the algorithm meet performance and numerical requirements? Can the same design model support simulation, generated HDL, and hardware testing?

Limitations: Generated code still requires verification, synthesis, implementation, and target-specific validation. Licensing and toolbox costs must be included in the project budget.

mathworks.com

+1

HDL Coder product information

2. AMD — Vivado Design Suite and Vitis

FPGA and adaptive SoC implementation

Used for supported AMD FPGA and adaptive SoC workflows, including hardware implementation, IP integration, and software development around programmable hardware.

Research questions: Can the hardware architecture meet the target's timing, resource, and interface constraints? What is the cost of communication between processor software and programmable logic?

Limitations: Device-specific constraints, IP dependencies, licensing, and the availability of the required board or device must be checked.

Vivado official page

Vitis official page

3. Intel FPGA — Quartus Prime, Platform Designer, Nios V

Used to design and integrate systems for supported Intel FPGA devices, including embedded processor systems, interconnects, and IP components. Platform Designer can generate interconnect logic connecting IP blocks and subsystems.

Intel

+1

Research questions: How should processors, memories, peripherals, and accelerators be connected? Can the system be integrated and compiled within the device's timing and resource limits?

Quartus Prime

Platform Designer

4. Synopsys — virtual prototyping and electronic design automation

Synopsys provides commercial tools across semiconductor design, verification, implementation, and virtual prototyping. Its virtual-prototyping workflows are relevant when software teams need earlier access to a model of a proposed SoC.

Research questions: Can software development begin before silicon is available? How much integration risk can be discovered before hardware fabrication?

Limitations: Evaluate model availability, supported processor/IP configurations, integration effort, and total licensing and support costs.

Synopsys official website

5. Cadence — system design, high-level synthesis, and verification

Cadence offers commercial EDA and verification tools for system architecture, RTL development, high-level synthesis, and hardware verification.

Research questions: Can a high-level description be implemented efficiently? Can verification find integration and corner-case errors before production?

Limitations: Product selection depends on the target process, design scale, verification methodology, and existing toolchain.

Cadence official website

6. Siemens EDA — Questa and related verification tools

Relevant to RTL simulation, design verification, and hardware verification workflows. Tool editions and supported verification capabilities vary.

Research questions: Have the required functional scenarios, interfaces, concurrency cases, and corner conditions been exercised? What verification evidence is missing?

Limitations: Simulation coverage does not automatically establish correctness; formal methods, static analysis, timing analysis, and physical testing may also be needed.

Siemens EDA official website

7. Sparx Systems — Enterprise Architect

Useful for SysML/UML modelling, requirements, traceability, interfaces, architecture views, and the relationship between requirements and verification activities.

Research questions: Can each design decision be traced to a need, assumption, requirement, model, test, and evidence item?

Limitations: A model repository does not itself prove that the implemented system conforms to the model. Integration with test automation and implementation repositories must be designed.

Enterprise Architect official website

The products above serve different purposes. They should not be treated as equivalent alternatives: an MBSE repository, a control-system modeller, an RTL simulator, and an SoC virtual-prototyping environment answer different engineering questions.

7.2 Commercial tools: selection criteria

Before procuring a tool, score it against the project's needs.

Criterion

Questions to ask

Technical fit

Does it support the target architecture, device, language, interfaces, and required abstractions?

Evidence quality

Does it produce the measurements, reports, waveforms, coverage data, or traceability records the project needs?

Integration

Can it work with the compiler, version control, CI, test equipment, and other design tools?

Reproducibility

Can configurations and tool versions be pinned and results repeated?

Portability

Can the project migrate to another vendor or platform if necessary?

Cost

What are the licence, maintenance, training, hardware, compute, and support costs?

Production readiness

Are required safety, security, quality, and certification processes supported?

Skills

Can the team operate and maintain the workflow?

A commercial tool is justified when it improves the project's evidence, productivity, integration, or delivery outcomes sufficiently to warrant its total cost—not merely because it offers more features than an open-source alternative.

8. Combining open-source and commercial tools into one workflow

A practical co-design environment can combine open-source tools for research and automation with commercial tools for target-specific implementation and verification.

Stage 1 — Research question and requirements

The Craft of Research · stakeholder interviews · Sparx Enterprise Architect · SysML/UML · BDD/Gherkin

Stage 2 — Architecture and design-space exploration

SystemC/TLM · MATLAB/Simulink · analytical models · workload profiling · performance budgets

Stage 3 — Software and virtual-platform development

QEMU · Renode · gem5 where appropriate · Zephyr · Yocto · cross-compilers · automated tests

Stage 4 — Hardware implementation

Verilog/SystemVerilog/VHDL · Verilator · Yosys/nextpnr or vendor FPGA tools · commercial EDA as required

Stage 5 — Integrated verification and evidence

Software tests · RTL tests · formal analysis where appropriate · hardware-in-the-loop · board measurements · traceability and release reports

This workflow is deliberately iterative. A timing failure may require a new hardware partition. A firmware integration problem may expose an incomplete interface specification. A physical measurement may reveal that the early model omitted an important source of latency or power consumption.

Every such discovery should feed back into the research question, assumption register, architecture model, and verification plan.

9. Mapping tools to hidden questions

The following matrix makes the tool-selection logic explicit. It helps prevent the team from adopting a tool simply because it is familiar or popular.

Hidden question

Primary evidence required

Candidate tools

What problem must the system solve?

Stakeholder needs, constraints, use cases

Interviews, The Craft of Research, SysML/UML, BDD

Which functions belong in hardware?

Performance, resource, cost, and latency comparisons

SystemC/TLM, MATLAB/Simulink, analytical models

Is a CPU or accelerator the better option?

Whole-system measurements and representative workloads

gem5, FPGA prototypes, profiling, SystemC

Can the firmware run before hardware exists?

Software execution and integration tests

QEMU, Renode, virtual platforms

Does the RTL implement the intended behaviour?

Test results, assertions, coverage, formal properties

Verilator, Cocotb, commercial simulators, formal tools

Can the implementation meet timing and resource limits?

Synthesis and implementation reports

Yosys/nextpnr or vendor FPGA tools

Is the model sufficiently accurate?

Model-versus-implementation comparison

SystemC/TLM, simulation, board measurements

Does the system meet real-time constraints?

Worst-case timing evidence and stress tests

RTOS tools, tracing, timing analysis, hardware instrumentation

Is the design safe and secure?

Hazard analysis, threat analysis, appropriate verification evidence

Domain-specific safety/security methods and qualified tools

Can the product be built and maintained?

Reproducible builds, lifecycle costs, support and supply-chain evidence

Yocto, CI, version control, software composition and security tools

The key rule is: select a tool only after defining the question and the evidence needed to answer it. A tool may be useful for multiple questions, but the project should record which claims its output can and cannot support.

10. Applying the research landscape to OBD-AI and smart inverters

10.1 Case study A — OBD-AI automotive diagnostics

The proposed OBD-AI system combines vehicle telemetry, diagnostic trouble codes (DTCs), technical manuals, retrieval-augmented generation (RAG), and an AI-based advisory service.

The co-design question is not simply whether an AI model can diagnose a fault. It is how the complete system can gather, interpret, validate, and communicate diagnostic evidence within its resource, latency, safety, and cost constraints.

Vehicle interface and telemetry

Candidate tools: microcontroller SDKs, CAN/OBD-II interfaces, logic analysers, bus logging and hardware test equipment.

Hidden assumption: The adapter, vehicle, and available signals expose sufficient and reliable data to support the intended diagnostic decisions.

Embedded firmware and data acquisition

Candidate tools: QEMU or Renode where target models exist, native unit tests, hardware-in-the-loop and actual vehicle measurements.

Hidden assumption: Timing, dropped messages, electrical conditions, and firmware failures will not invalidate the collected data.

Diagnostic knowledge and AI reasoning

Candidate tools: Python, retrieval evaluation, vector search, knowledge graphs, benchmark datasets and evidence-linked test cases.

Hidden assumption: Retrieved manuals and AI-generated explanations are accurate, relevant to the vehicle configuration, and sufficiently grounded to support the recommendation.

A suitable research hypothesis is:

Combining validated vehicle telemetry, explicit diagnostic rules, relevant retrieved service information, and evidence-linked AI explanations may improve diagnostic usefulness and auditability compared with an LLM-only baseline.

This is a hypothesis to test, not a proven result. Evaluation should include diagnostic accuracy, unsupported-claim rate, retrieval relevance, response latency, robustness to missing data, and the clarity of uncertainty communicated to users.

10.2 Case study B — smart inverter and distributed energy resources

A smart inverter combines electrical power conversion, sensing, control algorithms, embedded firmware, communications, and potentially supervisory monitoring or AI.

Its hidden questions concern both computation and physical behaviour:

  • Does the control loop meet its sampling and response-time requirements?
  • Is the selected processor or programmable logic sufficient for the control workload?
  • Are numerical precision and sensor delays acceptable?
  • What happens when communication is lost or sensor data is invalid?
  • Which functions must remain independent of a supervisory AI service?
  • How will the system be tested against electrical operating conditions and fault scenarios?

Function

Candidate approach

Evidence required

Power-stage behaviour

Circuit simulation and laboratory prototype

Electrical waveforms, losses, transient response

Control algorithms

MATLAB/Simulink or equivalent modelling

Stability analysis, response and numerical-error evaluation

Time-critical control

MCU, DSP, FPGA, or SoC implementation

Measured execution time, sampling behaviour, fault response

Supervisory functions

Embedded Linux or RTOS, depending on constraints

Integration tests, resource use, communication behaviour

AI and analytics

Separate supervisory software where justified

Accuracy, latency, uncertainty, and safe failure behaviour

System verification

Model-based tests, hardware-in-the-loop, physical tests

Traceable evidence against requirements

A useful hypothesis is that partitioning critical control and supervisory analytics according to measured timing and fault-containment requirements can reduce integration risk. That proposition must be tested against a defined baseline.

Safety boundary: AI should not be assumed suitable for a safety-critical control loop merely because it performs well in offline prediction. The control architecture, protection mechanisms, fault responses, and applicable standards must be established independently.

11. A practical literature and tool-selection procedure for IAS-Research.com

The following procedure turns the resource list into a repeatable research method.

  1. Define the research problem.
  2. Write one clear problem statement, one principal research question, and several subordinate questions. Use The Craft of Research to distinguish the topic from the problem that makes the research necessary.
  3. Build a literature search strategy.
  4. Search Google Scholar, IEEE Xplore, ACM Digital Library, SpringerLink, university repositories, and official project websites. Use phrases such as “hardware software co-design,” “electronic system-level design,” “transaction-level modelling,” “virtual prototyping,” “FPGA accelerator,” and “RISC-V hardware/software co-design.”
  5. Record and classify sources.
  6. Use Zotero or another reference manager to record the citation, publication type, URL/DOI, research question, method, assumptions, evidence, limitations, and relevance to the project.
  7. Reproduce one baseline.
  8. Select a small, well-documented example. Build and test it before making architectural modifications. Record the hardware, software, compiler, model, tool versions, workload, and measurements.
  9. Develop an assumption register.
  10. For every critical assumption, record its rationale, confidence, consequence if false, verification method, owner, and status.
  11. Select the smallest sufficient toolchain.
  12. Begin with the tools required to answer the research question. Add specialist tools only when the current evidence cannot resolve an important uncertainty.
  13. Run controlled experiments.
  14. Change one major design variable at a time where practical. Establish a baseline, repeat experiments, report uncertainty, and compare complete-system outcomes rather than isolated components alone.
  15. Publish reproducible findings.
  16. Document methods, configurations, test cases, results, limitations, and future questions. Release code and models when licensing, confidentiality, and safety constraints permit.

For a formal systematic review, the team should also document search dates, exact queries, inclusion and exclusion criteria, duplicate removal, screening decisions, and the reasons for excluding sources.

12. Strategic roles of IAS-Research.com, KeenComputer.com, and KeenDirect.com

The research landscape supports a clear division of responsibility between research, implementation, and hardware/product enablement.

IAS-Research.com — research, architecture, and innovation

  • Develop the literature review and identify unanswered research questions.
  • Apply MBSE, SysML/UML, BDD, and assumption-driven research methods.
  • Design experiments for SystemC/TLM, virtual platforms, FPGA prototypes, and embedded systems.
  • Produce technical reports, white papers, architecture models, and research-led feasibility assessments.
  • Help SMEs, universities, and engineering organisations evaluate innovation opportunities.

KeenComputer.com — implementation, integration, and engineering services

  • Build software and embedded-system prototypes.
  • Implement Linux, RTOS, automation, CI, integration tests, and deployment workflows.
  • Integrate open-source tools with commercial toolchains where needed.
  • Develop reproducible builds, diagnostic software, monitoring, and lifecycle support.
  • Turn a research result into a testable proof of concept and a maintainable implementation.

KeenDirect.com — hardware sourcing and product enablement

  • Support the sourcing of development boards, interfaces, components, and test equipment.
  • Help document hardware options and compatibility requirements.
  • Connect engineering prototypes with product selection and procurement needs.
  • Support the transition from a research bill of materials to a practical prototype or product offering.

These are proposed strategic roles for KeenDirect.com, not a claim that a particular supplier or inventory has been established.

Together, the three organisations can offer a coherent SME-oriented pathway:

Research question → literature and feasibility study → architecture and model → prototype → verification evidence → implementation and support → product enablement.

13. Recommended reference websites and repositories

The following directory consolidates the principal starting points discussed in this section.

Academic literature and university projects

Open-source tools

Commercial tools

14. Conclusion: from tool catalogues to evidence-driven co-design

The main contribution of this research landscape is not a list of recommended software products. It is a method for connecting research questions to appropriate books, papers, university projects, open-source implementations, commercial tools, and measurable evidence.

A sound hardware–software co-design study should be able to explain:

  • Why the problem matters.
  • What is not yet known.
  • Which assumptions could invalidate the proposed architecture.
  • Why each selected tool is appropriate to the question.
  • What the experiments can establish—and what they cannot.
  • How results will be reproduced and independently reviewed.
  • How the research could lead to a useful engineering solution or commercial product.

This is where The Craft of Research becomes strategically useful: it disciplines the reasoning behind the engineering work. SystemC/TLM, virtual platforms, RTL tools, MBSE, simulation, and physical test equipment then provide different means of collecting the evidence required to support or reject the team's claims.

For IAS-Research.com, the next logical step is to turn this literature review into a living research matrix linked to the project requirements, assumption register, Sparx Enterprise Architect model, tool evaluation, experiments, and verification evidence. That would make the white paper the foundation for a repeatable HW/SW co-design methodology rather than a static bibliography.