PICMG 2.20 R1.0 # Serial Mesh Backplane Short Form Specification October 21, 2002 ![PCI INDUSTRIAL PICMG® COMPUTERS](.picmg-2-20-serial-mesh-backplane-shortform/d59f392d5883dd6e10a6723a1d6cf2045298c9951e39e4144cfaf49f8ecc2ffe.jpg) # FOR INFORMATION ONLY; DO NOT ATTEMPT TO DESIGN FROM THIS DOCUMENT NOTE: This short form specification is a subset of the CompactPCI Serial Mesh Backplane specification, PICMG 2.20 R 1.0. For complete guidelines on the design of CompactPCI Serial Mesh Backplane implementations, the full specification is required. For a full copy of the PICMG 2.20 specification, go to www.picmg.org, or contact the PCI Industrial Computer Manufacturers Group at 401 Edgewater Place, Suite 500, Wakefield, Mass., 01880. Phone 781-246-9318, fax 781-224-1239, email info@picmg.org. Copyright 2002 PCI Industrial Computer Manufacturers Group. PICMG disclaims all warranties and liability for the use of this document and the information contained herein, and assumes no responsibility for any errors or omissions that may appear in this document, nor is PICMG responsible for any incidental or consequential damages resulting from the use of any data contained in this document, nor does PICMG assume any responsibility to update or correct any information in this publication. PICMG, CompactPCI, and the PICMG and CompactPCI logos are registered trademarks of the PCI Industrial Computer Manufacturers Group. All other brand or product names may be trademarks or registered trademarks of their respective holders. # INTRODUCTION # Objectives of the CompactPCI Serial Mesh Backplane Specification The complete 2.20 specification defines a high-speed serial fabric for CompactPCI  platforms. The purpose of this fabric is to enhance the data transport capability of CompactPCI  platforms for high-end applications like telecom multi-service routers and gateways while maintaining compatibility with existing CompactPCI  standards to protect investment. The goals of this fabric are: To increase backplane data transport capacities to a potential 700Gb/s Support multiple simultaneous transport protocols like ATM, IP, Frame Relay, GPRS Tunneling Protocol, and others • Leverage the current evolution of standards in network processing and switch fabric technology Maintain maximum backwards compatibility with existing PICMG  CompactPCI  standards (e.g. 2.0, 2.1, 2.9, 2.12, 2.16, 2.17) This enhancement to CompactPCI  provides a parallel capability consistent with the AdvancedTCA™ specifications. The differences in form factor and capacity allow the 2.x family to continue to serve a separate marketplace. PICMG 2.20 allows common technology to transition between the two families. The full 2.20 specification outlines a layered approach to provide interoperability for the mechanical, electrical, signaling, and packet protocol. # OVERVIEW The complete 2.20 specification defines a high-speed serial fabric for CompactPCI platforms. This fabric enables high performance transport of data for a wide variety of protocols. The fabric can serve applications for ATM, Frame Relay, and many proprietary packet protocols like those used in wireless telecom applications. The fabric consists of a rich set of differential serial signals capable of 1.25Gb/s, or 2.5Gb/s. The channels are arrayed in a “mesh” configuration that gives each slot a full set of interconnects to every other slot. This mesh arrangement supports a distributed switch fabric architecture. It has advantages in scalability and traffic management. The mesh may also be used as a subset of smaller fabrics in “star” configurations. The high-speed serial fabric is facilitated by a new connector family. The Zd connector family is supported by multiple vendors. This connector is specifically designed for high-speed differential signals up to 5Gb/s. The HM2 family currently used by CompactPCI will not support these kinds of signals. The fabric is located entirely within the space occupied by J4. It follows the precedent set by PICMG 2.5 (H.110) to use J4 as a common transport layer. This fabric is specifically oriented to packet-based applications. By utilizing J4, general-purpose boards (with no J4) will interoperate in standard CompactPCI systems, those with H.110 backplanes, and those with this high-speed serial fabric. This specification also co-exists in systems supporting PICMG 2.16. # Switch Fabric Architecture Switching systems can be characterized in layers. Protocol specific switching systems interface to specific layer 2 packet formats like Ethernet or ATM. Many low to medium performance fabrics can now be implemented in a single device making all the specifics of the switching architecture internal. ![The diagram features a central red rectangular block labeled **ATM SWITCH**. Flanking this central block are two columns of green square blocks: * **Left Column:** Three vertically stacked blocks labeled **LIU**. * **Right Column:** Three vertically stacked blocks labeled **LIU**. **Connections:** * **UTOPIA Connections:** Each **LIU** block connects to the central **ATM SWITCH** via a pair of yellow arrows (one pointing toward the switch, one pointing away). The label **UTOPIA** appears above each pair of arrows. * **OC3 Connections:** * On the left, each **LIU** block has a black double-headed arrow pointing to the left labeled **OC3**. * On the right, each **LIU** block has a black double-headed arrow pointing to the right labeled **OC3**.](.picmg-2-20-serial-mesh-backplane-shortform/7f70ad002037ea4075e26e9cfaba94d06e778b722be258baefb7d11d3885de99.jpg) Figure 1: ATM Switch Example Higher end switches utilize more layers in their architecture. This is to facilitate higher data rates and more complex traffic classification and management. Higher end fabrics define devices like traffic managers and switch fabrics. ![The diagram depicts a symmetrical architecture labeled **FABRIC LAYER 1** at the bottom. It is organized around a central processing unit with three distinct rows of components on the left and right. **Central Block:** * **SWITCH FABRIC**: A large red rectangle with a white inset box containing this text. **Left Side (Three Identical Rows):** 1. **LIU**: A green block connected to external double-headed arrows labeled **OC192**. 2. **TRAFFIC MGR**: A pink block connected to the **LIU** via yellow double-headed arrows labeled **UTOPIA**. 3. **Connection to Fabric**: The **TRAFFIC MGR** connects to the central **SWITCH FABRIC** via black double-headed arrows. (Note: The bottom-left connection arrow features a small loop symbol). **Right Side (Three Identical Rows):** 1. **TRAFFIC MGR**: A pink block connected to the central **SWITCH FABRIC** via black double-headed arrows. 2. **LIU**: A green block connected to the **TRAFFIC MGR** via yellow double-headed arrows labeled **UTOPIA**. 3. **OC192**: The **LIU** connects to external double-headed arrows labeled **OC192**.](.picmg-2-20-serial-mesh-backplane-shortform/b5b7f7a423f51618a0a1ad010567b82879bd1d57c0b29673f34386a7260cdf72.jpg) Figure 2: High End ATM Switch The traffic managers interface to the layer 2 packet. They classify, queue, and switch (or route) the layer 2 packet. The traffic managers encapsulate the layer 2 packet into a “layer 1” packet that contains information about how to transition through the switch fabric. The traffic managers perform the more complex tasks so the fabric does not have to. The fabric just transports the data to the appropriate destination. Many fabrics extend the interface between the fabric and managers to implement complex performance enhancing features. Most fabrics of this class utilize a proprietary protocol between the traffic managers and fabric requiring that these components come from the same vendor. # A Protocol and Vendor Independent Fabric In the telecom market, for example, many different networks exist and many different protocols exist. Equipment is required to inter-work between these protocols. Either the fabric must allow multiple protocols to co-exist, or all elements of the platform must convert to a single common protocol. ![This diagram illustrates a telecommunications switching architecture organized into three horizontal rows connected by a central component. **Central Component:** * A large grey block labeled **SWITCH FABRIC** at the bottom contains scattered red, yellow, and green squares. Vertical connections labeled **CONN** on both sides link it to the surrounding blocks. **Top Row:** * Left: Label **OC192** connects to a green block labeled **LIU**. * Connection: **UTOPIA** (yellow arrows) connects **LIU** to a pink-bordered block labeled **TRAFFIC MGR**. * Connection: **CONN** links **TRAFFIC MGR** to the **SWITCH FABRIC**. * Connection: **CONN** links **SWITCH FABRIC** to a blue-bordered block labeled **DSP**. * Connection: **MVIP** connects **DSP** to a green block labeled **LIU**. * Right: Label **E1/T1** connects to this rightmost **LIU**. **Middle Row:** * Left: Label **OC48** connects to a green block labeled **LIU**. * Connection: **POS** (yellow arrows) connects **LIU** to an orange block labeled **NETWORK PROC**. * Connection: **CONN** links **NETWORK PROC** to the **SWITCH FABRIC**. * Connection: **CONN** links **SWITCH FABRIC** to a pink-bordered block labeled **TRAFFIC MGR**. * Connection: **UTOPIA** (yellow arrows) connects **TRAFFIC MGR** to a green block labeled **LIU**. * Right: Label **E1/T1** connects to this rightmost **LIU**. **Bottom Row:** * Left: Label **OC3** connects to a green block labeled **LIU**. * Connection: **SERIAL** connects **LIU** to a light green block labeled **NETWORK PROC**. * Connection: **CONN** links **NETWORK PROC** to the **SWITCH FABRIC**. * Connection: **CONN** links **SWITCH FABRIC** to an orange-bordered block labeled **TRAFFIC MGR**. * Connection: **GMII** (yellow arrows) connects **TRAFFIC MGR** to a green block labeled **LIU**. * Right: Label **GbE** connects to this rightmost **LIU**.](.picmg-2-20-serial-mesh-backplane-shortform/2aca8627378a0a67627acbfc42fc2607859964c37ce87878c32822f2ea27102c.jpg) Figure 3: Multiple Protocol System In an open architecture system like CompactPCI, it is also necessary to distribute functions across multiple boards. For interoperability, boards must be able to share data at the lowest layer in the fabric. A common layer 1 protocol that encapsulates any layer 2 packet format provides for protocol independence. ![Layer 1 Header and Checksum](.picmg-2-20-serial-mesh-backplane-shortform/de21efd20e99a3c9d2d79eba9b9f654df08ec6cc1e2498d0b11aaccebc1e1441.jpg) Figure 4: Layer 1 Encapsulation The Network Processor Forum has defined a common switch fabric interface in its CSIX-L1 specification. This specification provides a common interface between all types of “traffic managers” and the switch fabric. The goal of this specification is to allow interoperability between different fabrics and different vendors. With the advent of network processors, this kind of open architecture fabric is important to an open architecture system. # A Distributed Fabric Architecture Fabric architectures are classically built around “star” architectures. All the devices in the system send their data to a central resource to be forwarded to a different device. ![The diagram depicts a hierarchical network structure with the following labeled blocks and connections: **Blocks:** * One green block at the top labeled **'Router'**. * Two pink blocks in the middle layer, both labeled **'Router'**. * Five brown blocks in the bottom layer, all labeled **'End Point'**. **Connections:** * **Top 'Router':** * Has a vertical double-headed arrow pointing upwards. * Connects via double-headed arrows to the two pink **'Router'** blocks below. * Has two arrows pointing to the right (one horizontal, one diagonal). * **Left Middle 'Router':** * Connects via arrows to three **'End Point'** blocks below it. * Encircled by a dotted line labeled **'Star'**. * **Right Middle 'Router':** * Connects via arrows to two **'End Point'** blocks below it. * Has an arrow pointing diagonally down-right.](.picmg-2-20-serial-mesh-backplane-shortform/c3308c64867d1a03156e0060c6111ebd1809d99e795d76821c910b7229c65866.jpg) ![Based on the provided image, here is an accurate and concise description of the flowchart/block diagram: **Labeled Blocks:** * **Router:** There are two blocks labeled 'Router' at the top level. One is colored pink (left) and the other is colored light blue (right). * **End Point:** There are three blocks labeled 'End Point' arranged horizontally at the bottom level. **Connections:** * **Upward Connections:** Both the pink 'Router' and the blue 'Router' have double-headed arrows pointing upwards, indicating an uplink or connection to a wider network. * **Downward Connections (Router to End Point):** * The pink 'Router' has three pink arrows pointing downwards, connecting to each of the three 'End Point' blocks. * The blue 'Router' has three blue arrows pointing downwards, connecting to each of the three 'End Point' blocks. * This creates a redundant structure where each 'End Point' receives connections from both routers. * **Grouping:** A dotted oval line labeled 'Dual Star' encircles the three 'End Point' blocks and curves upwards around the two 'Router' blocks, indicating the overall network topology.](.picmg-2-20-serial-mesh-backplane-shortform/f937796011b186ca0c7b554bdfddbf1858204af4a63d87c726d99cfbb75a8216.jpg) Figure 5: Star and Dual Star Topologies Another configuration for a fabric is a “mesh”. A mesh topology is a superset of a star topology. Connectivity is increased where all nodes have connections to all other nodes. Each node can be an endpoint, a router, or both. The figure below illustrates how a node can act as a star point for all other nodes in the system. ![The image displays a network diagram consisting of eight rectangular blocks arranged in a horizontal row. Each block is labeled with the text '**NODE**'. Seven of the blocks are light green, and the sixth block from the left is light blue. Numerous curved arrows connect the blocks, indicating directed relationships. The arrows originate from the top of a source block, arch upwards, and point downwards into the top of a destination block. The arrows are colored either green or blue: * **Green arrows** connect the green 'NODE' blocks to other green blocks and also point into the blue 'NODE' block. * **Blue arrows** originate from the blue 'NODE' block and point into all other 'NODE' blocks. Additionally, blue arrows originate from the first five green blocks (the ones to the left of the blue block) and point into the blue 'NODE' block.](.picmg-2-20-serial-mesh-backplane-shortform/13a419855e2b7d2d43024d43c7ad16430d1af4b1bb5e91f142d59385cf9bea5e.jpg) Figure 6: 8 Way Mesh Example A mesh network “distributes” the fabric among the node elements. Instead of a single N x N switch, the fabric contains M ⇒ 1xN switches, where M ≤ N. ![The image displays two block diagrams illustrating a network architecture. **Left Diagram:** * **Blocks:** There are three green blocks labeled 'M' and one light purple block labeled 'F'. * **Labels:** * 'Traffic Managers' points to the top 'M' block. * 'Fabric' points to the central 'F' block. * 'Layer 2' points to the left 'M' block. * 'Layer 1' points to the connection between the left 'M' and 'F' blocks. * **Connections:** * The top 'M' connects to the central 'F' via a yellow double-headed arrow. * The left 'M' connects to the central 'F' via a yellow double-headed arrow. * The right 'M' connects to the central 'F' via a yellow double-headed arrow. * The top 'M' has a pink double-headed arrow pointing upwards. * The left 'M' has a pink double-headed arrow pointing leftwards. * The right 'M' has a pink double-headed arrow pointing rightwards. **Right Diagram:** * **Blocks:** * Two green blocks labeled 'M' are enclosed in a dashed oval. * Four light purple blocks are enclosed in a dotted square box. * Two green blocks are on the far right. * **Labels:** * 'Network Processor' points to the dashed oval containing the 'M' blocks. * 'Fabric Interface' points to the dotted box containing the four purple blocks. * 'L0' points to the top-right purple block. * 'F' points to the bottom-left purple block. * 'Fabric Distributed Among Nodes' is the title at the bottom. * **Connections:** * The top 'M' (inside the Network Processor oval) connects to the top-left purple block via a yellow double-headed arrow. * The bottom 'M' (inside the Network Processor oval) connects to the bottom-left purple block via a yellow double-headed arrow. * The top-right purple block connects to the top-right green block via a yellow double-headed arrow. * The bottom-right purple block connects to the bottom-right green block via a yellow double-headed arrow. * The four purple blocks within the 'Fabric Interface' box are interconnected with small black double-headed arrows, forming a mesh-like topology (connecting top-left to bottom-left, top-left to bottom-right, bottom-left to top-right, bottom-left to bottom-right, and bottom-right to top-right).](.picmg-2-20-serial-mesh-backplane-shortform/be43995fe73afc17a39134b59679d130e805266f5765a42ad4de871ad9cdbe3a.jpg) Figure 7: Distributed Fabric This distributed fabric uses the richness of interconnect in the mesh to eliminate some of the contention that a crosspoint switch encounters. An NxM switch, for example, allows only a single connection from one of N sources to each of M destinations (M total packets in transit). Sources must arbitrate for a connection. As fabrics become more sophisticated, they must participate in the traffic management. A distributed fabric allows each source to transfer data to the destination. Each node implements its own traffic management according to its own needs. Mesh networks offer more resilience than star networks. There is no dependence on a central resource. If a node fails, only that traffic associated with that node is affected. The incremental capacity to protect a node is 1/N (for N+1 systems) instead of N (in 2N systems). In addition, mesh networks are more scalable. Once the mesh network interconnect is in the system, then capacity is added with each card. With a star network, the central resource has to have full system capacity, even if it is not immediately used. # Mesh Topology There are many different ways to interconnect a mesh. The mesh defined in the full 2.20 specification uses a “physical” channel arrangement. Each channel is physically associated with a slot. ![ SLOT 1 SLOT 2 SLOT 3 SLOT 4 SLOT 5 SLOT 6 --- --- --- --- --- --- --- CHAN 1 1-1 2-1 3-1 4-1 5-1 6-1 CHAN 2 1-2 2-2 3-2 4-2 5-2 6-2 CHAN 3 1-3 2-3 3-3 4-3 5-3 6-3 CHAN 4 1-4 2-4 3-4 4-4 5-4 6-4 CHAN 5 1-5 2-5 3-5 4-5 5-5 6-5 CHAN 6 1-6 2-6 3-6 4-6 5-6 6-6 ](.picmg-2-20-serial-mesh-backplane-shortform/e13e5cde58087e1be307f4181ab37f30c6cd99fc446779fdbfea04aeff0ab956.jpg) Figure 8: Square Mesh Topology ![ SLOT 1 SLOT 2 SLOT 3 SLOT 4 SLOT 5 SLOT 6 --- --- --- --- --- --- --- CHAN 1 1-1 2-1 3-1 4-1 5-1 6-1 CHAN 2 1-2 2-2 3-2 4-2 5-2 6-2 CHAN 3 1-3 2-3 3-3 4-3 5-3 6-3 CHAN 4 1-4 2-4 3-4 4-4 5-4 6-4 CHAN 5 1-5 2-5 3-5 4-5 5-5 6-5 CHAN 6 1-6 2-6 3-6 4-6 5-6 6-6 ](.picmg-2-20-serial-mesh-backplane-shortform/522d5184758baca63ffff770913320f2a106f916ed270d25cbbe102be92b0d03.jpg) Figure 9: The Mesh as a Hub Figure 8 illustrates that each channel is associated with a slot. Channel 2 in Slot 1 connects with Channel 1 in slot 2, and so on. This physical arrangement is symmetrical around the diagonal axis. Every connection to a specific slot is in the same physical location. It permits any slot to act as the hub for any subset of the mesh signals. # Distributed Fabric Interfaces Each node in a distributed system can act as a node, as a switch, or both. As a node, a board may send all traffic to a specific channel without any content related switching. This is the simplest form of the fabric interface. The interface simply encapsulates the traffic into the desired protocol and sends it to a fixed port. The board in the slot corresponding to this channel becomes the switch for the traffic. If boards are hard wired for specific channels, the switch boards must be placed in specific slots. A node may contain a full population of serial interfaces and a multiplexer. This is the same as the previous example, but with the connectivity to allow any board to be provisioned in any slot. A node may implement a basic degree of channelization by sending traffic to different destinations based on different sources. A UTOPIA port address, or a SONET sub-channel may be the determining factor. All of these methods allow the board designer to use a relatively fixed packet encapsulation mechanism. This may be the preferred method based on the capabilities of the traffic management. The local traffic manager might still need to do traffic queuing and shaping. ![Based on the provided image, here is the description of the flowchart: **Labeled Blocks:** * **LIU** (Green square) * **TM** (Red square) * **MUX** (Light blue rectangle) * **SERDES** (Yellow rectangle) **Connections:** * A double-headed vertical arrow (pointing up and down) connects the top of the **LIU** block to an external interface. * Double-headed vertical arrows connect the **LIU** block to the **TM** block below it. * Double-headed vertical arrows connect the **TM** block to the **MUX** block below it. * The **MUX** block is stacked directly above the **SERDES** block (with no visible connecting arrows between them). * Two sets of double-headed vertical arrows (pointing up and down) are positioned below the **SERDES** block, one on the left and one on the right.](.picmg-2-20-serial-mesh-backplane-shortform/4b5e3aee24b8e41bb01f58dcd07a33bd34a83d5d7d3b7905f47564c83bafb90b.jpg) ![Based on the provided image, here is an accurate description of the flowchart: **Labeled Blocks:** * **LIU**: A green square at the top. * **TM**: A pink/red square in the middle. * **1-N SW**: A large light-blue square at the bottom. * **SERDES**: A row of yellow rectangles at the very bottom of the 1-N SW block. **Connections:** * **Above LIU**: A pair of vertical bidirectional arrows (up and down). * **LIU to TM**: A pair of vertical bidirectional arrows connecting the two blocks. * **TM to 1-N SW**: A pair of vertical bidirectional arrows connecting the two blocks. * **Inside 1-N SW**: There are blue curved arrows. One points upward towards the TM connection, and another curves downward and to the right towards the SERDES blocks. * **Below SERDES**: Pairs of bidirectional arrows (up/down) indicating external I/O.](.picmg-2-20-serial-mesh-backplane-shortform/4cd4137f96b7868365af8dfdc208ba19dfc17d3c9528a85d74928426a3cf3a97.jpg) To implement a full switch, where packets are sent to specific destinations based on the packet itself, requires a more sophisticated interface. The traffic manager must encapsulate the traffic dynamically on a packet-by-packet t examine each packet and multiplex (switch)basis. The fabric interface mus the packet to the correct port. In a fully switched application, the fabric interface still only needs to distribute (aggregate) traffic to (from) the head end interface. This is 1-to-N switching. In a fully distributed system, traffic would not be switched between ports as they have their own direct route. In the node-switch relationship, traffic would to have Quality of Service rules applied still need to go to the traffic manager before transitioning the fabric again. veThe 1-to-N configuration simplifies the node card switch, but it does remo the ability to “bypass” down links by routing through another card. If the itionalTraffic Manager (TM) has the reserve capacity, it could provide the add forwarding. The failure rates of the links should be very low, but if this l capability is desired, the switch can be expanded to a full N x N additiona switch. # Interoperability The full 2.20 specification defines interoperability in two layers: the physical layer and the protocol layer. The physical layer defines the mechanical and electrical requirements for the al sourced signaling. This layer is common to l implementations of the fabric. It utilizes a multifor the mechanicalconnector (Zd) interconnect. The physical layer utilizes an industry 02.3z)standard physical signaling layer (8 for the electrical layer. (802.3z is incorporated in IEEE 802.3-2000 sections 39 – 43). The 802.3z physical layer can be supported by any number of SERDES Theseavailable from multiple sources. ailable in interfaces are also av programmable logic. ![3D rendering of two white plastic electrical connectors with metal traces, shown against a purple background (no text or symbols visible)](.picmg-2-20-serial-mesh-backplane-shortform/61facf8d48b6941358295ac0551a09660a8768480ea2b1208c4f7ffb7e8ef232.jpg) 20Pair Header and Receptacle The physical layer is contained entirely within the envelope of J4. The Zd connector will not illmate with the 2mm Hard Metric (HM2) connector, however, boards with J4 depopulated w and Zd connectors do not engage mate with backplanes supporting this fabric. The HM2 sufficiently to bend pins or damage plastic housings. dThe PICMG 2.20 configuration allows coexistence with other fabrics like PICMG 2.16 an PICMG 2.17. The switch fabric does not need to encompass all slots in the system. A backplane can contain standard CompactPCI slots, or 2.16 or 2.17 fabric slots in addition to the 2.20 mesh slots. The mesh slots can contain the 2.16 and 2.17 node connections. ![Standard CompactPCI Slots Mesh Fabric](.picmg-2-20-serial-mesh-backplane-shortform/8f6a60367571732331d493ed68c988fb1c9803bc2a144dbb453e5ae9e91580bf.jpg) Figure 10: Mesh Fabric Location Table 1: R g PICMG Specificationselationship to Existin
SpecificationCompatible?Comment
2.0 - CPCIMostlyJ4 is not HM2
2.1 - Hot SwapFullyPoint to Point network adds no new hot swap requirements
2.5 - TelephonyNo
2.9 - MgmtFully
2.10 - KeyingPartiallyZd keys all modules for this backplane, does not use HM2 keys in J4/P4.
2.12 - SoftwareFully
2.16 - CPSBMostlyMesh need not extend into fabric slots, J4 not HM2
2.17 - Star FabricPartiallyCompatible with the centralized fabric approach
The protocol layer is defined separately. The 2.20 specification defines a protocol layer based on the Common Switch Interchange (CSIX) protocol to leverage multiple switch fabric vendor support. The complete specification document contains extensions to the CSIX definition for a serial version of the protocol. upported. The meshThe PICMG 2.20 specification is layered to allow other protocols to be s architecture allows subsets of the fabric’s interconnects to be used with different protocols. They can all co-exist as long as the physical layer remains consistent. ![PICMG 2.20.3 – PICMG 2.20.2 – PICMG 2.20.1 – CSIX Protocol Layer PICMG 2.20 – Physical Layer Specification](.picmg-2-20-serial-mesh-backplane-shortform/3792acd1ea57c5adf7cc6218c7ed1ee0d52e80621f86c60f41a462d6bdb657e6.jpg) Figure 11: High Speed Serial Fabric Specifications For specifying interoperability, PICMG 2.20 is numbered with an extension to specify the protocol. For example, a PICMG 2.20.1 compliant board uses the CSIX packet protocol. \### [🔗 Link to the original document](.picmg-2-20-serial-mesh-backplane-shortform/picmg-2-20-serial-mesh-backplane-shortform.pdf)