A Practical Engineering Tutorial: SystemC/TLM-2.0, OVP and Model-Based System Design on Kubuntu Linux

Technical tutorial and implementation guide · IAS-Research.com · October 2026

Subtitle: From requirements and SysML architecture to executable virtual platforms, embedded software, RTOS/Linux, and FPGA hardware/software co-design.

Abstract

Modern embedded systems combine processors, memory subsystems, communication buses, peripherals, firmware, real-time operating systems, embedded Linux, and custom hardware. Developing these elements independently can lead to integration problems, expensive hardware iterations, and late discovery of architectural defects.

This tutorial presents a practical development methodology based on SystemC, Transaction-Level Modeling (TLM-2.0), Open Virtual Platforms (OVP), and Model-Based Systems Engineering (MBSE). It describes how to establish a SystemC development environment on Kubuntu, create transaction-level models, validate a memory-mapped subsystem, integrate an instruction-set simulator where supported, and progressively develop an executable virtual prototype.

The methodology is intended for embedded software engineers, hardware architects, FPGA developers, systems engineers, and research teams. Example applications include automotive diagnostics, OBD-AI, smart-grid controllers, ARM-based embedded Linux, RTOS systems, and FPGA-based control platforms.

A central principle is to validate the architecture and software-visible behavior before committing to detailed RTL implementation or physical hardware.

1. Learning objectives

By following this tutorial, you should be able to:

• Install and validate a C++ and SystemC development environment on Kubuntu.
• Explain the difference between SystemC simulation, TLM-2.0, and processor instruction-set simulation.
• Build a working TLM initiator, target, and memory-mapped subsystem.
• Define address maps, transactions, timing assumptions, and error handling.
• Understand the requirements for integrating an OVP processor model with a SystemC platform.
• Develop an MBSE workflow connecting requirements, architecture, models, software tests, and implementation.
• Extend the basic platform toward RTOS, embedded Linux, FPGA peripherals, and hardware/software co-design.
• Establish repeatable verification, regression testing, and continuous integration.

2. Reference architecture

Requirements and system design

Use cases · SysML/UML · interfaces · performance constraints

SystemC simulation kernel

Discrete-event simulation · processes · simulated time

Processor subsystem

OVP instruction-set model, firmware, processor-visible memory map

TLM interconnect

Initiator/target sockets, routing, transactions and timing

Memory

RAM / ROM

Peripherals

UART / timer / GPIO

Interfaces

CAN / SPI / I²C

Verification and implementation

Firmware tests · RTOS/Linux · trace analysis · RTL/FPGA · hardware validation

The architecture is conceptual: the exact processor-to-TLM bridge depends on the OVP product, processor model, and integration APIs available to your installation.

3. SystemC, TLM-2.0 and OVP: technical foundations

3.1 What is SystemC?

SystemC is a C++-based system-level modeling language and simulation environment standardized under IEEE 1666. The Accellera reference implementation provides the SystemC kernel, data types, and TLM support.

GitHub

+1

Its main concepts are:

• Modules: components representing processors, memory, peripherals or subsystems.
• Ports and interfaces: communication boundaries between modules.
• Processes: SC_THREAD, SC_METHOD and related constructs describing behavior.
• Events and time: mechanisms for coordinating simulation activity.
• Signals and channels: communication mechanisms for functional and timed models.

A SystemC simulation uses simulated time. Advancing simulated time by 100 microseconds does not require the host computer to wait 100 microseconds in real time.

3.2 What is TLM-2.0?

TLM-2.0 describes communication between hardware components at transaction level. Instead of modeling every electrical signal transition, a model can represent a bus access as a transaction containing an address, operation, data, attributes, and response status.

For example, a processor writing a control register might initiate a transaction to address 0x40001000. The interconnect routes it to the appropriate peripheral, which updates its internal state and returns a response.

Important TLM concepts include:

Concept	Purpose
Initiator socket	Sends transactions
Target socket	Receives transactions
Generic payload	Carries command, address, data and status
b_transport	Blocking transport interface
nb_transport_fw / nb_transport_bw	Forward and backward paths for nonblocking transport
Delay annotation	Represents modeled latency
DMI	Direct memory access optimization where supported
TLM utilities	Reusable sockets, interconnect helpers and related components

