AMBA CXS Protocol Specification

Copyright © 2017, 2018, 2020 Arm Limited or its affiliates. All rights reserved.
ARM IHI 0079B (ID121720)
 AMBA CXS Protocol Specification
Copyright © 2017, 2018, 2020 Arm Limited or its affiliates. All rights reserved.
Release Information

The following changes have been made to this specification.

Change history

Date Issue Confidentiality Change

12 March 2018 A Non-Confidential First release

18 December 2020 B Non-Confidential • Support for multiple protocol streams

• Extension to interface protection signaling to support new signals
• Clarification of continuous delivery guarantees

ii Copyright © 2017, 2018, 2020 Arm Limited or its affiliates. All rights reserved. ARM IHI 0079B
Non-Confidential ID121720
 Proprietary Notice

This document is NON-CONFIDENTIAL and any use by you is subject to the terms of this notice and the Arm AMBA
Specification Licence set about below.

This document is protected by copyright and other related rights and the practice or implementation of the information contained
in this document may be protected by one or more patents or pending patent applications. No part of this document may be
reproduced in any form by any means without the express prior written permission of Arm. No license, express or implied, by
estoppel or otherwise to any intellectual property rights is granted by this document unless specifically stated.

Your access to the information in this document is conditional upon your acceptance that you will not use or permit others to use
the information for the purposes of determining whether implementations infringe any third party patents.

THIS DOCUMENT IS PROVIDED "AS IS". ARM PROVIDES NO REPRESENTATIONS AND NO WARRANTIES,
EXPRESS, IMPLIED OR STATUTORY, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF
MERCHANTABILITY, SATISFACTORY QUALITY, NON-INFRINGEMENT OR FITNESS FOR A PARTICULAR
PURPOSE WITH RESPECT TO THE DOCUMENT. For the avoidance of doubt, Arm makes no representation with respect to,
and has undertaken no analysis to identify or understand the scope and content of, patents, copyrights, trade secrets, or other rights.

This document may include technical inaccuracies or typographical errors.

TO THE EXTENT NOT PROHIBITED BY LAW, IN NO EVENT WILL ARM BE LIABLE FOR ANY DAMAGES,
INCLUDING WITHOUT LIMITATION ANY DIRECT, INDIRECT, SPECIAL, INCIDENTAL, PUNITIVE, OR
CONSEQUENTIAL DAMAGES, HOWEVER CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY, ARISING
OUT OF ANY USE OF THIS DOCUMENT, EVEN IF ARM HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH
DAMAGES.

This document consists solely of commercial items. You shall be responsible for ensuring that any use, duplication or disclosure
of this document complies fully with any relevant export laws and regulations to assure that this document or any portion thereof
is not exported, directly or indirectly, in violation of such export laws. Use of the word "partner" in reference to Arm's customers
is not intended to create or refer to any partnership relationship with any other company. Arm may make changes to this document
at any time and without notice.

This document may be translated into other languages for convenience, and you agree that if there is any conflict between the
English version of this document and any translation, the terms of the English version of the Agreement shall prevail.

The Arm corporate logo and words marked with ® or ™ are registered trademarks or trademarks of Arm Limited (or its
subsidiaries) in the US and/or elsewhere. All rights reserved. Other brands and names mentioned in this document may be the
trademarks of their respective owners. Please follow Arm's trademark usage guidelines at
[Link]

Copyright © 2017, 2018, 2020 Arm Limited (or its affiliates). All rights reserved.

Arm Limited. Company 02557590 registered in England.

110 Fulbourn Road, Cambridge, England CB1 9NJ.
LES-PRE-21451 version 2.2

AMBA SPECIFICATION LICENCE

THIS END USER LICENCE AGREEMENT ("LICENCE") IS A LEGAL AGREEMENT BETWEEN YOU (EITHER A
SINGLE INDIVIDUAL, OR SINGLE LEGAL ENTITY) AND ARM LIMITED ("ARM") FOR THE USE OF ARM'S
INTELLECTUAL PROPERTY (INCLUDING, WITHOUT LIMITATION, ANY COPYRIGHT) IN THE RELEVANT AMBA
SPECIFICATION ACCOMPANYING THIS LICENCE. ARM LICENSES THE RELEVANT AMBA SPECIFICATION TO
YOU ON CONDITION THAT YOU ACCEPT ALL OF THE TERMS IN THIS LICENCE. BY CLICKING "I AGREE" OR
OTHERWISE USING OR COPYING THE RELEVANT AMBA SPECIFICATION YOU INDICATE THAT YOU AGREE TO
BE BOUND BY ALL THE TERMS OF THIS LICENCE.

"LICENSEE" means You and your Subsidiaries.

ARM IHI 0079B Copyright © 2017, 2018, 2020 Arm Limited or its affiliates. All rights reserved. iii
ID121720 Non-Confidential
 "Subsidiary" means, if You are a single entity, any company the majority of whose voting shares is now or hereafter owned or
controlled, directly or indirectly, by You. A company shall be a Subsidiary only for the period during which such control exists.

1. Subject to the provisions of Clauses 2, 3 and 4, Arm hereby grants to LICENSEE a perpetual, non-exclusive,
non-transferable, royalty free, worldwide licence to:
(i) use and copy the relevant AMBA Specification for the purpose of developing and having developed products
that comply with the relevant AMBA Specification;
(ii) manufacture and have manufactured products which either: (a) have been created by or for LICENSEE under
the licence granted in Clause 1(i); or (b) incorporate a product(s) which has been created by a third party(s)
under a licence granted by Arm in Clause 1(i) of such third party's AMBA Specification Licence; and
(iii) offer to sell, sell, supply or otherwise distribute products which have either been (a) created by or for
LICENSEE under the licence granted in Clause 1(i); or (b) manufactured by or for LICENSEE under the
licence granted in Clause 1(ii).

2. LICENSEE hereby agrees that the licence granted in Clause 1 is subject to the following restrictions:
(i) where a product created under Clause 1(i) is an integrated circuit which includes a CPU then either: (a) such
CPU shall only be manufactured under licence from Arm; or (b) such CPU is neither substantially compliant
with nor marketed as being compliant with the Arm instruction sets licensed by Arm from time to time;
(ii) the licences granted in Clause 1(iii) shall not extend to any portion or function of a product that is not itself
compliant with part of the relevant AMBA Specification; and
(iii) no right is granted to LICENSEE to sublicense the rights granted to LICENSEE under this Agreement.

3. Except as specifically licensed in accordance with Clause 1, LICENSEE acquires no right, title or interest in any Arm
technology or any intellectual property embodied therein. In no event shall the licences granted in accordance with Clause
1 be construed as granting LICENSEE, expressly or by implication, estoppel or otherwise, a licence to use any Arm
technology except the relevant AMBA Specification.

4. THE RELEVANT AMBA SPECIFICATION IS PROVIDED "AS IS" WITH NO REPRESENTATION OR

WARRANTIES EXPRESS, IMPLIED OR STATUTORY, INCLUDING BUT NOT LIMITED TO ANY WARRANTY
OF SATISFACTORY QUALITY, MERCHANTABILITY, NON-INFRINGEMENT OR FITNESS FOR A
PARTICULAR PURPOSE, OR THAT ANY USE OR IMPLEMENTATION OF SUCH ARM TECHNOLOGY WILL
NOT INFRINGE ANY THIRD PARTY PATENTS, COPYRIGHTS, TRADE SECRETS OR OTHER INTELLECTUAL
PROPERTY RIGHTS.

5. NOTWITHSTANDING ANYTHING TO THE CONTRARY CONTAINED IN THIS AGREEMENT, TO THE

FULLEST EXTENT PETMITTED BY LAW, THE MAXIMUM LIABILITY OF ARM IN AGGREGATE FOR ALL
CLAIMS MADE AGAINST ARM, IN CONTRACT, TORT OR OTHERWISE, IN CONNECTION WITH THE
SUBJECT MATTER OF THIS AGREEMENT (INCLUDING WITHOUT LIMITATION (I) LICENSEE'S USE OF THE
ARM TECHNOLOGY; AND (II) THE IMPLEMENTATION OF THE ARM TECHNOLOGY IN ANY PRODUCT
CREATED BY LICENSEE UNDER THIS AGREEMENT) SHALL NOT EXCEED THE FEES PAID (IF ANY) BY
LICENSEE TO ARM UNDER THIS AGREEMENT. THE EXISTENCE OF MORE THAN ONE CLAIM OR SUIT
WILL NOT ENLARGE OR EXTEND THE LIMIT. LICENSEE RELEASES ARM FROM ALL OBLIGATIONS,
LIABILITY, CLAIMS OR DEMANDS IN EXCESS OF THIS LIMITATION.

6. No licence, express, implied or otherwise, is granted to LICENSEE, under the provisions of Clause 1, to use the Arm
tradename, or AMBA trademark in connection with the relevant AMBA Specification or any products based thereon.
Nothing in Clause 1 shall be construed as authority for LICENSEE to make any representations on behalf of Arm in respect
of the relevant AMBA Specification.

7. This Licence shall remain in force until terminated by you or by Arm. Without prejudice to any of its other rights if
LICENSEE is in breach of any of the terms and conditions of this Licence then Arm may terminate this Licence
immediately upon giving written notice to You. You may terminate this Licence at any time. Upon expiry or termination
of this Licence by You or by Arm LICENSEE shall stop using the relevant AMBA Specification and destroy all copies of
the relevant AMBA Specification in your possession together with all documentation and related materials. Upon expiry
or termination of this Licence, the provisions of clauses 6 and 7 shall survive.

8. The validity, construction and performance of this Agreement shall be governed by English Law.

Confidentiality Status

This document is Non-Confidential. The right to use, copy and disclose this document may be subject to license restrictions in
accordance with the terms of the agreement entered into by Arm and the party that Arm delivered this document to.

