Verification

Enhancing Ethernet Security with MACsec

Harinee Rathod — Mon, 22 Jun 2026 05:13:00 GMT

Understanding MACsec in Today’s Ethernet World

Today, Ethernet is being widely adopted across domains ranging from high-performance computing (HPC) and cloud data centers to automotive systems, where security has become a critical requirement. If network security is compromised, sensitive data can be modified, intercepted, or stolen, leading to serious reliability and privacy concerns. Ethernet was originally designed for high-speed data transfer and interoperability between devices. However, traditional Ethernet does not provide built-in mechanisms for securing data traffic, such as encryption or authenticity protection. This is where MACsec comes into the picture. Media Access Control Security (MACsec) helps bridge this security gap by identifying and preventing the security threats at Data Link Layer (Layer 2) of Ethernet communication.

MACsec ensures data confidentiality, integrity, and authenticity for Ethernet communication. MACsec uses the Advanced Encryption Standard with Galois/Counter Mode (AES-GCM), which enables both encryption and integrity protection with high performance. Unlike security protocols such as Transport Layer Security and Internet Protocol Security, which operate at upper layers of the networking stack, MACsec is implemented directly at the Ethernet port level. This allows Ethernet links to be secured transparently at the Data Link Layer without requiring modifications to higher-layer protocols such as IP, TCP, UDP, or application software. MACsec is standardized under IEEE 802.1AE and is widely adopted in systems where secure and reliable Ethernet communication is essential.

Today, MACsec is widely deployed in environments where both high-speed communication and strong security are essential. In cloud data centers and enterprise networks, MACsec helps secure traffic between switches, routers, and servers against unauthorized access and packet tampering. In 5G infrastructure, MACsec protects fronthaul and backhaul communication carrying massive amounts of network traffic. The growing adoption of Automotive Ethernet has also increased the importance of MACsec, where secure communication between Electronic Control Units (ECUs) is critical for vehicle reliability and safety. Similarly, in HPC systems and secure chip-to-chip communication, MACsec provides hardware-level link security while maintaining high throughput and low latency.

Inside a MACsec Frame

Before MACsec protection is applied, a standard Ethernet frame contains the Destination MAC address, Source MAC address, EtherType field, payload, and Frame Check Sequence (FCS). As shown below.

When the frame enters the MACsec processing engine, MACsec modifies the frame structure by inserting a Security Tag (SecTAG) after the Source MAC address and appending an Integrity Check Value (ICV) before the frame check sequence (FCS). As shown below.

Let’s first look at the SecTAG. It carries control and security-related information such as the Packet Number (PN), Association Number (AN), Tag Control Information (TCI), Short Length (SL), and optionally the Secure Channel Identifier (SCI). These fields help the receiving device identify the secure channel, detect replay attacks, and process the frame correctly.

After the SecTAG is inserted, MACsec encrypts the Ethernet payload using AES-GCM. Encryption ensures that sensitive information carried within the Ethernet frame cannot be read by unauthorized devices while traversing the network.

Once encryption is completed, MACsec generates an Integrity Check Value (ICV), which acts as a cryptographic integrity tag appended near the end of the frame. The receiving device uses the ICV to verify that the frame has not been modified or tampered with during transmission.

MACsec inserts a dedicated EtherType value of 0x88E5 after the Source MAC address to identify a MACsec‑protected frame, while the original EtherType is preserved inside the encrypted payload.

How MACsec Secures Communication

Before secure communication begins, both devices must first authenticate each other and establish encryption keys. MACsec uses the MACsec Key Agreement (MKA) protocol to manage this process. MKA authenticates peers using the CAK and derives Secure Association Keys (SAKs) used by MACsec for frame encryption.

The communicating devices share a secret key called the Connectivity Association Key (CAK), which is used by MKA to authenticate peers. Once authentication is successful, MKA derives and distributes Secure Association Keys (SAKs) that are used by MACsec for frame encryption.

After the secure connection is established, MACsec starts encrypting Ethernet frames using AES-GCM. Each transmitted frame also carries a Packet Number (PN) inside the SecTAG. When replay protection is enabled, the receiving device validates the Packet Number to detect duplicated or replayed packets.

That's how MACsec provides data authenticity, confidentiality, integrity, and replay protection.

MACsec Verification with Cadence VIP

With the availability of the Cadence Verification IP for Ethernet MACsec, adopters can start working with these specifications immediately, ensuring compliance with the standard and achieving the fastest path to IP and SoC verification closure. Incorporating the latest protocol updates, the mature and comprehensive Cadence Verification IP (VIP) for the Ethernet protocol provides a complete bus functional model (BFM), integrated automatic protocol checks, and coverage model. Designed for easy integration in test benches at IP, system-on-chip (SoC), and system levels, the VIP for Ethernet helps you reduce the time to test, accelerate verification closure, and ensure end-product quality. The VIP for Ethernet runs on all major simulators and supports System Verilog and e-verification languages and associated methodologies, including the Universal Verification Methodology (UVM).

Ethernet Auto-Negotiation: Enabling Seamless Link Optimization

Krunal Patel — Fri, 19 Jun 2026 11:11:00 GMT

Ethernet has evolved significantly from 10 Mbps shared media to today’s multi-hundred gigabit high-speed links. One foundational feature that has enabled this scalability and ease of deployment is Auto-Negotiation (AN). Defined in multiple IEEE 802.3 clauses, Auto-Negotiation allows two connected devices to automatically determine the best possible operating parameters for a link, eliminating manual configuration and ensuring optimal performance.

Why Auto-Negotiation Is Required

In early Ethernet deployments, link parameters such as speed and duplex mode had to be manually configured on both ends of the link. This approach led to frequent issues, the most common being duplex mismatch, where one device operates in full-duplex and the other in half-duplex, causing severe performance degradation.

Auto-Negotiation addresses these challenges by:

Automatically selecting the highest common speed and mode: This ensures both devices operate at the best mutually supported configuration
Avoiding configuration errors: Eliminates manual mismatches that can lead to packet loss and poor throughput
Supporting feature compatibility: Modern Ethernet requires negotiation of additional capabilities such as:
- Flow control (pause frames)
- Forward Error Correction (FEC)
- Energy Efficient Ethernet (EEE)
- Link training for high-speed channels
Providing scalability for future standards: As speeds increase, negotiation becomes essential to decide lane counts, encoding, and error correction mechanisms.

In short, Auto-Negotiation ensures plug-and-play interoperability across diverse devices and generations of Ethernet technology.

Auto-Negotiation Clauses and Applicable Speeds

Different IEEE 802.3 clauses define how Auto-Negotiation works for various physical layers and speeds:

Clause	Applicable Speeds/Media	Key Characteristics
Clause 98	MultiGig BaseT1	Classic Auto-Negotiation using Fast Link Pulses (FLPs); negotiates speed and duplex
Clause 37	1000BASE-X (fiber), SGMII	Uses ordered sets instead of FLPs; supports gigabit links
Clause 73	10G to upto 1.6T (KR/CR/backplane)	Advanced AN with base + next pages; supports FEC, link training, multi-lane speeds

Key trend:

Lower speeds → Simple negotiation
Mid speeds (1G) → PHY-specific signaling
High speeds (10G and above) → Multi-stage negotiation with extended capabilities

Top-Level Overview: How Auto-Negotiation Works

At a high level, Auto-Negotiation is a structured handshake between two link partners. The process is similar across clauses, with increasing complexity at higher speeds.

Step 1: Capability Advertisement

Each device advertises its supported capabilities using a structured data format called a link code word (LCW).

In Clause 98: Sent using fast link pulses
In Clause 37/73: Sent using encoded ordered sets

Information is exchanged through base/next pages. Base/next page contains core capabilities:

Supported speeds
Duplex modes (for lower speeds)
Link types (e.g., KR, KX)
FEC support
Advanced speeds (e.g., 25G, 50G)
Link training capability

Step 2: Acknowledgment Handshake

Once a device receives its partner’s base page, it sets an ACK bit and continues transmitting its own advertisement.

Both partners must confirm:

They have received each other’s capabilities
The information is stable (not corrupted)

This ensures synchronization before proceeding further.

Step 3: Extended Capability Exchange (Next Pages)

For modern Ethernet (Clause 73), Auto-Negotiation continues with the exchange of next pages.

These pages are used to:

Negotiate Forward Error Correction (FEC)
Indicate support for link training (clause 72)
Advertise newer speed modes beyond base page limitations

A toggle bit mechanism ensures that new pages are distinguished from retransmissions.

Step 4: Resolution of Link Parameters

A deterministic priority resolution function selects the final link mode based on the common capabilities of both devices.
Typical rules:

Highest speed wins (e.g., 25G over 10G)
Compatible lane configuration selected
FEC enabled only if both sides support/request it

Key Takeaway

Auto-Negotiation is far more than just speed selection is a multi-stage protocol that ensures compatibility, reliability, and optimal operation across Ethernet links. At lower speeds, AN selects which link to use. At higher speeds (clause 73), it also decides how the link operates (FEC, training, lanes).

Conclusion

Auto-Negotiation is a critical feature that underpins Ethernet’s flexibility and backward compatibility. From simple duplex selection in early networks to complex multi-parameter negotiation in high-speed systems, AN has evolved to meet the demands of modern communication.

For engineers working with high-speed Ethernet, especially clause 73, understanding the interplay between base pages, next pages, and the state machine is essential for debugging and ensuring robust link bring-up.

With the availability of the Cadence Verification IP for Ethernet, adopters can start working with these specifications immediately, ensuring compliance with the standard and achieving the fastest path to IP and SoC verification closure. Incorporating the latest protocol updates, the mature and comprehensive Cadence Verification IP (VIP) for the Ethernet protocol provides a complete bus functional model (BFM), integrated automatic protocol checks, and coverage model. Designed for easy integration in test benches at IP, system-on-chip (SoC), and system levels, the VIP for Ethernet helps you reduce the time to test, accelerate verification closure, and ensure end-product quality. The VIP for Ethernet runs on all major simulators and supports SystemVerilog and e-verification languages and associated methodologies, including the Universal Verification Methodology (UVM).

DDR5 MRDIMM: A Transformational Evolution for DDR5 DIMM

Shyam Sharma — Tue, 09 Jun 2026 18:00:00 GMT

DDR5 is the latest generation of DDR server memory capable of supporting data rates of up to 9,200Mbps, which is a huge leap over the previous generation of DDR memories. It is used in a wide variety of applications, with the huge server and data center market being the key driver behind the adoption of DDR5-based memory systems. As systems move towards more CPU cores, bandwidth, and capacity, DDR5 is considered the most widely used DDR memory as compared to the previous generation, DDR4.

DDR memories are typically used as a part of dual in-line memory (DIMM) cards. DIMMs are a JEDEC-defined standard for increasing density and bus width by connecting several individual DRAM memories to a DIMM card. Traditionally, DIMMs can be categorized as Small Outline-DIMM/Unbuffered DIMM (uses just the DRAM memories), Registered DIMM (uses RCD + the DRAM), and Load Reduced DIMM (uses RCD + DRAM + DB).

The Registering Clock Driver (RCD) and Data Buffer (DB) help the RDIMM and LRDIMM with better Command/Clock and Data signal quality and help with Electrostatic Overstress (EOS) and electrostatic discharge (ESD) issues. However, even with these, bringing DDR5 LRDIMMs to support higher data rates has become a challenge beyond 4800Mbps due to issues like clock loading.

To enable DDR5 DIMM in supporting higher speeds like 12,800Mpbs, JEDEC members have produced a new architecture and a new category of DIMMs called Multiplexed Rank DIMM (MRDIMM). This is a paradigm shift for the DDR memories that not only enable DDR5 DIMM to support DDR5 SDRAM's current highest speeds of 9200 but can also allow for higher data rates. Some of the key features for DDR5 MRDIMM Generation 2 are:

For the first time, there will be two sets of clocks within the DIMM, including a Host side clock, which will run at twice the speed of the internal clock on which DRAMs will be operating. This will allow DRAM and DB's DRAM side interface to only require meeting half-rate operating speed requirements.
DDR5 MRDIMM will benefit from being able to support higher densities than traditional RDIMM/LR-DIMM, since it will have twice the number of DRAMs. These DRAMs are connected to support two Pseudo Channels for MRDIMMs, doubling the DIMM capacity.
DDR5 MRDIMM is pin compatible with traditional DIMM, and it can be used in the same DIMM slots that are used for DDR5 RDIMMs.
There is no change to the DRAMs used for DDR5 MRDIMM. DDR5 MRDIMM Generation 2 cards only require the use of new DDR5 MRCD and DDR5 MDB components and will use the same DDR5 SDRAM components.
DDR5 MDB has two DRAM side interfaces named as the A and B sides. It multiplexes DRAM data and sends it to the Host in an interleaved pattern at twice the speed at which it is sampling Data from the DRAMs on its A and B sides.
Unlike traditional DDR5 DIMMs that can only have two Physical Ranks, DDR5 MRDIMM is capable of supporting up to four physical ranks.
While DDR5 MRDIMM is pin compatible with traditional DDR5 RDIMM and follows the same DDR5 protocol. The memory controller and PHY will still need changes to support MRDIMMs, such as changes in the training sequences, handling two sets of DRAMs connected to PS0/PS1, programming of additional RCD/DB Control words, supporting burst with twice the burst lengths, etc.
DDR5 MRDIMM will have multiple generations, with Generation 2 supporting up to 12.8GT/s and Generation 3 supporting even higher data rates.

DDR5 MRDIMM is an evolving standard that is still in progress at JEDEC.

The Cadence memory model for DDR5/DDR5 DIMM aims to support all generations of DDR5 MRDIMM with Cadence DDR5 MRDIMM (including MRCD and MDB) VIPs features tracking JEDEC DDR5 MRDIMM Generation 2 and Generation 3 Specification development.

Learn more about Cadence DDR5 MRDIMM VIP at the Cadence VIP Memory Models webpages and reach out to our Cadence Verification IP experts with any questions.

Controller Memory Buffer (CMB): NVMe 2.0’s On-Controller Memory Feature

Rajan Jani — Mon, 08 Jun 2026 05:18:00 GMT

Non-volatile Memory Express (NVMe) has become the dominant interface protocol for high-performance storage devices. As workloads demand ever-lower latencies, the NVMe specification has evolved with features that reduce data-path overhead. One such fe...(read more)

Inside Akeana and Cadence’s Secret Sauce for Faster RISC-V Chip Verification

HSV Marketing — Tue, 26 May 2026 23:00:00 GMT

The Nightmare of Chip Testing (And How to Fix It)

Let's be real: designing ambitious new RISC-V chips is cool, but testing them is an absolute nightmare. When you are building crazy complex pipelines and custom instructions, you eventually hit a massive brick wall. Your designs are brilliant, but traditional simulators are too slow to run actual software on them. To catch every glitch before making the physical chip, you need trillions of test cycles. Who has the time to wait around for that while the launch deadline creeps closer?

The crew at Akeana hit this exact roadblock. Instead of crying into their coffee, they teamed up with Cadence Palladium Cloud to speed things up. Here is how they turned a scheduling nightmare into a massive win.

The Backstory and The Big Problem