Two common coding styles are loosely timed (LT) and approximately timed (AT). LT is useful for early architectural validation. AT is appropriate when transaction phases, synchronization, and more detailed protocol timing matter.

Important: TLM does not automatically guarantee accurate bus timing. The designer must explicitly implement the timing and protocol properties required by the intended analysis.

3.3 What is OVP?

Open Virtual Platforms provides processor-model and virtual-platform technology associated with Imperas, now part of the Synopsys ecosystem.

OVP-style instruction-set simulation can execute compiled processor instructions without the physical CPU. A processor model can run firmware, while peripheral models provide the software-visible behavior of the target system.

There are two distinct integration tasks:

1. Load and execute firmware using the selected processor simulator.
2. Connect processor memory accesses and relevant events to the SystemC/TLM platform.

The second task is integration-specific. A standalone processor simulator does not automatically become a TLM initiator merely because both technologies are installed.

Before committing to a combined platform, establish which processor model, simulator API, bridge, licensing terms and synchronization mechanism your chosen OVP package supports.

4. Prepare the Kubuntu development workstation

The following procedure assumes an x86-64 Kubuntu workstation. The instructions are suitable for a typical Ubuntu-based environment, but package availability and versions vary by release.

4.1 Install build dependencies

sudo apt update sudo apt install -y \ build-essential \ cmake \ ninja-build \ git \ pkg-config \ gdb \ python3 \ python3-venv \ python3-pip \ doxygen \ graphviz

Check the host architecture and compiler:

uname -m g++ --version cmake --version ninja --version

For the current SystemC reference implementation, use a compatible C++17 compiler and CMake. Accellera recommends CMake and documents its installation and package-discovery process in the official installation guide.

GitHub

+1

4.2 Obtain SystemC

mkdir -p ~/eda/src cd ~/eda/src git clone https://github.com/accellera-official/systemc.git cd systemc git tag --sort=-version:refname | head -10

Review the release notes and choose a stable version. For reproducibility, record the exact tag or commit used by your project.

If a tag is selected, check it out explicitly:

git checkout <RELEASE_TAG>

Replace <RELEASE_TAG> with the real tag shown by Git; do not type the placeholder literally.

4.3 Configure and compile SystemC

cd ~/eda/src/systemc cmake -S . -B build -G Ninja \ -DCMAKE_BUILD_TYPE=Release \ -DCMAKE_CXX_STANDARD=17 \ -DCMAKE_CXX_STANDARD_REQUIRED=ON \ -DCMAKE_INSTALL_PREFIX=/opt/systemc cmake --build build --parallel 4 ctest --test-dir build --output-on-failure

Inspect the test results. If compilation and tests succeed, install:

sudo cmake --install build

The official build files export CMake packages, including SystemCLanguage and SystemCTLM; the TLM headers are supplied with the SystemC installation.

GitHub

+1

Check the installation:

find /opt/systemc -name 'SystemCLanguageConfig.cmake' find /opt/systemc -name 'libsystemc*' find /opt/systemc -path '*/include/tlm'

If a library or package configuration is not found, inspect the installation prefix and CMake output rather than assuming a fixed library directory.

4.4 Configure a project environment

Create a workspace:

mkdir -p ~/projects/mbse-tlm/{src,include,tests,models,docs,scripts} cd ~/projects/mbse-tlm

For individual projects, prefer passing the installation prefix to CMake:

cmake -S . -B build \ -DCMAKE_PREFIX_PATH=/opt/systemc

This is more reliable than depending exclusively on manually configured linker paths.

If the executable cannot find the shared library at runtime, inspect the installation:

ldd ./build/tlm_lab

For a temporary test, set LD_LIBRARY_PATH to the actual directory containing libsystemc.so. For a persistent system installation, use an appropriate library configuration or packaging strategy.

5. Create the first executable TLM model

This exercise builds a small memory subsystem with an initiator and target. It validates the native SystemC/TLM environment before adding a processor simulator.

5.1 Define the project

Create CMakeLists.txt:

cmake_minimum_required(VERSION 3.16) project(mbse_tlm_lab LANGUAGES CXX) find_package(SystemCLanguage CONFIG REQUIRED) set(CMAKE_CXX_STANDARD 17) set(CMAKE_CXX_STANDARD_REQUIRED ON) add_executable(tlm_lab src/main.cpp) target_link_libraries( tlm_lab PRIVATE SystemC::systemc )

Create src/main.cpp:

#include <systemc> #include <tlm> #include <tlm_utils/simple_initiator_socket.h> #include <tlm_utils/simple_target_socket.h> #include <cstdint> #include <cstring> #include <iostream> using namespace sc_core; struct Memory : sc_module { tlm_utils::simple_target_socket<Memory> socket; std::uint32_t value = 0; SC_CTOR(Memory) : socket("socket") { socket.register_b_transport( this, &Memory::transport ); } void transport( tlm::tlm_generic_payload& tx, sc_time& delay ) { if (tx.get_address() != 0x1000 || tx.get_data_length() != sizeof(value) || tx.get_streaming_width() < sizeof(value) || tx.get_byte_enable_ptr() != nullptr) { tx.set_response_status( tlm::TLM_ADDRESS_ERROR_RESPONSE ); return; } if (tx.get_command() == tlm::TLM_WRITE_COMMAND) { std::memcpy(&value, tx.get_data_ptr(), sizeof(value)); } else if ( tx.get_command() == tlm::TLM_READ_COMMAND ) { std::memcpy(tx.get_data_ptr(), &value, sizeof(value)); } else { tx.set_response_status( tlm::TLM_COMMAND_ERROR_RESPONSE ); return; } delay += sc_time(10, SC_NS); tx.set_response_status(tlm::TLM_OK_RESPONSE); } }; struct CPU : sc_module { tlm_utils::simple_initiator_socket<CPU> socket; SC_CTOR(CPU) : socket("socket") { SC_THREAD(run); } void access(tlm::tlm_command cmd, std::uint32_t& data) { tlm::tlm_generic_payload tx; sc_time delay = SC_ZERO_TIME; tx.set_command(cmd); tx.set_address(0x1000); tx.set_data_ptr( reinterpret_cast<unsigned char*>(&data)); tx.set_data_length(sizeof(data)); tx.set_streaming_width(sizeof(data)); tx.set_response_status( tlm::TLM_INCOMPLETE_RESPONSE); socket->b_transport(tx, delay); if (tx.is_response_error()) { SC_REPORT_ERROR("CPU", "TLM access failed"); } wait(delay); } void run() { std::uint32_t data = 42; access(tlm::TLM_WRITE_COMMAND, data); data = 0; access(tlm::TLM_READ_COMMAND, data); std::cout << "Read value = " << data << " at " << sc_time_stamp() << std::endl; sc_stop(); } }; int sc_main(int, char**) { Memory memory("memory"); CPU cpu("cpu"); cpu.socket.bind(memory.socket); sc_start(); return 0; }

The code is a teaching model, not a production memory component. It deliberately supports one address and one 32-bit value. A production model should validate null data pointers, byte enables, burst and streaming behavior, alignment, address ranges, reset behavior, and other required protocol rules.

5.2 Build and execute

From the project root:

cmake -S . -B build \ -DCMAKE_PREFIX_PATH=/opt/systemc cmake --build build --parallel 4 ./build/tlm_lab

The expected output is:

Read value = 42 at 20 ns

The write adds 10 ns of annotated latency, and the read adds another 10 ns. The simulation time advances when the initiator waits for the annotated delay.

The test establishes that:

• The SystemC simulation kernel starts and stops correctly.
• The TLM initiator binds to the target.
• A transaction reaches the target.
• The target stores and returns data.
• Simulated delay affects the reported simulation time.

It does not establish processor instruction execution, real bus throughput, arbitration behavior, or cycle-accurate hardware timing.

6. Extend the model into a memory-mapped SoC

Once the initial transaction works, replace the single-address memory with a system address map and reusable peripheral models.

6.1 Example address map

The following is an illustrative architecture, not a standard address assignment.

