QUIC10GS IP Core Datasheet

· Set parameters. 8

· Listen for a secure connection. 8

· Open and close a secure connection. 9

· Handshake process 10

· User Tx interface. 12

· User Rx interface. 15

· Alert handling. 19

· MAC Interface. 21

Verification Methods. 22

Recommended Design Experience. 22

Ordering Information. 22

Revision History. 22

Core Facts
Provided with Core
Documentation	User Guide, Design Guide
Design File Formats	Encrypted File
Instantiation Templates	VHDL
Reference Designs & Application Notes	Vivado Project, See Reference design manual
Additional Items	Demo on KCU116
Support
Support Provided by Design Gateway Co., Ltd.

Design Gateway Co., Ltd

E-mail: ip-sales@design-gateway.com

URL: design-gateway.com

Features

· 10Gbps QUIC engine conforming to RFC9000.

· Supports the Client-side QUIC operation.

· Supports TLS1.3 cipher suite:

· Key exchange: X25519

· Derive key: HKDF with SHA256

· Encryption/decryption: AES128GCM

· Certificate type: RSA2048

· Signature algorithm: rsa_pss_rsae_sha256

· Supports four streams (StreamIDs #0-3) compliant with the QUIC standard.

· Recommend clock frequency at least 200 MHz for high throughput.

· Supports unaligned AXI4 protocol for user data interface.

· Utilizes a ring buffer technique for user memory management interface.

· Supports 32-bit MAC interface using AXI4-Stream protocol, operating at 322.266 MHz.

· Customized service options:

· Increase the number of supported streams.

· Increase user buffer size.

· Extend certificate size.

· Enable 0-RTT session resumption.

Table 1 Example Implementation Statistics

Family

Example Device

Fmax (MHz)

CLB

Regs

CLB

LUTs

CLB¹

DSP

BRAMTile

Design Tools

Kintex UltraScale+

XCKU5P-FFVB676-2-E

200

22380

47024

8773

123

Vivado2022.1

Notes:

1) The actual logic resource depends on the percentage of unrelated logic.

Figure 1 The QUIC protocol architecture

General Description

QUIC is a cryptographic transport protocol designed to provide a secure and efficient connection between a client and server over the network. Before the development of the QUIC protocol, the TLS protocol was widely used for secure communication, but it depends on the transport protocol, named TCP/IP, for the connection-oriented and reliable data transmission. This dependency limits the performance of the TLS protocol. For this reason, the QUIC protocol was designed and later approved as a standard to provide a secure data transfer protocol and to address the limitations faced by TLS.

The fact that QUIC protocol spans multiple layers in the OSI model offers the flexibility and control over how it manages its own data flow. This allows QUIC protocol to implement its transport specification to tackle network problems in actual systems, as well as to develop its own data flow structure to support the need for multiple stream connections. These advantages of the QUIC protocol are just examples of what it offers to overcome the limitations of TLS.

Although several network applications these days still use the TLS protocol for secure data transfer, it is becoming more common, at the time of writing this document, to find the use of the QUIC protocol in web browsing, DNS, and other applications. For example, the QUIC protocol is on by default in Chrome browser, and many other major companies, such as Apple and Facebook, have adopted QUIC in their applications.

Our QUIC Server 10Gbps IP Core (QUIC10GS-IP) is specifically engineered to manage the TLS1.3 handshake for a server, encrypt outgoing payload data, decrypt incoming payload data and handle QUIC transport tasks, effectively covering both QUIC and UDP/IP layers, as illustrated in Figure 1. Prior to transferring payload data using the QUIC protocol, a handshake process is initiated to establish a secure connection. During this phase, the server exchanges and generates cryptographic keys to ensure data confidentiality. It also provides its signature and certificate for validation by the QUIC client to establish authenticity. The QUIC10GS-IP enables data transmission only after a successful handshake has established a secure channel between the two parties.

The QUIC Protocol Version 1 and several technical terms mentioned in this document adheres to the standards defined by RFC9000. For more information, please refer to the RFC9000 document. For details on TLS Protocol Version 1.3, please refer to the RFC8446 document.

Functional Description

Figure 2 illustrates QUIC10GS-IP block diagram and its interface signals. Users can control and transfer data with QUIC10GS-IP via the user interface signals as described in Table 2. Additionally, users may refer to the QUIC10GS-IP reference design document for an example implementation, which provides a clearer understanding of how to utilize the QUIC10GS-IP.

· MAC Interfaces: The interfaces that connect to the lower layer, namely MAC Tx I/F and MAC Rx I/F, run at a clock frequency of 322.266 MHz. These interfaces are used to transfer network packets with the MAC layer.

· Core Interfaces: The remaining interfaces run at the IP core clock frequency, called QUICClk, which is recommended to be set greater than 200 MHz for optimized performance.

