Skip to main content

Transaction Layer Packet Emulation

· 3 min read
Paul Kang
Founding Engineer @ EEUM, Inc.

Introduction​

OpenCXL stands out for its unique method of modeling CXL components around CXL transaction layer packets. Unlike QEMU, which includes CXL models that only replicate functional behaviors from the CXL specification without utilizing CXL transaction layer packets, OpenCXL aims for a comprehensive emulation. Functional implementations suffice for emulating CXL hosts and supporting Linux guest OS. However, to construct an extensive CXL ecosystem that models multiple CXL hosts with various CXL devices, functional implementations fall short.

Below is an illustration showing the structure of CXL transaction layer packets and the interaction among CXL components using these packets through a TCP socket.

As depicted, diverse CXL components such as CXL type 1, 2, 3 devices, and CXL hosts connect to a CXL switch as a TCP client. Upon connection, they interact using CXL transaction layer packets. This method offers numerous benefits, detailed in the upcoming sections.

Isolation of Components​

Connecting each component to a CXL switch via a TCP socket allows for the addition of CXL components with minimal dependencies on the existing ones within OpenCXL.

Provided that each component adheres to the packet standards set by OpenCXL, which closes follows the CXL specificiation, developers have the flexibility to use any programming language for component development. Moreover, components can be located on different machines, connecting over a TCP/IP network.

For those interested in creating their components, OpenCXL offers readily available building blocks, particularly in Python.

Standardization of Models​

The diagrams below showcase how OpenCXL relies on the CXL Connection, a series of FIFOs storing various CXL transaction layer packets.

The internal hardware models are interconnected through the CXL Connection, facilitating the replacement of one hardware model with another. This is because the connection standardizes the method of component interaction.

Interoperability with Hardware​

Currently, OpenCXL is implemented entirely in software. However, it is not confined to software limitations. EEUM, the creator of the OpenCXL, plans to introduce a hardware-based Ethernet to CXL bridge. This innovation will bridge software-based CXL components with hardware components, expanding OpenCXL's capabilities.

The diagram below highlights different applications possible with the Ethernet to CXL bridge.

This bridge extends OpenCXL beyond software, enabling a hybrid environment that integrates both software and hardware-based CXL components.

The subsequent diagrams illustrate two key applications of the Ethernet to CXL bridge:

SW CXL Switch Interacting with Physical CXL Hosts and Devices​

SW CXL Hosts and Devices Interacting with Physical CXL Switch​

Conclusion​

OpenCXL's adoption of transaction layer packet emulation marks a significant advancement in modeling and simulating complex CXL architectures. By emphasizing isolation, standardization, and interoperability, it paves the way for a more versatile and inclusive development environment. This approach not only simplifies the integration of new components but also opens up possibilities for hybrid configurations that merge software and hardware elements. As OpenCXL continues to evolve, the potential for innovation and efficiency in CXL component emulation and interaction grows, offering promising prospects for developers and engineers alike.