CANbus Protocol

Concept

CANbus (Controller Area Network bus) is a networking system used for in-vehicle data buses, standardized in ISO 11898. This article summarizes the CANbus message format (2.0A) and the typical SystemVerilog modeling constructs (structs, classes, and constraints) used to represent CANbus transactions in constrained-random verification testbenches.

First seen 6/9/2026

Last seen 6/9/2026

Evidence 2 chunks

Wiki v1

WIKI

Overview

CANbus is a networking system used for in-vehicle data buses, as described in ISO standard 11898. The protocol defines a serial message format used to transfer short, structured transactions between nodes on the bus. In verification contexts, the protocol is commonly modeled using SystemVerilog data structures that can be randomized under constraints to produce directed-random stimulus.

CANbus 2.0A Message Format

READ FULL ARTICLE →

NEIGHBORHOOD

No graph connections found for this entity yet. It may appear in future ingestion runs.

explore full graph →

RELATIONSHIPS

2 connections

CAN_Message class ← implements 95% 2e

The CAN_Message class implements a data model for CANbus protocol messages.

message_t struct ← implements 95% 1e

message_t struct implements the CANbus protocol message format fields.

LINKED ENTITIES

2 links

CAN_Message class IMPLEMENTS Extracted graph relationship

message_t struct IMPLEMENTS Extracted graph relationship

CITATIONS

6 sources

6 citations — click to expand

[1] CANbus is a networking system used for in-vehicle data buses, described in ISO standard 11898. Testbench Automation and Constraints Tutorial - Doulos

[2] The CANbus 2.0A message format contains an 11-bit identifier, an RTR bit, two reserved bits fixed at zero, a 4-bit data length field valid in 0–8, a 0–8 byte data payload, and a 15-bit CRC field. Testbench Automation and Constraints Tutorial - Doulos

[3] The `message_t` typedef struct maps CANbus fields to typed bit-vector members, marking ID, RTR, DLC, and data as `rand` while leaving reserved bits and CRC non-random, and uses an unpacked dynamic array for the payload to allow randomized length. Testbench Automation and Constraints Tutorial - Doulos

[4] Wrapping the message struct in the `CAN_Message` class enables methods (such as `set_RTR` and `clear_data`) and built-in hooks like `pre_randomize()` and `post_randomize()` to operate on CANbus fields. Testbench Automation and Constraints Tutorial - Doulos

[5] A typical `set_RTR` task sets the RTR bit and, when RTR is asserted, zeros DLC and clears the data list because remote-request frames must not carry payload data. Testbench Automation and Constraints Tutorial - Doulos

[6] The DLC field, although a 4-bit value (0–15), must be constrained to the CANbus-specified range 0–8 using either `DLC <= 8` or `DLC inside {[0:8]}`. Testbench Automation and Constraints Tutorial - Doulos