In just four years, Akeana built a massive tech portfolio. We are talking about everything from tiny edge microcontrollers and smart car brains to data center AI chips. They do way more than basic processor cores; they build the heavy-duty system infrastructure like cache controllers, data highways, and advanced AI engines. But mixing and matching all these parts creates a giant puzzle. Testing individual blocks is easy. Testing how they all interact when running actual operating systems and AI software? That is a different beast. Traditional testing methods could not keep up. Akeana needed a way to test everything at scale without blowing their budget or burning out their engineers.

Enter Cadence Palladium Cloud

Instead of just buying a mountain of expensive new servers, Akeana upgraded their strategy by moving to Cadence Palladium Cloud. This gave them instant access to top-tier hardware acceleration in the cloud, allowing them to subscribe massive emulation computing power exactly when they needed it. No huge upfront hardware costs and no new IT infrastructure to build up. Their engineers just code securely on-site, push the massive workloads to the cloud, and let it rip. Even better, they aligned their emulation models so they could run massive system checks every single night with zero drama.

The Results: Working Like Tech Giants

This partnership turned Akeana into a speed machine, giving them the kind of agile development power usually reserved for trillion-dollar tech giants.

Supercharged tuning: They managed 10 to 15 performance upgrade iterations per month.
Two-day turnaround: They cut the time between writing code and getting system feedback down to just two days.
Running real AI workloads: They ran continuous AI data tests to prove their hardware handles real-world software without breaking a sweat.
Trillions of cycles: By running 24/7 in the cloud, they ran trillions of test cycles. When customers get their tech, it is already battle-tested.

"Using Cadence Palladium Cloud was critical for Akeana to get to high-quality product readiness in a short time. The platform enabled fast development and debug cycles... and provided a cost-effective way to scale."

Your Turn!

If your engineering team is losing its mind trying to validate massive AI workloads or complex chip architectures, stop waiting on traditional simulators. Reach out to the Cadence Sales Support Team to see how Palladium Cloud can save your timeline.

Cadence Announces PCIe 8.0 Verification IP Availability at PCI‑SIG US

Sangeeta Soni — Mon, 18 May 2026 05:17:00 GMT

At the recent PCI‑SIG Developers Conference US held on May 6-7,2026, Cadence announced the availability of its PCIe 8.0 Verification IP (VIP)—taking another significant step in enabling early, confident adoption of the PCI Express roadmap.

As PCIe continues to evolve to meet the growing demands of AI accelerators, high‑performance computing, and hyperscale data centers, the complexity of verification grows alongside bandwidth. With PCIe Gen8 VIP, Cadence equips customers with a production‑ready verification solution aligned with emerging specifications, helping translate evolving standards into reliable silicon implementations.

Built on a Proven, Scalable VIP Architecture

PCI Express remains the backbone interconnect for modern compute platforms, delivering scalable performance while preserving backward compatibility across generations. Each new generation introduces architectural advances that require equally advanced verification capabilities.

Cadence PCIe Gen8 VIP is built on the same C/C++‑based VIP architecture that has been widely adopted across previous PCIe generations and complementary interconnect standards. This architecture delivers a consistent user experience across protocols and verification environments, while enabling reuse from IP‑level verification through full SoC integration.

The VIP supports both serial and PIPE‑based architectures and maintains protocol behavior consistency across transaction, data link, and physical layers—allowing verification teams to adopt Gen8 with minimal disruption to existing flows.

Supporting System‑Level Verification at Extreme Speeds

PCIe Gen8 extends the PCIe architecture to support significantly higher data rates while preserving core concepts introduced in earlier generations, such as PAM4 signaling, FLIT‑based transfers, and low‑power states. Cadence PCIe Gen8 VIP is designed to validate these capabilities across realistic system configurations.

The VIP supports verification of root complexes, endpoints, switches, and retimers, along with monitor components for serial, pipe interface, and switch topologies, enabling customers to validate complex topologies and interoperability scenarios. Integration‑friendly building blocks, configurable checking, and coverage‑driven flows help verification teams scale from focused IP validation to full system‑level verification.

Enhancing Debug and Productivity

As PCIe speeds increase, observability and debug efficiency become critical. Cadence PCIe Gen8 VIP provides rich debug visibility through protocol‑aware packet tracking, waveform‑based transaction views, and trace‑file correlation across layers.

Complemented by Cadence’s verification ecosystem—including GUI‑based configuration, reusable test suites, and automated verification planning—the Gen8 VIP helps reduce bring‑up time and accelerates convergence toward verification closure.

Moving the PCIe Ecosystem Forward

The announcement of PCIe Gen8 VIP at PCI‑SIG US reflects Cadence’s continued role in advancing the PCIe ecosystem—from early standards participation through customer‑ready verification solutions.

With its combination of early availability, architectural consistency, and system‑level verification focus, Cadence PCIe VIP continues to set the benchmark for PCI Express verification, empowering customers to innovate with confidence as the industry transitions into the PCIe Gen8 era.

For more info on how Cadence PCIe Verification IP and TripleCheck VIP enable users to confidently verify PCIe designs, see our product pages on  VIP for PCI Express and Triplecheck.

Refer to the PCI-SIG website for more details on PCIe in general and upcoming revisions on PCIe 8.0

Reach out to Cadence Verification IP experts at talk_to_vip_expert@cadence.com

VLAB at the MATLAB Expo Japan 2026

JEngblom — Wed, 06 May 2026 22:05:00 GMT

The Cadence VLAB team will be part of the Cadence team present at the MATLAB Expo Japan on May 26 in Tokyo. We will be demonstrating how MATLAB and Simulink models can be used to co-simulate with VLAB virtual development machines (VDMs), allowing software to be tested in a virtual hardware-in-the-loop environment.

Virtualized hardware-in-the-loop (HIL), processor-in-the-loop (PIL), and software-in-the-loop (SIL) techniques provide the ease of testing and development agility needed to realize software-defined vehicles (SDV). Virtualization provides developers and automated continuous integration and deployment (CI/CD) systems with instant access to any amount of hardware, avoiding the need to queue up tests for execution on limited physical test rigs.

A VLAB VDM typically runs the complete software stack from the target system—applications, operating system, and drivers. The software is compiled for the target system, with no need for a special simulation variant. The VDM contains models of various input and output devices, both digital and analog. Sometimes it is as simple as a GPIO pin being driven in pulse-width modulated (PWM) mode. But it can also be analog signals or high-current drivers on a separate board, whatever is in the hardware.

From a VLAB perspective, it does not matter if the software being tested is written manually or generated from MATLAB/Simulink models. The software running on the VDM can be debugged and tested using standard software tools. It can be subjected to faults injected by VLAB scripts. This makes it possible to test the system under conditions like faulty sensors and actuators, exploring system stability and error handling. And, of course, challenging physical conditions can be simulated by the MATLAB/Simulink side.

Learn more about Cadence's VLAB and automotive solutions.

Unraveling Precision Time Measurement (PTM)

Igor Krause — Fri, 01 May 2026 17:00:00 GMT

Introduction

Precision Time Measurement (PTM) is an optional capability for communicating precise timing information between components. PTM enables precise coordination of events across multiple components with independent local time clocks. Such precise coordination is difficult, given that individual time clocks have differing notions of the value and rate of change of time. PTM is used in links/domains where the system needs its devices to have precise coordination. Good examples of systems that may take advantage of PTM include media processing, telecommunications, and scientific instrumentation.

PTM Theory and Operation

PTM enables components to calculate the relationship between their local times and a shared PTM Master Time: an independent time domain associated with a PTM Root.

Each Upstream Port initiates PTM dialogs to establish the relationship between its local time and the PTM Master Time provided by the Root Port.

PTM-capable components can make their PTM context available for inspection by software, enabling software to translate timing information between local times and the PTM Master Time. In turn, this capability enables software to coordinate events across multiple components with very fine precision.