Product Status

The information in this document is final, that is for a developed product.

iv Copyright © 2017, 2018, 2020 Arm Limited or its affiliates. All rights reserved. ARM IHI 0079B
Non-Confidential ID121720
 Web Address

[Link]

Progressive terminology commitment

Arm values inclusive communities. Arm recognizes that we and our industry have used terms that can be offensive. Arm strives
to lead the industry and create change.

If you find offensive terms in this document, please contact terms@[Link].

ARM IHI 0079B Copyright © 2017, 2018, 2020 Arm Limited or its affiliates. All rights reserved. v
ID121720 Non-Confidential
vi Copyright © 2017, 2018, 2020 Arm Limited or its affiliates. All rights reserved. ARM IHI 0079B
Non-Confidential ID121720
Contents
AMBA CXS Protocol Specification

Preface
About this document ................................................................................................... x

Chapter 1 Introduction
1.1 About the CXS streaming interface protocol .......................................................... 1-14
1.2 Use case ................................................................................................................ 1-15

Chapter 2 CXS operation

2.1 Protocol operation .................................................................................................. 2-18
2.2 CXS interface properties ........................................................................................ 2-20
2.3 Support for contiguous packets .............................................................................. 2-22
2.4 Support for multiple protocol streams .................................................................... 2-23

Chapter 3 Signal descriptions

3.1 Mandatory and optional CXS signals ..................................................................... 3-26
3.2 CXS interface checking signals .............................................................................. 3-27

Chapter 4 CXS packets

4.1 Packet position constraints .................................................................................... 4-30
4.2 Packet control signal .............................................................................................. 4-31
4.3 Packet size constraints .......................................................................................... 4-35
4.4 Packet examples .................................................................................................... 4-36

Chapter 5 CXS interface activation and deactivation

5.1 Interface control with explicit credit return .............................................................. 5-42
5.2 Request and acknowledgment handshaking ......................................................... 5-44
5.3 Response to a new state ........................................................................................ 5-46
5.4 Race conditions ...................................................................................................... 5-47

ARM IHI 0079B Copyright © 2017, 2018, 2020 Arm Limited or its affiliates. All rights reserved. vii
ID121720 Non-Confidential
 5.5 Timing relationships between data and link control signals ................................... 5-48
5.6 Interface activation and deactivation examples ..................................................... 5-49

Chapter 6 CXS packet continuous delivery guarantees

6.1 Continuous delivery guarantees for CXS packets .................................................. 6-52

Appendix A Revisions

viii Copyright © 2017, 2018, 2020 Arm Limited or its affiliates. All rights reserved. ARM IHI 0079B
Non-Confidential ID121720
Preface

This specification describes the CXS streaming interface protocol. The protocol is designed for point-to-point
packetized communication that can support sharing a common CXS link between different protocols.

This chapter contains the following sections:

• About this document on page x
• Intended audience on page x
• Typographic conventions on page x
• Additional reading on page x
• Feedback on this specification on page xi

ARM IHI 0079B Copyright © 2017, 2018, 2020 Arm Limited or its affiliates. All rights reserved. ix
ID121720 Non-Confidential
Preface
About this document

About this document

Intended audience
This specification is written for hardware and software engineers who want to design or debug systems and modules
that are compatible with the CXS protocol.

Typographic conventions

Convention Meaning

italic Introduces special terminology, denotes cross-references, and citations.

bold Highlights interface elements, such as menu names. Denotes signal names. Also used for terms in
descriptive lists, where appropriate.

monospace Denotes text that you can enter at the keyboard, such as commands, file and program names, and source
code.

underline Denotes a permitted abbreviation for a command or option. You can enter the underlined text instead of
the full command or option name.

monospace italic Denotes arguments to monospace text where the argument is to be replaced by a specific value.

monospace bold Denotes language keywords when used outside example code.

<and> Encloses replaceable terms for assembler syntax where they appear in code or code fragments. For
example:
MRC p15, 0, <Rd>, <CRn>, <CRm>, <Opcode_2>

SMALL CAPITALS Used in body text for a few terms that have specific technical meanings, that are defined in the ARM®
Glossary. For example, IMPLEMENTATION DEFINED, IMPLEMENTATION SPECIFIC, UNKNOWN, and
UNPREDICTABLE.

Signal Representations
Signal Representations shows the various signal types used in the information flow diagrams in this specification.

Unidirectional signal
Bidirectional signal
Unidirectional bus
Bidirectional bus

Signal Representations

Additional reading
This section lists relevant documents published by third parties:

PCI Express Base Specification [Link]

CCIX specification [Link]

CXL Specification [Link]

x Copyright © 2017, 2018, 2020 Arm Limited or its affiliates. All rights reserved. ARM IHI 0079B
Non-Confidential ID121720
 Preface
About this document

Feedback on this specification

If you have comments on the content of this specification, send e-mail to errata@[Link]. Give:
• The title AMBA CXS Protocol Specification
• The number, ARM IHI 0079B
• The page number(s) that your comments apply
• A concise explanation of your comments

Feedback
Arm welcomes feedback on its documentation.

ARM IHI 0079B Copyright © 2017, 2018, 2020 Arm Limited or its affiliates. All rights reserved. xi
ID121720 Non-Confidential
Preface
About this document

xii Copyright © 2017, 2018, 2020 Arm Limited or its affiliates. All rights reserved. ARM IHI 0079B
Non-Confidential ID121720
Chapter 1
Introduction

This chapter introduces the CXS protocol:

• About the CXS streaming interface protocol on page 1-14
• Use case on page 1-15

ARM IHI 0079B Copyright © 2017, 2018, 2020 Arm Limited or its affiliates. All rights reserved. 1-13
ID121720 Non-Confidential
1 Introduction
1.1 About the CXS streaming interface protocol

1.1 About the CXS streaming interface protocol

This specification describes the Credited eXtensible Stream (CXS) streaming interface protocol. The CXS
protocol can be used for any point-to-point packetized communication, specifically optimized for wide interfaces.
Wide interface optimization means that the protocol can be used to pass packets to a high data rate external
interface. The availability of a wide interface permits merging of multiple packets into a single transfer.

1-14 Copyright © 2017, 2018, 2020 Arm Limited or its affiliates. All rights reserved. ARM IHI 0079B
Non-Confidential ID121720
 1 Introduction
1.2 Use case

1.2 Use case

The primary use case for a CXS interface is to transport packets between an on-chip interconnect and PCIe
controller. Data transfer in CXS is unidirectional, so it is typical to have a pair of CXS interfaces between
communicating blocks. Figure 1-1 shows a typical implementation of CXS that transports both CCIX and CXL
packets on both of the CXS interfaces.

CXS
PCIe
CCIX and CXL data link
protocol layer interfaces and
PHY layers
CXS

Figure 1-1 Typical implementation of CXS

ARM IHI 0079B Copyright © 2017, 2018, 2020 Arm Limited or its affiliates. All rights reserved. 1-15
ID121720 Non-Confidential
1 Introduction
1.2 Use case

1-16 Copyright © 2017, 2018, 2020 Arm Limited or its affiliates. All rights reserved. ARM IHI 0079B
Non-Confidential ID121720
Chapter 2
CXS operation

This chapter gives an overview of the operation of the CXS protocol and the properties that describe the
configuration of a CXS interface. It contains the following sections:
• Protocol operation on page 2-18
• CXS interface properties on page 2-20

ARM IHI 0079B Copyright © 2017, 2018, 2020 Arm Limited or its affiliates. All rights reserved. 2-17
ID121720 Non-Confidential
2 CXS operation
2.1 Protocol operation

2.1 Protocol operation

A single instance of the interface has one Transmitter (TX) connected to one Receiver (RX). The data is sent in one
direction. The data that is transferred in one cycle is known as a flit. A packet can occupy one or more flits.

Table 2-1 shows the mandatory signals of the interface.

Table 2-1 CXS mandatory signals

Name Direction Description

CXSVALID Transmitter to Indicates that valid information is being passed this cycle.
Receiver

CXSDATA Transmitter to The flit data containing the packet bytes being transmitted. Ignore if
Receiver the CXSVALID signal is not asserted.

CXSCNTL Transmitter to Control information for identifying the start and end of packets
Receiver within the data field. Ignore if the CXSVALID signal is not asserted.

CXSCRDGNT Receiver to Flow control information indicating that the Receiver can accept one
Transmitter flit of data.

The Transmitter transfers data by driving CXSDATA, placing packet control information on CXSCNTL, and
asserting the CXSVALID signal. See Packet examples on page 4-36 for more details.

Flow control on the interface is implemented through a credit exchange mechanism. The rules of the credit
mechanism are:

• Data can only be sent when the Transmitter has at least one credit from the Receiver.

• When the interface is reset or first activated, the Transmitter has no credits and therefore cannot send data
across the interface.

• Credits are transferred to the Transmitter using the CXSCRDGNT signal.

• When the CXSCRDGNT signal is asserted, one credit is transferred to the Transmitter every cycle. Each
credit permits one flit of data transfer.

• The Receiver must guarantee that it can receive one flit of data for each credit that it grants.

• The Transmitter sends one flit of data for each cycle when the CXSVALID signal is asserted, which
consumes one credit.

• The maximum number of credits that a Receiver can grant a Transmitter is specified using the
CXS_MAX_CREDIT property.
— If the interface is configurable, the Transmitter must be able to track up to CXS_MAX_CREDIT
number of credits.
— If the interface is not configurable, the Transmitter must be able to track 15 credits.

• A Transmitter cannot use a credit to send a flit until the cycle after the CXSCRDGNT signal is asserted. This
specification recommends against a combinational path between the CXSCRDGNT and CXSVALID
signals.