To configure and operate the QUIC10GS-IP, the user utilizes specific control groups. The Network Parameters Group is used to set essential network parameters, including source MAC address, IP address, and port. The Connection Parameters Group defines QUIC-specific parameters along with some network settings. The Connection Control Interface manages and monitors the QUIC connection. To transfer QUIC data, the user manages send and receive data through User Tx/Rx Memory I/F, and IP is then responsible for handling user data transfers through AXI4 Write/Read Channels. Additionally, the user can also monitor QUIC Rx information frames through User Rx Info group and can access handshake information in details through QUIC handshake info group. However, these optional interfaces enable advanced monitoring and debugging capabilities but can be ignored if the user only needs a straightforward data transfer channel through the QUIC10GS-IP.

Figure 2 QUIC10GS-IP block diagram

Table 2 Core Parameters

Parameter name	Value	Description
ClockPerUS	100-1000	Setting number of cycles per micro-second. This value is a requirement for using the IP.
ConRespTimeoutBit	1-16	Number of counter bits for connection response timeout.

Table 3 QUIC10GS-IP Interface signals

Signal name	Dir	Description
RstB	In	IP core system reset. Active low.
QUICClk	In	IP core system clock.
MacTxClk	In	Clock signal which is synchronous to Tx MAC interface for running with low-latency 10G MAC, at the frequency of 322.266 MHz.
MacRxClk	In	Clock signal which is synchronous to Rx MAC interface for running with low-latency 10G MAC, at the frequency of 322.266 MHz.
version[31:0]	Out	32-bit version number of QUIC10GS.
Network parameters
NetworkSet	In	User asserts to ‘1’ when network parameters are valid. Must be asserted while QUICConnOnBusy is ‘0’.
SrcMacAddr[47:0]	In	MAC address of QUIC10GS-IP.
SrcIPAddr[31:0]	In	IP address of QUIC10GS-IP.
SrcPort[15:0]	In	UDP source port of QUIC10GS-IP.
QUICALPNLen[4:0]	In	User sets ALPN string length. Maximum value is 16 ("10000"). Values exceeding this cause a QUIC error. To disable ALPN validation, set this field to 0.
QUICALPNStr[127:0]	In	User sets ALPN string value.
Connection Information
DstIPAddr[31:0]	Out	IP address of the target device. Becomes valid when QUICConnOnBusy is asserted to ‘1’.
DstPort[15:0]	Out	UDP target port of the QUIC connection. Becomes valid when QUICConnOnBusy is asserted to ‘1’.
Connection Control interface
QUICConnOn	In	User sets connection status. ‘1’: Accept and establish the connection. ‘0’: Reject the connection.
QUICConnOnBusy	Out	Indicates the busy status of the connection operation. Asserted to ‘1’ from the moment a client requests a secure connection until the connection is closed.
QUICHandshakeBusy	Out	Specifies the busy status of handshake operation.
QUICTxTrnsBusy	Out	Specifies the busy status of data transmit operation.
QUICRxTrnsBusy	Out	Specifies the busy status of data receive operation.
QUICAlertInt	Out	Alert Interrupt. Asserted to ‘1’ for a cycle when an alert is detected.
QUICAlertCode[15:0]	Out	Indicates normal or alert conditions. QUICAlertCode[15]: ‘1’ alert from server, ‘0’ alert from IP. QUICAlertCode[14:0]: Alert description.

AXI4 Address Read Channel
QUICTxArReady	In	Indicates that the slave is ready to accept the address read command.
QUICTxArValid	Out	Indicates that the address and control information is valid.
QUICTxArAddr[63:0]	Out	Carries the address for the read transaction.
QUICTxArLen[7:0]	Out	Specifies the length of the data transaction (number of data transfers).
AXI4 Read Data Channel
QUICTxrReady	Out	Indicates that the master is ready to accept the read data.
QUICTxrValid	In	Indicates that the read data is valid and can be read by the master.
QUICTxrData[127:0]	In	Carries the read data from the slave to the master.
QUICTxrStrb[15:0]	In	Indicates which bytes of the read data are valid (one bit per byte).
QUICTxrLast	In	Indicates the last transfer in a burst transaction.
AXI4 Address Write Channel
QUICRxAwReady	In	Indicates that the slave is ready to accept the address write command.
QUICRxAwValid	Out	Indicates that the address and control information is valid.
QUICRxAwAddr[63:0]	Out	Carries the address for the write transaction.
QUICRxAwLen[7:0]	Out	Specifies the length of the data transaction (number of data transfers).
AXI4 Write Data Channel
QUICRxwReady	Out	Indicates that the slave is ready to accept the write data.
QUICRxwValid	In	Indicates that the write data is valid and can be written from the master to the slave.
QUICRxwData[127:0]	In	Carries the write data from the master to the slave.
QUICRxwStrb[15:0]	In	Indicates which bytes of the write data are valid (one bit per byte).
QUICRxwLast	In	Indicates the last transfer in a burst transaction.
AXI4 Write Response Channel
QUICRxbReady	Out	Indicates that the master is ready to accept the write response.
QUICRxbValid	In	Indicates that the write response is valid.
User Tx Memory Management interface
AppTxBaseAddr[63:0]	In	Base address for the application streams.
AppTxWrFin0	In	Write finish signal for StreamID0.
AppTxWrAddr0[17:0]	In	Write address for StreamID0.
AppTxRdAddr0[17:0]	Out	Read address for StreamID0.
AppTxWrFin1	In	Write finish signal for StreamID1.
AppTxWrAddr1[17:0]	In	Write address for StreamID1.
AppTxRdAddr1[17:0]	Out	Read address for StreamID1.
AppTxWrFin3	In	Write finish signal for StreamID3.
AppTxWrAddr3[17:0]	In	Write address for StreamID3.
AppTxRdAddr3[17:0]	Out	Read address for StreamID3.