Component	Base address	Size	Purpose
Boot ROM	0x00000000	64 KiB	Startup code
SRAM	0x20000000	256 KiB	Working memory
UART	0x40000000	4 KiB	Serial console
Timer	0x40001000	4 KiB	Timing and interrupts
GPIO	0x40002000	4 KiB	Digital I/O
CAN controller	0x40003000	4 KiB	Automotive or industrial communication

Document the map in a machine-readable file so that the hardware model, firmware headers, testbench and design documentation use consistent definitions.

Example models/address-map.yaml:

address_map: - name: boot_rom base: 0x00000000 size: 0x00010000 access: read_only - name: sram base: 0x20000000 size: 0x00040000 access: read_write - name: uart base: 0x40000000 size: 0x00001000 access: read_write - name: timer base: 0x40001000 size: 0x00001000 access: read_write - name: gpio base: 0x40002000 size: 0x00001000 access: read_write

A YAML file does not configure the SystemC interconnect automatically. Your platform must implement the address decoder, route transactions to the correct target, and reject unmapped addresses. A generator can later produce C/C++ constants, firmware headers, and documentation from the same source.

6.2 Model a peripheral using registers

A timer peripheral can expose a small register interface:

Offset	Register	Example behavior
0x00	Control	Enable or disable timer
0x04	Counter	Current counter value
0x08	Compare	Interrupt threshold
0x0C	Status	Pending interrupt flag

Model the behavior in stages:

1. Implement register reads and writes.
2. Validate supported access sizes and offsets.
3. Define reset values.
4. Add counter progression and interrupt events.
5. Add interrupt clearing and edge cases.
6. Test the firmware-visible behavior.
7. Add detailed timing only when the project requires it.

Keep register semantics separate from bus transport where practical. This improves reuse and makes it easier to compare the model against an RTL peripheral specification.

6.3 Add an interconnect

For a small system, an address-decoding target can route transactions to multiple peripherals. For more complex platforms, reusable interconnect components or TLM utilities can reduce custom code.

The interconnect should explicitly define:

• Address decoding and unmapped-address behavior.
• Supported transaction types and access widths.
• Arbitration policy if multiple initiators share a resource.
• Latency and contention assumptions.
• Error responses.
• Whether direct-memory-interface access is enabled.

A single initiator connected directly to a single target is a useful first exercise, but it is not yet a realistic multicore or multi-master SoC.

7. Integrate an OVP processor model

This is the most integration-sensitive part of the tutorial. SystemC can be installed independently, but a working OVP-to-TLM platform also needs a compatible processor model and a supported connection mechanism.

7.1 Decide which simulation level is required

Level A — Native SystemC/TLM

Model system behavior, memory and peripherals. Use a software testbench to generate transactions.

Best first milestone: no processor integration required.

Level B — Instruction-set simulation

Execute a compiled program using a standalone processor simulator. Verify instruction execution and the simulator's firmware-loading workflow.

Establishes that the selected processor model and toolchain work.

Level C — Integrated virtual platform

Connect processor-visible memory accesses to SystemC/TLM targets and coordinate simulation time and events.

Requires the integration APIs and bridge supported by your specific package.

7.2 Verify the OVP installation

After obtaining the appropriate package from the official provider, record its version, supported processor models and installation requirements.

Inspect the installed executables and supplied examples using the package's documentation. Do not assume every OVP installation uses the same directory layout or executable names.

Confirm the following:

• The simulator starts successfully.
• A model of your target ISA is available.
• The toolchain produces binaries compatible with that model.
• The simulator can load and execute the supplied sample program.
• The model exposes the required memory, interrupt, exception and debug behavior.
• The available integration interface supports your intended SystemC/TLM connection.

Official resources:

• OVP documentation and information
• Synopsys product and support resources

7.3 Compile firmware for the modeled processor

A native Kubuntu executable cannot generally be loaded directly into an ARM or RISC-V instruction-set simulator. Build the program for the target architecture.

For example, a RISC-V bare-metal toolchain may be installed from the distribution repositories if available:

sudo apt install gcc-riscv64-unknown-elf \ binutils-riscv64-unknown-elf

Check the actual package names for your Kubuntu release before installation.

Verify the compiler:

riscv64-unknown-elf-gcc --version riscv64-unknown-elf-objdump --version