• Optionally, credits can be returned to the Receiver without a flit transfer, using the CXSCRDRTN signal.
When the CXSCRDRTN signal is asserted, one credit is returned to the Receiver every cycle. The
CXSCRDRTN and CXSVALID signals must not be asserted in the same cycle. See Interface control with
explicit credit return on page 5-42 for more details.

• A Receiver cannot reuse a consumed or returned credit until the cycle after the CXSVALID signal or the
CXSCRDRTN signal is asserted. This specification recommends against having a combinational path
between the CXSVALID and CXSCRDGNT signals, or between the CXSCRDRTN and CXSCRDGNT
signals.

2-18 Copyright © 2017, 2018, 2020 Arm Limited or its affiliates. All rights reserved. ARM IHI 0079B
Non-Confidential ID121720
 2 CXS operation
2.1 Protocol operation

• If the Transmitter receives a credit in the same cycle that it returns or uses a credit, the number of available
credits does not change.

This specification expects that most Receivers have sufficient storage to issue multiple credits to the Transmitter.
The number of credits that are required to keep the interface flowing at full bandwidth depends on the credit latency.
Credit latency is the number of cycles between the Receiver issuing a credit and that credit being reissued after being
returned by the Transmitter. If the number of credits the Receiver can issue is greater than or equal to the credit
latency, then the interface can sustain one flit per cycle.

This specification defines signal names for a CXS connection. Port names can be differentiated by adding TX or
RX into the name after the CXS designation. Figure 2-1 shows an example of a pair of CXS links between two
components.

On-chip Off-chip
Interconnect Transport Logic

CXSRXVALID CXSVALID CXSTXVALID

CXSRXDATA CXSDATA CXSTXDATA
CXSRXCNTL CXSCNTL CXSTXCNTL
CXSRXCRDGNT CXSCRDGNT CXSTXCRDGNT

CXSTXVALID CXSVALID CXSRXVALID

CXSTXDATA CXSDATA CXSRXDATA
CXSTXCNTL CXSCNTL CXSRXCNTL
CXSTXCRDGNT CXSCRDGNT CXSRXCRDGNT

Figure 2-1 CXS connection example

ARM IHI 0079B Copyright © 2017, 2018, 2020 Arm Limited or its affiliates. All rights reserved. 2-19
ID121720 Non-Confidential
2 CXS operation
2.2 CXS interface properties

2.2 CXS interface properties

A CXS interface is configured for a particular application by setting properties. Table 2-2 describes the properties
and their options.

Table 2-2 Interface properties

Property Options Default Description

CXS_LAST True, False False Used to indicate support for the flit insertion
indicator.
True The link interface includes the
CXSLAST signal.
False The link interface does not include
the CXSLAST signal.

CXS_MAX_CREDIT 1-15 - Specifies the maximum number of credits that the

Receiver can issue.

CXS_MAX_CREDIT_LATENCY 1-16 - Receiver: Specifies the maximum number of

cycles before a credit is re-used,
from the CXSVALID signal HIGH
to the CXSCRDGNT signal HIGH.
Transmitter: Specifies the maximum number of
cycles before a credit is used when it
has flits to send, from the
CXSCRDGNT signal to the
CXSVALID signal.

CXS_PROTOCOL_TYPE True, False False Used to indicate support for the protocol type
indicator:
True The link interface includes the
CXSPRCLTYPE signal.
False The link interface does not include
the CXSPRCLTYPE signal.

CXSCHECKTYPE None, Odd_Byte_Parity None Integrity checking on the CXS interface.

None: No signals for integrity checking.
Odd_Byte_Parity:
Odd parity error detection signals
included with a nominal granularity
of one byte. See section CXS
interface checking signals on
page 3-27.

CXSCONTINUOUSDATA True, False False Receiver: If set to True, the Receiver requires
that after a packet is started, it is
completed in consecutive cycles if
enough credits are available.
Transmitter: If set to True, the Transmitter must
not begin a packet until it can deliver
the complete packet in consecutive
cycles while credits are available.

CXSDATAFLITWIDTH 256, 512, 1024 256 Width of the CXSDATA signal in bits.

2-20 Copyright © 2017, 2018, 2020 Arm Limited or its affiliates. All rights reserved. ARM IHI 0079B
Non-Confidential ID121720
 2 CXS operation
2.2 CXS interface properties

Table 2-2 Interface properties (continued)

Property Options Default Description

CXSERRORFULLPKTa True, False False Receiver: If set to True, the Receiver requires
that the length of every packet
matches the packet length that is
specified in the packet header. This
includes packets that end with
EndError.
Transmitter: If set to True, the Transmitter sends
the number of bytes specified in the
packet header, even if this packet
ends with an EndError indication.

CXSLINKCONTROL None, None None: Interface has no link control signals.

Explicit_Credit_Return Explicit_Credit_Return:
The interface includes the following
signals:
• CXSACTIVEREQ
• CXSACTIVEACK
• CXSDEACTHINT
• CXSCRDRTN
See Interface control with explicit credit return on
page 5-42 for more details

CXSMAXPKTPERFLITb 2, 3, 4 2 Maximum number of packets that can be present in

a single flit of data.
a. The encoding of the packet length within the packet is outside of the scope of the CXS document. For use of this interface for CCIX packet
transmission, see the CCIX specification for packet length encoding.
b. If CXSDATAFLITWIDTH is 256, then CXSMAXPKTPERFLIT must be 2.

Parameters can be set independently for the Transmitter and the Receiver. When assembling a system, the
parameters for connected Transmitter and Receiver interfaces must be compatible. The compatibility requirements
for each of the defined properties are shown in Table 2-3.

Table 2-3 Property compatibility requirements

Parameter Compatibility requirement

CXSCHECKTYPE Transmitter and Receiver must match.

CXSCONTINUOUSDATA If Receiver CXSCONTINUOUSDATA = True,

then Transmitter CXSCONTINUOUSDATA must be True.

CXSDATAFLITWIDTH Transmitter and Receiver must match.

CXSERRORFULLPKT If Receiver CXSERRORFULLPKT = True,

then Transmitter CXSERRORFULLPKT must be True.

CXSLINKCONTROL Transmitter and Receiver must match.

CXSMAXPKTPERFLIT Transmitter must be less than or equal to Receiver.

ARM IHI 0079B Copyright © 2017, 2018, 2020 Arm Limited or its affiliates. All rights reserved. 2-21
ID121720 Non-Confidential
2 CXS operation
2.3 Support for contiguous packets

2.3 Support for contiguous packets

The CXS protocol supports the transport of packets, which must remain together after passing through different
layers of the communication stack.

The CXSLAST signal indicates when packets, such as data link layer information, can be inserted between the
protocol layer packets. When the CXSLAST signal is deasserted, the Receiver must expect additional packets from
the Transmitter and must not insert packets from another source.

The CXSLAST signal is defined in Table 2-4.

Table 2-4 CXSLAST signal definition

Signal Width Direction Description

CXSLAST 1 Transmitter to Receiver Indicates information can be inserted between

packets after this cycle.

CXSLAST must be deasserted when:

• The following packet must remain after the current packet.

• When there is an incomplete packet in the current cycle. In other words, a packet has already started, but not
ended in the current cycle.

If CXSLAST is not present, it is assumed to be asserted, unless a packet has been started, but not ended, in the
current flit.
The CXS_LAST property is used to indicate that a link interface supports contiguous packets. CXS_LAST can have
the following values:

True The interface includes the CXSLAST signal.

False The interface does not include the CXSLAST signal.

If the CXS_LAST property is not declared, it is considered False.

2-22 Copyright © 2017, 2018, 2020 Arm Limited or its affiliates. All rights reserved. ARM IHI 0079B
Non-Confidential ID121720
 2 CXS operation
2.4 Support for multiple protocol streams

2.4 Support for multiple protocol streams

This specification enables sharing a CXS link, where packets carrying different protocols can be transmitted on the
same link.

CXSPRCLTYPE is an optional signal that indicates the protocol type of a flit.

The CXSPRCLTYPE signal is defined in Table 2-5.

Table 2-5 CXSPRCLTYPE signal definition

Signal Width Direction Description

CXSPRCLTYPE 3 Transmitter to Receiver Indicates the protocol type of a flit, encoded as:
0b000 Protocol Type 0
0b001 Protocol Type 1
Other Reserved

The following rules apply when interleaving packets from different protocols on a CXS link:
• A CXS packet that is transported using multiple flits must use the same protocol type for each flit.
• Where a flit contains more than one packet, each must have the same protocol type.
• If CXSCONTINUOUSDATA is False, flits with different protocol types can be interleaved on any cycle.
• If CXSCONTINUOUSDATA is True, the protocol type can only change after the CXSLAST signal is
asserted.

The CXS_PROTOCOL_TYPE property is used to indicate that a link interface supports the protocol type indicator,
it can have the following values:

True The interface includes the CXSPRCLTYPE signal.

False The interface does not include the CXSPRCLTYPE signal.

If the CXS_PROTOCOL_TYPE property is not declared, it is considered False.

ARM IHI 0079B Copyright © 2017, 2018, 2020 Arm Limited or its affiliates. All rights reserved. 2-23
ID121720 Non-Confidential
2 CXS operation
2.4 Support for multiple protocol streams

2-24 Copyright © 2017, 2018, 2020 Arm Limited or its affiliates. All rights reserved. ARM IHI 0079B
Non-Confidential ID121720
Chapter 3
Signal descriptions

This chapter describes the signal requirements of the CXS interface. It contains the following section:
• Mandatory and optional CXS signals on page 3-26

ARM IHI 0079B Copyright © 2017, 2018, 2020 Arm Limited or its affiliates. All rights reserved. 3-25
ID121720 Non-Confidential
3 Signal descriptions
3.1 Mandatory and optional CXS signals

3.1 Mandatory and optional CXS signals