User Rx Memory Management interface
AppRxBaseAddr[63:0]	In	Base address for the application streams.
AppRxWrFin0	Out	Write finish signal for StreamID0.
AppRxWrAddr0[17:0]	Out	Write address for StreamID0.
AppRxRdAddr0[17:0]	In	Read address for StreamID0.
AppRxWrFin1	Out	Write finish signal for StreamID1.
AppRxWrAddr1[17:0]	Out	Write address for StreamID1.
AppRxRdAddr1[17:0]	In	Read address for StreamID1.
AppRxWrFin2	Out	Write finish signal for StreamID2.
AppRxWrAddr2[17:0]	Out	Write address for StreamID2.
AppRxRdAddr2[17:0]	In	Read address for StreamID2.
User Rx information
QUICRxInfoValid	Out	Indicates that the Rx information is valid.
QUICRxInfoType	Out	Type of the Rx information.
QUICRxInfoID	Out	StreamID associated with the Rx information.
QUICRxInfoD0	Out	Data field 0 of the Rx information.
QUICRxInfoD1	Out	Data field 1 of the Rx information.
Server certificate and RSA private key file
QUICCertRdEn	Out	Asserted to ‘1’ as Read Enable when reading QUICCertRdData.
QUICCertRdAddr[11:0]	Out	Specifies the read address for QUICCertRdData. Valid when QUICCertRdEn is asserted to ‘1’.
QUICCertRdData[15:0]	In	QUICCertRdData is 16-bit input data of server’s certificate. This signal must be valid after QUICCertRdEn is asserted to be ‘1’ and corresponding to QUICCertRdAddr.
QUICRSAKeyRdEn	Out	Asserted to ‘1’ as Read Enable when reading QUICRSAKeyRdData.
QUICRSAKeyRdAddr[9:0]	Out	Specifies the read address for QUICRSAKeyRdData. Valid when QUICRSAKeyRdEn is asserted to ‘1’.
QUICRSAKeyRdData[15:0]	In	QUICRSAKeyRdData is 16-bit input data of RSA private key. This signal must be valid after QUICRSAKeyRdEn is asserted to be ‘1’ and corresponding to QUICRSAKeyRdAddr.
QUIC handshake information*
QUICKeyValid	Out	Asserted to ‘1’ when key materials are valid.
Random[255:0]	Out	256-bit Random number in ClientHello. Valid when QUICKeyValid is asserted to ‘1’.
CTS[255:0]	Out	Client Traffic Secret is key material Valid when QUICKeyValid is asserted.
STS[255:0]	Out	Server Traffic Secret is key material Valid when QUICKeyValid is asserted.

MAC Tx Interface (Synchronous to TxClk)
MACTxReady	In	Asserted to ‘1’ when MACTxData is being accepted.
MACTxValid	Out	Asserted to ‘1’ when MACTxData is valid.
MACTxData[31:0]	Out	Transmitted data of the IP to the Ethernet MAC. It is valid when ‘MACTxValid’ is set to ‘1’.
MACTxByteEn[3:0]	Out	Byte enable of MACTxData. Valid when MACTxValid=‘1’. During packet transmission, this signal is equal to “1111” for enabling all 32-bit data except the final data of the packet which can be equal to four values: “0001”, “0011”, “0111”, or “1111” when MACTxData[7:0], [15:0], [23:0], or [31:0] is valid respectively.
MACTxSOP	Out	Asserted to ‘1’ with the first data of the packet on MACTxData. Valid when MACTxValid is asserted to ‘1’.
MACTxEOP	Out	Asserted to ‘1’ with the final data of the packet on MACTxData. Valid when MACTxValid is asserted to ‘1’.
MAC Rx Interface (Synchronous to RxClk)
MACRxValid	In	Asserts to ‘1’ to transfer MACRxData.
MACRxData[31:0]	In	Received data from the Ethernet MAC. It is valid when MACRxValid is set to ‘1’.
MACRxByteEn[3:0]	In	Byte enable of MACRxData. Valid when MACRxValid=‘1’. During packet transmission, this signal is equal to “1111” for enabling all 32-bit data except the final data of the packet which0 can be equal to four values: “0001”, “0011”, “0111”, or “1111” when MACRxData[7:0], [15:0], [23:0], or [31:0] is valid respectively.
MACRxEOP	In	Asserts to ‘1’ to indicate that this is the last data.
MACRxError	In	Asserts to ‘1’ to indicate that this frame contains an error. This signal is valid when the last data is transferred, as indicated by MACRxEOP=‘1’.