Compile a simple test using the appropriate startup code, linker script, ISA and ABI for the selected processor model. Then inspect the result:

riscv64-unknown-elf-objdump -h firmware.elf riscv64-unknown-elf-objdump -d firmware.elf

These commands inspect an ELF binary; they do not by themselves run it in OVP. The firmware's ISA, memory layout, entry point and ABI must match the selected processor model.

For ARM, Cortex-M and AArch64, choose the corresponding compiler and target configuration rather than using the RISC-V example unchanged.

7.4 Connect processor accesses to TLM

A typical integrated platform contains these components:

1. Processor model: executes the target instructions.
2. Memory interface: exposes RAM and ROM according to the processor's model interface.
3. Address bridge: translates processor reads and writes into TLM transactions, or uses a vendor-provided integration layer.
4. TLM interconnect: routes transactions to the correct target.
5. Peripheral models: implement UART, timers, GPIO, CAN or other devices.
6. Interrupt bridge: communicates peripheral events to the processor model.
7. Time synchronization: ensures the processor and SystemC simulation remain consistent.

Before writing a bridge, answer these design questions:

• Does the selected processor integration provide callback-based memory access, a native TLM socket, or another mechanism?
• How are instruction execution and SystemC time synchronized?
• How are exceptions, resets and interrupts communicated?
• Can memory accesses be cached or bypass the modeled interconnect?
• Which timing properties are preserved, and which are approximated?

These decisions determine the implementation. A generic, vendor-independent bridge cannot be specified correctly without knowing the selected OVP package and interface.

7.5 A practical integration acceptance test

Use a small bare-metal program that performs the following operations:

1. Reads a known RAM location.
2. Writes a test pattern to RAM.
3. Writes a character to the UART transmit register.
4. Programs a timer.
5. Waits for a timer event or interrupt.
6. Reads peripheral status.
7. Reports completion through a debug interface.

The integrated model should verify not only the final output but also transaction addresses, data values, response statuses, interrupt behavior and simulation-time assumptions.

8. Model-Based Systems Engineering (MBSE)

MBSE provides the process for deriving the executable platform from system requirements and architecture.

A practical workflow combines requirements management, SysML/UML diagrams, executable C++ models, firmware, test cases and implementation evidence.

8.1 Build a traceable system model

Use a modeling tool such as Sparx Enterprise Architect to capture:

• Requirements and their relationships.
• System context and external actors.
• Functional decomposition.
• Logical and physical architecture.
• Interfaces, ports and data flows.
• Timing and performance requirements.
• Verification cases and acceptance criteria.

SysML is useful for expressing system structure and behavior, but the degree of automation from diagrams to C++/SystemC depends on the selected tooling, model profile and generation process.

8.2 Example traceability chain

REQ-TMR-001

The controller shall generate a timer event within the specified deadline.

SYS-TMR-01

Timer peripheral, interrupt controller and processor interface.

MODEL-TMR-01

SystemC model of counter, compare register, status and interrupt behavior.

TEST-TMR-001

Configure timer, advance simulation and verify event timing and status.

Verification evidence

Test result, trace, model version and requirement status.

The timing requirement should include a numerical deadline and a clearly defined start and end event. For example, a deadline might be measured from the timer's programmed compare event to interrupt assertion. The actual value must come from the system requirements, not an arbitrary example.

8.3 Manage the model as an engineering artifact

Store model source, architecture diagrams, register specifications, test cases and build instructions under version control. Each verified build should identify:

• Source revision.
• Compiler and tool versions.
• Configuration parameters.
• Test results.
• Model assumptions.
• Known limitations.

This makes the virtual prototype useful for design reviews and later regression testing rather than merely a demonstration that runs on one workstation.

9. RTOS and embedded Linux development

SystemC/TLM and processor simulation are especially valuable when the target firmware interacts with memory-mapped devices, interrupt sources, boot firmware and device drivers.

However, executing a full RTOS or Linux distribution requires a sufficiently complete processor and platform model. A simple TLM memory model does not provide a bootable machine.

9.1 RTOS workflow

For an RTOS-based design:

1. Select the target processor architecture and ABI.
2. Create a linker script and startup code matching the memory map.
3. Implement clock, timer, interrupt and serial-device models.
4. Integrate the RTOS port and board-support package.
5. Verify scheduler startup, task switching and interrupt handling.
6. Add timing measurements and stress tests.
7. Compare model behavior against a reference implementation or target board.

9.2 Embedded Linux workflow

A Linux-capable platform generally requires a processor with the relevant privilege modes and MMU support, a boot strategy, memory, interrupt handling, a timer, a console, and the devices required by the kernel and device tree.

A typical development chain is:

• Cross-compile the bootloader, Linux kernel and root filesystem.
• Define the memory map and platform devices.
• Configure the kernel and device tree for the modeled hardware.
• Implement the necessary device models.
• Boot the guest and inspect console output.
• Validate device-driver interactions.
• Add performance and fault-injection tests.

OVP may be suitable when its selected models and integrations meet these requirements. Another option is QEMU system emulation, which supports ARM and RISC-V system models and can boot guest operating systems on supported machine types.

QEMU documentation

+2

QEMU and OVP should be chosen based on the required processor models, board support, licensing, debug capabilities, performance, and integration needs.

10. Hardware/software co-design and FPGA implementation

The purpose of a virtual prototype is not to eliminate hardware design. It is to help establish requirements, interfaces, and behavior before implementation becomes expensive to change.

A recommended sequence is:

1. Establish the functional architecture.
2. Explore processor, memory and interconnect choices.
3. Identify functions that should execute in software and those that may need hardware acceleration.
4. Implement behavioral TLM models.
5. Evaluate algorithmic and communication bottlenecks.
6. Define register maps, interrupts and DMA interfaces.
7. Implement the selected hardware in RTL.
8. Integrate the firmware and hardware on an FPGA platform.
9. Compare measured hardware behavior with the assumptions made in the virtual prototype.

SystemC/TLM can explore architectural trade-offs, but loosely timed models cannot reliably predict all physical timing, signal-integrity effects, FPGA resource use or cycle-level contention. Detailed RTL simulation, synthesis, static timing analysis and hardware measurements remain necessary.

11. Engineering use cases

11.1 OBD-AI: automotive diagnostics and vehicle interfaces

An automotive diagnostic platform can use SystemC/TLM to model an ECU, memory-mapped CAN controller, timers, interrupt paths and diagnostic firmware.

esol.com

A useful development plan is:

• Implement a virtual ECU with registers and diagnostic state.
• Model CAN-controller behavior at the abstraction level required by the tests.
• Exercise diagnostic firmware and communication error paths.
• Verify how DTC data and sensor information reach the host application.
• Connect captured or simulated diagnostic data to the OBD-AI knowledge and reasoning pipeline.
• Validate the final behavior against a real ECU and controlled CAN test equipment.

IAS-Research contribution: system architecture, virtual-platform design, verification methodology, and integration of diagnostic knowledge with AI.

KeenComputer contribution: development environment, software integration, test automation, and deployment of the supporting IT infrastructure.

11.2 Smart-grid controllers and power electronics

imperix.com

For a smart-grid or power-electronics controller, the digital platform can model:

• ADC result registers and sensor interfaces.
• PWM configuration registers.
• Timer and interrupt behavior.
• Communications with supervisory controllers.
• Control-state transitions and fault handling.
• DMA or data-acquisition pathways where applicable.

Couple the digital controller model to an appropriate electrical simulation environment when studying plant behavior. SystemC/TLM is not a replacement for detailed power-system transient simulation in PSCAD or MATLAB/Simulink.

A co-simulation interface can pass control commands and sampled values between the electrical model and the digital platform. The interface must define units, timestamps, sample rates, synchronization, and the consequences of different solver time steps.

11.3 FPGA-based embedded systems

For FPGA systems, use the virtual platform to evaluate the processor's software-visible interface before RTL implementation.

Potential tasks include:

• Register and memory-map definition.
• Interrupt routing and priorities.
• DMA buffer ownership.
• Peripheral reset behavior.
• Processor-to-accelerator communication.
• Driver and firmware testing.

A TLM model is particularly valuable when firmware and hardware are being developed by separate teams. Both teams can work against the same interface contract before the physical implementation is available.