Table 3-1 shows the mandatory and optional signals on a CXS interface.

Table 3-1 CXS interface signals

Signal Optional Property Description

CXSVALID - - Current cycle has a valid data flit.

CXSDATA - - Data bytes being transmitted.

CXSCNTL - - Information on packet start, end, and errors.

CXSLAST Y CXS_LAST Indicates that a link interface supports

contiguous packets.

CXSPRCLTYPE Y CXS_PROTOCOL_TYPE Indicates that a link interface supports the

protocol type indicator,

CXSCRDGNT - - Grants a single credit to Transmitter.

CXSCRDRTN Y CXSLINKCONTROL Returns a single credit to Receiver.

CXSACTIVEREQ Y CXSLINKCONTROL Link activation or deactivation request.

CXSACTIVEACK Y CXSLINKCONTROL Link activation or deactivation acknowledge.

CXSDEACTHINT Y CXSLINKCONTROL Indicates Receiver wants the link deactivated.

Table 3-2 shows the width of the CXS signals, when present on the interface.

Table 3-2 Signal widths

Signal Width

CXSVALID 1 bit

CXSDATA CXSDATAFLITWIDTH (256, 512, or 1024 bits)

CXSCNTL 14, 18, 22, 27, 33, 36, or 44 bits. Depends on

CXSMAXPKTPERFLIT and CXSDATAFLITWIDTH,
See Table 4-2 on page 4-32.

CXSLAST 1 bit

CXSPRCLTYPE 3 bits

CXSCRDGNT 1 bit

CXSCRDRTN 1 bit

CXSACTIVEREQ 1 bit

CXSACTIVEACK 1 bit

CXSDEACTHINT 1 bit

3-26 Copyright © 2017, 2018, 2020 Arm Limited or its affiliates. All rights reserved. ARM IHI 0079B
Non-Confidential ID121720
 3 Signal descriptions
3.2 CXS interface checking signals

3.2 CXS interface checking signals

If the CXSCHECKTYPE property is set to Odd_Byte_Parity, the interface has additional signals, which can be used
to improve the integrity of the interface.

Odd_Byte_Parity describes an error detection scheme where check bits are added such that the total count of 1s
across the signal and check bits is an odd number. In this scheme, signals wider than 8 bits have one bit added per
byte. If the signal width is not divisible by 8, then the most significant parity bit covers less than 8 bits. For example,
when CXSCNTL is 27 bits wide, CXSCNTLCHK[3] covers CXSCNTL[26:24].

Single bit control signals have one odd parity bit, so are effectively duplicated with an inverted signal.

Table 3-3 shows the check signals that are included if the CXSCHECKTYPE property is set to Odd_Byte_Parity.
If the corresponding signal is not present on the interface, then the check signal is not present either.

Table 3-3 Check signal widths (bits)

Signal Check signal Signal width Check signal width

CXSVALID CXSVALIDCHK 1 1

CXSDATA CXSDATACHK 256 32

512 64

1024 128

CXSCNTL CXSCNTLCHK 14 2

18 3

22 3

27 4

33 5

36 5

44 6

CXSLAST CXSLASTCHK 1 1

CXSPRCLTYPE CXSPRCLTYPECHK 3 1

CXSCRDGNT CXSCRDGNTCHK 1 1

CXSCRDRTN CXSCRDRTNCHK 1 1

CSXACTIVEREQ CXSACTIVEREQCHK 1 1

CXSACTIVEACK CXSACTIVEACKCHK 1 1

CXSDEACTHINT N/A 1 -

ARM IHI 0079B Copyright © 2017, 2018, 2020 Arm Limited or its affiliates. All rights reserved. 3-27
ID121720 Non-Confidential
3 Signal descriptions
3.2 CXS interface checking signals

3-28 Copyright © 2017, 2018, 2020 Arm Limited or its affiliates. All rights reserved. ARM IHI 0079B
Non-Confidential ID121720
Chapter 4
CXS packets

The data that is transmitted on the CXS interface is organized into packets. In CCIX or PCIe terminology, this is a
Transaction Layer Packet (TLP). This chapter describes CXS packets:
• Packet position constraints on page 4-30
• Packet control signal on page 4-31
• Packet size constraints on page 4-35
• Packet examples on page 4-36

ARM IHI 0079B Copyright © 2017, 2018, 2020 Arm Limited or its affiliates. All rights reserved. 4-29
ID121720 Non-Confidential
4 CXS packets
4.1 Packet position constraints

4.1 Packet position constraints

CXS places restrictions on the placement of packets within each flit of data to simplify data path implementation:

• The first byte of a packet must be placed on an aligned 16-byte boundary.

• Subsequent bytes of the packet occupy subsequent bytes of the flit.

• Packets can end on any four-byte aligned boundary.

• The packet that starts at a byte position will occupy every subsequent byte in that flit until the packet ends or
the flit ends.

• If there are remaining bytes in the packet when the flit ends, that packet will start at byte[0] of the next flit
and occupy every subsequent byte position until the packet ends or the flit ends.

• When a packet ends within a flit, the remaining bytes in the flit can be unused.

• Any packet in a flit must begin at the first available 16-byte boundary relative to the start of the flit or the
ending of a previous packet.
CXSMAXPKTPERFLIT specifies the maximum number of packets that can have bytes in a flit. There can be up to
CXSMAXPKTPERFLIT new packets starting in a flit, and up to CXSMAXPKTPERFLIT packets ending in a flit.
This defines the maximum packets per flit, including any packet started in previous flits and any packet started in
this flit which will be completed in subsequent flits.

4-30 Copyright © 2017, 2018, 2020 Arm Limited or its affiliates. All rights reserved. ARM IHI 0079B
Non-Confidential ID121720
 4 CXS packets
4.2 Packet control signal

4.2 Packet control signal

The control fields of a CXS packet are signaled using CXSCNTL. This section describes the fields and positioning
within the CXSCNTL signal.

4.2.1 Packet control fields

The CXSCNTL signal contains five fields. The widths of each field, and therefore the bit position of each field,
vary with the properties of the interface. The fields are described in Table 4-1.

Table 4-1 Packet control fields

Field Description

START Each bit in START indicates that a packet is starting in this flit.
The number of bits in START is CXSMAXPKTPERFLIT, which is the number of packets that can be
present in a flit of data. For example, when CXSMAXPKTPERFLIT = 4, then:
• START[0] = 1, at least one packet is starting in this flit.
• START[1] = 1, at least two packets are starting in this flit.
• START[2] = 1, at least three packets are starting in this flit.
• START[3] = 1, at least four packets are starting in this flit.
If any bit of START is 1, all lower bits of START must be 1.

START[N:0]PTR This field is an array of pointers to the starting location of each of the packets in this flit.
• There is one pointer for each bit in the START field, valid if that bit of START is set.
• If the corresponding START bit is 0, the pointer can have any value and should be ignored.
• All packet starts are 16-byte aligned.
• The width of each pointer is log2(CXSDATAFLITWIDTH/128) bits.
• The first byte of the Nth starting packet is (START[N]PTR << 4).
• Start pointers are defined to be monotonically increasing, for example START1PTR must be
greater than START0PTR.

ARM IHI 0079B Copyright © 2017, 2018, 2020 Arm Limited or its affiliates. All rights reserved. 4-31
ID121720 Non-Confidential
4 CXS packets
4.2 Packet control signal

Table 4-1 Packet control fields (continued)

Field Description

END Each bit in END indicates that a packet is ending in this flit.
The number of bits in END is CXSMAXPKTPERFLIT, which is the number of packets that can be
present in a flit of data. For example, when CXSMAXPKTPERFLIT = 4, then:
• END[0] = 1, at least one packet is ending in this flit.
• END[1] = 1, at least two packets are ending in this flit.
• END[2] = 1, at least three packets are ending in this flit.
• END[3] = 1, at least four packets are ending in this flit.
If any bit of END is 1, all lower bits of END must be 1.

ENDERROR Each bit in ENDERROR indicates that a packet is ending with an error condition in this flit.
• ENDERROR[0] = 1, the first packet ending this cycle has an error.
• ENDERROR[1] = 1, the second packet ending this cycle has an error.
• ENDERROR[2] = 1, the third packet ending this cycle has an error.
• ENDERROR[3] = 1, the fourth packet ending this cycle has an error.
The number of bits in ENDERROR is the number of bits in END.
If ENDERROR[N] is asserted, END[N] must be asserted.

END[N:0]PTR This field is an array of pointers to the last 4 bytes of packets ending in this flit.
• There is one pointer for each END bit, valid only if that END bit is set.
• If the corresponding END bit is 0, the pointer can have any value and should be ignored.
• All packet ends are 4-byte aligned.
• The width of each pointer is log2(CXSDATAFLITWIDTH/32) bits.
• Each end pointer points to the first byte of the last aligned 4 bytes of the packet.
• The last byte of the Nth ending packet is therefore ((END[N]PTR << 2)+3).
• Valid end pointers are defined to be monotonically increasing, for example if two packets end
in this flit then END1PTR must be greater than END0PTR.
Note
START[N]PTR and END[N]PTR might not point to the same packet, for example if a packet
started in a previous flit.

4.2.2 Packet control field structure

Table 4-2 shows Packet control field widths and placement information for all combinations of
CXSMAXPKTPERFLIT and CXSDATAFLITWIDTH. See Packet examples on page 4-36 for illustrations of how
these structures are used.
Table 4-2 Packet control field widths and placement

Width of Bit positions in

CXSMAXPKTPERFLIT CXSDATAFLITWIDTH Field
CXSCNTL CXSCNTL
2 256 14 START[1:0] CXSCNTL[1:0]
START0PTR[0] CXSCNTL[2]
START1PTR[0] CXSCNTL[3]
END[1:0] CXSCNTL[5:4]
ENDERROR[1:0] CXSCNTL[7:6]
END0PTR[2:0] CXSCNTL[10:8]
END1PTR[2:0] CXSCNTL[13:11]