Note:

* QUIC handshake information is optional signals that user can access handshake information in details. User can ignore these signals and implement QUIC10GS-IP as a channel to pass through payload.

· Set parameters

Users must configure network parameters for the QUIC10GS-IP on the IP (Source) side by asserting NetworkSet to ‘1’ while QUICConnOnBusy is ‘0’. During this operation, the SrcMacAddr[47:0], SrcIPAddr[31:0], and SrcPort[15:0] parameters must be valid. These parameters will remain unchanged for every connection until the user sets new parameters.

For ALPN (Application-Layer Protocol Negotiation), the ClientHello message includes an extension that specifies the application-layer protocol for the secure connection. To enable ALPN validation, set QUICALPNLength[4:0] and QUICALPNString[127:0] when asserting NetworkSet to ‘1’ while QUICConnOnBusy is ‘0’. To disable ALPN validation, set QUICALPNLength[4:0] to 0. If QUICALPNLength[4:0] is not 0, the server validates the ALPN in the received ClientHello message. If the ClientHello does not include an ALPN extension or the protocol does not match QUICALPNString, the server returns error 0x0178 (tls_no_application_protocol).

Figure 3 Example of setting parameters

· Listen for a secure connection

The QUIC10GS-IP handles the full handshake process using a supported cipher suite and manages encryption and decryption of network data. After configuring the network parameters, the QUIC10GS-IP listens for incoming QUIC connections.

When a client initiates a secure connection, QUICConnOnBusy is asserted to ‘1’, and DstPort[15:0] and DstIPAddr[31:0] become valid. The user can check and validate the connection status. To accept the secure connection, the user must assert QUICConnOn to ‘1’. To reject the connection, the user must keep QUICConnOn set to ‘0’ until the timeout period expires (QUICConnOnBusy=‘0’).

The timeout duration is specified by the user through the ConRespTimeoutBit generic parameter. QUICConnOnBusy remains valid for 2^ConRespTimeoutBit clock cycles. If the user does not respond within this period, the QUIC10GS-IP automatically rejects the connection and resumes listening for an incoming QUIC connection.

Figure 4 Example of QUIC10GS-IP detecting client initiates a secure connection

· Open and close a secure connection

As shown in Figure 5, after QUICConnOn is asserted to ‘1’, the QUIC10GS-IP begins the handshake operation, indicated by the assertion of QUICHandshakeBusy to ‘1’. It is important to note that during this phase, data transmission is not permitted. Additionally, this version supports only open connections with 1-RTT.

However, before the handshake process is finished (i.e., QUICHandshakeBusy is de-asserted to ‘0’), users are allowed to prepare TxData in the Tx user buffer. Once the handshake process is complete, the QUIC10GS-IP transitions to the data-transfer phase. QUICTxTrnsBusy is asserted to ‘1’ when the Tx user buffer is not empty and is cleared when the TxData has been fully acknowledged by the server. When the client sends data to the QUIC10GS-IP, QUICRxTrnsBusy is asserted to ‘1’. QUICRxTrnsBusy is cleared when the received data is written to the Rx user buffer.

Users can close the connection only when QUICHandshakeBusy, QUICTxTrnsBusy, and QUICRxTrnsBusy are all not asserted to ‘1’. To ensure the connection is fully closed, users must wait for QUICConnOnBusy to be de-asserted (QUICConnOnBusy=‘0’). The IP will assert QUICConnOnBusy to ‘1’ again when a new connection request arrives. If the user attempts to close the connection while any of these signals are asserted, the QUIC10GS-IP will return an alert code ABNORMAL_CLOSE_ERROR.

During the connection, if an error occurs, the IP sends an alert code through the QUICAlertCode signal by asserting QUICAlertInt. After this, users should clear QUICConnOn to ‘0’ to allow the QUIC10GS-IP to resume listening for an incoming QUIC connection. More details about the alert codes can be found in the Alert handling section.

Figure 5 Example of opening and closing a connection

· Handshake process

Figure 6 Handshake process

Figure 6 shows the main flow of the QUIC full handshake process. Once the UDP connection is established and the ClientHello message is received from the client, QUIC10GS-IP, acting as the server, checks the supported TLS parameters. These parameters include the supported cipher suite (which must be TLS_AES_128_GCM_SHA256), compression method, signature algorithm, supported version, and the client’s public key. If all parameters are valid and supported, QUIC10GS-IP responds by transmitting a ServerHello message, which includes the server’s ephemeral X25519 public key.

