As automotive ECUs increasingly adopt software-defined and virtualized development flows, validating communication IPs early before RTL or silicon becomes critical. CAN-FD (Flexible Data Rate) remains a backbone protocol for automotive networks, and its correctness, performance, and its robustness must be verified at the system level.
This blog describes a cross-platform virtual testing approach where a CAN-FD TLM 2.0 model running on Ubuntu is tested using Vector CANoe executing on Windows, with both environments connected using SilKit APIs. This setup enables realistic, scalable, and automation-friendly validation of CAN-FD IPs in a virtual ECU context.
Cross-Platform Virtual CAN-FD Testing Using SilKit
Traditional CAN validation relies heavily on physical CAN controllers and hardware interfaces. While effective, such approaches limit early software development and slow down regression cycles. A TLM 2.0-based CAN-FD model allows system architects and software teams to begin validation much earlier in the development flow.
SilKit plays a central role in this setup by acting as a neutral integration layer between heterogeneous tools and operating systems. The CAN-FD TLM model executes on Ubuntu as a SilKit participant, while CANoe runs on Windows as the test controller and stimulus generator. SilKit provides a virtual CAN bus abstraction that synchronizes communication, timing, and error signaling across platforms. This enables seamless interoperability without requiring proprietary tool coupling or physical CAN hardware.
Architecture Overview
The overall architecture closely resembles a real automotive CAN network, implemented entirely in software. On the Ubuntu host, the CAN-FD TLM 2.0 model is instantiated as a SystemC component with TLM sockets and connected to SilKit’s CAN controller APIs. The model typically includes transmit and receive paths, buffering logic, error state handling, and optional interrupt signaling.
On the Windows host, Vector CANoe is configured with CAN network descriptions and test configurations. CANoe connects to the same SilKit registry and communicates with the Ubuntu host over TCP/IP. Time synchronization across participants ensures deterministic behavior, allowing CANoe to act as a realistic bus master while observing responses from the CAN-FD model as if it were a physical ECU.
CAN-FD Features Targeted for Testing
The testing scope focuses on validating the functional, protocol, and performance aspects of the CAN-FD TLM model. The model is exercised with both classical CAN and CAN-FD frames to ensure correct handling of backward compatibility and extended data lengths. Payload sizes from zero up to sixty-four bytes are tested to validate DLC encoding and decoding.
Bit Rate Switching behavior is verified by observing correct transitions between arbitration and data phases. Identifier handling, including both standard and extended IDs, is validated under varying bus loads. Arbitration behavior is tested by injecting competing frames and ensuring that priority rules are respected.
The controller’s internal behavior is also examined in detail. Transmit and receive state machines are monitored for correctness, acceptance filtering is verified, and FIFO handling is validated under stress conditions. Error counters, including transmit and receive error counts, are observed to ensure correct progression through error-active, error-passive, and bus-off states. Recovery mechanisms from bus-off conditions are also validated to ensure compliance with CAN-FD specifications.
CANoe Capabilities for Test Pattern Generation
Vector CANoe serves as a comprehensive test stimulus and analysis platform in this validation flow. Using CAPL scripts and configuration-based test setups, CANoe generates a wide range of CAN-FD traffic patterns. Frames can be transmitted periodically, in response to events, or in randomized sequences to simulate real vehicle network conditions.
CANoe allows dynamic modification of frame identifiers, payload lengths, data patterns, and CAN-FD-specific attributes such as the BRS and ESI bits. Error scenarios are intentionally introduced to test robustness, including malformed frames, invalid DLC values, CRC mismatches, and bus overload conditions. Multiple virtual CAN nodes can be simulated concurrently, enabling realistic network contention and stress testing of the CAN-FD model.
Pass and Fail Decision Criteria
A key strength of using CANoe is its automated and deterministic verdict mechanism. Each test case defines explicit expectations for frame reception, timing behavior, and state transitions. The CAN-FD model’s responses are continuously monitored against these expectations.
A test is marked as pass if transmitted frames are received correctly with expected payloads, CRCs, and timing constraints. Error handling behavior is verified by checking whether the model enters appropriate error states and recovers correctly when fault conditions are removed. Any unexpected frame loss, incorrect arbitration behavior, or deviation from protocol timing results in a fail verdict.
CANoe automatically generates detailed test reports that include pass or fail status, time-stamped logs, decoded protocol traces, and statistical summaries. These reports are well suited for regression testing and continuous integration pipelines.
Unit Test Setup for the CAN-FD TLM Model
Before integrating the model into the system-level SilKit and CANoe environment, unit testing is performed to validate the CAN-FD TLM model in isolation. The unit test environment consists of a standalone SystemC testbench where the CAN-FD controller is instantiated without external dependencies.
Stimulus is applied directly through TLM transactions to exercise transmit and receive paths. Clocking, reset behavior, and internal state transitions are validated in a controlled manner. Error conditions are injected at the transaction level to ensure that error counters, state machines, and recovery logic behave as expected. Unit testing enables fast debugging and ensures that the model is functionally stable before full system-level testing begins.
Quality Metrics for Testing Effectiveness
To ensure the thoroughness of validation, both code coverage and functional coverage metrics are used. Code coverage focuses on ensuring that all relevant statements, branches, and state machine transitions within the CAN-FD model are exercised during testing. This includes normal operation as well as error handling and corner cases.
Functional coverage measures how well the test suite exercises the CAN-FD feature set defined by the specification. Coverage points include frame types, payload sizes, identifier formats, error scenarios, arbitration conditions, and recovery sequences. Together, these metrics provide confidence that the CAN-FD TLM model has been validated comprehensively and systematically.
Conclusion
Validating a CAN-FD TLM 2.0 model on Ubuntu using CANoe on Windows through SilKit APIs enables an efficient, hardware-independent, and scalable testing strategy. This approach combines the strengths of industry-standard automotive test tools with modern virtual prototyping techniques, allowing early detection of issues and faster design convergence.
As automotive development increasingly relies on virtual platforms and software-defined architectures, such cross-platform validation methodologies form a critical foundation for building robust and reliable communication subsystems.
To learn more about automotive virtual prototyping, CAN-FD modeling, and SilKit-based integrations, follow LeadSOC blog page on LinkedIn and visit www.leadsoc.com for suitable opportunities.