4-32 Copyright © 2017, 2018, 2020 Arm Limited or its affiliates. All rights reserved. ARM IHI 0079B
Non-Confidential ID121720
 4 CXS packets
4.2 Packet control signal

Table 4-2 Packet control field widths and placement (continued)

Width of Bit positions in

CXSMAXPKTPERFLIT CXSDATAFLITWIDTH Field
CXSCNTL CXSCNTL
2 512 18 START[1:0] CXSCNTL[1:0]
START0PTR[1:0] CXSCNTL[3:2]
START1PTR[1:0] CXSCNTL[5:4]
END[1:0] CXSCNTL[7:6]
ENDERROR[1:0] CXSCNTL[9:8]
END0PTR[3:0] CXSCNTL[13:10]
END1PTR[3:0] CXSCNTL[17:14]
2 1024 22 START[1:0] CXSCNTL[1:0]
START0PTR[2:0] CXSCNTL[4:2]
START1PTR[2:0] CXSCNTL[7:5]
END[1:0] CXSCNTL[9:8]
ENDERROR[1:0] CXSCNTL[11:10]
END0PTR[4:0] CXSCNTL[16:12]
END1PTR[4:0] CXSCNTL[21:17]
3 256 - Not legal: 256-bit interface has maximum of 2
packets per flit.
3 512 27 START[2:0] CXSCNTL[2:0]
START0PTR[1:0] CXSCNTL[4:3]
START1PTR[1:0] CXSCNTL[6:5]
START2PTR[1:0] CXSCNTL[8:7]
END[2:0] CXSCNTL[11:9]
ENDERROR[2:0] CXSCNTL[14:12]
END0PTR[3:0] CXSCNTL[18:15]
END1PTR[3:0] CXSCNTL[22:19]
END2PTR[3:0] CXSCNTL[26:23]
3 1024 33 START[2:0] CXSCNTL[2:0]
START0PTR[2:0] CXSCNTL[5:3]
START1PTR[2:0] CXSCNTL[8:6]
START2PTR[2:0] CXSCNTL[11:9]
END[2:0] CXSCNTL[14:12]
ENDERROR[2:0] CXSCNTL[17:15]
END0PTR[4:0] CXSCNTL[22:18]
END1PTR[4:0] CXSCNTL[27:23]
END2PTR[4:0] CXSCNTL[32:28]
4 256 - Not legal: 256-bit interface has maximum of 2
packets per flit.

ARM IHI 0079B Copyright © 2017, 2018, 2020 Arm Limited or its affiliates. All rights reserved. 4-33
ID121720 Non-Confidential
4 CXS packets
4.2 Packet control signal

Table 4-2 Packet control field widths and placement (continued)

Width of Bit positions in

CXSMAXPKTPERFLIT CXSDATAFLITWIDTH Field
CXSCNTL CXSCNTL
4 512 36 START[3:0] CXSCNTL[3:0]
START0PTR[1:0] CXSCNTL[5:4]
START1PTR[1:0] CXSCNTL[7:6]
START2PTR[1:0] CXSCNTL[9:8]
START3PTR[1:0] CXSCNTL[11:10]
END[3:0] CXSCNTL[15:12]
ENDERROR[3:0] CXSCNTL[19:16]
END0PTR[3:0] CXSCNTL[23:20]
END1PTR[3:0] CXSCNTL[27:24]
END2PTR[3:0] CXSCNTL[31:28]
END3PTR[3:0] CXSCNTL[35:32]
4 1024 44 START[3:0] CXSCNTL[3:0]
START0PTR[2:0] CXSCNTL[6:4]
START1PTR[2:0] CXSCNTL[9:7]
START2PTR[2:0] CXSCNTL[12:10]
START3PTR[2:0] CXSCNTL[15:13]
END[3:0] CXSCNTL[19:16]
ENDERROR[3:0] CXSCNTL[23:20]
END0PTR[4:0] CXSCNTL[28:24]
END1PTR[4:0] CXSCNTL[33:29]
END2PTR[4:0] CXSCNTL[38:34]
END3PTR[4:0] CXSCNTL[43:39]

4-34 Copyright © 2017, 2018, 2020 Arm Limited or its affiliates. All rights reserved. ARM IHI 0079B
Non-Confidential ID121720
 4 CXS packets
4.3 Packet size constraints

4.3 Packet size constraints

A CXS interface transmits packets of data that meet the following requirements:
• At least 4 bytes in size
• A multiple of 4 bytes in size
• No upper limit on packet size

When used to transmit CCIX packets, there may be further constraints on packet size. Refer to the CCIX
specification for more details.

ARM IHI 0079B Copyright © 2017, 2018, 2020 Arm Limited or its affiliates. All rights reserved. 4-35
ID121720 Non-Confidential
4 CXS packets
4.4 Packet examples

4.4 Packet examples

The following examples illustrate packet placement rules and the CXSCNTL field usage. Examples that are shown
in Table 4-3 and Table 4-4 on page 4-37 both have CXSCONTINUOUSDATA = True and CXSDATACHECK =
None. Each data packet in the figures is shaded and has a unique identifier. Unused packet slots have dashes instead
of identifiers.

Table 4-3 shows an example with 256-bit data, CXSDATAFLITWIDTH = 256. It has up to two packets per flit,
CXSMAXPKTPERFLIT = 2.
Table 4-3 Example 256-bit wide interface with maximum of two packets per flit.

Cycle

Signal Field 0 1 2 3 4 5 6 7 8 9 10 11
CXSVALID 0 1 1 0 1 1 1 1 1 1 1 1
CXSDATA[31:0] - TLPA TLPB - TLPD TLPD TLPE TLPE TLPF TLPH TLPI TLPK

CXSDATA[63:32] - TLPA TLPB - TLPD - TLPE TLPE - TLPH TLPI TLPK

CXSDATA[95:64] - TLPA TLPB - TLPD - TLPE TLPE - TLPH TLPI TLPK

CXSDATA[127:96] - TLPA - - TLPD - TLPE TLPE - TLPH TLPI TLPK

CXSDATA[159:128] - TLPA TLPC - TLPD TLPE TLPE TLPE TLPG TLPI TLPJ TLPL

CXSDATA[191:160] - TLPA TLPC - TLPD TLPE TLPE - TLPG TLPI TLPJ TLPL

CXSDATA[223:192] - TLPA TLPC - TLPD TLPE TLPE - TLPG TLPI TLPJ TLPL

CXSDATA[255:224] - - TLPC - TLPD TLPE TLPE - TLPG TLPI TLPJ TLPL

CXSCNTL[1:0] START[1:0] - 0x1 0x3 - 0x1 0x1 0x0 0x0 0x3 0x3 0x1 0x3
CXSCNTL[2] START0PTR[0] - 0x0 0x0 - 0x0 0x1 - - 0x0 0x0 0x1 0x0
CXSCNTL[3] START1PTR[0] - - 0x1 - - - - - 0x1 0x1 - 0x1
CXSCNTL[5:4] END[1:0] - 0x1 0x3 - 0x0 0x1 0x0 0x1 0x3 0x1 0x3 0x3
CXSCNTL[7:6] ENDERROR[1:0] - 0x0 0x0 - 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
CXSCNTL[10:8] END0PTR[2:0] - 0x6 0x2 - - 0x0 - 0x4 0x0 0x3 0x3 0x3
CXSCNTL[13:11] END1PTR[2:0] - - 0x7 - - - - - 0x7 - 0x7 0x7

4-36 Copyright © 2017, 2018, 2020 Arm Limited or its affiliates. All rights reserved. ARM IHI 0079B
Non-Confidential ID121720
 4 CXS packets
4.4 Packet examples

Table 4-4 shows an example with 512-bit data, CXSDATAFLITWIDTH = 512. It has up to four packets per flit,
CXSMAXPKTPERFLIT = 4.
Table 4-4 Example 512-bit wide interface with maximum of four packets per flit.

Cycle

Signal Field 0 1 2 3 4 5 6 7 8 9 10 11
CXSVALID 0 1 1 0 1 1 1 1 1 1 1 0
CXSDATA[31:0] - TLPA TLPB - TLPD TLPD TLPE TLPE TLPF TLPI TLPM -
CXSDATA[63:32] - TLPA TLPB - TLPD - TLPE TLPE - TLPI TLPM -
CXSDATA[95:64] - TLPA TLPB - TLPD - TLPE TLPE - TLPI TLPM -
CXSDATA[127:96] - TLPA TLPB - TLPD - TLPE TLPE - TLPI TLPM -
CXSDATA[159128] - TLPA TLPB - TLPD TLPE TLPE TLPE TLPG TLPJ TLPN -
CXSDATA[191:160] - TLPA TLPB - TLPD TLPE TLPE TLPE TLPG TLPJ TLPN -
CXSDATA[223:192] - TLPA - - TLPD TLPE TLPE TLPE TLPG TLPJ TLPN -
CXSDATA[255:224] - TLPA - - TLPD TLPE TLPE TLPE TLPG TLPJ TLPN -
CXSDATA[287:256] - TLPA TLPC - TLPD TLPE TLPE TLPE TLPH TLPK TLPO -
CXSDATA[319:288] - - TLPC - TLPD TLPE TLPE TLPE TLPH TLPK TLPO -
CXSDATA[351:320] - - TLPC - TLPD TLPE TLPE TLPE TLPH TLPK TLPO -
CXSDATA[383:352] - - TLPC - TLPD TLPE TLPE TLPE TLPH TLPK TLPO -
CXSDATA[415:384] - - TLPC - TLPD TLPE TLPE TLPE TLPI TLPL TLPP -
CXSDATA[447:416] - - TLPC - TLPD TLPE TLPE - TLPI TLPL TLPP -
CXSDATA[479:448] - - TLPC - TLPD TLPE TLPE - TLPI TLPL TLPP -
CXSDATA[511:480] - - TLPC - TLPD TLPE TLPE - TLPI TLPL TLPP -