When QUIC10GS-IP receives the ClientHello message, it uses the client’s public key to compute the shared key using X25519. This shared key is then passed to a key derivation function (KDF) to generate the key materials needed for encryption and decryption. The QUIC10GS-IP uses the Hash-based Key Derivation Function (HKDF) with SHA256 for this process.

The key materials derived from HKDF-SHA256 include the Client Traffic Secret (CTS) and Server Traffic Secret (STS). CTS is used to derive the client traffic key and initialization vector (IV) to encrypt handshake messages sent by the client. Similarly, STS is used to derive the server traffic key and IV to decrypt handshake messages sent by the server. Users can access the CTS and STS when QUICKeyValid is asserted to ‘1’.

To provide authenticity via the server’s certificate, which uses RSA2048-PSS with a SHA256 signature, users must prepare the server’s certificate and RSA private key file for QUIC10GS-IP in ASN.1 DER binary encoding. The maximum size is 8 kB for the certificate and 2 kB for the RSA private key file.

For certificate handling, the QUIC10GS-IP asserts QUICCertRdEn to ‘1’ and sets QUICCertRdAddr[11:0] as the read address to access the certificate data (QUICCertRdData[15:0]). Similarly, the QUIC10GS-IP asserts QUICRSAkeyRdEn to ‘1’ and sets QUICRSAKeyRdAddr[9:0] as the read address to access the RSA key data (QUICRSAkeyRdData[15:0]). Both QUICCertRdData[15:0] and QUICRSAkeyRdData[15:0] must be valid after one clock cycle corresponding to their respective read addresses.

Figure 7 Example of timing diagram for reading certification information

Figure 8 Example of timing diagram for reading RSA key information

After receiving the client’s Finished message, QUIC10GS-IP regenerates the key materials, specifically CTS and STS, to derive the key and IV for application data encryption. During this process, QUICKeyValid is de-asserted to ‘0’ while key derivation is in progress. Once key derivation is complete, QUICKeyValid is asserted to ‘1’, indicating that the CTS and STS are valid and ready for use, as shown in Figure 9.

Figure 9 Example of controlling signals in handshake process timing diagram

· User Tx interface

The QUIC10GS-IP provides the support of four stream connections. Before using QUIC10GS-IP, users are required to allocate 1024KB of memory starting from AppTxBaseAddr[63:0], which the IP will use as a transmit buffer. This memory is divided into four blocks of 256KB, each designated for StreamID0, StreamID1, StreamID2, and StreamID3, respectively, as illustrated in Figure 10.

According to the QUIC protocol, StreamID0 and StreamID2 are client-initiated streams, while StreamID1 and StreamID3 are server-initiated streams. So StreamID0 and StreamID2 can be opened by the client sending data first, and StreamID1 and StreamID3 can be opened by the server sending data first. Therefore, users can use StreamID1 and StreamID3 to transmit data immediately after the handshake is complete. However, StreamID0 can only be used after the client has initiated it. Moreover, StreamID2 is a unidirectional stream, reserved for receive-only data, and cannot be used to transmit data.

Figure 10 Transmit memory structure

Each block of memory in the transmit buffer functions as a circular buffer. This means that the buffer uses a write pointer (WrPtr) and a read pointer (RdPtr) to manage the flow of data. The WrPtr indicates the byte address to which data will be written, while the RdPtr indicates the byte address from which data will be read. The difference between these pointers shows the position of available data.

In Figure 11, three examples illustrate how to use the circular buffer in context. Figure 11a shows an empty buffer, with both pointers at the same address, at address 1. Figure 11b depicts data written from address 1 to 5, with WrPtr at address 6, indicating 5 bytes of available data from address 1 to 5, while RdPtr remains unchanged. Figure 11c demonstrates a full buffer scenario, where WrPtr is at address 3 and RdPtr has moved to address 4, preventing WrPtr from increasing further to avoid overwriting unread data. This also illustrates address 1 and 2 being reused, showing the use of the circular buffer concept.

Figure 11 Example of the circular buffer concept

The transmit buffer uses AppTxWrAddrX[17:0] as the write pointer (WrPtr) and AppTxRdAddrX[17:0] as the read pointer (RdPtr), where ‘X’ represents the streamID. When a new connection is opened, AppTxRdAddrX[17:0] will be moved to the location of AppTxWrAddrX[17:0], ensuring that the transmit buffer is initially empty. The user can then prepare transmission data in the memory by updating AppTxWrAddrX[17:0], signaling to the QUIC10GS-IP that data is available in the transmit buffer for StreamID ‘X’. The QUIC10GS-IP reads this data via the AXI4 protocol, segments it into QUIC packets, encrypts, and sends it to the other endpoint. After reading the data, the QUIC10GS-IP moves AppTxRdAddrX[17:0] to the next byte address to be read, allowing the user to reuse that buffer section.

