Verifying FSED in MIPI CSE v2.0 with Cadence VIP

Automotive camera systems face a threat model that goes beyond packet-level tampering. Someone with physical access to the camera data link could swap out an entire live video frame for a fabricated one while every individual packet checksum stays untouched — a gap that per-packet protection alone can't close. At the same time, that same link has to prove it can catch faults reliably enough to meet automotive safety requirements, frame after frame, at scale. 

The Frame-based Service Extensions Data (FSED) protocol in MIPI CSE v2.0 (Simulation VIP for MIPI CSI-2 | Cadence) takes on both challenges at once. It inserts dedicated cryptographic messages at defined frame partition boundaries to authenticate entire frame segments (the security service), while appending interlocking CRC-32 checks and message counters to those same messages to satisfy functional safety detection requirements (the Functional Safety, or FuSa, service). This frame-level approach is fundamentally more efficient for high-resolution camera systems than per-packet Service Extension Packet (SEP) protection, and verifying its correctness demands an equally sophisticated tool. 

Figure 1. FSED messages sit at fixed points in the CSI-2 frame  FSED_CTRL_SYNC after frame start, an optional FSED_TOP_TAG mid-frame, and FSED_FRAME_TAG before frame end. 

Introduction to FSED 

FSED works by inserting up to three dedicated messages directly into the CSI-2 frame, at fixed points in the packet sequence, rather than adding headers or footers to every packet the way MIPI's other CSE protocol, SEP, does. Each FSED message is simply a CSI-2 Embedded Data (ED) Long Packet — FSED_CTRL_SYNC right after frame start, an optional FSED_TOP_TAG mid-frame, and FSED_FRAME_TAG just before frame end — so no new packet type needs to be introduced into the protocol. The key advantages of this frame-level approach include: 

• Frame-level efficiency: One authentication and safety check per frame segment instead of per packet, which scales far better for high-resolution ADAS and autonomous-driving cameras. 

• Three services, one structure: The same three messages carry a mandatory base service plus two independently selectable services — Security (authentication, with optional encryption) and Functional Safety (CRC-based fault detection) — so designs get either or both protections without duplicating the frame structure. 

• Backward-compatible by design: The mid-frame message is optional, so implementations can start with the minimum message set and add mid-frame checking only where latency budgets allow. 

• Built-in replay protection: Layered frame counters embedded in the authentication tag catch replayed or stale frames, even across session boundaries. 

Security Meets Functional Safety 

FSED is actually three independently selectable services, layered on top of each other rather than bundled as one fixed feature. The FSED Base Service is mandatory — it tags every FSED message with a source identifier, the eVC (virtual channel) it belongs to, and a frame counter, so every message is uniquely identified and ordered no matter which protections are switched on above it. Layered on that foundation, designs can independently enable the Security Service, the FuSa Service, or both — with Security sitting at a higher layer than FuSa, a detail that turns out to matter once both are active. 

FSED's Security service offers a choice of two ciphersuites on the same message structure - a performance mode (AES-GMAC, with optional AES-CTR encryption) built for high-throughput, forward-facing ADAS cameras, and an efficiency mode (AES-CMAC, no encryption) for area- and power-constrained image sensor silicon. Switching between them is a configuration choice, not a redesign. 

The Functional Safety service layers five interlocking Cyclic Redundancy Check (CRC-32) checks plus two independent counters (frame-level and message-level) on top of the same messages, catching corrupted, dropped, duplicated, or reordered frames before they ever reach the application layer. When both services run together, Security is applied first at the transmitter and verified last at the receiver — a direct consequence of Security sitting above FuSa in the layering — so the safety checks cover the fully protected data, not just the raw payload. 

FSED is actually three independently selectable services, layered on top of each other rather than bundled as one fixed feature. The FSED base service is mandatory — it tags every FSED message with a source identifier, the eVC (virtual channel) it belongs to, and a frame counter, so every message is uniquely identified and ordered, no matter which protections are switched on above it. Layered on that foundation, designs can independently enable the security service, the FuSa service, or both — with security sitting at a higher layer than FuSa, a detail that turns out to matter once both are active. 