CXSCNTL[3:0] START[3:0] - 0x1 0x3 - 0x1 0x1 0x0 0x0 0xF 0x7 0xF -

CXSCNTL[5:4] START0PTR[1:0] - 0x0 0x0 - 0x0 0x1 - - 0x0 0x1 0x0 -

CXSCNTL[7:6] START1PTR[1:0] - - 0x2 - - - - - 0x1 0x2 0x1 -

CXSCNTL[8:9] START2PTR[1:0] - - - - - - - - 0x2 0x3 0x2 -

CXSCNTL[11:10] START3PTR[1:0] - - - - - - - - 0x3 - 0x3 -

CXSCNTL[15:12] END[3:0] - 0x1 0x3 - 0x0 0x1 0x0 0x1 0x7 0xF 0xF -

CXSCNTL[19:16] ENDERROR[3:0] - 0x0 0x0 - 0x0 0x0 0x0 0x0 0x0 0x0 0x0 -

CXSCNTL[23:20] END0PTR[3:0] - 0x8 0x5 - - 0x0 - 0xC 0x0 0x3 0x3 -

CXSCNTL[27:24] END1PTR[3:0] - - 0xF - - - - - 0x7 0x7 0x7 -
CXSCNTL[31:28] END2PTR[3:0] - - - - - - - - 0xB 0xB 0xB -
CXSCNTL[35:32] END3PTR[3:0] - - - - - - - - - 0xF 0xF -

ARM IHI 0079B Copyright © 2017, 2018, 2020 Arm Limited or its affiliates. All rights reserved. 4-37
ID121720 Non-Confidential
4 CXS packets
4.4 Packet examples

Table 4-5 on page 4-38 shows an example with 512-bit data, CXSDATAFLITWIDTH = 512. It has up to two
packets per flit, CXSMAXPKTPERFLIT = 2 and CXSCONTINUOUSDATA is True.

In this example, Protocol 0 uses packets that are variable length and Protocol 1 uses packets that are always 64B.

In the Protocol 0 stream the following groups of packets must remain together:
• P0D and P0E
In the Protocol 1 stream the following groups of packets must remain together:
• P1B and P1C
• P1E, P1F, and P1G
Table 4-5 Example 512-bit interface with multiple protocols and CXSCONTINUOUSDATA is True.

Cycle

Signal 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
CXSVALID - 1 1 1 1 1 1 1 1 1 1 0 1 1 1 1
CXSDATA [31:0] - P1A P0A P1B P1C P0B P1D P0D P0D P0E P0E P1E P1F - P1G P1H

CXSDATA [63:32] - P1A P0A P1B P1C P0B P1D P0D - P0E P0E P1E P1F - P1G P1H

CXSDATA [95:64] - P1A P0A P1B P1C P0B P1D P0D - P0E P0E P1E P1F - P1G P1H

CXSDATA [127:96] - P1A P0A P1B P1C P0B P1D P0D - P0E P0E P1E P1F - P1G P1H

CXSDATA [159:128] - P1A P0A P1B P1C P0B P1D P0D P0E P0E P0E P1E P1F - P1G P1H

CXSDATA [191:160] - P1A P0A P1B P1C P0B P1D P0D P0E P0E P0E P1E P1F - P1G P1H

CXSDATA [223:192] - P1A P0A P1B P1C - P1D P0D P0E P0E P0E P1E P1F - P1G P1H

CXSDATA [255:224] - P1A P0A P1B P1C - P1D P0D P0E P0E P0E P1E P1F - P1G P1H

CXSDATA [287:256] - P1A P0A P1B P1C P0C P1D P0D P0E P0E P0E P1E P1F - P1G P1H

CXSDATA [319:288] - P1A - P1B P1C P0C P1D P0D P0E P0E P0E P1E P1F - P1G P1H

CXSDATA [351:320] - P1A - P1B P1C P0C P1D P0D P0E P0E P0E P1E P1F - P1G P1H

CXSDATA [383:352] - P1A - P1B P1C P0C P1D P0D P0E P0E P0E P1E P1F - P1G P1H

CXSDATA [415:384] - P1A - P1B P1C P0C P1D P0D P0E P0E P0E P1E P1F - P1G P1H

CXSDATA [447:416] - P1A - P1B P1C P0C P1D P0D P0E P0E - P1E P1F - P1G P1H

CXSDATA [479:448] - P1A - P1B P1C P0C P1D P0D P0E P0E - P1E P1F - P1G P1H

CXSDATA [511:480] - P1A - P1B P1C P0C P1D P0D P0E P0E - P1E P1F - P1G P1H

CXSLAST - 1 1 0 1 1 1 0 0 0 1 0 0 - 1 1

CXSPRCLTYPE [2:0] - 0x1 0x0 0x1 0x1 0x0 0x1 0x0 0x0 0x0 0x0 0x1 0x1 - 0x1 0x1

START [1:0] - 0x1 0x1 0x1 0x1 0x3 0x1 0x1 0x1 0x0 0x0 0x1 0x1 - 0x1 0x1
START0PTR [1:0] - 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x1 - - 0x0 0x0 - 0x0 0x0
START1PTR [1:0] - - - - - 0x2 - - - - - - - - - -

END [1:0] - 0x1 0x1 0x1 0x1 0x3 0x1 0x0 0x1 0x0 0x1 0x1 0x1 - 0x1 0x1
ENDERROR [1:0] - 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 - 0x0 0x0
END0PTR [3:0] - 0xF 0x8 0xF 0xF 0x5 0xF - 0x0 - 0xC 0xF 0xF - 0xF 0xF
END1PTR [3:0] - - - - - 0xF - - - - - - - - -

4-38 Copyright © 2017, 2018, 2020 Arm Limited or its affiliates. All rights reserved. ARM IHI 0079B
Non-Confidential ID121720
 4 CXS packets
4.4 Packet examples

Table 4-6 shows an example with 512-bit data, CXSDATAFLITWIDTH = 512. It has up to two packets per flit,
CXSMAXPKTPERFLIT = 2 and CXSCONTINUOUSDATA is False.

In this example, Protocol 0 uses packets that have variable length and Protocol 1 uses packets that are always 64B.

In the Protocol 0 stream the following groups of packets must remain together:
• P0D and P0E
In the Protocol 1 stream the following groups of packets must remain together:
• P1B and P1C
• P1E, P1F, and P1G

With CXSCONTINUOUSDATA set False, packets with a different protocol can be interleaved, even if the
CXSLAST signal is deasserted. In the example, CXSLAST is used to indicate that Protocol 1 packets must not be
inserted after cycles 3, 8, or 10.

Table 4-6 Example 512-bit interface with multiple protocols and CXSCONTINUOUSDATA is False

Cycle
Signal 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
CXSVALID 0 1 1 1 1 1 1 1 1 1 1 0 1 1 1 1
CXSDATA [31:0] - P1A P0A P1B P0B P1C P1D P0D P1E P0D P1F - P0E P1G P0E P1H

CXSDATA [63:32] - P1A P0A P1B P0B P1C P1D P0D P1E - P1F - P0E P1G P0E P1H

CXSDATA [95:64] - P1A P0A P1B P0B P1C P1D P0D P1E - P1F - P0E P1G P0E P1H

CXSDATA [127:96] - P1A P0A P1B P0B P1C P1D P0D P1E - P1F - P0E P1G P0E P1H

CXSDATA [159:128] - P1A P0A P1B P0B P1C P1D P0D P1E P0E P1F - P0E P1G P0E P1H

CXSDATA [191:160] - P1A P0A P1B P0B P1C P1D P0D P1E P0E P1F - P0E P1G P0E P1H

CXSDATA [223:192] - P1A P0A P1B - P1C P1D P0D P1E P0E P1F - P0E P1G P0E P1H

CXSDATA [255:224] - P1A P0A P1B - P1C P1D P0D P1E P0E P1F - P0E P1G P0E P1H

CXSDATA [287:256] - P1A P0A P1B P0C P1C P1D P0D P1E P0E P1F - P0E P1G P0E P1H

CXSDATA [319:288] - P1A - P1B P0C P1C P1D P0D P1E P0E P1F - P0E P1G P0E P1H

CXSDATA [351:320] - P1A - P1B P0C P1C P1D P0D P1E P0E P1F - P0E P1G P0E P1H

CXSDATA [383:352] - P1A - P1B P0C P1C P1D P0D P1E P0E P1F - P0E P1G P0E P1H

CXSDATA [415:384] - P1A - P1B P0C P1C P1D P0D P1E P0E P1F - P0E P1G P0E P1H

CXSDATA [447:416] - P1A - P1B P0C P1C P1D P0D P1E P0E P1F - P0E P1G - P1H

CXSDATA [479:448] - P1A - P1B P0C P1C P1D P0D P1E P0E P1F - P0E P1G - P1H

CXSDATA [511:480] - P1A - P1B P0C P1C P1D P0D P1E P0E P1F - P0E P1G - P1H

CXSLAST - 1 1 0 1 1 1 0 0 0 0 - 0 1 1 1
CXSPRCLTYPE [2:0] - 0x1 0x0 0x1 0x0 0x1 0x1 0x0 0x1 0x0 0x1 - 0x0 0x1 0x0 0x1