To close a stream in StreamID ‘X’, AppTxWrFinX needs to be set to ‘1’ along with the last valid address of AppTxRdAddrX[17:0] to ensure the remaining data up to this address is transmitted. After this, no additional data can be sent through StreamID ‘X’.

Figure 12 Example of reading data from the transmit buffer

To transfer data from memory, an AXI4 read controller is utilized in the User Tx data interface of our IP. The following constraints are applied:

· The burst attribute is set to INCR (ARBURST=0b00), indicating that the address for each transfer is incremented.

· Transfers can be unaligned, utilizing an unaligned start address and byte lane strobes.

· Single AXI4 transactions are applied.

· ARSIZE is set to 0b100, indicating 16 bytes per transfer.

· ARLEN is not fixed to 2, 4, 8, or 16.

· Maximum transaction bytes are capped at 4096 bytes per transaction.

· The address for each transfer is guaranteed to always be within a memory boundary.

· RRESP is not presented and assumed to be 0b000 (OKAY).

Figure 13 AXI4 read operation for the User Tx data interface

The example presents the sequence of the AXI4 read operation used by the IP to obtain the transmit data from the memory. The IP performs this operation in a single access only. It starts by sending the address transaction, asserting the QUICTxArValid to ‘1’ along with the valid values for QUICTxArAddr and QUICTxArLen. The first variable is the start address of the accessed memory, and the second is the transfer length in word units. For instance, Figure 13 shows the transfer of D0 – D20, hence, the transfer length is 0x14.

Once the address transaction is complete, the IP waits to receive the data transaction, which can be a burst or a single beat depending on the QUICTxArLen value. The read operation finishes when both QUICTxrValid and QUICTxrLast are asserted to ‘1’.

The IP supports the discontinuous transfers. When QUICTxArReady equals ‘0’, the IP holds the current valid values of the address transaction. Similarly, the data transaction can be paused by de-asserting QUICTxrValid to ‘0’. Additionally, QUICTxrReady is always asserted to ‘1’, indicating that the IP is ready to receive the data it requested.

For unaligned data transfer, the IP may request an unaligned start address, which is setting QUICTxArAddr[3:0] to any value other than 0x0. For example, when QUICTxArAddr[3:0]=0xA, the first data (D0) will be valid only in QUICTxrData[127:80], and the first value of QUICTxrStrb can be set to either 0xFFFF or 0xFC00.

· User Rx interface

Similar to the User Tx interface, the QUIC10GS-IP supports four stream connections. Another 1024KB of memory, starting from AppRxBaseAddr[63:0], must be reserved for the IP as a receive buffer, divided into four 256KB blocks for StreamID0, StreamID1, StreamID2, and StreamID3, respectively, as shown in Figure 14.

As specified by the QUIC protocol, the client can send data to StreamID0 and StreamID2 of the server without restrictions. However, the user must first send data through StreamID1 before the client can transmit any data through StreamID1. Additionally, StreamID3 is a unidirectional stream, reserved for a send-only stream and is not used as a receive buffer.

Figure 14 Receive memory structure

The circular buffer concept is also applied to the User Rx interface. In this direction, however, the IP will write data to the receive buffer, and according to the protocol, it is possible that the data might not be in order. As depicted in Figure 15a, 5 bytes are available and confirmed by WrPtr and RdPtr from address 1 – 5. Other spaces in the memory can be filled with valid data but cannot yet be confirmed by WrPtr because it is not continuous. This case can also be seen in our QUIC10GS-IP environment and therefore, the users should threat the receive buffer as a read-only buffer.

As soon as the missing data is retransmitted to the IP, the new position of WrPtr will be recalculated and presented to the users. In Figure 15b, for example, if data at address 6, 7, and 10 are received, the IP will fill the data and then update WrPtr to the point where it is highest and continuous, which is address 11.

Figure 15 Example of the circular buffer concept in the receive buffer

The receive buffer uses AppRxWrAddrX[17:0] as the write pointer (WrPtr) and AppRxRdAddrX[17:0] as the read pointer (RdPtr), where 'X' represents the streamID. When a new connection is opened, AppRxWrAddrX[17:0] will be moved to the location of AppRxRdAddrX[17:0], ensuring that the receive buffer is initially empty. During data transfer, the QUIC10GS-IP uses the AXI4 protocol to write incoming data of the Stream ‘X’ into the receive buffer, only after which it will update AppRxWrAddrX[17:0] to point to the next valid and continuous data position. After processing the data in the receive buffer of the Stream ‘X’, the user updates AppRxRdAddrX[17:0] to the next read position, allowing the IP to reuse the buffer up to that section.