PTM Requester - A Function capable of using PTM as a consumer associated with an Endpoint or an Upstream Port.
PTM Responder - A Function capable of using PTM to supply the PTM Master Time associated with a Port or an RCRB.
Time Source - A local clock associated with a PTM Responder.
PTM Root - The source of PTM Master Time for a PTM Hierarchy. A PTM Root must also be a Time Source and is typically also a PTM Responder.

PTM Link Protocol

A PTM dialog is defined as a matched pair of messages consisting of a PTM Request and the corresponding PTM Response or PTM ResponseD message.

The timestamps captured during the PTM dialogs enable the calculation of the timing relationship between the PTM Requester and PTM Responder (please see the image below for reference). The value (t3-t2) measures the time consumed by the PTM Responder for a given PTM dialog. The time (t4-t1) is the time from request to response. Therefore, ((t4 - t1) - (t3 - t2)) effectively gives the round-trip message transit time between the two components, and that quantity divided by 2 approximates the Link delay - the time difference between t1 and t2.

PTM Link Protocol

A PTM Requester must update its stored t1 timestamp when transmitting a PTM Request Message, even if that transmission is a replay.
A PTM Responder must update its stored t2 timestamp when receiving a PTM Request Message, even if the received TLP is a duplicate.
A PTM Responder must update its stored t3 timestamp when transmitting a PTM Response or ResponseD Message, even if that transmission is a replay.
A PTM Requester must update its stored t4 timestamp when receiving a PTM Response Message, even if the received TLP is a duplicate.

The PTM Master Time field is a 64-bit value containing the value of PTM Master Time at the receipt of the PTM Request Message for the current PTM Dialog. In the shared image, for the 2nd PTM dialog, this is the PTM Master Time at time t2'.

The Propagation Delay field is a 32-bit value containing the interval between the receipt of the PTM Request Message and the transmission of the PTM Response Message for the previous PTM dialog. In the shared image, for the second PTM dialog, this is the time interval between t2 and t3 captured during the first PTM dialog.

In NFM, Timestamps must be based on the STP Symbol or Token that frames the TLP, as if observing the first bit of that Symbol or Token at the Port's pins. The image below shows the PTM Request and Response Messages for Non-Flit Mode:

PTM Request/Response Message - Non-Flit Mode

PTM ResponseD Message - Non-Flit Mode

In Flit Mode, timestamps for PTM messages are measured at the Flit level rather than at the TLP level. There is the bit "PTM Message contained in this Flit" in the Flit_Marker field, which signals the presence of a non-nullified PTM Message inside the Flit. The PTM timestamps must be based on the Flit_Marker field.

The images below show the PTM Request and Response Messages for Flit Mode, and the Flit_Marker indicator:

PTM Request/Response Message - Flit Mode

PTM ResponseD Message - Flit Mode

Flit_Marker

PTM Extended Capability Structure

The Extended Capability structure is required for any port of the Root-Complex that supports PTM and in only one function of the Endpoint. The images below show the PTM Capability and Control registers:

PTM Capability Register

PTM Control Register

Enhanced Precision Time Measurement (ePTM) places additional requirements on PTM Devices. It must be implemented in all PTM devices that support Flit-Mode. Support for ePTM is indicated by the ePTM Capable bit.

PTM Verification Challenges and Solutions

The PTM feature introduces the PTM Request and Response Messages, whose proper utilization requires careful coordination between the devices. The new Messages may be checked to avoid any violation of the reserved fields, time accuracy, and data precision.
The PTM Extended Capability structure brings a new set of configuration registers. Verifiers must guarantee that the device's capability register correctly indicates feature support, that the control register is configured with the proper value, and that the feature is not enabled before the system is ready. Users can take advantage of VIP's error messages to identify Spec's violations more efficiently.

Verifying the PTM dialog can be really challenging. The PCIe specification defines the exact gathering point for the timestamp values. But at the same time, the devices may hold a small to moderate delay for processing incoming data, which may compromise the timestamp gathering value. The PTM dialog verification requires precise timing analysis.

Please refer to the VIP PCIe User Guide for more information on VIP PTM implementation and configuration.

Learn More

For more information on how Cadence PCIe Verification IP and TripleCheck VIP enable users to confidently verify IDE, see our VIP for PCI Express, VIP for Compute Express Link, and TripleCheck for PCI Express
For more information on PCIe in general, and on the various PCI standards, see the PCI-SIG website.
If you have more feedback or need more information, reach out to us at talk_to_vip_expert@cadence.com.

Unraveling Embedded Clock Mode in MIPI D-PHY: Simplifying High-Speed Serial Link

ArupC — Thu, 23 Apr 2026 23:00:00 GMT

As flagship smartphones push camera sensors beyond 200 megapixels and display resolutions beyond 4K, and as automotive applications demand ever-higher bandwidth, the physical layer interfaces connecting these components must evolve in lockstep. The M...(read more)

Struggling to Rewrite Functionality in PSS? Import Functions Streamlines

Siddh Virani — Thu, 23 Apr 2026 21:00:00 GMT

One of the most powerful features of the Portable Stimulus Standard (PSS) is the ability to import functions from foreign languages like C or SystemVerilog. This capability is far more than a convenience; it solves a critical real-world challenge. A very common real-life use case is that many teams already have a substantial firmware/software API library (usually in C, sometimes SV), and they do not want to re-model that realization layer purely in native PSS terms (e.g., PSS registers or native PSS functions). Instead, they want PSS to orchestrate and sequence existing firmware APIs as part of scenario realization. Imported functions are what make that layering possible.

PSS models the what (intent, ordering, constraints, coverage), while foreign functions implement the how (actual FW calls and platform-specific behavior). This approach enables seamless integration of PSS scenarios with proven, production-quality code, ensuring code reuse, layered abstraction, and faster adoption (actual FW calls and platform-specific behavior).

Imagine you're developing a feature and realize the same functionality already exists in C or SystemVerilog. Instead of rewriting it in PSS, you can simply reuse that code—saving time and reducing the risk of bugs. Or consider tackling a complex logic problem and thinking, "If I could use XYZ language here, this would be easier." That's where PSS's foreign language support shines. It is introduced in the PSS 2.0 Language Reference Manual. Import functions allow integration with languages like C and SystemVerilog, making it especially useful when connecting a UVM/SV testbench with a PSS environment. You can specify the target language and embed foreign code directly within the function body. This capability works seamlessly across both target and solve platforms, making it a powerful tool for engineers looking to streamline workflows and leverage existing assets.

Please note that only static functions can be imported via the foreign language interface.

The sections below will help you with the following:

How to use import functions on the Solving platform and the target platform
How to use Perspec for the import function

Import Function with Target Platform

In the PSS model, the Import function on the target platform can be declared as mentioned below.

Function Declaration

import target function return_type function_name( input|output|inout parameter );

Function Definition

In the exec declaration block, the definition of the function can be provided as mentioned below:

exec declaration <name_of_target_language> = “”” return_type function_name ( parameters ){ functionality implementation in the C } “””

Another option for C implementation is to create a separate external library and link that library with the Perspec-generated executable. Example 1.1 shows this approach.

Example 1.1: Import Function with Target Platform with a Separate External Library

PSS file:

//--------------

// dma_c