START [1:0] - 0x1 0x1 0x1 0x3 0x1 0x1 0x1 0x1 0x1 0x1 - 0x0 0x1 0x0 0x1
START0PTR [1:0] - 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x1 0x0 - - 0x0 - 0x0
START1PTR [1:0] - - - - 0x2 - - - - - - - - - - -
END [1:0] - 0x1 0x1 0x1 0x3 0x1 0x1 0x0 0x1 0x1 0x1 - 0x0 0x1 0x1 0x1
ENDERROR [1:0] - 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 - 0x0 0x0 0x0 0x0
END0PTR [3:0] - 0xF 0x8 0xF 0x5 0xF 0xF - 0xF 0x0 0xF - - 0xF 0xC 0xF
END1PTR [3:0] - - - - 0xF - - - - - - - - - - -

ARM IHI 0079B Copyright © 2017, 2018, 2020 Arm Limited or its affiliates. All rights reserved. 4-39
ID121720 Non-Confidential
4 CXS packets
4.4 Packet examples

4-40 Copyright © 2017, 2018, 2020 Arm Limited or its affiliates. All rights reserved. ARM IHI 0079B
Non-Confidential ID121720
Chapter 5
CXS interface activation and deactivation

This chapter describes the activation and deactivation mechanisms when the CXSLINKCONTROL property is set
to Explicit_Credit_Return, and has the following sections:
• Interface control with explicit credit return on page 5-42
• Request and acknowledgment handshaking on page 5-44
• Response to a new state on page 5-46
• Race conditions on page 5-47
• Timing relationships between data and link control signals on page 5-48
• Interface activation and deactivation examples on page 5-49

ARM IHI 0079B Copyright © 2017, 2018, 2020 Arm Limited or its affiliates. All rights reserved. 5-41
ID121720 Non-Confidential
5 CXS interface activation and deactivation
5.1 Interface control with explicit credit return

5.1 Interface control with explicit credit return

A CXS interface can be optionally configured to include signaling for activation and deactivation, using the
CXSLINKCONTROL property. The property can be set to None or Explicit_Credit_Return.

When the CXSLINKCONTROL property is set to None, there are no signals for interface activation and
deactivation. This setting requires that the Receiver must always send credits when they are available and the
Transmitter must always be able to receive them.

When the CXSLINKCONTROL property is set to Explicit_Credit_Return, the following specification applies and
signals are added to the interface as shown in Table 5-1.

Table 5-1 Signals for link control using explicit credit return

Name Direction Description

CXSCRDRTN Transmitter to Flow control information indicating that the Transmitter is returning
Receiver a previously granted credit without using it. Can only be asserted if
the CXSVALID signal is not asserted.

CXSACTIVEREQ Transmitter to Link activation or deactivation request.

Receiver

CXSACTIVEACK Receiver to Link activation or deactivation acknowledge.

Transmitter

CXSDEACTHINT Receiver to Hint that Receiver would like the link to be deactivated.
Transmitter

The interface starts in an idle state either on exit from reset or when moving to a full operational state. Transfer of
flits can commence when credits have been granted by the Receiver side. Credits can be granted when the
Transmitter side indicates that it is ready to receive them.

A two-signal, four-phase, handshake mechanism is used. This mechanism synchronizes the state of the link between
the Transmitter and Receiver and is initiated by the Transmitter. In addition, a signal is available for the Receiver to
request that the link be deactivated.

Figure 5-1 on page 5-43 shows a typical connection, with one outbound and one inbound CXS interface, each of
which has an instance of the credit control signals.

5-42 Copyright © 2017, 2018, 2020 Arm Limited or its affiliates. All rights reserved. ARM IHI 0079B
Non-Confidential ID121720
 5 CXS interface activation and deactivation
5.1 Interface control with explicit credit return

On-chip Off-chip
Interconnect Transport Logic

CXSRXVALID CXSTXVALID
CXSRXDATA CXSTXDATA
CXSRXCNTL CXSTXCNTL
CXSRXCRDGNT CXSTXCRDGNT

CXSRXCRDRTN CXSTXCRDRTN
CXSRXACTIVEREQ CXSTXACTIVEREQ
CXSRXACTIVEACK CXSTXACTIVEACK
CXSRXDEACTHINT CXSTXDEACTHINT

CXSTXVALID CXSRXVALID
CXSTXDATA CXSRXDATA
CXSTXCNTL CXSRXCNTL
CXSTXCRDGNT CXSRXCRDGNT

CXSTXCRDRTN CXSRXCRDRTN
CXSTXACTIVEREQ CXSRXACTIVEREQ
CXSTXACTIVEACK CXSRXACTIVEACK
CXSTXDEACTHINT CXSRXDEACTHINT

Figure 5-1 Example with two CXS links

ARM IHI 0079B Copyright © 2017, 2018, 2020 Arm Limited or its affiliates. All rights reserved. 5-43
ID121720 Non-Confidential
5 CXS interface activation and deactivation
5.2 Request and acknowledgment handshaking

5.2 Request and acknowledgment handshaking

Request and acknowledge handshaking uses CXSACTIVEREQ and CXSACTIVEACK as primary signals.

The Transmitter requires a credit before it can send a flit. A credit is passed from the Receiver when it has resources
available to accept a flit.

• On exit from reset, all credits are held by the Receiver and at least one must be passed to the Transmitter
before flit transfer can begin.

• During normal operation, there is an ongoing exchange of flits and credits between the two sides of the
interface.

• Before entering a low-power state, the sending of payload flits must be stopped and all credits must be
returned to the Receiver. This action returns the interface to the same state that it was at immediately after
reset.

Four states are defined for the interface operation:

STOP
• The interface does not operate in the STOP state. All credits are held by the Receiver.
• STOP is a stable state. When this state is entered, a channel can remain in it for an indefinite
time.
• The Receiver is guaranteed not to receive flits or credit returns. It must not send credit.
• The Transmitter is guaranteed not to receive credit. It must not send flits or credit returns.
• The Transmitter can move from the STOP state to the ACTIVATE state when it has flits
waiting to be sent.

ACTIVATE
• This state is used when transitioning from the STOP state to the RUN state.
• It is expected that when this state is entered, a channel moves to the next stable state in a
relatively short time.
• The Transmitter must accept credit, but it cannot send flits until it observes the move to the
RUN state.
• The Receiver is guaranteed not to receive flits or credit returns.
• The Receiver is not permitted to send credit in the ACTIVATE state. It is permitted to send
credit in the same cycle that it moves to the RUN state. Because of a potential race condition,
it is therefore possible for the Transmitter to receive credit while in the ACTIVATE state.
• The Receiver can move from the ACTIVATE state to the RUN state when it is prepared to
receive flits.

RUN
• This state has an ongoing exchange of flits and credits between the two components.
• RUN is a stable state. A channel can remain in it for an indefinite time when this state is
entered.
• The Receiver can send credit and receive flits or credit returns.
• The Transmitter can send flits and receive credits.
• The Transmitter is permitted to send credit returns but this is not expected.
• The Transmitter can move from the RUN state to the DEACTIVATE state for a number of
reasons, such as when it has no flits to send. See Response to a new state on page 5-46 for
more information.

DEACTIVATE
• This state is used when transitioning from RUN state to the STOP state.

5-44 Copyright © 2017, 2018, 2020 Arm Limited or its affiliates. All rights reserved. ARM IHI 0079B
Non-Confidential ID121720
 5 CXS interface activation and deactivation
5.2 Request and acknowledgment handshaking

• DEACTIVATE is a transient state. It is expected that when this state is entered, a channel
moves to the next stable state in a relatively short time.
• The Transmitter must stop sending flits before entering this state. Because of a potential race
condition, it is possible for the Receiver to receive flits in this state.
• The Receiver can send credit when entering this state. In a timely manner, it must stop
sending credit to allow all credit to be returned to the Receiver.
• The Receiver can receive credit returns.
• The Transmitter must send credit returns to allow all credits to be returned to the Receiver.
• The Receiver must only exit this state and move to the STOP state when all credits have been
returned.

This specification does not define a maximum time in a transient state, but it is expected that for any given
implementation that it is deterministic.

The state transitions are triggered by the CXSACTIVEREQ and CXSACTIVEACK signals. Figure 5-2 shows the
relationship between the four states, with values of the signals CXSACTIVEREQ and CXSACTIVEACK
respectively, on each transition.

STOP
CXSACTIVEREQ = 0 CXSACTIVEREQ = 1
CXSACTIVEACK = 0 CXSACTIVEACK = 0

DEACTIVATE ACTIVATE

CXSACTIVEREQ = 0 CXSACTIVEREQ = 1
CXSACTIVEACK = 1 CXSACTIVEACK = 1
RUN

Figure 5-2 Request and acknowledge handshake states

ARM IHI 0079B Copyright © 2017, 2018, 2020 Arm Limited or its affiliates. All rights reserved. 5-45
ID121720 Non-Confidential
5 CXS interface activation and deactivation
5.3 Response to a new state

5.3 Response to a new state

If the state change has been initiated by the other side of the interface, a component might be required to change its
behavior when moving to a new state.

If the state change requires a component to stop sending flits or credits, then the component is permitted to take
some time to respond.

The Transmitter is always responsible for initiating the state change from RUN to STOP, or from STOP to RUN.
This state change requirement can be detected through several mechanisms. The following examples are not
exhaustive:

• The Transmitter can determine that it has flits to send, so must move from STOP to RUN.

• The Transmitter can determine that it has no activity to perform for a significant period, so can move from
RUN to STOP.

• The Transmitter can observe an independent sideband signal that indicates it should move either from RUN
to STOP, or from STOP to RUN.

• The Transmitter can observe the CXSDEACTHINT signal from the Receiver and decide to move from RUN
to STOP.

5-46 Copyright © 2017, 2018, 2020 Arm Limited or its affiliates. All rights reserved. ARM IHI 0079B
Non-Confidential ID121720
 5 CXS interface activation and deactivation
5.4 Race conditions

5.4 Race conditions

A race condition exists when one side of the interface performs two actions at, or around, the same time. The CXS
specification permits different delays between the data flow and link control groups of signals. Therefore, the order
of the actions at arrival might not be the same as the order of issue.