If the other endpoint requests to close the stream ‘X’, the QUIC10GS-IP will set AppRxWrFinX to ‘1’ along with the last valid address of AppRxWrAddrX[17:0]. After this, there will be no data received in Stream ‘X’.

Figure 16 Example of QUIC10GS-IP write data to receive memory

To transfer data to memory, similar to the User Tx data interface, an AXI4 write controller is included in the User Rx data interface. The following constraints are applied:

· The burst attribute is set to INCR (AWBURST=0b00), indicating that the address for each transfer is incremented.

· Transfers can be unaligned, utilizing an unaligned start address and byte lane strobes.

· Single AXI4 transactions are applied.

· AWSIZE is set to 0b100, indicating 16 bytes per transfer.

· AWLEN is not fixed to 2, 4, 8, or 16.

· Maximum transaction bytes are capped at 4096 bytes per transaction.

· The address for each transfer is guaranteed to always be within a memory boundary.

· BRESP is not presented and assumed to be 0b000 (OKAY), and BCOMP is not presented.

Figure 17 AXI4 write operation for the User Rx data interface

The above illustration shows the AXI4 write operation used by the IP to write data to the memory. Only a single access of the write operation is performed at a time. It starts by sending the address transaction, asserting QUICRxAwValid to ‘1’ along with two associated values, QUICRxAwAddr and QUICRxAwLen. The first value is the start address of the write position in the memory, and the other is the transfer length. This timing diagram, for example, presents the transfer of D0 – D15, where QUICRxAwLen must be 0xF.

The completion of the address transaction is indicated by the assertion of both QUICRxAwReady and QUICRxAwValid. After one clock cycle, the data transaction begins by asserting QUICRxwValid to ‘1’ with the valid values of QUICRxwData, QUICRxwStrb and QUICRxwLast. When QUICRxwLast is valid and asserted to ‘1’, the data transaction is completed. At the end, the IP waits for the write response from QUICRxbValid.

Discontinuous transfers of the address and data transaction are supported. QUICRxAwReady can be ‘0’, and the address transaction holds valid values, while the data transaction is paused when QUICRxwReady is set to ‘0’. Furthermore, QUICRxbReady is always asserted to ‘1’ to receive the write response.

For unaligned data transfer, QUICRxAwAddr[3:0] can be set to any value other than 0x0, and the first and the last write strobes (QUICRxwStrb) can be set to other values than 0xFFFF for writing the data into a particular byte address. In this example, QUICRxAwAddr[3:0] must be set to 0x8 so that the first QUICRxwStrb is 0xFF00.

Table 4 User Rx information

Name	Type[7:0]	ID[7:0]	D0[63:0]	D1[63:0]
RESET_STREAM	0x04	StreamID	Application Protocol Error Code	Final Size
STOP_SENDING	0x05	StreamID	Application Protocol Error Code	-
DATA_BLOCKED	0x14	-	Maximum Data	-
STREAM_DATA_BLOCKED	0x15	StreamID	Maximum Stream Data	-
STREAMS_BLOCKED	0x16 - 0x17	-	Maximum Streams	-

While the QUIC connection is established and enters the data transfer phase, specific QUIC frame types can be passed to the user for system monitoring purposes. These frame types are detailed in Table 4 and are communicated to the user through the User Rx Information interface.

For example, if a DATA_BLOCKED (0x14) frame is encountered, it will be sent to the user via the QUICRxInfoType signal, with the associated parameter Maximum Data presented through the QUICRxInfoD0 signal. This information indicates that the remote QUIC endpoint is attempting to send data but is being blocked by flow control constraints.

Receiving such frames allows users to identify issues in detail and subsequently manage their system more effectively. In the given scenario, users could release the used Rx buffer space back to the IP, enabling the remote QUIC endpoint to continue sending data. This monitoring and management can help maintain optimal data flow and system performance during QUIC data transfers.

Figure 18 Example of User Rx information

· Alert handling

In the QUIC protocol, a sender can send alert messages to indicate closure information and errors to the receiver. The QUIC10GS-IP is designed to support such alert messages, as shown in Error! Reference source not found.. It uses the QUICAlertCode[15] to represent the direction of the error code, asserting to ‘1’ when an error is received from the server and asserting to ‘0’ when an error arises from the QUIC10GS-IP. The QUICAlertCode[14:0], represents the specific error code.

Table 5 Alert code description