extend component dma_c {

import target static function void dma_program(int channel_id,sml_addr_t src_addr,sml_addr_t dst_addr,int size);

import target static function void dma_start(int channel_id);

import target static function void dma_wait_for_completion(int channel_id);

import target static function bool dma_is_done(int channel_id);

extend action transfer {

exec body {

// calling the user firmware routine

comp.dma_program(channel.instance_id,in_buff.mem_seg.addr,out_buff.mem_seg.addr,in_buff.mem_seg.size);

comp.dma_start(channel.instance_id);

while (!comp.dma_is_done(channel.instance_id)) {

yield;

}

exec post_solve {

out_buff.data.bytes = in_buff.data.bytes;

}

C_File: dma_functions.h

#ifndef YAMM_STUB_DD_

#define YAMM_STUB_DD_

void dma_program(int chan_num,

void* src_buff,

void* dst_buff,

int size);

void dma_start(int chan_num);

void dma_wait_for_done(int chan_num);

int dma_is_done(int chan_num);

C File: dma_functions.c

#include "dma_functions.h"

#include <stdio.h>

#include <stdint.h>

#include <unistd.h>

void dma_program(int chan_num,

void* src_buff,

void* dst_buff,

int size) {

printf("dma_program()\n");

printf(" chan_num = %d\n",chan_num);

printf(" src_buff = %p\n",src_buff);

printf(" dst_buff = %p\n",dst_buff);

printf(" size = %d\n",size);

}

static long long int chan_end_time[2] = {-1, -1};

void dma_start(int chan_num) {

printf("dma_start()\n");

printf(" chan_num = %d\n",chan_num);

yamm_rand_delay();

chan_end_time[chan_num] = SLN_GET_TIME() + SLN_STABLE_RANDOM(500,700,0);

}

void dma_wait_for_done(int chan_num) {

while (!dma_is_done(chan_num)) ; /* busy wait */

}

int dma_is_done(int chan_num) {

int result = (SLN_GET_TIME() >= chan_end_time[chan_num]);

if (result) {

printf("dma_is_done()\n");

printf(" chan_num = %d\n",chan_num);

}

return result;

}

PSS model in Example 1.1 is calling the functions of the DMA c library, using the import target function, and its definitions are present in separate C files.

Another example where a c implementation is present in the exec body. If you need the descramble_64bit_data functionality on the target platform and already have its implementation in C, there's no need to redevelop it in PSS. You can directly reuse existing functionality available in C, as demonstrated in Example 1.2.

Example 1.2: Import Function on Target Platform

PSS file:

import std_pkg::*;

component pss_top{

import target static function bit[64] descramble_64bit_data(bit[64] scrambled_data);

action test{

rand bit[64] scrambled_data;

bit[64] descrambled_data;

exec body{

descrambled_data = descramble_64bit_data(scrambled_data);

message(LOW, "scrambled_data: %x, | descrambled_data: %x", scrambled_data, descrambled_data);

};

exec declaration C = """

unsigned short int lfsr_state = 0xABCD;

unsigned char generate_prbs_bit(void) {

// The new bit is the XOR of the tap positions (16, 5, 4, 3)

// Note: Since lfsr_state is uint16_t, we use its bits directly.

// The tap positions are relative to the *output* bit in some designs.

// A more standard approach uses a shift register and taps the bits of the register.

// Standard Galois LFSR implementation for a 16-bit polynomial

unsigned char new_bit = ((lfsr_state >> 15) ^ (lfsr_state >> 4) ^ (lfsr_state >> 3) ^ (lfsr_state >> 2)) & 1;

lfsr_state = (lfsr_state << 1) | new_bit;

return (lfsr_state >> 15) & 1; // The output bit is typically the MSB after shift in this form

}

// Function to descramble 64 bits of data

unsigned long long descramble_64bit_data(unsigned long long scrambled_data) {

unsigned long long descrambled_data = 0;

for (int i = 0; i < 64; ++i) {

unsigned char prbs_bit = generate_prbs_bit();

// Extract the i-th bit from the scrambled data

unsigned char data_bit = (scrambled_data >> i) & 1;

// Descramble the bit (XOR with PRBS bit)

unsigned char descrambled_bit = data_bit ^ prbs_bit;

// Place the descrambled bit into the result

if (descrambled_bit) {

descrambled_data |= ((unsigned long long)1 << i);

}

return descrambled_data;

}

""";

};

Composer View of Example 1.2: The Highlighted Part of the Snapshot Shows a Functional Call in the Generated C Code in the Perspec Composer Window

The descramble_64bit_data function is declared within the PSS model. It accepts 64-bit scrambled data as input and returns the corresponding 64-bit descrambled data. Since this function is implemented specifically for a target platform, it can only be invoked inside target execution blocks. For this reason, it is called within the exec body.

The exec declaration block contains the C implementation of descramble_64bit_data. Additionally, this function internally calls other C functions, which are also defined within the same exec declaration block.

Import Function on Solve Platform

In the PSS model, the import function on the solve platform can be declared as mentioned below.

Function Declaration

import solve function return_type function_name( input|output|inout parameter );

Function definitions should be placed in a separate C file based on the target language. Use a dedicated .c file containing the function definition. This file must be precompiled and linked at solve time. For example, a C file can be compiled with gcc using the command below.

Command to Generate .so File

gcc -shared <path_of_c_file>.c -o <path_of_so_file>.so -fPIC;

Now the PSS file can be executed with the generated .so file using the command below.

Command to Run the PSS Model with the Generated .so File Using Perspec

perspec generate -pss_import_c_lib <path_of_so_file>.so -pss <path_of_pss_file>.pss – top_action test

Command to Run the PSS Model with the Generated .so File Using the Perspec Composer GUI

perspec compose -pss_import_c_lib <path_of_so_file>.so -pss <path_of_pss_file>.pss – top_action test

Here -pss_import_c_lib loads the specified shared library file(s). These files are supposed to contain the precompiled C implementations for imported solve C functions, to be invoked as part of the solve exec blocks execution.

Let’s take an example where the PSS model requires the logic for xor_scrambling, and you already have an implementation available in C, there’s no need to rewrite it from scratch. You can simply reuse the existing C code within the PSS model, as demonstrated in Example 2.1.

Example 2.1: Import Function on Solve Platform

PSS file:

import std_pkg::*;

component pss_top{

import solve static function bit[64] xor_scramble (bit[64] data, bit[64] seed);

action perform_scrambling{

rand bit[64] data;

rand bit[64] seed;

bit[64] scrambled_data;

exec pre_body{

scrambled_data = xor_scramble(data, seed);

print("Data: %x | Seed: %x \n", data, seed);

print("Scrambled data: %x \n", scrambled_data);

};

C file:

unsigned long long xor_scramble(unsigned long long data, unsigned long long seed) {

// In a real implementation, 'seed' would be generated by a more complex PRBS generator

// For this example, we use a simple shift and XOR for demonstration

unsigned long long prbs = (seed ^ (seed >> 7) ^ (seed >> 11) ^ (seed >> 31)); // Simplified feedback taps

unsigned long long scrambled_data = data ^ prbs;

return scrambled_data;

}

Composer View of Example 2.1: Highlighted Portion of Snapshot Showing Input Values and Output Value After Function Call at Perspec Composer Window

The import solve function xor_scramble is defined with input arguments like 64-bit data and a seed, and returns scrambled data. The xor_scramble function is declared on the Solve platform, and its C-language implementation is already available. This shows that any functionality previously developed in another programming language can be seamlessly reused.

As shown in the above examples, if you want to reuse functionality that already exists in a foreign language and make it available on the target platform within a PSS model, you can achieve this by leveraging exec blocks and using functionality present in separate external libraries. These allow you to integrate and invoke platform-specific implementations, enabling seamless reuse of existing code without rewriting it from scratch.

Annex D of the Portable Stimulus Standard (PSS) LRM has details of type mapping of PSS data types to C/SV.

Conclusion

The ability to import and integrate foreign language logic into PSS on both Target and Solve platforms opens powerful possibilities for code reuse and cross-language collaboration. This feature enables teams to leverage existing solutions written in other languages, reducing duplication of effort and accelerating development. By bridging the gap between PSS and external languages, we can now build a more flexible, scalable, and efficient verification flow. Perspec supports PSS import functions (all of the examples shown in this blog are supported by Perspec).

Learn more about PSS and the Cadence Perspec System Verifier.

C-PHYv3.0 Verification, 35% Throughput Boost for Camera and Display Designs

Meet S Chauhan — Tue, 14 Apr 2026 04:54:00 GMT

With the evolution of advanced camera systems and higher-resolution displays for mobile devices, the challenges for MIPI (Mobile Industry Processor Interface) based systems are increasing for physical interfaces to operate efficiently over bandwidth-limited channels while supporting higher data rates, reliable signal integrity, lower power, and EMI sensitivity, along with minimal verification complexity. MIPI CPHY solution provides innovative three-phase symbol encoding methodology, enabling significant data rates with high throughput, designed specifically to connect peripherals such as displays and image sensors, with the added advantage of sharing pin-level coexistence with DPHY (Simulation VIP for MIPI D-PHY, C-PHY and A-PHY | Cadence), providing manufacturers the flexibility to build integrated devices that can support both interfaces without added silicon cost.

Introduction to CPHY

MIPI CPHY is a trio-based embedded clock physical layer interface used to connect cameras and displays to application processors. Unlike DPHY, CPHY operates on three wire lanes (A, B, and C) encoding the protocol data through transitions between different wire states instead of direct voltage levels, eliminating the need for separate clock lanes. The key advantages of using CPHY include:

Ternary signaling architecture where each symbol is represented using one of the six valid wire states (while operating in 6-wire state mode), delivering 16 bits over seven symbols, producing a yield of 2.28 bits/symbol.
Simplified clock recovery through timing retrieval from state transitions at symbol boundaries.
Low Electro Magnetic Interference (EMI) due to the use of three-phase signaling, canceling common mode noise, making it an excellent candidate to be operated on with RF receivers on mobile SoCs.
Low pin count, flexible lane allocation, and many more.

Developments in CPHYv3.0

The new 18 wire state mode introduced in CPHYv3.0 opens the door to meet the demands for high-resolution display and image sensors, motion vector generators and complex compute platforms, all without adding more physical interconnects. With new encoding scheme introduced in version 3.0, we can now transport 32 bits over 9 symbols (3.556 bits/symbol) which is significant improvement in bits-per-symbol efficiency thus increasing overall performance by approximately 30-35% while maintaining proven industry leading characteristics and full backward compatibility.

The 18 wire state mode is optional and implementations can continue to use 6 wire state mode without any changes giving designers the flexibility to adopt the new mode selectively in performance critical applications while keeping the existing proven design unchanged.

In the traditional 6 wire state mode, each of three wires (A,B,C) were driven to one of three voltage levels creating constraint that at least one wire must always transition to next valid state, 18 wire state relaxes this constraint by introducing additional intermediate voltage levels and drive combinations where each symbol carries more information. The three wires still use the same physical pins but it creates challenges for transmitter and receiver across every layer of verification stack to support finer voltage discrimination and complex clock recovery logic.

Key Verification Challenges

Encoding/decoding complexity: The mapper and demapper become substantially complex, requiring rigorous stimulus to verify all state transitions.
Clock recovery and timing: With more states, the CDR (clock-data recovery) circuit faces more complex symbol boundaries than earlier.
Calibration and training sequences: Operating in 18-wire state mode requires resolving tighter voltage thresholds.
Backward compatibility and mode negotiation: Newer implementations must be capable of interoperate with legacy devices and negotiating capabilities with link partners.
Error detection and handling: Undetected error rate is potentially higher, resulting in silent data corruption.
Protocol layer interaction: With an effective increase in data rate, flow control, and adaptation between the protocol and PHY layer must be verified under burst and sustained traffic patterns.

The 18 wire state mode in CPHYv3.0 delivers a compelling throughput improvement, but it trades noise margins and operational complexity for bandwidth, making verification a true challenge for digital logic correctness, signal integrity, and protocol compliance at system level integration

Simplifying 18-Wire State Mode with Cadence CPHY VIP

Cadence CPHY Verification IP (Simulation VIP for MIPI D-PHY, C-PHY, and A-PHY | Cadence) is built to address all the above-mentioned challenges, delivering a single, unified verification solution for CPHYv3.0 design adoption. It provides a golden reference model that can act as both primary and secondary in active/passive modes, fully compliant with the specification, supporting HS data burst with the 18-wire state mode, new ALP initialization, calibration for 18-wire state mode, PRBS mode 2, and all other features. Our Verification IP solution includes built-in protocol checks and assertions, functional coverage model, error injection and fault coverage with different levels of callbacks for scoreboarding, static and dynamic configuration support for complete simulation control, and pre-built sequences for constrained random stimulus generation with easier integration. Cadence VIP eliminates the verification gap, and customers can effectively validate their designs by leveraging these capabilities.

Learn more about Cadence C-PHY Verification IP, including key features, capabilities, and benefits, by visiting our product page Simulation VIP for MIPI D-PHY, C-PHY, and A-PHY | Cadence

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

EUSB2 V2 Explained: Multi Gigabit Symmetric and Asymmetric Operation

WilsonKobalkar — Wed, 08 Apr 2026 09:32:00 GMT

eUSB2‑V2 is stepping into the spotlight at a time when hardware designers are being asked to do something that sounds simple but deliver more performance, in less space, with lower power, and without compromising reliability. eUSB2‑V2 represents a major evolutionary step for the USB 2.0 ecosystem. In this blog, we’ll break down what’s new in eUSB2‑V2, how it achieves multi‑gigabit HSx operation, and why symmetric/asymmetric modes unlock new design possibilities. We'll also explore the verification challenges that come with this leap

To set the stage, here’s a quick benchmark comparing eUSB2 v1 and eUSB2‑V2, highlighting just how significant this upgrade really is.

Why eUSB2‑V2 Exists in the First Place

For years, USB 2.0 has been the dependable “workhorse” interface. It’s everywhere—accessories, debugging ports, internal device links, and legacy compatibility layers. But as system‑on‑chip (SoC) platforms became more integrated, and as external connectors became less desirable inside tightly packed devices, traditional USB 2.0 wiring began to show its age. Designers needed something that could retain USB 2.0 software compatibility and ecosystem familiarity while better supporting advanced packaging, internal interconnects, and strict power constraints.

That’s where eUSB2 (embedded USB2) and its newer evolution, eUSB2‑V2, come in. It addresses the needs of internal, short‑reach connections where the “classic” USB 2.0 electrical assumptions—cables, connectors, long routes, and noisy environments—are no longer the norm. In short, eUSB2‑V2 is designed to let engineers keep the benefits of USB 2.0 while modernizing the physical layer for contemporary products.

“Multi Gigabit” — What Does That Really Mean?

At face value, “multi-gigabit – 4.8 Gb/s” is a throughput figure, and it immediately raises eyebrows because classic USB 2.0 High-Speed is known for 480 Mb/s, not multiple gigabits. The point here is that eUSB2‑V2 is discussing HSx data rates, where “HSx” signals a high-speed extended mode that can scale significantly beyond the original 480 Mb/s signaling rate.

Even if your final application won’t always run at the absolute peak rate, having a headroom ceiling in the gigabit range changes the design conversation. It can mean:

Faster internal transfers between modules
More responsive accessory or peripheral interactions
Better support for higher data-rate device functions without jumping to a completely different interface
The ability to consolidate what previously required multiple links or parallel paths

In many products, the limiting factor isn’t just raw compute it’s how quickly data can move between blocks. A higher-speed embedded link can relieve those bottlenecks.

Symmetric vs Asymmetric HSx Operation

One of the most distinctive strengths of eUSB2‑V2 is its ability to operate in either symmetric or asymmetric high‑speed modes:

HSSx (Symmetric): Both upstream (device → host) and downstream (host → device) operate at the same HSx multiplier.
Example: HSS10 = 4.8 Gb/s in both directions simultaneously.
HSUx (Asymmetric Upstream): Upstream runs at an HSx speed (up to 4.8 Gb/s), while downstream remains fixed at 480 Mb/s.
Example: HSU10 = 4.8 Gb/s upstream + 480 Mb/s downstream.
HSDx (Asymmetric Downstream): Downstream is HSx, but upstream runs at 480 Mb/s.
Example: HSD8 = 3.84 Gb/s downstream + 480 Mb/s upstream.

This asymmetric capability is not only unique but strategically significant. Many embedded peripherals—such as cameras—generate large upstream data flows (e.g., image streams) but need only modest downstream control bandwidth. In such cases, the SoC can eliminate the need for a high‑speed receiver on the peripheral side, reducing power, die area, and bill‑of‑materials cost. The specification explicitly states that asymmetric operation reduces peripheral complexity by avoiding the need for a gigabit‑class receiver.

Symmetric Speed Examples (Both Directions Matched)

Asymmetric Speed Examples (Directional Optimization)

Asymmetric Link Behavior: Implications for Verification

Dynamic Link Speed Switching in eUSB2‑V2

In eUSB2‑V2 asymmetric mode, the link doesn’t run at the same speed in both directions. Even though the speed is different, both directions share the same physical wires (half‑duplex). This means the PHY must constantly switch between a very fast data burst (HSx) and a much slower control/handshake packet (480 Mb/s). If this switching is not perfectly timed, the receiver may not recognize the start of the next packet. This results in Wrong interpretation of SYNC, Squelch mis‑detect, Missed packet boundaries, Protocol timeouts.

Power‑State Interactions (L1/L2) Under Asymmetry

After L1/L2 resume, links must return to pre‑configured HSx in the fast direction and 480 Mb/s in the slow direction, with correct HSx SYNC and squelch exit sequencing. The verification hurdle is ensuring the Frequency Locked Loop (FLL) or PLL on the receiver can re-acquire the high-speed clock sync immediately upon wake-up without dropping the first few packets of the data burst. Cadence VIP addresses each of these challenges.

Maintains UI’s between packets: Correct UI timing between packets is automatically enforced, preventing subtle timing violations that silicon might easily miss.
Signal‑level recovery (SYNC + squelch) is correct at the new rate: SYNC and squelch transitions are validated at every HSx rate, ensuring reliable signal‑level behavior during dynamic speed changes
Scheduler visible timing (SOF/EOP) does not drift or misalign: SOF/EOP timing accuracy are checked so that host scheduling remains stable even after resume, bursts, or asymmetric transitions.
PHY configuration is restored exactly as before suspend operation: PHY state is tracked across suspend/resume cycles to guarantee the link reinitializes at the exact pre‑suspend configuration.
On‑the‑fly protocol checking: Live traffic is monitored to flag protocol issues instantly, without requiring post‑processing or manual waveform inspection.

Cadence has a comprehensive Verification IP solution for the verification of various aspects of eUSB2 Version 2.0 (eUSB2v2), with capabilities provided to do a comprehensive verification of all features. You may contact the local Cadence account team to get more details on eUSB2v2 VIP.

For more information on how Cadence eUSB2 V2 Verification IP enables users to confidently verify eUSB2 V2 designs, see our product pages on VIP for eUSB2V2

For more details, reach out to us at talk_to_vip_expert@cadence.com

Powering the Future of Memory-Centric Computing with CXL 4.0 VIP

Sangeeta Soni — Fri, 03 Apr 2026 04:18:00 GMT

CXL 4.0 Verification IP Now Available!

Empowering Advanced AI, HPC, and Data-Centric Workloads with Unmatched Bandwidth, Scalability, and System Flexibility

As artificial intelligence (AI), high‑performance computing (HPC), and data‑intensive workloads continue to scale, traditional system architectures are hitting fundamental limits in memory capacity, bandwidth, and efficiency. Addressing these challenges, Compute Express Link (CXL) has emerged as the industry‑standard solution to meet this need. With the release of CXL 4.0 in August 2025, the ecosystem takes a major leap forward in bandwidth, scalability, and system flexibility.

CXL 4.0 specification aligns with PCIe 7.0 and doubles the per‑lane data rate to 128 GT/s, while preserving the standard and latency optimized flit mode introduced in CXL 3.x. With doubling link bandwidth from 64 GT/s to 128 GT/s, as per current claims, there is no added protocol latency observed, enabling dramatically higher throughput for memory‑intensive and accelerator‑heavy workloads. As with previous CXL versions of CXL2 and CXL3, CXL4 maintains backward compatibility. Additionally, CXL4 has introduced the concept of bundled ports, allowing multiple physical CXL links to be aggregated into a single logical attachment. This enables higher effective bandwidth and improved scalability without changing software enumeration models. We are yet to see how designs adopt different variants of bundles port to their advantage.

Verification Challenges – Why CXL 4.0 Demands Advanced VIP

While CXL 4.0 unlocks unprecedented performance and scalability, it also introduces substantial verification complexity. Designs must validate semantics supported by design - CXL.io, CXL.cache, and CXL.mem as per end-application and ensure correct operation across complex fabrics and heterogeneous device types. In addition, high‑speed operation at 128 GT/s with standard and latency optimized flit mode and backward‑compatibility requirements significantly raise the bar for functional verification. Comprehensive CXL 4.0 Verification IP is therefore essential to reduce risk, accelerate compliance, and ensure first‑silicon success for next‑generation CXL‑based platforms.

CXL 4.0 Verification IP

Cadence announces CXL 4.0 Verification IP that provides a comprehensive and proven foundation for validating the most advanced CXL designs, enabling customers to confidently deploy next‑generation, memory‑centric architectures. Built on Cadence's proven PCIe Gen7 Verification IP, the solution supports high‑speed 128GT/s operation and enables early, thorough validation from IP‑level through SoC and full system‑level verification. By addressing the complexity of CXL 4.0 designs upfront, Cadence CXL 4.0 Verification IP significantly reduces integration risk, accelerates debug, and shortens time‑to‑market for AI, HPC, and data‑center platforms.

The snippet below shows a fully functional CXL4 Type3 configured VIP operating at Gen7 speed with M2S packets being transmitted:

CXL 4.0 Triplecheck

In addition, Cadence Verification IP offers the TripleCheck solution, which combines an extensive compliance test suite, a comprehensive coverage model, and a structured verification plan with clear traceability to the CXL specification. This enables fast, efficient, and compliance‑oriented verification. CXL TripleCheck support spans CXL 4.0, CXL 3.2/3.1/3.0, and CXL 2.0 specifications, and is available for both CXL Host and CXL Device DUTs. The test suite includes comprehensive compliance test cases with coverage directly annotated to the CXL specification, simplifying standards compliance and accelerating interoperability readiness.

For more information on how Cadence CXL Verification IP and TripleCheck VIP enable users to confidently verify CXL designs, see our product pages on VIP for CXL, and TripleCheck.

For more details, reach out to us at vip_marketing@cadence.com.

Cadence VLAB at the Embedded World 2026

JEngblom — Wed, 01 Apr 2026 18:00:00 GMT

Just like every year, the Embedded World took place in Nürnberg in mid-March. It was a great show, and it felt busier than last year. That feeling was supported by the conference's numbers, which show 13% more visitors than in 2025!

The increase in attendance was despite another year with travel difficulties. It seems the Embedded World cannot catch a break! Last year, an airport strike on the Monday before the show caused many people to get their trips canceled. This year, all train and car traffic to the Messe was stopped for a few hours at the start of the first day (Tuesday) due to a WWII ordinance being found close to the tracks (it was safely removed). At the end of the show, Lufthansa pilots went on strike, causing many issues with the return trips for attendees. I guess this latter problem might have increased attendance on the last day, though… Better luck in 2027, I guess!

VLAB in the Cadence Booth

For the first time, VLAB was exhibiting at the Embedded World. VLAB had a demo pod in the Cadence booth, alongside demos of Cadence Automotive and hardware security solutions. We had some long days with an almost constant stream of visitors asking questions about VLAB and virtualization—what it is, how it works, what it can do.

As usual, we had a professional barista in the Cadence booth, entertaining our guests with coffee made to order. You can spot him just behind the VLAB pod in the photo above. The FlowCAD booth was on the other side of the "block", just behind the barista.

Trendspotting

The show was so busy that it was hard to find time to walk the floor to see what was going on in the industry. But it was not hard to spot the main themes just from a brief walk around.

AI – AI was everywhere. Most booths had demos featuring AI or machine learning. Any hardware can be made to run AI in some form. Tiny microcontrollers can run small models, while dedicated accelerators can host full-blown (local) LLMs. Software companies showed off ways to implement AI, as well as AI being used in tools to automate debug and coding.

Robots – Robots and robotics were just as common as AI. Some companies brought in full-size industrial arms, while others settled for small toy-level arms. Compared to previous years, there were fewer cars around the floor—they were still there, just not as many. And make no mistake, automotive is still a ubiquitous application area for tools and hardware. Several booths featured driving simulators.

On the software side, RISC-V is still hot. Tool companies showed debuggers and compilers for RISC-V, often combined with the Rust programming language. There is a sense of robustness, safety, and security becoming more of a priority in embedded, and that brings with it the need not just for better tools but also better languages and methodologies. Rust fits well with that trend.

VLAB Demos

The VLAB demo pod featured a few demos (obviously) of what VLAB can do and how you can use it for software testing and debug.

The first demo demonstrated software testing using the Vector SIL Adapter for software-in-the-loop (SIL) testing. The SIL Adapter runs the software under test on hardware (or virtual hardware) without requiring an operating system on the target or a network connection to communicate with the target. Test control and test data are provided to the target over a debugger connection.

The exact same setup works on hardware boards and a VLAB virtual platform. Both setups, physical and virtual, run the same binary. Both setups use the same debugger backends (Lauterbach and Tasking) to communicate with the targets. From the perspective of the CANoe tool, the virtual and physical hardware look identical. The difference is hidden in the debugger layer, which uses either a physical debug probe or the MCD protocol to access the target system.

The second demo showed agentic AI analyzing and fixing a software problem autonomously. The VLAB virtual ECU runs a charger-station demo from the Zephyr project, which requires a network connection to a management system. However, when the target system boots, networking fails to initialize, and the software does not work.

The AI agent accesses VLAB through the Visual Studio Code VLAB tools, investigating the problem from several angles. It examines the target system's serial output, the target system's hardware hierarchy, and the source code of the software. The issue, a misconfiguration in the device tree, is resolved, and the resulting changes are rebuilt and retested.

Tasking winIDEA and VLAB

The Tasking booth featured a demo with the winIDEA debugger and a VLAB model of a future Renesas Arm-based automotive SoC. The virtual SoC was shown alongside physical ECUs and debug probes, demonstrating the continuum from pre-silicon to post-silicon and production debug that is enabled by debugger connections from virtual platforms.

Harald Paschke from Tasking, demonstrating debugging Arm code running on VLAB

WinIDEA is one of the debuggers used in the software testing demo discussed above. As already mentioned, it uses the MCD protocol to connect to VLAB. This enables all debugger features - including debug and tracing.

AUMOVIO Functional Twins: V-ECU with VLAB

AUMOVIO showed a very different type of demo with VLAB. In this case, a VLAB model of an MCU was integrated into an ECU-level simulation that also included a model of an electronically resettable fuse. The ECU model, in turn, was integrated into a system-level model that included some (simulated) electrical components.

The AUMOVIO demo setup – the simulation is shown on the right. It can be controlled from the touch-screen setup on the left (over a network bridge between the real world and the simulation).

The software on the ECU controls a windshield wiper. As the user selects different modes, the animation on the display on the right shows the wiper's behavior. It is also possible to simulate an overload of the electric motor, at which point the electronic fuse would trigger and protect the system.

The demo provides a good example of how a virtual ECU includes models of digital components, analog components, and the external world. Such a virtual ECU allows software to be tested in both nominal and exceptional situations.

Back Next Year!

The Embedded World is a perfect example of why physical trade shows matter. It is very efficient and effective to gather the industry in a single place for a few days to meet, demo, and discuss. We will be back next year with new innovations and technologies to showcase!

Learn more about Cadence's VLAB, automotive, and hardware security solutions.

UCIe Manageability: The Hidden Control Plane of Chiplet Systems

Mannan — Wed, 01 Apr 2026 09:44:00 GMT

Chiplet-based architectures are quickly becoming the foundation of next-generation silicon systems. While most attention goes to high-bandwidth die-to-die links and data protocols like PCIe or CXL, an equally important layer operates quietly in the background: System Manageability.

Section 8 of the Universal Chiplet Interconnect Express (UCIe) Specification introduces the manageability architecture, which defines a standardized framework for discovering, configuring, and controlling chiplets inside a System-in-Package (SiP).

For system architects and verification engineers, this layer effectively functions as the control plane of a chiplet system, enabling firmware, debug tools, and system software to interact with chiplets using a consistent management infrastructure.

Why Manageability Matters in Chiplet Systems

Unlike monolithic SoCs, chiplet-based systems often integrate dies from multiple vendors, each with different internal architectures. Without a common management framework, system-level operations such as configuration, monitoring, and debug would require vendor-specific solutions, complicating system integration.

UCIe manageability addresses this by defining a management network spanning all chiplets within the package. Through this network, system firmware can perform essential operations including:

Chiplet discovery during system initialization
Chiplet ID assignment and topology configuration
Remote register access and telemetry collection
Firmware loading and system configuration
Debug and diagnostic access
Security configuration

Core Components of Manageability Architecture

At a high level, UCIe manageability defines a distributed management infrastructure composed of several architectural elements.

Conceptually, the architecture can be visualized as a management network connecting chiplets across the package:

How Management Communication Works

UCIe defines a dedicated Management Transport protocol that enables communication between management entities across chiplets.

Each management entity is identified by a Management Network ID, composed of:

Chiplet ID
Entity ID

This addressing scheme allows management messages to be routed to any management element across the package.

The transport packets carry requests and responses for different management protocols, including memory access operations and vendor-defined services.

A Key Capability: Cross-Chiplet Memory Access

One of the most useful capabilities enabled by the manageability architecture is the UCIe Memory Access Protocol (UMAP).

UMAP allows software or firmware running on a management controller to read or write registers located inside remote chiplets.

This capability enables:

Remote configuration of chiplet registers
Firmware loading across chiplets
Collection of telemetry data
Debug access during validation and post-silicon bring-up

Because the protocol is standardized, system integrators can interact with chiplets from different vendors using a unified mechanism.

The Bigger Picture

As chiplet ecosystems mature, manageability becomes essential for enabling interoperability, scalability, and lifecycle management.

The architecture defined in the UCIe specification effectively creates a standardized control plane for chiplet systems, enabling:

Consistent system discovery
Vendor-agnostic management services
Scalable debug and telemetry infrastructure

For verification teams, this means that validating a UCIe system is no longer just about link correctness—it also involves system-level management flows that span multiple chiplets and protocols. Key focus areas include:

Management packet routing across chiplets
Chiplet discovery and ID assignment during initialization
Remote register access using UMAP

These topics deserve deeper exploration and will be covered in future posts. Stay tuned!

Cadence has a mature Verification IP solution for the verification of various aspects of UCIe design, with verification capabilities provided to perform a comprehensive verification of chiplet designs. Manageability support in the VIP is currently evolving, with new features being added as we progress.

Learn how Cadence UCIe Verification IP accelerates compliance, interoperability, and system-level validation on the Simulation VIP for UCIe page—and explore how Cadence Chiplet Framework addresses the chiplet design, integration, and system lifecycle.

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