The following race conditions can occur:

• The Receiver asserts the CXSACTIVEACK signal, to move from ACTIVATE to RUN, and starts sending
credits:
— The Receiver is permitted to assert CXSCRDGNT in the same cycle that the CXSACTIVEACK
signal is asserted.
— The credit might be received at the Transmitter before its local CXSACTIVEACK signal is asserted.
— Therefore, the Transmitter must accept credits while in the ACTIVATE or RUN state.

• The Transmitter stops sending flits and then deasserts the CXSACTIVEREQ signal, to move from RUN to
DEACTIVATE:
— The Transmitter must not send flits when the CXSACTIVEREQ signal is deasserted.
— An in-flight flit might be received at the Receiver after its local CXSACTIVEREQ signal is
deasserted.
— Therefore, the Receiver must accept flits while in the DEACTIVATE state and it can only move to the
STOP state when all credits are returned.

These race conditions are possible because the CXSACTIVEREQ and CXSACTIVEACK signals need not have
the same delay between Transmitter and Receiver as the other signals.

ARM IHI 0079B Copyright © 2017, 2018, 2020 Arm Limited or its affiliates. All rights reserved. 5-47
ID121720 Non-Confidential
5 CXS interface activation and deactivation
5.5 Timing relationships between data and link control signals

5.5 Timing relationships between data and link control signals

Permitted timing relationships between the CXS signals depend on signal type.

The following signals must be synchronous with identical delay:

• CXSVALID
• CXSDATA
• CXSCNTL
• CXSCRDRTN

The following signals must be synchronous but can have any delay:
• CXSCRDGNT
• CXSACTIVEACK
• CXSDEACTHINT

The following signal must be driven synchronously but can be captured asynchronously with any delay:
• CXSACTIVEREQ

CHK signals must be clocked and pipelined identically to their corresponding signals.

Usually, the physical distance between the Transmitter and Receiver will determine the number of flip-flop stages
that are required to achieve the necessary frequency. The required number of flip-flop stages will most likely be
applied to all the signals on the interface.

The exception is the CXSACTIVEREQ signal. It is common for the clock in the Receiver to stop during the STOP
state due to clock gating. The assertion of the CXSACTIVEREQ signal might be used to restart that clock. It is
possible that the flip-flops between Transmitter and Receiver are in the Receiver clock domain and are also clock
gated during STOP state. The CXSACTIVEREQ signal might need to have a combinational path between
Transmitter and Receiver. This path might be a multicycle path due to distance and required frequency of the
interface. This multicycle character is acceptable because the CXSACTIVEREQ and CXSACTIVEACK signals
participate in a four-phase handshake and can run asynchronously.

The CXSACTIVEREQ signal must therefore be treated by the Receiver as an asynchronous signal and run through
appropriate synchronization logic to avoid metastability before use.

It is permitted for the CXSACTIVEACK and CXSDEACTHINT signals to be treated as synchronous input
signals by the Transmitter. These signals must not be multicycle path between Receiver and Transmitter, although
they can have as many flip-flops as is needed.

5-48 Copyright © 2017, 2018, 2020 Arm Limited or its affiliates. All rights reserved. ARM IHI 0079B
Non-Confidential ID121720
 5 CXS interface activation and deactivation
5.6 Interface activation and deactivation examples

5.6 Interface activation and deactivation examples

This section provides interface activation and deactivation examples.

An activation of an interface is shown in Figure 5-3.

1. At Time 0, both the Transmitter and Receiver are in the STOP state. Both sides could be clock gated or
powered down.
2. The Transmitter asserts CXSACTIVEREQ and moves into the ACTIVATE state at Time 1.
3. The Transmitter then waits for the Receiver to wake up and assert CXSACTIVEACK at Time 6.
4. In this case, CXSCRDGNT is asserted the same cycle as CXSACTIVEACK.
5. Having received a credit, the Transmitter sends a flit at Time 7.
6. Transmitter continues to send while it is receiving credits.

Time 0 1 2 3 4 5 6 7 8 9 10 11 12 13

Clock

CXSACTIVEREQ

CXSACTIVEACK

CXSCRDGNT

CXSCRDRTN

CXSVALID

CXSDATA a b c d e f g

(TX credit count) 0 0 0 0 0 0 0 1 1 1 1 1 1 1

Figure 5-3 Interface activation example

Figure 5-4 shows the same example with more delay between the Receiver and Transmitter on the
CXSACTIVEACK signal path than there is on the CXSCRDGNT path. Because of the additional delay, the
Transmitter receives a credit while in the ACTIVATE state. However, the Transmitter cannot send a flit until
CXSACTIVEACK signal goes HIGH at Time 6 and it moves into the RUN state.

Time 0 1 2 3 4 5 6 7 8 9 10 11 12 13

Clock

CXSACTIVEREQ

CXSACTIVEACK

CXSCRDGNT

CXSCRDRTN

CXSVALID

CXSDATA a b c d e f g

(TX credit count) 0 0 0 0 0 0 1 2 2 2 2 2 2 2

Figure 5-4 Interface activation example with race

ARM IHI 0079B Copyright © 2017, 2018, 2020 Arm Limited or its affiliates. All rights reserved. 5-49
ID121720 Non-Confidential
5 CXS interface activation and deactivation
5.6 Interface activation and deactivation examples

Figure 5-5 shows an interface deactivation example. Both sides of the link start in RUN state. The Transmitter has
no more flits to send and decides to deactivate the interface. The Transmitter deasserts the CXSACTIVEREQ
signal, taking the interface into DEACTIVATE state. The Transmitter has a nonzero credit count, so it returns credits
by asserting CXSCRDRTN.

The Receiver continues to grant credits for several cycles until it recognizes that the link is being deactivated. The
Transmitter must return the additional credits as well, asserting CXSCRDRTN until its credit count is zero. The
Receiver must not deassert the CXSACTIVEACK signal until it has all the credits and there are no credit grants in
flight. The Transmitter will never see that the CXSACTIVEACK signal is deasserted while it still has credits.

Time 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

Clock

CXSDEACTHINT

CXSACTIVEREQ

CXSACTIVEACK

CXSCRDGNT

CXSCRDRTN

CXSVALID

CXSDATA a b c

(TX credit count) 1 1 1 1 2 3 3 3 3 3 2 1 0 0 0 0 0 0

Figure 5-5 Interface deactivation example

5-50 Copyright © 2017, 2018, 2020 Arm Limited or its affiliates. All rights reserved. ARM IHI 0079B
Non-Confidential ID121720
Chapter 6
CXS packet continuous delivery guarantees

This chapter describes CXS packet continuous delivery guarantees:

• Continuous delivery guarantees for CXS packets on page 6-52.

ARM IHI 0079B Copyright © 2017, 2018, 2020 Arm Limited or its affiliates. All rights reserved. 6-51
ID121720 Non-Confidential
6 CXS packet continuous delivery guarantees
6.1 Continuous delivery guarantees for CXS packets

6.1 Continuous delivery guarantees for CXS packets

Some CXS implementations have a downstream interface that cannot tolerate interruptions in the data flow. PCIe
is an example. An uninterrupted flow can be achieved using a CXS interface if either the Receiver or Transmitter
has a store-and-forward buffer.

If the Receiver is built with the store-and-forward buffer, a packet must be able to be received in full before it is
transmitted on the downstream interface. The Receiver must have enough buffering to store the largest packet that
can be sent by the Transmitter. In this case, the Receiver and Transmitter can set the CXSCONTINUOUSDATA
property False and the Transmitter is not required to buffer the packet.

If the Receiver does not have a buffer and requires continuous data, then it sets the CXSCONTINUOUSDATA
property True and the attached Transmitter must also have CXSCONTINUOUSDATA as True. The Transmitter
must then be able to issue all flits within a packet without dependence on another interface.

The Transmitter must also not attempt to deactivate the link if that deactivation could occur at a time when some,
but not all, data of a packet has been issued.

If a continuous flow is required, the integrator must ensure that the Receiver has enough credits to cover the
worst-case round-trip credit latency. This includes:

• The delay on CXSCRDGNT between Receiver and Transmitter.

• The maximum internal delay between CXSTXCRDGNT and CXSTXVALID when the Transmitter has a
packet that is stalled waiting for credits. This is described by the CXS_MAX_CREDIT_LATENCY property
of the Transmitter.

• The delay on the CXSVALID signal between the Transmitter and Receiver.

• The maximum internal Receiver delay between CXSRXVALID and CXSRXCRDGNT. This is described
by the CXS_MAX_CREDIT_LATENCY property of the Receiver.

The maximum number of credits that a Receiver can issue is dependent on the size of its buffer, it can be described
by its CXS_MAX_CREDIT property.

If the downstream interface is clocked slower than the CXS link, then it might not be necessary to transmit one flit
every cycle. In this case, the number of credits required for the Receiver to maintain a constant flow might be fewer
than the round-trip latency.

6-52 Copyright © 2017, 2018, 2020 Arm Limited or its affiliates. All rights reserved. ARM IHI 0079B
Non-Confidential ID121720
Appendix A
Revisions

This appendix describes the technical changes between released issues of this specification.

Table A-1 Issue A

Change Location

First release of Version A −

Table A-2 Issue B

Change Location
Support for multiple protocol streams Chapter 2
Extension to interface protection signaling to support Chapter 2
new signals
Clarification of continuous delivery guarantees Chapter 6

ARM IHI 0079B Copyright © 2017, 2018, 2020 Arm Limited or its affiliates. All rights reserved. A-53
ID121720 Non-Confidential
Appendix A Revisions

A-54 Copyright © 2017, 2018, 2020 Arm Limited or its affiliates. All rights reserved. ARM IHI 0079B
Non-Confidential ID121720