Alert Code [14:0]	Alert Message	Description
QUIC error codes
0x0000	NO_ERROR	Closed connection without error.
0x0001	INTERNAL_ERROR	Encountered unsupported features or resource exhausted.
0x0003	FLOW_CONTROL_ERROR	Received data that exceeds limit.
0x0004	STREAM_LIMIT_ERROR	Opened streamID that exceeds limit.
0x0005	STREAM_STATE_ERROR	Violated protocol in the stream level.
0x0006	FINAL_SIZE_ERROR	Received a frame that violates the final size agreement.
0x0007	FRAME_ENCODING_ERROR	Received data that does not follow the QUIC encoding format.
0x0008	TRANSPORT_PARAMETER_ERROR	Received a handshake message with invalid QUIC transport parameters.
0x000A	PROTOCOL_VIOLATION	Received a frame in an incorrect packet type.
0x000D	CRYPTO_BUFFER_EXCEEDED	Received a crypto frame that exceeds the size of the crypto buffer.
TLS alert code
0x010A	TLS_UNEXPECTED_MESSAGE	Received an out-of-sequence message: the packet type of received handshake packet is not matched to the expected packet type.
0x0128	TLS_HANDSHAKE_FAILURE	Indicated that the sender was unable to negotiate an acceptable set of security parameters given the options available. For example, when the QUIC10GS-IP validates a ClientHello in the handshake process and finds that the TLS_AES_128_GCM_SHA256 option is not available in the client’s cipher suite.
0x012B	TLS_UNSUPPORTED_CERTIFICATE	Received an unsupported certificate type.
0x012F	TLS_ILLEGAL_PARAMETER	Received the extensions with an invalid value.
0x0132	TLS_DECODE_ERROR	Received a message that cannot be decoded because some fields are out of the specified ranges, or the length of the message is incorrect.
0x0133	TLS_DECRYPT_ERROR	Failed during handshake cryptographic operation: unable to correctly verify a signature or validate a finished message.
0x0146	TLS_PROTOCOL_VERSION	Failed to handshake with the client due to the fact that the TLS version is not 1.3.
0x0150	TLS_INTERNAL_ERROR	Indicated that the client does not response within a specific timeout period, while the IP is waiting for the handshake packet returned from the target device.

U0ser error code
0x1000	TARGET_TIMEOUT_ERROR	Indicated that the client does not response within a specific Idle timeout.
0x1001	ABNORMAL_CLOSE_ERROR	Indicated that the user de-asserts “ConnOn” signal to ‘0’ when QUICHandshakeBusy, QUICTxTrnsBusy, or QUICRxTrnsBusy are still busy, any of which is asserted to ‘1’.
0x1002	OPEN_CONNECTION_TIMEOUT	Indicated that the IP cannot connect to a network system.
0x1003	ALPN_SIZE_ERROR	Indicated that user inputs an unsupported value of QUICALPNLen, which is when QUICALPNLen is greater than 16 bytes.
0x1004	USER_PEM_KEY_ERROR	Indicated that there is an issue with the user-provided private key file in ASN.1 DER binary encoding, which could be due to an invalid format or corrupted key data.
0x1005	USER_PEM_CERT_ERROR	Indicated that there is an issue with the user-provided certificate file in ASN.1 DER binary encoding, which could be due to an invalid format or corrupted certificate data.

* QUIC10GS-IP can present an alert code from a server only in format of 15-bit value.

· MAC Interface

The MAC interface of the QUIC10GS-IP uses simple streaming data interface similar to the AXI4-Stream interface. It is used to transmit and receive packets, which are reduced Ethernet frames. According to IEEE 802.3, this reduced frame includes only the destination address, source address, length and data.

When the QUIC10GS-IP requests to send a packet, it sets MacTxValid to ‘1’ along with the valid values of MacTxData, MacTxSOP, MacTxEOP and MacTxByteEn. The transmission can be paused if MacTxReady is de-asserted to '0' at any clock cycle and resumed afterward. MacTxByteEn[3:0] indicates which bytes within MacTxData[31:0] are valid. For example, MacTxByteEn[0] indicates the validity of MacTxData[7:0], and MacTxByteEn[1] for the validity of MacTxData[15:8]. MacTxSOP is set to indicate the start of a packet, while MacTxEOP is asserted to indicate the end of a packet. Figure 19 depicts an example of sending a packet.

Figure 19 Transmit MAC Interface timing diagram

On the other hand, Figure 20 shows an example of receiving a packet. To start receiving a packet, MacRxValid is asserted to indicate valid data on MacRxData[31:0]. MacRxByteEn[3:0] is used to indicate which bytes within MacRxData[31:0] are valid, and MacRxEOP is asserted to indicate the end of a packet. If an error occurs during reception, MacRxError will be asserted to ‘1’ at the end of the packet, and the receiving packet will be discarded. In this example, the reception of data (D0 to D72) happens when MacRxValid is asserted.

Figure 20 Receive MAC Interface timing diagram

Verification Methods

The QUIC10GS IP Core functionality was verified by simulation and also proved on real board design by using KCU116 Evaluation Board.

Recommended Design Experience

The user must be familiar with HDL design methodology to integrate this IP into a system.

Ordering Information

This product is available directly from Design Gateway Co., Ltd. Please contact Design Gateway Co., Ltd. For pricing and additional information about this product, use the contact information on the front page of this datasheet.

Revision History

Revision	Date (D-M-Y)	Description
1.00	13-Mar-25	Initial release