12. Verification strategy

A reliable model-based workflow uses multiple levels of verification rather than treating a successful simulation run as proof of correctness.

Test level	What to verify
Unit	Individual memory and peripheral behaviors
Interface	Transaction commands, addresses, data and response statuses
Integration	Address decoding, interrupts and peripheral interactions
Firmware	Startup, drivers, error handling and application behavior
Timing	Modeled latency, deadlines and synchronization assumptions
Regression	Previously passing tests remain valid after changes
Hardware correlation	Model behavior agrees with measured target behavior where expected

12.1 Automated regression tests

Use CTest to run simulation tests from the build system. Each test should have a defined pass/fail condition and a timeout to prevent a hung simulation from blocking the entire test suite.

A project might contain:

tests/ ├── test_memory_read_write.cpp ├── test_unmapped_address.cpp ├── test_timer_compare.cpp ├── test_interrupt_delivery.cpp └── test_reset_behavior.cpp

The filenames are an example of an intended project layout; they must be implemented and registered with CTest before they can be executed.

For automated verification, record the expected result, actual result, simulated time, source revision, and any relevant configuration. Keep diagnostic traces when a test fails.

12.2 Timing and accuracy

Distinguish three different quantities:

• Wall-clock time: how long the simulation takes to run on Kubuntu.
• Simulation time: the time maintained by the SystemC kernel.
• Target execution time: the real hardware time that the model is intended to approximate.

These values are not interchangeable. A simulation that advances by one millisecond does not necessarily take one millisecond to execute, nor does that simulated millisecond necessarily correspond to the target's actual execution time.

13. Troubleshooting on Kubuntu

Problem: CMake cannot find SystemC

Check the package location:

find /opt/systemc -name 'SystemCLanguageConfig.cmake'

Reconfigure using the correct installation prefix:

cmake -S . -B build \ -DCMAKE_PREFIX_PATH=/opt/systemc

If necessary, inspect the installation tree and pass the directory containing the CMake package configuration.

Problem: tlm_utils/simple_initiator_socket.h is missing

Check whether the TLM utility headers were installed:

find /opt/systemc -name simple_initiator_socket.h

Verify that the source and installed headers belong to the same SystemC release. Avoid mixing headers and libraries from different installations.

Problem: shared-library loading fails

Inspect dynamic dependencies:

ldd ./build/tlm_lab

Confirm that the SystemC shared library exists and is discoverable by the runtime linker.

Problem: SystemC/TLM compiles, but firmware does not run

Native compilation validates the host-side model, not the processor instruction set. Check the firmware architecture, entry point, linker script, ABI, startup code and processor-model support.

Problem: processor and peripheral timing disagree

Verify time synchronization, transaction delay handling, interrupt delivery, event scheduling and any modeled execution quantum. A bridge that transfers data correctly may still implement inaccurate timing.

Problem: Linux fails to boot

Check the reset vector, bootloader assumptions, RAM size, kernel architecture, device tree, timer, interrupt controller, console and required peripheral models. A minimal TLM memory target is not sufficient to boot Linux.

14. Suggested development roadmap

1. Week 1 — Development environment
2. Install CMake, GCC and SystemC. Build and run the basic TLM memory test. Commit the source, build instructions and expected output to version control.
3. Week 2 — SoC modeling
4. Implement the address decoder, RAM, ROM, UART and timer. Define register semantics and build automated tests for valid and invalid transactions.
5. Week 3 — Processor simulation
6. Install the selected OVP/Imperas package, confirm processor-model availability, build compatible firmware and execute a standalone instruction-set simulation.
7. Week 4 — Virtual-platform integration
8. Integrate the processor model using the supported bridge, implement interrupt and time synchronization, and execute firmware that accesses modeled peripherals.
9. Weeks 5–6 — MBSE and verification
10. Connect requirements to architecture, models and tests. Add regression automation, traceability and a documented set of simulation assumptions.
11. Weeks 7–8 — Application prototype
12. Extend the platform toward an automotive diagnostic controller, smart-grid controller or FPGA-based embedded system. Correlate the results with an independent simulator or physical hardware where appropriate.