FSED's security service offers a choice of two ciphersuites on the same message structure - a performance mode (AES-GMAC, with optional AES-CTR encryption) built for high-throughput, forward-facing ADAS cameras, and an efficiency mode (AES-CMAC, no encryption) for area- and power-constrained image sensor silicon. Switching between them is a configuration choice, not a redesign. 

The Functional Safety service layers five interlocking Cyclic Redundancy Check (CRC-32) checks plus two independent counters (frame-level and message-level) on top of the same messages, catching corrupted, dropped, duplicated, or reordered frames before they ever reach the application layer. When both services run together, security is applied first at the transmitter and verified last at the receiver — a direct consequence of security sitting above FuSa in the layering — so the safety checks cover the fully protected data, not just the raw payload. 

Key Verification Challenges 

• Security variant coverage: Each security variant, including Cadence's own region-of-interest extension, defines a different MAC coverage boundary across the frame partitions, so each one needs its own targeted test scenarios. 

• Optional payload encryption: When AES-CTR encryption is layered on top of the MAC, verification has to confirm the plaintext round-trips byte-for-byte through encryption and decryption without disturbing MAC coverage. 

• Optional packet presence and absence: The pre-image and post-image embedded data packets and the mid-frame message are all optional, so verification has to exercise every combination of which ones are present or missing, since that directly changes what gets MAC- and CRC-covered. 

• MAC validation across every message type: CTRL_SYNC, TOP_TAG, and FRAME_TAG each carry independent MAC coverage, and all three need correct generation and checking under both ciphersuites. 

• Counter roll-over without false alarms: Frame counters must wrap and hand off to a secondary counter without triggering a false frame-loss error. 

• Fault injection granularity: Proving out diagnostic coverage requires corrupting each MAC and CRC field independently and confirming the matching checker fires. 

Figure 2. Six key FSED verification challenges: Security variant coverage; optional AES-CTR payload encryption; optional packet presence; MAC validation across all three FSED messages; counter roll-over; and per-field fault injection granularity. 

Simplifying FSED Verification with Cadence CSI-2 VIP 

Figure 3. Cadence CSI-2 VIP test bench: Active and passive primary/secondary agents generate and check FSED CTRL_SYNC, TOP_TAG, and FRAME_TAG messages against a PHY-agnostic DUT. 

Cadence CSI-2 Verification IP (Simulation VIP for MIPI CSI-2 | Cadence) is built to close every one of these gaps with a single, spec-compliant verification solution. It provides a golden reference model that runs as primary or secondary, generating and checking all FSED messages in real time, exercising every Security Variant defined in the specification — plus a Cadence-only Region-of-Interest (ROI) extension that protects just the critical portion of a frame, such as the center lane in a forward-facing ADAS camera, to reduce computational overhead. Backed by an industry-standard cryptographic library, it verifies AES-CTR payload encryption round-trips byte-for-byte and validates the MAC independently at CTRL_SYNC, TOP_TAG, and FRAME_TAG under both ciphersuites. 

It also exercises every combination of optional pre-image, post-image, and mid-frame message presence, includes a dedicated regression for frame-counter roll-over, and ships with independent, targeted fault injection for every MAC and CRC field, so teams can generate per-mechanism diagnostic-coverage evidence and confirm each checker fires exactly when it should. The full FSED suite runs PHY-agnostically across D-PHY, C-PHY, and A-PHY and ships with 50+ regression tests out of the box. With this breadth of coverage, Cadence CSI-2 VIP eliminates the verification gap for FSED, letting design teams validate frame-level security and functional safety together, out of the box. 

Learn more about Cadence MIPI CSI-2 Verification IP, including key features, capabilities, and benefits, by visiting our product page: Simulation VIP for MIPI CSI-2 | Cadence 

For more details, connect directly with Cadence Verification IP experts at talk_to_vip_expert@cadence.com