These are planning estimates, not guaranteed completion times. OVP package access, processor-model availability, firmware readiness and integration complexity can substantially affect the schedule.

15. Strategic role of IAS-Research and KeenComputer

The combination of MBSE, SystemC/TLM, processor simulation and verification can form a reusable engineering service rather than a one-off simulation project.

IAS-Research.com — Research and architecture

• Requirements engineering and SysML/UML architecture.
• System-level modeling and hardware/software partitioning.
• Virtual-platform methodology and design-space exploration.
• Verification strategy, technical reports and engineering training.

KeenComputer.com — Engineering implementation

• Kubuntu-based engineering workstation and build environment.
• SystemC/TLM model development and integration.
• Firmware, RTOS and embedded Linux development support.
• Automated regression, debugging and engineering toolchain maintenance.

KeenDirect.com — Potential commercialization channel

• Distribution of training material, engineering templates and approved software or hardware products.
• Packaging of reusable development kits and reference-platform documentation.
• Online technical resources and customer onboarding.

A commercially viable initial offering could be an Embedded System Architecture and Virtual-Prototyping Assessment. The deliverables might include a requirements review, a block-level architecture, a software/hardware partitioning proposal, a demonstrator TLM model, a risk register and a staged implementation plan.

The engagement should define what is included in the model, what timing accuracy is achievable, which commercial licenses are required, and what remains to be verified on real hardware.

16. Recommended references and learning resources

The following resources provide the foundation for implementing and extending the tutorial.

1. Accellera — SystemC Reference Implementation

The primary source for installation, CMake configuration, SystemC APIs, release notes and examples.

GitHub

+1

Source repository · Installation guide

2. IEEE Std. 1666-2023 — SystemC Language Reference Manual

The normative language reference for SystemC semantics and simulation behavior. The standard is useful when defining a consistent modeling methodology.

GitHub

+1

SystemC standards and implementations

3. Accellera — TLM and SystemC documentation

Use the SystemC distribution's TLM headers, examples and documentation to learn generic payloads, sockets, blocking and nonblocking transport, timing annotation and direct memory interface.

Documentation and examples

4. Imperas / OVP — Processor models and virtual platforms

Consult the documentation for the specific simulator package, processor model, APIs, integration options and licensing terms.

GitHub

OVP information repository · Synopsys

5. QEMU — System emulation documentation

A useful alternative or complement for operating-system boot, processor emulation, machine models and device integration. Check the supported machine types and devices for your target.

QEMU documentation

+2

System emulation manual

Further reading

For deeper study, organize the literature review around these subjects:

• Transaction-level modeling methodology and timing abstraction.
• Virtual prototyping and instruction-set simulation.
• SysML-based requirements and architecture engineering.
• Hardware/software co-design and FPGA prototyping.
• Embedded Linux and RTOS architecture.
• Functional verification, regression testing and simulation correlation.

For academic and commercial projects, record the exact edition, publication year, release, and access date of each reference used in the final research paper.

17. Conclusion

SystemC/TLM-2.0 provides an effective foundation for executable system-level models. OVP can extend the workflow with processor instruction execution where an appropriate model and integration interface are available. MBSE provides the traceability connecting system requirements to architecture, executable models, firmware tests and hardware validation.

For Kubuntu, the most reliable path is incremental:

1. Establish a reproducible SystemC installation.
2. Build and test a standalone TLM model.
3. Expand it into a memory-mapped platform.
4. Validate the target processor and firmware in a standalone simulator.
5. Integrate the processor with the SystemC platform using the supported interface.
6. Connect requirements, tests and evidence through the MBSE workflow.
7. Validate timing assumptions and correlate results with the implemented hardware.

This sequence reduces integration risk while preserving a clear path from architectural research to practical embedded-system development.

Prepared as a technical tutorial for IAS-Research.com, with implementation and commercialization opportunities for KeenComputer.com and KeenDirect.com. The example code is an educational starting point and must be extended and verified before use in production or safety-critical systems.

• HARDWARE SOFTWARE CODESIGN
• CONSULTING ENGINEERING
• VIRTUAL PLATFROMS
• MODEL BASED SYSTEMS ENGINEERING
• WHY IASR