Security IP 96 - HW4.6 - Hardware Reference and Programmer Manual - RevB

Security IP
Protocol-IP-96 HW4.6
Multi-Protocol Transform Engine

supporting IPsec, MACsec, SRTP, SSL, TLS, DTLS, Wireless
Hardware Reference and Programmer Manual
Document Revision: B
Document Date: 2022-03-01
Document Number: 007-096460-207
Document Status: Accepted
© Rambus Inc. • rambus.com CONFIDENTIAL

Copyright 2008-2022 Rambus Inc. This document contains information which is proprietary and confidential, and
which is protected under patents, copyrights, and/or other IP rights of Rambus Inc. If you are not the intended
recipient of this material, please destroy this document and inform Rambus at +1 408 463 8000 or
sipsupport@rambus.com immediately.
Rambus Inc. Corporate Headquarters

4453 North First Street, Suite 100
San Jose, CA 95134
Phone: +1 408-462-8000
Website : https://www.rambus.com/
Contact : sipsupport@rambus.com
Rambus ROTW Holding B.V.

Boxtelseweg 26A
5261 NE Vught
The Netherlands
Phone: +31-73-6581900
© Rambus Inc. • rambus.com CONFIDENTIAL 2

Security IP Protocol-IP-96 HW4.6
007-096460-207
Hardware Reference and Programmer Manual Rev. B
Product Summary Synthesized at 400 MHz in a typical CMOS 28 nm LvT

technology.
APPLICATIONS
The Protocol-IP-96 (EIP-96) is a Multi-Protocol Transform IPsec (IPv4 and IPv6):
Engine designed to accelerate and offload the very CPU • Full IPsec packet ESP/AH transforms according to latest
intensive IPsec, MACsec, SRTP, SSL, TLS and DTLS protocol RFCs (2403, 2404, 2405, 2410, 3566, 3602, 3686, 4106,
operations. The Multi-Protocol Transform Engine is suited for 4301, 4303, 4308, 4309, 4543, 4868, 4869, 6054, 6379,
communications processors and other general-purpose 7321),
processors that require maximum data plane offload to
• IPsec ESP and AH tunnel and transport mode,
dedicated security hardware. The Multi-Protocol Transform
• Complete IPsec (IPv4/IPv6) Header/Trailer processing,
Engine accommodates designs that already include Packet
Classifiers (such as NPUs) as well as designs that require bulk • Insert ESP/AH header for outbound packets, strip and
crypto processing without any flow processing. In addition, the verify ESP/AH header for inbound packets,
Multi-Protocol Transform Engine can be used in various SoC • Anti-replay check,
architectures, even 'look-a-side' architectures. In designs • Calculate and insert Integrity Check Value for outbound
where no packet classification hardware is available Rambus packets, strip and verify for inbound packets,
also offers the EIP-197 Flow-Through Security Packet Engine • Append (outbound) / strip and verify (inbound) padding up
that completes the Multi-Protocol Transform Engine with flow to 255 bytes.
pre- and post processors to accelerate this classification.
The standard configurations of the EIP-96 are:
MACsec
• EIP-96i IPsec, MACsec, SSL/TLS/DTLS and
• MACsec frame transforms according to IEEE 802.1AETM-
SRTP Crypto Accelerator
2006
• EIP-96ie EIP-96i with SHA2-384/512
• SecTAG insertion and removal,
• EIP-96iw EIP-96i with Kasumi, SNOW and ZUC
• PN insertion, removal, and verification
• EIP-96iew EIP-96ie with Kasumi, SNOW and ZUC
• ICV generation, insertion, removal, and verification
• EIP-96iewc EIP-96iew with SM3, SM4 and BC0
• EIP-96is EIP-96i with ARC4
• EIP-96ies EIP-96is with SHA2-384/512 SRTP
• EIP-96iesb EIP-96ies with ChaCha20 and Poly1305 • SRTP packet transforms according to RFC 3711, 6188,
• EIP-96iesw EIP-96ies with Kasumi, SNOW and ZUC 7714.
• EIP-96iex EIP-96ie with AES-XTS • ROC insertion and removal,
• EIP-96ieswx EIP-96iesw with AES-XTS • MKI insertion and removal,
• EIP-96ieswxk EIP-96ieswx with SHA3 hash functions • TAG generation and insertion.
FEATURES SSL v3.0 / TLS v1.0-1.3 / DTLS v1.0/v1.2:

Performance: • Packet transforms according to latest RFCs (2246, 3268,
4346, 4347, 5246, 5288, 5430, 6101, 6347, 6460, 6655 and
• IPsec 5000Mbps using AES and SHA-1
8446)
• MACsec 6000Mbps using AES-GCM
• Full header processing
• SSL/TLS/DTLS 5000Mbps using AES and SHA-1
• All packets are processed autonomous, including length
• The performance is specified for packets (frames) of 1500 correction based on pad-length.
bytes with a new SA (context) for each packet (frame)
• ARC4 ciphers only included for EIP-96*s
based on a 500 MHz system clock. For detailed
performance is referred to Table 3.
Wireless algorithm support
Gate count: (EIP-96iw / EIP-96iew / EIP-96iesw / EIP-96ieswx / EIP-
96ieswxk):
• EIP-96i 300k gates
• Kasumi f8 and Kasumi f9
• EIP-96ie 357k gates
• SNOW 3G integrity or authentication
• EIP-96iew 442k gates
• ZUC integrity or authentication
• EIP-96is 362k gates
• EIP-96ies 418k gates
• EIP-96iesw 503k gates SA (context) records
• EIP-96iex 423k gates • Optimized Security Association format (Context Record).
• EIP-96ieswx 569k gates • Supports unlimited number of Security Associations.
• EIP-96ieswxk 609k gates • Support for 64-bit addressing.
• Default support for sequence number masks of 256-bit
and 384-bit, optional support for 1024-bit masks.

007-096460-207
CRYPTO ENGINE EIP-96-f SPECIFIC PROPERTIES

The cryptographic engine supports the following cryptographic The standard EIP-96 configurations use DMA interfaces for
algorithms: data and context. The same configurations are also available
• (3)DES in ECB and CBC with (3x) 56-bit key, with a streaming FIFO interface for data only (EIP-96-f) or
• AES in ECB, CBC, ICM, CTR, CFB, OFB mode with optionally for both data and context (EIP-96-cf).
128/192/256-bit keys, GCM, GMAC and CCM modes Performance and gate counts of the FIFO interface based
• AES-XTS encryption mode (EIP-96*x) configurations are equal to their corresponding default
• ARC4 in Stateful and Stateless mode, up to 128-bit key, configuration. However, in the FIFO configurations with small
(EIP-96*s), buffers, the memory for the data buffer is reduced to a
minimum because it is assumed that the packets can be
• Padding insertion and removal up to 255 bytes.
buffered externally. For optimal performance, access time to
For EIP-96*w only: and from these data FIFOs is expected to be short.
• Kasumi in basic and f8 mode (=UEA1),
• SNOW in basic and 128-EEA1 (=UEA2),
INTERFACE (EIP-96-f)
• Streaming data input and output interfaces
• ZUC in basic and 128-EEA3 (=UEA3),
For EIP-96*b only: • Selection between 2 kinds of context interface:
• ChaCha20 with 32/64-bit counter length, and 128/256-bit • SA (context) bus can have a master DMA and target
key TCM interface to allow optimal context data requests
by the EIP-96.
For EIP-96*c only:
• Optionally this interface is configured for two
• SM4 in ECB, CBC, ICM, CTR, CFB, OFB128 mode with 128-
independent streaming context input and output
bit keys
interface (EIP-96-cf).
• BC0 (external bock cipher) in ECB, CBC, ICM, CTR, CFB, OFB
• Streaming token input and output interfaces
mode with 256-bit keys
• Target TCM interface for SW debug and configuration
HASH ENGINE
The Hash engine supports the following algorithms: The actual size of the attached data output buffer limits the
• CRC-32 header update capabilities of the EIP-96-f.
• MD5 and SHA-1
• SHA-2 with 224-bit, 256-bit digest
Low-Power Operation
• SHA-2 with 384-bit, 512-bit digest (EIP-96ie*)
• Dynamic clock gating for the active sub-modules.
• SHA-3 with 224-bit, 256-bit, 384-bit, 512-bit digest (EIP-
96*k) • Each cipher and hash algorithm has a separate clock
enabling control.
• HMAC transforms for above algorithms,
• Fast Double Round implementation for SHA-224/256
• Keyed-hash for SHA-3 algorithms,
• GHASH (for GCM and GMAC)
• XCBC-MAC and CBC-MAC (for CCM)
• SSL MAC transforms (EIP-96*s),
For EIP-96*w only:
• Kasumi in f9 (=UIA1),
• SNOW in 128-EIA1 (=UIA2),
• ZUC in 128-EIA3 (=UIA3).
For EIP-96*b only:
• Poly1305
For EIP-96*c only:
• SM3, 256-bit digest (Hash / HMAC)
Optionally internal PRNG for optimal IV generation
INTERFACE (standard EIP-96)

• Data busses have a master DMA and target TCM interface
to allow optimal packet data requests by the EIP-96.
• SA (context) bus has a master DMA and target TCM
interface to allow optimal context data requests by the
EIP-96.
• Streaming token input and output interfaces
• Target TCM interface for SW debug and configuration

007-096460-207
Table of Contents
Product Summary ................................................................................... 3

Table of Contents ................................................................................... 5
List of Tables......................................................................................... 12
List of Figures ....................................................................................... 13
Document Revision History .................................................................. 15
1 Introduction .................................................................................. 16
1.1 Purpose ................................................................................................... 16
1.2 Scope ...................................................................................................... 16
1.2.1 General References ................................................................................................. 16
1.2.2 Explicit References .................................................................................................. 16
1.3 Applicable Rambus Documents ............................................................... 16
1.4 Target Audience ...................................................................................... 17
1.5 Part Numbers for Standard Configurations ............................................. 17
1.6 Conventions ............................................................................................ 18
2 Features and Characteristics ......................................................... 19
2.1 Features .................................................................................................. 19
2.2 Datastream Naming Convention ............................................................. 20
2.3 Standard EIP-96 Interfaces ...................................................................... 21
2.4 EIP-96-f Interfaces ................................................................................... 21
2.5 System Integration Examples .................................................................. 22
2.6 Modes of operation ................................................................................ 23
2.6.1 Protocols ................................................................................................................. 23
2.6.2 Algorithm combinations.......................................................................................... 23
2.6.3 Wireless algorithms................................................................................................. 26
2.7 Performance ........................................................................................... 26
2.8 Standard Rambus IP Cores ...................................................................... 33
2.9 Gate counts and memories ..................................................................... 34
3 Processing Overview ..................................................................... 36
3.1 Processing Terms .................................................................................... 36
3.1.1 Tokens ..................................................................................................................... 36
3.1.2 Context .................................................................................................................... 36
3.2 Data Processing Overview ....................................................................... 37

007-096460-207
3.2.1 Duplicate context handling ..................................................................................... 37

4 Architecture Overview .................................................................. 39
4.1 Introduction ............................................................................................ 39
4.2 Clocking................................................................................................... 39
4.2.1 Clock and clock gating signals ................................................................................. 39
4.3 Standard EIP-96 external Interfaces ........................................................ 41
4.3.1 Signal descriptions .................................................................................................. 42
4.3.2 Token FIFO Interfaces ............................................................................................. 47
4.3.3 TCM Interface .......................................................................................................... 48
4.3.4 DMA Request Interface ........................................................................................... 49
4.3.5 DMA Interface and TCM (Master) Interface Collaboration .................................... 49
4.3.6 Packet Buffer Interface Timing ............................................................................... 51
4.3.7 External PRNG Interface Timing .............................................................................. 52
4.4 EIP-96-f external interfaces ..................................................................... 52
4.4.1 Signal descriptions .................................................................................................. 53
4.4.2 Target TCM Interface .............................................................................................. 58
4.4.3 Token FIFO Interfaces ............................................................................................. 59
4.4.4 Context Interface .................................................................................................... 60
4.4.5 DMA Interface and TCM (Master) Interface Collaboration .................................... 60
4.4.6 Data input FIFO interface ........................................................................................ 62
4.4.7 Data output FIFO interface ..................................................................................... 62
4.4.8 Output Packet Buffer Interface Timing ................................................................... 63
4.4.9 External PRNG Interface Timing .............................................................................. 64
4.5 Context update Interface timing ............................................................. 64
4.6 Internal Modules ..................................................................................... 66
4.6.1 Input fetch and output store modules .................................................................... 66
4.6.2 Preprocessing module ............................................................................................. 66
4.6.3 Postprocessing module ........................................................................................... 68
4.6.4 Packet processing module ...................................................................................... 68
4.6.5 Context module....................................................................................................... 68
4.6.6 Control module ....................................................................................................... 68
5 Initialization .................................................................................. 70
5.1 Protocol enables ..................................................................................... 70
5.2 Context Fetch Modes .............................................................................. 70
5.3 Buffer Control ......................................................................................... 71
5.3.1 Standard EIP-96 buffer control ............................................................................... 71
5.3.2 EIP-96-f Buffer Control ............................................................................................ 72
5.4 Packet Processing Modes ........................................................................ 72

007-096460-207
6 Pseudo Random Number Generator............................................. 75

6.1 Purpose ................................................................................................... 75
6.2 Functional Description ............................................................................ 75
6.3 Performance ........................................................................................... 76
7 Input Token Definition .................................................................. 77
7.1 Introduction ............................................................................................ 77
7.2 Input Token Diagram............................................................................... 77
7.2.1 Input Token Header ................................................................................................ 77
7.2.1.1 Token Control Word .......................................................................................................................... 77
7.2.1.2 Input packet pointer.......................................................................................................................... 95
7.2.1.3 Output packet pointer/identifier ...................................................................................................... 95
7.2.1.4 Context data pointer ......................................................................................................................... 95
7.2.1.5 Context Control Words [1:0] ............................................................................................................. 96
7.2.1.6 IV [3:0] ............................................................................................................................................... 96
7.2.1.7 Checksum .......................................................................................................................................... 96
7.2.1.8 U-word .............................................................................................................................................. 96
7.2.1.9 Processing instructions...................................................................................................................... 97
7.2.1.10 Bypass token data ............................................................................................................................. 97
8 Processing Instructions ................................................................. 98

8.1 Instruction Types..................................................................................... 98
8.1.1 Operational Data Instructions (Type 1)................................................................... 98
8.1.2 IP Header Instructions (Type 2)............................................................................... 98
8.1.3 Postprocess Instructions (Type 3) ........................................................................... 98
8.1.4 Result Instructions (Type 4) .................................................................................... 98
8.1.5 Context Control Instructions (Type 5) ..................................................................... 98
8.1.6 Special Instructions (Type 6) ................................................................................... 99
8.2 Instruction Sequencing............................................................................ 99
8.2.1 Sequencing Rules .................................................................................................... 99
8.3 Instruction Format .................................................................................. 99
8.3.1 length/pointer ......................................................................................................... 99
8.3.1.1 length ................................................................................................................................................ 99
8.3.1.2 offset ................................................................................................................................................. 99
8.3.2 STAT ....................................................................................................................... 100
8.3.2.1 STAT definition for Type 1 and 2 instructions ................................................................................. 100
8.3.2.2 STAT definition for Type 3 instructions ........................................................................................... 100
8.3.3 instruction dependent fields ................................................................................. 100
8.3.4 opcode................................................................................................................... 100
8.3.5 Data (optional) ...................................................................................................... 101
8.4 Operational Data Instructions ............................................................... 101
8.4.1 DIRECTION Instruction .......................................................................................... 101

007-096460-207
8.4.2 PRE_CHECKSUM Instruction ................................................................................. 102

8.4.3 INSERT Instruction ................................................................................................. 103
8.4.3.1 INSERT Instruction Example – INSERT (immediate) ........................................................................ 105
8.4.3.2 INSERT Instruction Example – NOP ................................................................................................. 106
8.4.4 INSERT_CTX Instruction ........................................................................................ 106
8.4.5 REPLACE Instruction .............................................................................................. 107
8.4.6 RETRIEVE Instruction ............................................................................................. 107
8.4.6.1 RETRIEVE (copy, store, and pass) Instruction Example ................................................................... 108
8.4.6.2 RETRIEVE (remove and store) Instruction Example ........................................................................ 108
8.4.6.3 RETRIEVE (remove only) Instruction Example ................................................................................. 108
8.4.7 MUTE Instruction .................................................................................................. 108
8.4.8 Single pass SSL/TLS/DTLS extensions .................................................................... 109
8.4.8.1 INSERT Instruction Example – INSERT (retrieved length correction byte) ...................................... 110
8.5 IP Header Instructions ........................................................................... 111
8.5.1 IPv4 Instruction ..................................................................................................... 111
8.5.2 IPv4_CHECKSUM Instruction................................................................................. 112
8.5.3 IPv6 Instruction ..................................................................................................... 113
8.6 Postprocess Instructions ....................................................................... 114
8.6.1 INSERT_REMOVE_RESULT (IRR) Instruction ......................................................... 114
8.6.1.1 INSERT_REMOVE_RESULT Instruction (remove_result operation) ................................................. 115
8.6.1.2 INSERT_REMOVE_RESULT Instruction (insert_result operation) .................................................... 117
8.6.1.3 INSERT_REMOVE_RESULT Instruction (insert_result operations): ................................................. 118
8.6.1.4 Summary append options ............................................................................................................... 127
8.6.1.5 INSERT_REMOVE_RESULT Instruction (ip_tunfix operation) .......................................................... 128
8.6.2 REPLACE_BYTE Instruction .................................................................................... 129
8.6.3 Reserved Instructions............................................................................................ 129
8.7 Result Instructions ................................................................................ 130
8.7.1 VERIFY_FIELDS Instruction .................................................................................... 130
8.8 Context Control Instructions ................................................................. 131
8.8.1 CONTEXT_ACCESS Instruction ............................................................................... 131
8.9 Bypass Token Data – Special Instruction ............................................... 134
9 Context Record ........................................................................... 135
9.1 Context Record Format ......................................................................... 135
9.1.1 Context Record Example ....................................................................................... 139
9.2 Context Control Words ......................................................................... 140
9.2.1 Context Control Word 0 Field Encoding................................................................ 141
9.2.2 Context Control Word 1 Field Encoding................................................................ 148
10 Result Token Definition............................................................... 155
A Pre and Postprocessing by Host Software .................................. 161
A.1 Preprocessing........................................................................................ 161

007-096460-207
A.2 Postprocessing ...................................................................................... 162

A.2.1 Result Token .......................................................................................................... 162
A.2.2 Appended Data ..................................................................................................... 162
A.2.3 Suggested Postprocessing Operations .................................................................. 162
A.2.4 Rambus internal debugging options ..................................................................... 163
A.2.4.1 The Upper layer header function bit ............................................................................................... 163
A.2.4.2 Bit [30] of the token header word................................................................................................... 163
A.2.4.3 IRR bypass offset correction in length field ..................................................................................... 164
A.2.4.4 Token Control Register 2 ................................................................................................................. 165
B Context Record Fields ................................................................. 167

B.1 Key ........................................................................................................ 167
B.2 Hash Digest ........................................................................................... 169
B.2.1 SHA-1, SHA-2, SHA-3 ............................................................................................. 170
B.2.2 SM3 ....................................................................................................................... 171
B.2.3 MD5 ....................................................................................................................... 172
B.2.4 Poly1305 ................................................................................................................ 172
B.2.5 CRC-32 ................................................................................................................... 174
B.2.6 AES-GCM (GHASH) Precalculation ........................................................................ 174
B.2.7 AES-XCBC-MAC Precalculations ............................................................................ 175
B.2.8 AES-XTS Key2 loading ............................................................................................ 176
B.2.9 Wireless algorithm – Authentication modes ........................................................ 176
B.2.9.1 Kasumi ............................................................................................................................................. 176
B.2.9.2 Encryption ....................................................................................................................................... 176
B.2.9.3 Authentication ................................................................................................................................ 177
B.2.9.4 SNOW and ZUC ................................................................................................................................ 177
B.2.9.5 Encryption (UEA) ............................................................................................................................. 177
B.2.9.6 Authentication (Integrity, UIA) ........................................................................................................ 178
B.3 SPI ......................................................................................................... 178
B.4 Sequence number processing ............................................................... 178
B.4.1 Introduction .......................................................................................................... 178
B.4.2 Sequence number overflow .................................................................................. 180
B.4.3 Sequence number check ....................................................................................... 180
B.4.4 IPsec sequence numbering, sliding window ......................................................... 182
B.4.5 IPsec sequence numbering, fixed window............................................................ 182
B.4.6 MACsec sequence numbering .............................................................................. 183
B.5 IV........................................................................................................... 183
B.6 ARC4 State Record and I/J pointer ........................................................ 185
B.7 Examples for most common scenarios .................................................. 185
B.7.1 Basic encrypt operation ........................................................................................ 185
B.7.2 Basic hash operation ............................................................................................. 185

007-096460-207
B.7.3 Combined basic encrypt hash operations............................................................. 186

B.7.4 IPsec hash only operation ..................................................................................... 186
B.7.5 IPsec encrypt only operation ................................................................................ 186
B.7.6 IPsec combined encrypt hash operation .............................................................. 186
B.7.7 Typical initialization values for IPsec operation .................................................... 186
C Register and Memory Map ......................................................... 187
C.1 Configuration registers .......................................................................... 194
C.1.1 Token Control ........................................................................................................ 194
C.1.1.1 Token Control / Status Register ...................................................................................................... 194
C.1.1.2 Extended Token Control Register .................................................................................................... 196
C.1.1.3 Protocol/Algorithm Enable Register................................................................................................ 196
C.1.1.4 Extended Protocol/Algorithm Enable Register ............................................................................... 198
C.1.2 Context Control ..................................................................................................... 198
C.1.2.1 Context Control Register ................................................................................................................. 198
C.1.2.2 Context Status Register ................................................................................................................... 199
C.1.3 Data Fetch Control ................................................................................................ 200
C.1.4 Standard EIP-96 Input and Output transfer Control/Status Register ................... 200
C.1.4.1 Input transfer Control/Status Register ............................................................................................ 200
C.1.4.2 Output Transfer Control/Status Register ........................................................................................ 200
C.1.4.3 Output Buffer Control Register ....................................................................................................... 202
C.1.5 EIP-96-f Input and Output transfer Control/Status Register ................................ 203
C.1.5.1 Input Transfer Control/Status Register ........................................................................................... 203
C.1.5.2 Output Transfer Control/Status Register ........................................................................................ 203
C.1.5.3 Output Buffer Control Register ....................................................................................................... 204
C.1.6 Sequence Number Thresholds .............................................................................. 205
C.1.6.1 Sequence Number 32-bit Threshold Register ................................................................................. 205
C.1.6.2 Sequence Number 64-bit Threshold Register ................................................................................. 205
C.2 PRNG Registers ..................................................................................... 206
C.2.1 PRNG Status Register (PRNG STAT)....................................................................... 206
C.2.2 PRNG Control Register (PRNG_CTRL) .................................................................... 206
C.2.3 PRNG Seed Register (PRNG_SEED_L/H) ................................................................ 207
C.2.4 PRNG DES Key Registers (PRNG_KEY0_L/H, PRNG_KEY1_L/H) ............................ 208
C.2.5 PRNG Output Registers (PRNG_RES0_L/H, PRNG_RES1_L/H) .............................. 209
C.2.6 PRNG LFSR Registers (PRNG_LFSR_L/H) ............................................................... 209
C.3 Interrupt Controller Registers ............................................................... 210
C.3.1 Interrupt sources................................................................................................... 210
C.3.2 Polarity Control Registers...................................................................................... 210
C.3.3 Type Control Registers .......................................................................................... 210
C.3.4 Enable Control Registers ....................................................................................... 211
C.3.5 Raw Source Status Registers and Enable Set Registers ........................................ 211
C.3.6 Enabled Status Registers and Acknowledge Registers ......................................... 212

007-096460-207
C.3.7 Enable Clear Registers ........................................................................................... 213

C.3.8 Options Registers .................................................................................................. 213
C.3.9 Version Registers................................................................................................... 214
C.4 Protocol Control .................................................................................... 214
C.4.1.1 ECN Table Registers ......................................................................................................................... 214
C.4.1.2 ECN IP Tunnel Error Configuration Register .................................................................................... 215
C.5 Global Type and Version Registers ........................................................ 216
C.5.1 Type and Configuration Register........................................................................... 216
C.5.2 Version Register .................................................................................................... 218
D Protocol Compliance ................................................................... 219
D.1 Introduction .......................................................................................... 219
D.2 Disclaimer ............................................................................................. 219
D.3 IP header ............................................................................................... 219
D.4 IPsec ESP ............................................................................................... 220
D.5 AH ......................................................................................................... 221
D.6 SSL......................................................................................................... 222
D.7 TLS ........................................................................................................ 223
D.8 DTLS ...................................................................................................... 224
D.9 SRTP/SRTCP........................................................................................... 226
D.10 MACsec ................................................................................................. 226
E Optional Context FIFO Interface ................................................. 227
E.1 Introduction .......................................................................................... 227
E.2 Context FIFO Interface Signals............................................................... 227
E.3 Context FIFO Interface Timing ............................................................... 228
E.3.1 Reuse Context ....................................................................................................... 229
F References .................................................................................. 230
F.1 Conventions Used in this Manual .......................................................... 230
F.1.1 Acronyms............................................................................................................... 230
F.1.2 Typographical conventions ................................................................................... 232
F.2 References ............................................................................................ 233
G Deliverables ................................................................................ 239

007-096460-207
List of Tables
Table 1 Features ................................................................................................................................................ 19
Table 2 Supported crypto / hash combinations ................................................................................................ 23
Table 3 Maximum throughput figures (at 500 MHz) ......................................................................................... 26
Table 4 Maximum throughput figures for Low gatecount (at 500 MHz) ........................................................... 29
Table 5 Embedded standard IP cores ................................................................................................................ 33
Table 6 Gate counts for all standard configurations ......................................................................................... 34
Table 7 Gate counts for all low gatecount configurations ................................................................................. 35
Table 8 Memories, depending on interface ...................................................................................................... 35
Table 9 Clocks and Clock enables signals........................................................................................................... 39
Table 10 EIP-96 Interface Signal Descriptions ..................................................................................................... 42
Table 11 EIP-96-f Interface Signal Descriptions ................................................................................................... 53
Table 12 Context fetch control ............................................................................................................................ 70
Table 13 Relation between ‘Type of Destination’ and ‘Type of Packet’ fields .................................................... 73
Table 14 PRNG Performance ............................................................................................................................... 76
Table 15 IV Register Usage .................................................................................................................................. 81
Table 16 Selecting IV Source using Input Token Control Word ........................................................................... 83
Table 17 XTS tweak value load options ............................................................................................................... 94
Table 18 Reduced bitmask coding ....................................................................................................................... 96
Table 19 Instruction Operation Codes ............................................................................................................... 101
Table 20 Types of destination ............................................................................................................................ 102
Table 21 Padding Values for INSERT Instruction ............................................................................................... 104
Table 22 ‘Origin’ Field Encoding for Preprocessing Instructions ....................................................................... 104
Table 23 Little-endian representation of IPv4 header datagram ...................................................................... 121
Table 24 Little-endian representation of IPv6 header datagram ...................................................................... 122
Table 25 32-bit, little-endian representation of appended IPv4 data ............................................................... 124
Table 26 32-bit, little-endian representation of appended IPv6 data ............................................................... 125
Table 27 Typical ICV lengths for authentication operations with IPsec ............................................................ 128
Table 28 ‘Origin’ Field Encoding for CONTEXT_ACCESS Instruction .................................................................. 132
Table 29 Context Record Address Map for Context Fetch Mode = Address Mode ........................................... 135
Table 30 Decision Table for Address Set for Context Fetch Mode = Control Mode .......................................... 139
Table 31 Example Context Record Address Map for Context Fetch Mode = Control Mode ............................. 140
Table 32 Context Control Words layout ............................................................................................................ 140
Table 33 Coding of the context_size field.......................................................................................................... 143
Table 34 Result Token Error Codes .................................................................................................................... 155
Table 35 Result Token E14, E6, E5 and E4 errors .............................................................................................. 156
Table 36 Result Token Detailed Error Codes ..................................................................................................... 157
Table 37 Pad Info Fields Definition .................................................................................................................... 159
Table 38 Modes with inbound sequence number checking .............................................................................. 180
Table 39 Modes with inbound sequence number checking for extended masks ............................................. 181
Table 40 Modes with inbound sequence number checking for XL masks ......................................................... 181
Table 41 Register and Memory Map ................................................................................................................. 187
Table 42 AIC interrupt sources .......................................................................................................................... 210
Table 43 Supported IPv4 functionality .............................................................................................................. 219
Table 44 Supported IPv6 functionality .............................................................................................................. 219
Table 45 Supported ESP functionality ............................................................................................................... 220

007-096460-207
Table 46 Supported AH functionality ................................................................................................................ 221

Table 47 Supported SSL functionality ................................................................................................................ 222
Table 48 Supported TLS functionality ................................................................................................................ 223
Table 49 Supported DTLS functionality ............................................................................................................. 225
Table 50 Supported SRTP/SRTCP functionality .................................................................................................. 226
Table 51 Supported MACsec functionality ........................................................................................................ 226
Table 52 Context FIFO Interface Signal Descriptions ......................................................................................... 227
Table 53 Typographical Styles and Use ............................................................................................................. 232
List of Figures
Figure 1 Data stream naming convention........................................................................................................... 20
Figure 2 Two examples of EIP-96 system integration ......................................................................................... 22
Figure 3 General Data Processing Overview ....................................................................................................... 38
Figure 4 EIP-96 Block Diagram ............................................................................................................................ 41
Figure 5 FIFO input interface read timing ........................................................................................................... 47
Figure 6 FIFO output interface write timing ....................................................................................................... 47
Figure 7 TCM bus read timing ............................................................................................................................. 48
Figure 8 TCM bus write timing ............................................................................................................................ 48
Figure 9 DMA request/grant timing .................................................................................................................... 49
Figure 10 TCM master and DMA request interface cooperation ......................................................................... 50
Figure 11 Packet buffer RAM interface write timing ............................................................................................ 51
Figure 12 Packet buffer RAM read timing............................................................................................................. 51
Figure 13 EIP-96 external PRNG read timing ........................................................................................................ 52
Figure 14 EIP-96-f TCM bus read timing ............................................................................................................... 58
Figure 15 EIP-96-f TCM bus write timing .............................................................................................................. 58
Figure 16 EIP-96-f Token input FIFO interface read timing................................................................................... 59
Figure 17 EIP-96-f Token output FIFO interface write timing ............................................................................... 59
Figure 18 DMA request/grant timing .................................................................................................................... 60
Figure 19 TCM master and DMA request interface cooperation ......................................................................... 61
Figure 20 EIP-96-f Data Input FIFO interface timing diagram ............................................................................... 62
Figure 21 EIP-96-f Data Output FIFO interface timing diagram ............................................................................ 62
Figure 22 EIP-96-f Packet buffer RAM interface write timing ............................................................................... 63
Figure 23 EIP-96-f Packet buffer RAM read timing ............................................................................................... 63
Figure 24 EIP-96-f Example of address wrapping of the small buffer RAM access ............................................... 64
Figure 25 EIP-96-f external PRNG read timing ...................................................................................................... 64
Figure 26 Context update interface example timing diagram .............................................................................. 69
Figure 27 Packet processor with ToP=4’b000x ..................................................................................................... 72
Figure 28 Packet processor with ToP=4’b001x (left) and with ToP=4’b010x (right) ............................................. 72
Figure 29 Packet processor with ToP=4’b011x (left) and with ToP=4’b111x (right) ............................................. 73
Figure 30 Multiple encryption with triple DES using two keys. ............................................................................ 75
Figure 31 Schematic overview of the pseudo-random algorithm specified by ANSI X9.17 .................................. 76
Figure 32 Result IV using IV [2:0] = 3'b000 with IV format [11:10], XOR disabled ................................................ 84
Figure 33 Result IV using IV [2:0] = 3'b000, IV format [11:10]=’10’, XOR enabled ............................................... 85
Figure 35 Result IV using IV [2:0] = 3'b001 with IV format [11:10] , XOR disabled ............................................... 86

007-096460-207
Figure 50 IPv4 (with checksum untouched) Instruction: datagram modifications ............................................. 111
Figure 51 IPv4_CHECKSUM Instruction: datagram modifications ...................................................................... 112
Figure 52 IPv6 Instruction: datagram modifications ........................................................................................... 113
Figure 53 IPv4 inserted field - insert_hash_result operation - AH header ICV field ........................................... 119
Figure 54 IPv4 appended field – insert_hash_result_operation – AH header ICV field...................................... 119
Figure 55 IPv4 header datagram ......................................................................................................................... 121
Figure 56 IPv6 header datagram ......................................................................................................................... 122
Figure 57 IPv4 updated fields - insert_result operation - ‘L’, ‘NH’, ‘CS’ and ‘P’ fields selected .......................... 123
Figure 58 IPv4 appended updates - insert_result operation - ‘L’, ‘NH’ and ‘CS’ fields selected ......................... 123
Figure 59 IPv6 updated fields - insert_result operation - ‘L’, ‘NH’ fields selected and ‘length’ = 0x28 .............. 124
Figure 60 IPv6 appended updates - insert_result operation - ‘L’, ‘NH’ fields selected and ‘length’ = 0x28 ....... 124
Figure 61 SHA-1, SHA-2, SHA-3 hash result endianness in context words ......................................................... 170
Figure 62 MD 5 hash result endiannes in context words ................................................................................... 172
Figure 63 Poly1305 MAC result endiannes in context words ............................................................................. 173
Figure 64 AES-GCM (GHASH) pre-calculation result endianness ........................................................................ 174
Figure 65 AES XCBC precalculation result endianness ........................................................................................ 175
Figure 66 Sequence number processing logic .................................................................................................... 179
Figure 67 EIP-96-cf Context FIFO interface timing diagram ................................................................................ 228
Figure 68 Key to timing diagrams ....................................................................................................................... 232

007-096460-207
Document Revision History

Doc. Page(s) Date Author Purpose of Revision
Rev. Section(s) (Y-M-D)
A All 2021-11-16 ROO • Updated from HW4.5 RevB
4.5, 8.8.1 • Added multi-DMA context updates
7.2.1.1.9, • Updated use for smaller mask selection of XL mask
7.2.1.8
Table 29, C.1.2.1 • Added XL bitmask fields to context record layout
Table 30 • Added decision table for fetch mode addressing
B.4 • Extended for XL masks
B C.1.1.2 2022-03-01 ROO • Added seqnum append feature enable

007-096460-207
1 Introduction
1.1 Purpose
This manual describes the digital interfaces and signals used by the Protocol-IP-96 HW4.6 allowing the ASIC
designer to successfully integrate this IP into their design. This Embedded IP, also named EIP-96 is part of
Rambus Security IP modules that includes all formally known SafeXcel IP™ products from Inside Secure.
Hereafter the IP will be referred to as EIP-96.
To assist the software developer with programming the EIP-96 security features, this manual also provides
overviews, programming details on all supported token instructions, usage scenarios, and a complete map
of the internal registers and memory spaces.
For an extensive set of example tokens, refer to the EIP-96 Operations Manual with Token Examples [2]
document.
This document is not intended to be an architecture specification. Descriptions of the internal submodules
of the EIP-96 are outside of the scope of this manual.
1.2 Scope
This document covers the EIP-96 and EIP-96-f product features, functionality description, configuration
options, and performance and gate count figures. The detailed protocol operations are described in
separate documents. Details of sub-modules are out of the scope of this document.
The EIP-96 referenced to in this document has a superset of features that are available in the standard
configurations: EIP-96i, EIP-96ie, EIP-96is, and EIP-96ies. Differences between these configurations with
respect to the feature superset are indicated in this manual where applicable.
The EIP-96-f referenced in this document has a superset of features that are available in the ‘-
f’configurations: EIP-96i-f, EIP-96ie-f, EIP-96is-f, and EIP-96ies-f. Differences between these configurations
with respect to the standard EIP-96 configurations are indicated where applicable.
1.2.1 General References

If not explicitly mentioned or if referred to as the EIP-96, it can be assumed that the text is valid for all EIP-
96 and EIP-96-f configurations.
1.2.2 Explicit References

If the text explicitly mentions ‘standard EIP-96’ or ‘EIP-96-f’ it is only valid for that referenced set of
configurations.
1.3 Applicable Rambus Documents

The following documents are part of the EIP-96 documentation set.
Ref. Document Name Document
Number
[1] Security-IP-96 HW4.6 Hardware Reference and Programmer Manual (this document) 007-096460-207
[2] Security-IP-96 HW4.6 Operations Manual with Token Examples 007-096460-400
[3] Security-IP-96 HW4.6 Integration Manual 007-096460-200
[4] Securtiy-IP-96 HW4.6 Verification Specification 007-096460-205
This information is correct at the time of document release. Rambus reserves the right to update the related
documents without updating this document. Please contact Rambus for the latest document revisions.
The preferred method for getting technical support is to use our online support system at
https://sipsupport.rambus.com. If you do not have an account yet for this system, please contact Rambus
technical support (sipsupport@rambus.com).

007-096460-207
1.4 Target Audience

This document is intended for ASIC designers and software developers who are integrating the EIP-96
security IP into their system design. The reader is expected to be familiar with all details of the Internet
Protocol (IPv4 and IPv6). A general understanding of, and access to external specifications for various
security protocols supported by the EIP-96, such as IPsec and SRTP, is also required.
1.5 Part Numbers for Standard Configurations

Order Number Configuration Description
913-096011-460 EIP-96i EIP-96 Multi-Protocol Transform Engine
with IPsec, SRTP, MACsec + AES-GCM/CCM/GMAC/XCBC-MAC,
SSL/TLS/DTLS (without ARC4) + Support 256-bit and 384-bit sequence
number mask
913-096012-460 EIP-96ie EIP-96 Multi-Protocol Transform Engine
= EIP-96i + SHA2-384, SHA2-512
913-096013-460 EIP-96is EIP-96 Multi-Protocol Transform Engine
= EIP-96i + ARC4
913-096014-460 EIP-96ies EIP-96 Multi-Protocol Transform Engine
= EIP-96ie + ARC4
913-096015-460 EIP-96iw EIP-96 Multi-Protocol Transform Engine
= EIP-96i + Kasumi, SNOW and ZUC
913-096016-460 EIP-96iew EIP-96 Multi-Protocol Transform Engine
= EIP-96ie + Kasumi, SNOW and ZUC
913-096032-460 EIP-96iex EIP-96 Multi-Protocol Transform Engine
= EIP-96ie + AES-XTS
913-096018-460 EIP-96iesw EIP-96 Multi-Protocol Transform Engine
= EIP-96ies + Kasumi, SNOW and ZUC
913-096038-460 EIP-96ieswx EIP-96 Multi-Protocol Transform Engine
= EIP-96iesw + AES-XTS
913-096001-460 EIP-96i-f EIP-96 Multi-Protocol Transform Engine
with IPsec, SRTP, MACsec + AES-GCM/CCM/GMAC/XCBC-MAC,
SSL/TLS/DTLS (without ARC4)
including FIFO interfaces and a minimum (small) size output buffer
913-096002-460 EIP-96ie-f EIP-96 Multi-Protocol Transform Engine
= EIP-96i + SHA2-384, SHA2-512
913-096003-460 EIP-96is-f EIP-96 Multi-Protocol Transform Engine
= EIP-96i + ARC4
913-096004-460 EIP-96ies-f EIP-96 Multi-Protocol Transform Engine
= EIP-96ie + ARC4
913-096005-460 EIP-96iw-f EIP-96 Multi-Protocol Transform Engine
= EIP-96i + Kasumi, SNOW and ZUC

007-096460-207
913-096006-460 EIP-96iew-f EIP-96 Multi-Protocol Transform Engine

= EIP-96ie + Kasumi, SNOW and ZUC
913-096042-460 EIP-96iex-f EIP-96 Multi-Protocol Transform Engine
= EIP-96ie + AES-XTS
913-096008-460 EIP-96iesw-f EIP-96 Multi-Protocol Transform Engine
= EIP-96ies + Kasumi, SNOW and ZUC
913-096048-460 EIP-96ieswx-f EIP-96 Multi-Protocol Transform Engine
= EIP-96iesw + AES-XTS
1.6 Conventions
Documentation conventions and terminology are described in Appendix F.1.

007-096460-207
2 Features and Characteristics

The EIP-96 design is suited to be integrated as an inline processor. Once the processing token has been
built, packets can be processed completely autonomously by the EIP-96 engine, thereby bypassing the host
processor and maximizing overall system performance.
2.1 Features
The EIP-96 incorporates the following basic features for efficient processing of IPsec, SSL, TLS, DTLS, MACsec
and SRTP packets. See Table 1 below.
Table 1 Features
External interfaces IPv4 support
• DMA • Length field update
• TCM • Next header replacement
• FIFO • TTL decrement
Support of the following encryption algorithms Checksum update
• DES (ECB, CBC) IPv6 support
• 3DES (ECB, CBC) • Length field update
• AES-128/192/256 (ECB, CBC, CTR, ICM, CFB, OFB) • Next header replacement
• ARC4 (stateless, stateful) (EIP-96*s) • Hop-limit decrement
• Kasumi (basic and f8 (=UEA1)) (EIP-96*w) ESP support
• SNOW (128-EEA1 (=UEA2)) (EIP-96*w) • ESP header insertion / removal
• ZUC (basic and 128-EEA3 (=UEA3)) (EIP-96*w) • Using all available algorithms
• AES-XTS-128/192/256 (EIP-96*x) • Padding and de-padding
• ChaCha20 (EIP-96*b) • Next header retrieval
• SM4 (ECB, CBC, CTR, ICM, CFB, OFB) (EIP-96*c) • Extended sequence numbers and large mask
• BC0 (ECB, CBC, CTR, ICM, CFB, OFB) (EIP-96*c) • ICV appending / verification
Support of the following hash algorithms AH support
• CRC-32 • AH header insertion / removal
• MD5 (and HMAC) • Using all available hash algorithms
• SHA-1 (and HMAC) • Extended sequence numbers
• SHA-2: SHA-2241/SHA-2561 (and HMAC) • ICV update / verification
• SHA-2: SHA-3841/SHA-5121 (and HMAC) • IPv4 option header muting
(EIP-96*e) • IPv6 extension header muting
• SHA-3 (and HMAC, Keyed-hash) with digest lengths SSL/TLS/DTLS (excluding ARC4) support
224, 256, 384 and 512 (EIP-96*k) SSL/TLS/DTLS (including ARC4) support (EIP-96*s)
• AES-XCBC-MAC (all key sizes 128, 192 and 256-bit) • Header insertion / removal
• GHASH (used with AES-GCM) • Using all available algorithms
• Kasumi (f9 (=UIA1)) (EIP-96*w) • Padding and de-padding
• SNOW (128-EIA1 (=UIA2)) (EIP-96*w) • Sequence numbers
• ZUC (128-EIA3 (=UIA3)) (EIP-96*w) • MAC appending / verification
• Poly1305 (EIP-96*b) Standard 256-bit and 384-bit sequence number mask
• SM3 (and HMAC) (EIP-96*c) support. (EIP-96ies / EIP-96ieswx / EIP-96ieswxk)
Support of the following combined-mode algorithms Wireless algorithm support (EIP-96*w)
• AES-GCM/AES-GMAC (all key sizes 128, 192 and 256- • Basic integrity modes for 3GPP algorithms
bit) • Basic authentication modes for 3GPP algorithms
• AES-CCM (all key sizes 128, 192 and 256-bit) MACsec support
• ChaCha20-Poly1305 (basic and AEAD mode) • Header insertion / removal
(EIP-96*b) • Using AES-GCM/AES-GMAC
• Sequence numbers
• ICV appending / verification

007-096460-207
Optional PRNG for IV generation

Insertion, replacement and removal of arbitrary data in
the packet data
Hash result retrieval after decryption
Checksum modification
Identifier, sequence number, hash result and padding
verification
Context Record updates and modification
1
In this document, SHA-224, SHA-256, SHA-384 and
SHA-512 refer to the SHA-2 algorithm with respectively
a digest length of 224, 256, 384 and 512 bit, as defined
by NIST in [FIPS Pub. 180-4].
2.2 Datastream Naming Convention

To make sure there is no ambiguity when specifying data streams in the EIP-96 packet processing system,
this manual uses the following conventions.
Private EIP-96 Public

Domain Domain
outbound
RED Data data BLACK Data
(plaintext) inbound (encrypted)
data
Security
Boundary
Figure 1 Data stream naming convention

As shown in Figure 1, data residing in the public domain is typically encrypted and is referred to as ‘black
data’. Black data in the public domain must be decrypted by the EIP-96 into ‘red data’ (or plaintext) before
entering the private domain. Conversely, ‘red data’ must be encrypted by the EIP-96 before entering the
public domain.
Outbound and inbound data stream directions are defined relative to the security boundary between the
EIP-96 and the public domain, also shown in Figure 1. ‘Inbound data’ refers to packet data (typically
encrypted) entering the EIP-96 from the public domain. This data is typically decrypted by the EIP-96.
Outbound data refers to packet data entering the EIP-96 for the private domain. This data is typically
encrypted by the EIP-96.

007-096460-207
2.3 Standard EIP-96 Interfaces

Note: This section is only applicable for the standard EIP-96 configurations, so the non-EIP-96*-f
configurations.
Three types of interfaces are used within the standard EIP-96, FIFO, DMA and TCM. Both token input and
output interfaces are FIFO interfaces, where the transfer of data is enabled when both sides have an active
output control signal. The interfaces are specified in more detail in Chapter 4.
The EIP-96 can pipeline up to three tokens to optimize the processing of packets. While the first packet is
written out of the output RAM, the second packet is processed and the third packet is loaded into the input
RAM and its context is pre-fetched.
For packet and context data, DMA and TCM interfaces are available. Each DMA interface has its own TCM
interface to transfer the requested data. The EIP-96 sets-up a DMA request that should be handled by an
external DMA engine. These external engines return the related data over the corresponding TCM interface.
Each TCM interface with its associated DMA interface is referred to as a Master TCM interface. Refer to
Sections 4.3.3, 4.3.4 and 4.3.5 for timing details.
In addition, a TCM target (slave) interface is present. This interface is used as the control interface. Through
this interface, the EIP-96 engine can be configured and status information can be read. All token and
context registers can also be read to provide debug information. The registers accessible through this
interface are listed in Appendix C.
2.4 EIP-96-f Interfaces

Note: This section is only applicable for the EIP-96 configurations with FIFO interfaces, so the EIP-96*-f
configurations.
Two types of interfaces are used within the EIP-96-f, FIFO and TCM.
Token input and output interfaces, the Data input and output interface are FIFO type interfaces, where the
transfer of data is enabled when both sides have an active output control signal. The interfaces are specified
in more detail in Chapter 4. On customer request, the context interface can also be a FIFO type interface.
The EIP-96-f can pipeline up to three tokens to optimize the processing of packets. While the EIP-96-f is
writing first packet out of the output RAM, it can also be processing the second packet, and loading the
header of the third packet into the EIP-96, while its context is pre-fetched. Refer to Sections 4.3.3, 4.3.4 and
4.3.5 for timing details.
The TCM target (slave) interface is used as the control interface. Through this interface, the EIP-96-f engine
can be configured and status information can be read. Also for debugging purposes, all token and context
registers can be read through this interface. The registers accessible through this interface are listed in
Appendix C.

007-096460-207
2.5 System Integration Examples

The EIP-96 can be integrated in different system environments. Figure 2 illustrates two examples.
INPUT Data In OUTPUT

PACKET PACKET
Data Out PACKET PACKET
IN M S FIFO FIFO FIFO FIFO S M OUT
DMA Context
CONTEXT
IN S M
CONTEXT DMA&TCM “Flow-through”
EIP-96-f
System Integration
Example
S 2TCM
TCM target
M S INPUT Token Token OUTPUT S M

HOST TOKEN TOKEN HOST
FIFO In FIFO Out FIFO FIFO
DMA controller
PACKET
I/O
S M
DMA
M PKT OUT
S
PACKET
RAM
M DMA Data In Data Out
System bus
PKT IN
DMA&TCM DMA&TCM
DMA Context
M CONTEXT DMA&TCM
“Look-a-Side”
CONTEXT
RAM S EIP-96 System Integration
S 2TCM Example
TCM target
S INPUT Token Token

TOKEN
HOST
M FIFO In FIFO Out FIFO
OUTPUT
TOKEN
FIFO
* M is a master on the bus, S a slave (bridge and packet I/O can be both)
Figure 2 Two examples of EIP-96 system integration

007-096460-207
The first and recommended scenario shows a flow-through implementation where both token and data are
cached in separate FIFOs. The EIP-96 reads the cached input tokens from the input token FIFO. DMA
requests for the related data blocks are setup, followed by sequential data writes from the input packet
FIFO to the EIP-96. As much data is written as is requested. When packet result data becomes available, the
EIP-96 requests (via DMA) the output packet FIFO to read data from the EIP-96 output buffer. When all
result data is read the packet result token is written to the result token FIFO. The EIP-96 is designed and
optimized for use in this type of system environment.
In the second example, the EIP-96 is connected as look-aside engine. In this scenario, the EIP-96 is used to
perform operations on packets from the packet RAM. Both original and result packets are in the same RAM.
Optionally the DMA request interfaces can be merged in one DMA engine. If a packet needs to be processed
by the EIP-96, the host writes a token to the token FIFO. When the EIP-96 finishes processing a packet, it
returns a result token in the result token FIFO.
2.6 Modes of operation

2.6.1 Protocols
The EIP-96 supports packet transformations using the following protocols:
• IPsec
• In combination with IPv4 and IPv6
• Transport and Tunnel mode
• ESP (autonomously)
• AH (muting is prepared externally)
• MACsec
• SSL3.0
• TLS1.0, TLS1.1, TLS1.2 and TLS1.3
• DTLS1.0 and DTLS1.2
2.6.2 Algorithm combinations

Refer to Table 1 for details on the supported operations per protocol.
Table 2 Supported crypto / hash combinations
Crypto Algorithm Crypt Feedback Hash Algorithm Hash Mode

None - None bypass
CRC-32 -
MD5 Basic / HMAC
SHA-1 Basic / HMAC / SSL-MAC
SHA2-224/256 Basic / HMAC
SHA3-224/256/384/512 Basic / HMAC / Keyed-hash
GHASH Basic
AES-XCBC-MAC (X)CBC-MAC, incl. CMAC
(=128-EIA2)
Kasumi f9 (=UIA1)
SNOW 128-EIA1 (=UIA2)
ZUC 128-EIA3 (=UIA3)
Poly1305 Basic (=MAC)
SM3 Basic / HMAC
AES ECB None -
CRC-32 -

007-096460-207

MD5 Basic / HMAC
GHASH Basic
AES-XCBC-MAC (X)CBC-MAC
SM3 Basic / HMAC
CBC None -
CRC-32 -
MD5 Basic / HMAC
GHASH Basic
SM3 Basic / HMAC
CTR None -
(incl. ICM and 128- CRC-32 -
EEA2)
MD5 Basic / HMAC
GHASH GCM, GMAC
AES-XCBC-MAC (X)CBC-MAC, CMAC
SM3 Basic / HMAC
XTS None -
(3)DES ECB None -
CRC-32 -
MD5 Basic / HMAC
SM3 Basic / HMAC
CBC None -
CRC-32 -
MD5 Basic / HMAC

007-096460-207

SM3 Basic / HMAC
ARC4 stateless None -
CRC-32 -
MD5 Basic / HMAC
None -
stateful CRC-32 -
MD5 Basic / HMAC
None -
Kasumi Basic None -
f8 (=UEA1) None -
SNOW 128-EEA1 (=UEA2) None -
ZUC Basic None -
128-EEA3 (=UEA3)
ChaCha20 Basic None -
Poly1305 Basic (=MAC) / AEAD
SM4 / BC0 ECB None -
CRC-32 -
MD5 Basic / HMAC
SM3 Basic / HMAC
CBC None -
CRC-32 -
MD5 Basic / HMAC
SM3 Basic / HMAC
CTR None -
CRC-32 -
MD5 Basic / HMAC

007-096460-207

SM3 Basic / HMAC
Appendix D provides the overview of the algorithm combinations that are supported for the various
protocols with the corresponding RFC reference.
2.6.3 Wireless algorithms

The EIP-96 is available in configurations that supports wireless algorithms: ZUC, Kasumi and SNOW.
The [SNOW-3G] specification specifies a maximum message size of 2500 bytes (20000 bits) but the EIP-96
can process up to 8191 bytes.
The [EEA3-EIA3] specification for the ZUC algorithm specifies a maximum message size of 8188 bytes (65504
bits) but the EIP-96 can process up to 8191 bytes.
2.7 Performance
The optimal performance of the EIP-96 will be met when multiple tokens are available for processing and
the fetching of context, input data or output data does not take longer than processing a packet.
The following requirements need to be met to have optimal performance figures:
1. When a packet is being processed, the next context needs to be fetched and at least some data of the
next packet must already be available before the current packet finishes processing.
2. During the processing of a packet, the previous packet must be read out of the result data RAM and its
token must be written to the result token FIFO before the current packet finishes processing.
3. In the standard EIP-96 the input data RAM may never become empty during processing of a packet. In
the EIP-96-f the external FIFO must always have data available while the engine is processing.
If these system requirements are met, the following optimal performance figures can be achieved.
Table 3 Maximum throughput figures (at 500 MHz)
Protocol Ciphe Hash Payloa Result Result Payload Packet Perfor
r d pkt size pkt throughpu throughpu mance
(bytes) (bytes) through t (Mbit/s) t (Mbit/s) (kpkts/sec
put )
(bits/clk)
IPsec ESP AES- SHA-12 9020 9080 11.4 [11.4] 5660 [5655] 5698 [5693] 78 [78]
outbound 128- 1436 1496 10.2 [10.1] 4872 [4847] 5075 [5050] 424 [422]
(IPv4 CBC
320 392 8.0 [8.0] 3282 [3232] 4021 [3960] 1282 [1263]
transport
-mode) 130 200 6.2 [6.1] 2016 [1970] 3101 [3030] 1938 [1894]
64 136 5.1 [5.0] 1196 [1164] 2542 [2473] 2336 [2273]
SHA2- 1436 1500 10.4 [6.9] 4952 [3340] 5172 [3480] 431 [291]
2561 320 396 8.5 [5.7] 3422 [2330] 4235 [2850] 1337 [910]
130 204 6.8 [4.5] 2149 [1460] 3372 [2260] 2066 [1413]
64 140 5.7 [3.7] 1293 [880] 2828 [1880] 2525 [1728]
AES- SHA-1 9020 9080 8.4 [8.4] 4183 [4180] 4211 [4208] 58 [58]
256-
64 136 4.8 [4.8] 1133 [1103] 2407 [2345] 2212 [2155]
CBC2
Triple SHA-1 1436 1488 3.5 1701 1763 148
DES- 320 376 3.4 1465 1721 572
CBC
130 184 3.3 1176 1665 1131
64 120 3.2 859 1611 1678

007-096460-207

put )
(bits/clk)
MD5 1446 1496 3.4 1649 1706 143
350 400 3.2 1434 1639 512
64 120 2.7 719 1348 1404
SM4- SHA-1 9020 9080 7.5 3699 3724 51
128- 1436 1496 7.0 3343 3483 291
CBC
320 392 6.2 2530 3099 988
130 200 5.3 1722 2649 1656
64 136 4.7 1094 2325 2137
SM3 9020 9084 7.4 3671 3697 51
1436 1500 6.7 3188 3330 277
320 396 5.5 2196 2718 858
130 204 4.4 1367 2145 1314
64 140 3.7 815 1784 1593
AES-GCM / 1436 1492 12.0 5770 5990 502
AES-GMAC 320 376 9.8 4170 4900 1629
130 184 7.9 2780 3940 2674
64 120 6.5 1740 3270 3401
AES-CCM 1436 1492 11.1 5340 5550 465
320 376 9.4 4000 4700 1563
130 184 7.4 2600 3680 2500
64 120 6.0 1600 3000 3125
ChaCha20- 1436 1496 11.4 5470 5700 476
Poly1305 320 376 8.7 3700 4350 1446
130 200 7.1 2310 3550 2218
64 120 5.2 1390 2600 2708
SRTP AES- SHA-1 1436 1498 11.1 5400 5550 463
outbound ICM 320 382 8.0 3560 4000 1309
130 192 5.9 2320 2970 1931
64 126 4.6 1540 2310 2294
SSL Triple SHA-1 1436 1469 3.4 1660 1700 145
outbound DES 320 349 3.0 1350 1470 528
130 157 2.5 1010 1220 973
64 93 2.0 690 1000 1348
ARC4 SHA-1 1436 1461 7.2 3530 3590 307
320 345 5.2 2370 2560 926
130 155 3.6 1490 1780 1433
64 89 2.6 900 1250 1761
TLS AES2 SHA-1 1436 1493 10.4 [10.8] 4982 [5184] 5180 [5390] 434 [451]
outbound 320 373 7.5 [7.6] 3200 [3241] 3730 [3777] 1250 [1266]
130 181 5.4 [5.3] 1948 [1919] 2712 [2672] 1873 [1845]
64 117 4.1 [4.0] 1133 [1108] 2071 [2026] 2212 [2165]
Triple SHA-1 1436 1477 3.5 1686 1735 147
DES 320 357 3.2 1433 1599 560
130 165 2.9 1130 1435 1087
64 101 2.5 808 1274 1577

007-096460-207

put )
(bits/clk)
ARC4 SHA-1 1436 1461 7.4 3635 3700 316
320 345 5.6 2602 2805 1016
130 155 4.1 1728 2060 1661
64 89 3.0 1085 1508 2119
DTLS AES2 SHA-1 1436 1501 10.3 [10.7] 4940 [5140] 5160 [5370] 430 [447]
outbound 320 381 7.4 [7.5] 3120 [3160] 3720 [3760] 1220 [1235]
130 189 5.5 [5.4] 1880 [1850] 2730 [2690] 1805 [1779]
64 125 4.2 [4.1] 1090 [1060] 2120 [2080] 2119 [2075]
Triple SHA-1 1436 1485 3.5 1681 1739 146
DES 320 365 3.2 1417 1617 554
130 173 3.0 1106 1472 1064
64 109 2.7 783 1333 1529
MACsec AES-GCM2 1436 1468 12.0 [11.9] 5860 [5830] 5990 [5960] 510 [507]
outbound 320 352 9.7 [9.5] 4400 [4310] 4840 [4740] 1718 [1684]
(with SCI)
130 162 7.6 [7.3] 3040 [2940] 3790 [3660] 2924 [2825]
64 96 5.9 [5.6] 1950 [1870] 2930 [2800] 3817 [3650]
Basic AES-128-CBC2 9000 9024 11.6 [11.6] 5790 [5780] 5790 [5780] 80 [80]
AES-CBC 1500 1504 11.3 [11.3] 5660 [5630] 5660 [5630] 470 [468]
with
350 352 10.4 5200 [5080] 5200 [5080] 1845 [1805]
padding
[10.24]
64 64 7.0 [6.5] 3510 [2980] 3510 [2980] 6849 [6329]
AES-256-CBC2 9000 9024 8.5 [8.5] 4250 [4250] 4250 [4250] 59 [59]
1500 1504 8.4 [8.3] 4180 [4160] 4180 [4160] 347 [346]
350 352 7.8 [7.7] 3920 [3860] 3920 [3860] 1393 [1370]
64 64 5.8 [5.4] 2880 [2700] 2880 [2700] 5618 [5263]
Basic 2 9000 9008 12.6 [12.6] 6320 [6320] 6320 [6320] 88 [88]
AES-GCM-128
GCM with 1500 1508 11.9 [11.8] 5970 [5940] 5970 [5940] 495 [492]
padding
350 358 9.9 [9.6] 4940 [4840] 4940 [4840] 1724 [1689]
64 72 5.3 [5.0] 2640 [2500] 2640 [2500] 4587 [4348]
AES-GCM-2562 9000 9008 9.1 [9.0] 4530 [4530] 4530 [4530] 63 [63]
1500 1508 8.7 [8.6] 4340 [4320] 4340 [4320] 360 [358]
350 358 7.5 [7.3] 3750 [3690] 3750 [3690] 1309 [1289]
64 72 4.5 [4.2] 2230 [2130] 2230 [2130] 3876 [3704]
Basic AES-128-XTS 9000 9000 12.6 6316 6316 88
1500 1500 11.9 5927 5927 494
350 350 9.5 4773 4773 1705
64 64 4.9 2462 2462 4808
Basic ChaCha20- 9000 9016 12.2 6128 6139 85
with Poly1305 1500 1516 11.3 5605 5665 467
padding
350 366 8.4 4031 4216 1440
64 80 3.4 1384 1730 2703

007-096460-207

put )
(bits/clk)
Encryptio Kasumi 9000 9000 4.0 1995 1995 28
n 1500 1500 3.9 1965 1965 164
(f8, 350 350 3.8 1875 1875 670
UEA2,
64 64 3.0 1505 1505 2939
EEA3)
SNOW 9000 9000 15.8 7910 7910 110
1500 1500 15.0 7480 7480 623
350 350 12.3 6140 6140 2193
64 64 6.1 3050 3050 5952
ZUC 9000 9000 12.6 6300 6300 88
1500 1500 11.7 5860 5860 488
350 350 9.1 4560 4560 1629
64 64 4.0 2020 2020 3936
Integrity Kasumi 9000 9000 4.0 1990 1990 28
(f9, 1500 1500 3.9 1955 1955 163
UIA2, 350 350 3.7 1830 1830 654
EIA3) 64 64 2.5 1250 1250 2441
SNOW 8188 8188 12.6 6320 6320 97
1500 1500 12.0 6010 6010 501
350 350 10.0 4980 4980 1779
64 64 5.1 2560 2560 5000
ZUC 8188 8188 12.6 6280 6280 96
1500 1500 11.6 5790 5790 482
350 350 8.7 4360 4360 1558
64 64 3.7 1830 1830 3571
1
All figures are for Double Round SHA-256 hash core, figures between brackets ([n]) are for Single Round SHA-256
hash core.
2
All figures are for EIP-36b AES core, figures between brackets ([n]) are for EIP-38b AES core.
Note: The Mbit/s throughput calculation is based on the size of layer 3 outbound packets, including 4 cycles
required for the removal of a 14-byte Ethernet header, the 14-bytes Ethernet header is not included in
throughput calculation.
Note: For basic operations, the column ‘Result pkt size (incl. IPv4 header)’ indicates the length of the encapsulated
packet with IV inserted in front of the payload, addition of IPsec type of padding to align the payload and ICV
in case of GCM. It does not include an IP header.
Table 4 Maximum throughput figures for Low gatecount (at 500 MHz)
put )
(bits/clk)
IPsec ESP AES- SHA-1 9020 9080 6.2 3091 3111 43
outbound 128- 1436 1496 5.7 2715 2828 236
(IPv4 CBC2 320 392 4.8 1945 2383 760
transport
-mode) 130 200 3.9 1253 1928 1205
64 136 3.3 766 1629 1497
SHA2- 1436 1500 7.0 3343 3492 291
2561 320 396 5.8 2336 2891 912

007-096460-207

put )
(bits/clk)
130 204 4.6 1473 2312 1416
64 140 3.9 889 1944 1736
AES- SHA-1 9020 9080 6.2 3087 3108 43
256-
64 136 3.1 740 1572 1445
CBC2
Triple SHA-1 1436 1488 3.4 1662 1722 145
DES- 320 376 3.1 1306 1535 510
CBC
130 184 2.7 949 1343 912
64 120 2.4 634 1188 1238
MD5 1446 1496 3.4 1649 1706 143
350 400 3.3 1434 1639 512
64 120 2.7 719 1348 1404
SM4- SHA-1 9020 9080 - - - -
128- 1436 1496 - - - -
CBC3 320 392 - - - -
130 200 - - - -
64 136 - - - -
SM3 9020 9084 - - - -
1436 1500 - - - -
320 396 - - - -
130 204 - - - -
64 140 - - - -
AES-GCM / 1436 1492 11.9 5826 5972 507
AES-GMAC2 320 376 9.6 4310 4795 1684
130 184 7.4 2938 3706 2825
64 120 5.8 1869 2920 3650
AES-CCM2 1436 1492 11.1 5393 5529 469
320 376 9.1 4103 4564 1603
130 184 6.9 2737 3453 2632
64 120 5.3 1707 2667 3333
SRTP AES- SHA-1 1436 1498 5.8 2873 2901 247
outbound ICM2 320 382 4.4 2092 2178 769
130 192 3.2 1474 1612 1229
64 126 2.4 1031 1202 1534
SSL Triple SHA-1 1436 1469 3.3 1609 1645 140
outbound DES 320 349 2.5 1156 1261 452
130 157 1.9 772 932 742
64 93 1.4 482 701 942
ARC43 SHA-1 1436 1461 - - - -
320 345 - - - -
130 155 - - - -
64 89 - - - -
TLS AES2 SHA-1 1436 1493 5.8 2799 2910 244
outbound 320 373 4.5 1910 2227 746
130 181 3.4 1221 1700 1174
64 117 2.7 740 1353 1445

007-096460-207

put )
(bits/clk)
Triple SHA-1 1436 1477 3.4 1648 1695 143
DES 320 357 2.8 1264 1410 494
130 165 2.3 897 1138 862
64 101 1.8 586 924 1144
ARC43 SHA-1 1436 1461 - - - -
320 345 - - - -
130 155 - - - -
64 89 - - - -
DTLS 2 SHA-1 1436 1501 5.8 2786 2912 242
AES
outbound 320 381 4.5 1882 2241 735
130 189 3.5 1193 1734 1147
64 125 2.8 719 1404 1404
Triple SHA-1 1436 1485 3.4 1643 1699 143
DES 320 365 2.9 1251 1427 489
130 173 2.3 881 1173 847
64 109 2.0 573 975 1119
MACsec AES-GCM2 1436 1468 12.0 [11.9] 5860 [5830] 5990 [5960] 510 [507]
outbound 320 352 9.7 [9.5] 4400 [4310] 4840 [4740] 1718 [1684]
(with SCI)
130 162 7.6 [7.3] 3040 [2940] 3790 [3660] 2924 [2825]
64 96 5.9 [5.5] 1950 [1870] 2930 [2800] 3817 [3650]
Basic AES-128-CBC2 9000 9024 11.6 5786 5786 80
AES-CBC 1500 1504 11.3 5628 5628 468
with
350 352 10.2 5083 5083 1805
padding
64 64 6.5 3241 3241 6329
AES-256-CBC2 9000 9024 8.5 4249 4249 59
1500 1504 8.3 4163 4163 346
350 352 7.7 3858 3858 1370
64 64 5.4 2695 2695 5263
Basic AES-GCM-1282 9000 9008 12.6 6315 6315 88
GCM with 1500 1508 11.9 5937 5937 492
padding
350 358 9.7 4838 4838 1689
64 72 5.0 2504 2504 4348
AES-GCM-2562 9000 9008 9.1 4525 4525 63
1500 1508 8.6 4321 4321 358
350 358 7.4 3691 3691 1289
64 72 4.3 2133 2133 3704
Basic3 AES-128-XTS 9000 9000 - - - -
1500 1500 - - - -
350 350 - - - -
64 64 - - - -
Basic ChaCha20- 9000 9016 - - - -
with Poly1305 1500 1516 - - - -
padding3 350 366 - - - -
64 80 - - - -

007-096460-207

put )
(bits/clk)
Encryptio Kasumi 9000 9000 - - - -
n 1500 1500 - - - -
(f8, 350 350 - - - -
UEA2,
64 64 - - - -
EEA3)3
SNOW 9000 9000 - - - -
1500 1500 - - - -
350 350 - - - -
64 64 - - - -
ZUC 9000 9000 - - - -
1500 1500 - - - -
350 350 - - - -
64 64 - - - -
Integrity Kasumi 9000 9000 - - - -
(f9, 1500 1500 - - - -
UIA2, 350 350 - - - -
EIA3)3 64 64 - - - -
SNOW 8188 8188 - - - -
1500 1500 - - - -
350 350 - - - -
64 64 - - - -
ZUC 8188 8188 - - - -
1500 1500 - - - -
350 350 - - - -
64 64 - - - -
1
All figures are for Single Round SHA-256 hash core.
2
All figures are for EIP-36b AES core.
3
Figures not available.
Note: The Mbit/s throughput calculation is based on the size of layer 3 outbound packets, including 4 cycles
required for the removal of a 14-byte Ethernet header, the 14-bytes Ethernet header is not included in
throughput calculation.
Note: For basic operations, the column ‘Result pkt size (incl. IPv4 header)’ indicates the length of the encapsulated
packet with IV inserted in front of the payload, addition of IPsec type of padding to align the payload and ICV
in case of GCM. It does not include an IP header.

007-096460-207
2.8 Standard Rambus IP Cores

The performance figures above (and gate count figures below) are based on an EIP-96 configuration utilizing
the following combination of standard Rambus IP cores.
Table 5 Embedded standard IP cores
Module Function Supported in configurations Performance

(bits/clock)
eip36b AES All (except EIP-96*x) 12.8
eip38b AES w/ XTS EIP-96*x 12.8 8
eip16c (default) (3)DES All 10.7 (3.6) 3, 5
eip16d 16 (5.3) 4, 5
eip213a CRC-32 All 32
9 MD5 All 7.9
eip57
SHA-1 All 12.8
SHA2-224/256 All 15.5
SHA2-384/512 EIP-96ie* 12.6
SHA3-224/256/384/512 EIP-96*k 15.8
eip58c AES-XCBC All 12.8
1 AES-CCM All 12.8
eip54c GHASH 2 All 16.0
eip53a Poly1305 EIP-96*b 14.2
eip52d SM3 EIP-96*c 7.8
eip13b ChaCha20 EIP-96*b 12.5
eip12b SM4 EIP-96*c 8.0
eip44c ARC4 EIP-96*s 8.0
eip73d PRNG All (optional) 0.78 6
eip06a (default) Kasumi EIP-96*w 4.0 7
eip06b 8.0 7
eip46b SNOW EIP-96*w 10.7 (enc.) / 12.8 (auth)
eip48c ZUC EIP-96*w 10.7 (enc.) / 12.8 (auth)
1
The AES-CCM algorithm uses both AES and AES-XCBC cores in parallel.
2
The AES-GCM and AES-GMAC algorithms use the GHASH core.
3
Default configuration: Three DES rounds per clock. This configuration is used for the performance numbers in
this document.
4
Alternative configuration: Two DES rounds per clock, maximum clock frequency of EIP-96 can be improved with
up to ~30%.
5
When ordering the EIP-96, the customer must specify which (3)DES core should be included in the package, the
eip-16-med (default) or eip-16-fast. To achieve the maximum frequency listed in Table 6 the default
configuration must be selected, the other configuration has a significantly lower maximum frequency.
6
The PRNG generates a new random value once per 165 cycles.
7
When ordering the EIP-96, the customer must specify which Kasumi core should be included in the package, the
eip-06a (default) or eip-06b. To achieve the maximum frequency listed in Table 6 the default configuration must
be selected, the other configuration has a significantly lower maximum frequency.
8
For ECB and CTR modes with 128 bit keys. CBC mode has slightly lower throughput, as do larger keysizes.
9
Depending on the configuration, several instances of eip57 may be required separately or combined.
The addition of other protocols with similar bits/cycle characteristics should lead to similar overall
performance for the EIP-96. This does not cover the addition of new protocols, which may require
additional overhead.

007-096460-207
2.9 Gate counts and memories

The gate count values listed in Table 6 and Table 7 are NAND equivalents and indicative for generic cell
libraries in two different technologies.
Table 6 Gate counts for all standard configurations
Configuration Technology Approximate Maximum Performance
(standard / (nm) gate count at frequency IPsec-ESP AES-SHA-1
fifo intf.) 400 MHz1 clock (MHz) (mid-size packet)
frequency
Bits/clk Max. freq.
(K gates)
(Mbit/sec)
EIP-96i / TSMC 40 292 660 4336
EIP-96i-f TSMC 28 279 720 4730
EIP-96ie / TSMC 40 342 660 4336
EIP-96ie-f TSMC 28 328 720 4730
EIP-96is / TSMC 40 352 660 4336
EIP-96is-f TSMC 28 338 720 4730
EIP-96iw / TSMC 40 357 660 4336
EIP-96iw-f TSMC 28 342 720 4730
EIP-96ies / TSMC 40 402 660 4336
EIP-96ies-f TSMC 28 385 720 6.57 4730
EIP-96iesb / TSMC 40 477 660 4336
EIP-96iesb-f TSMC 28 460 720 4730
EIP-96iew / TSMC 40 402 660 4336
EIP-96iew-f TSMC 28 386 720 4730
EIP-96iewc / TSMC 40 463 660 4336
EIP-96iewc-f TSMC 28 444 720 4730
EIP-96iesw / TSMC 40 473 660 4336
EIP-96iesw-f TSMC 28 453 720 4730
EIP-96ieswb / TSMC 40 558 660 4336
EIP-96ieswb-f TSMC 28 536 720 4730
EIP-96iex / TSMC 40 407 645 4238
EIP-96iex-f TSMC 28 390 700 4599
EIP-96ieswx / TSMC 40 548 645 4238
EIP-96ieswx-f TSMC 28 525 700 4599
EIP-96ieswxk / TSMC 40 583 645 4238
EIP-96ieswxk-f TSMC 28 560 700 4599
EIP-96ieswxkbc / TSMC 40 695 625 4106
EIP-96ieswxkbc-f TSMC 28 671 680 4468
1
Typical frequency. At the maximum clock frequency the gate count will be higher.
The gatecounts do not include the (default external) PRNG module, which adds approx. 9 K gates; The
gatecounts do not include support for 1K sequence number bitmasks, which adds approximately 128 K gates.
The EIP-96*e configurations do not include the alternative Double Round SHA-256 hash core, which adds 15-20 K
gates.
Note: The clock frequency numbers are achieved from a synthesis run (from RTL to netlist) using wireload models
from the respective libraries. It is expected that after scan insertion and place and route of the module the
maximum frequency is lower than indicated in the table. The synthesis run included I/O delays, 0.2ns clock
uncertainty and 0.2ns transition time of the clock signal. For 28nm and 40nm, the LVT libraries are used.

007-096460-207
Table 7 Gate counts for all low gatecount configurations

Configuration Technology Approximate Maximum Performance
(fifo intf.) (nm) gate count at frequency IPsec-ESP AES-SHA-1
400 MHz1 clock (MHz) (mid-size packet)
frequency
Bits/clk Max. freq.
(K gates)
(Mbit/sec)
EIP-96ie-f-lb-p-lg TSMC 40 317 780 4.77 3721
TSMC 28 303 850 4055
1
Typical frequency. At the maximum clock frequency the gate count will be higher.
The gatecounts do not include the (default external) PRNG module, which adds approx. 9 K gates;
All hash algorithms are combined in a single hash core, if available.
Note: The clock frequency numbers are achieved from a synthesis run (from RTL to netlist) using wireload models
from the respective libraries. It is expected that after scan insertion and place and route of the module the
maximum frequency is lower than indicated in the table. The synthesis run included I/O delays, 0.2ns clock
uncertainty and 0.2ns transition time of the clock signal. For 28nm and 40nm, the LVT libraries are used.
In addition, the memories shown in Table 8 are needed.

Table 8 Memories, depending on interface
Interface Memory requirement Use

Standard 512x32, 1R/1W Data input buffer
512x32, 1R/1W, byte writable Data output buffer
1 80x32, 1R/1W, byte writable Data output buffer
FIFO
FIFO (large buffer) 512x32, 1R/1W, byte writable Data output buffer
1
Also referred to as “small buffer” FIFO interface in the remainder of this document.
Note: Main reason for the existence of large buffer FIFO interface configurations is to offload the host from doing
header updates, at the cost of a minor gatecount increase.

007-096460-207
3 Processing Overview
3.1 Processing Terms
This document makes frequent use of the terms ‘token’ and ‘context’. These terms refer to data structures
that the EIP-96 uses to perform packet processing operations. In IPsec, a context is a (packet independent)
data structure that contains key material and processing parameters associated with the processing of
packets that have been recognized (classified) to be sent through a specific IPsec tunnel. In IPsec
terminology, the Security Association (SA) structure that defines an IPsec tunnel is represented as the
context in the EIP-96. Because the EIP-96 can support more protocols than just IPsec, the EIP-96 context
contains more parameters than just the IPsec SA parameters. The term context is often said to describe a
packet transform. The term transform stems from the definition: if a packet is processed according to the
rules specified in the context, the packet is said to have been transformed by the EIP-96. Alternate terms for
the transformation of packets in this way are tunneling or encapsulation, which specifically refer to packet
transformations requiring the encryption of plaintext data, and the detunneling or decapsulation, the
reverse operation. Clearly, a context contains data that is not packet specific; multiple packets can be
processed (transformed) under the same context.
The term token refers to a data structure that is created for each (individual) packet. A token is a specific
data structure containing processing commands and instructions that the EIP-96 uses to process one
specific packet. Among other things, a token contains a pointer to a Context Record, as well as a number of
parameters extracted from the packet itself, for example, packet or packet header length, specific packet
header fields or offsets to such fields in the packet stream, that is, data that can change with each packet.
An EIP-96 token also contains ‘processing instructions’ used to control the detailed packet processing
operation performed by the EIP-96.
3.1.1 Tokens
The packet processing starts with providing a token to the EIP-96. From that moment, the EIP-96 starts
fetching the context and packet data autonomously. If the packet is processed, the result packet will be
stored and a result token is provided on an output interface.
The token provided to the EIP-96 must have at least four words: three words that constitute a minimum-
sized input token and one instruction word. The first three words contain pointers, options and packet
length. The next token words can contain instructions or data. The length of the input token is unlimited.
The order and sequence of instructions and data in the input token is restricted and is explained in Chapter
7. The result token can contain four to sixteen data words and contains the result-packet length, error flags,
packet result information and optionally meta data. See Chapter 10.
3.1.2 Context
The context data contains processing parameters and keying data. The first two words of each context
contain the options and information about the available fields in the context.
Note: For optimal performance, these first two context words (processing control words) can optionally
be located in the token so that the EIP-96 does not have to fetch them, reducing the context
information that the EIP-96 needs to fetch by, at least, 8 bytes.
The sequence of the different fields within a context is fixed, but not all fields need to be available. The
length of a field is variable and depends on the selected options and algorithms in the first two context
words. For optimal memory usage, all available fields are concatenated to each other.
Since multiple packets can use one context, a context can be reused. This means that the EIP-96 does not
always have to fetch a new context.

007-096460-207
3.2 Data Processing Overview

When a token is provided to the EIP-96, the complete processing of the packet, up to the creation of the
result token, is fully controlled by the EIP-96 itself. After receiving the first token words with length, options
and pointers, the packet data requests are set up and if required the context data is requested. Both
requests are setup via their DMA interfaces.
If packet data is available, the token instructions will be executed and the related data is moved to the
required crypto and/or hash engines. The result packet will be built up in the output RAM. When the output
data is ready to be transferred, output requests are set up to read out the result data. When packet
processing has completed, the output packet data has been transferred via DMA, and context data has been
updated (if needed), the result token becomes available and if possible written to the result token FIFO.
Figure 3 gives an overview of the EIP-96 data processing. Some characteristics of the EIP-96 data processing
operation are as follows:
• The EIP-96 has an internal, functional pipeline of three stages: input buffer, processing, output buffer.
Therefore, the EIP-96 can operate on three tokens at a time.
• The EIP-96 starts the packet context prefetch at the same time as the first packet data fetch, even if the
packet has not entered the processing stage yet. This ensures that key material, context control
commands etc. are available to the processing stage by the time the first packet data arrives. The EIP-
96 contains internal context update functionality to handle the ‘duplicate context’ case (see below).
• Packets are never reordered; the EIP-96 processes packets in the order that their tokens arrive. Result
tokens will be returned in the exact same order. This also implies that the EIP-96 will never request data
for a packet before all data of the previous packet has been read. The same holds for writing packet
data. Context Record access operations in themselves are also ordered, just as context update
operations for different packets. Note that, due to the Context Record prefetch mechanism, it is likely
that the context read for a second packet precedes the context update for the first packet.
3.2.1 Duplicate context handling

Special care must be taken in the case when two subsequent packets make use of the same Context Record,
referred to as the duplicate context situation. Either always select automatic reuse detection or make sure
that the EIP-96 is notified of this situation so that any context updates are also performed on the prefetched
context. Refer to the description on Reuse Context in Section 7.2.1.1.5 for details.

Security IP
New token not accepted until less than 12

instruction words are left from the
previous token
Figure 3
Output Context record optional Processing
Token input Input Pkt ptr (Next token)
pkt ptr pointer words Instructions
© Rambus Inc. • rambus.com

Packet data Transfer for next packet can
commence immediately if next packet
pointer from next token available.
Input packet Input Pkt data

data transfer
Context data Transfer for next packet can

commence immediately if next context record
pointer from next token available.
Context Data
Context data transfer
Only if no packet header update is available. In case of packet
header update, data output starts after Processing completed
May start here
(see below)
Packet data Next packet
Processing
processing processing
CONFIDENTIAL
General Data Processing Overview
Output
Output Pkt data transfer
packet data
Context Context Data Update

Update (If applicable)
Result token
Result Token
If ‘Optimal Context Update’ bit in ‘Token Control/Status Register’ (internal address 0x0, bit 16) is May start sooner
set, this dependency is released and the result token can be output in parallel with the context (see below)
data update (but only -after- packet processing was completed). This is only done (and useful) if
a new token is already available; in this case, packet processing can immediately commence for
the new packet without having to wait for the context data update to complete.
007-096460-207
Protocol-IP-96 HW4.6
38
007-096460-207
4 Architecture Overview
4.1 Introduction
This chapter describes all interfaces for both the standard EIP-96 and EIP-96-f. Section 4.2 describes the
clocking related signals, Section 4.3 describes the interfaces of standard EIP-96 configurations, Section 4.3.7
describes the EIP-96 configurations with streaming data interfaces, the EIP-96-f. Based on the customer’s
system the appropriate EIP-96 configuration must be selected. Refer to section 2.5 for details and system
integration examples for the two different EIP-96 configurations. Note that this chapter does not discuss the
impact of the size limitation of the data buffers. In the EIP-96-f configurations there is no input buffer and,
in case of a “small buffer” configuration, the output buffer is reduced in size from 2048 bytes to 320 bytes.
The effect of this size limitation of the output buffer is discussed in Section 4.4.8.
The remainder of this chapter (sections 4.4.9 and 4.6) describe context interface properties and the internal
modules of the EIP-96 and these are applicable to all configurations of the EIP-96.
4.2 Clocking
The EIP-96 provides clock enable signals to reduce power consumption, but does not contain the clock
switching logic itself. For verification purposes, clock gate models are provided in a separate EIP-96 shell-
level around the EIP-96 top-level module. These models are to be replaced with dedicated clock gates from
the target technology library by the integrator. Please refer to the EIP-96 Integration Manual [3] for details.
The EIP-96 has many clocks input signals. There is one global clock input clk and a number of individual clock
inputs to clock the cryptographic functions. These individual clocks must be all derivatives of the main clk,
meaning that the design is fully synchronous to one single clock. By using external clock switching, the
individual clocks can be enabled and disabled depending on the actual operation in progress, based on
information in the EIP-96 modules.
For details on the various clock signals and their enables, refer to Table 9.
4.2.1 Clock and clock gating signals

This section is applicable for both configuration types EIP-96 and EIP-96-f.
Table 9 Clocks and Clock enables signals
Port Name Dirctn Description

Clock signals
clk IN Clock that times the EIP-96 global control. All signal timings are relative
to the rising edge of clk.
core_clk IN This clock times the EIP-96 data path and context module.
aes_clk IN This clock times the hardware module for the AES algorithm.
des_clk IN This clock times the hardware module for the DES algorithm.
arc4_clk IN This clock times the hardware module for the ARC4 algorithm (only
applicable for EIP-96*s configuration).
snow_clk IN This clock times the hardware module for the SNOW algorithm (only
applicable for EIP-96*w configuration)
zuc_clk IN This clock times the hardware module for the ZUC algorithm (only
applicable for EIP-96*w configuration)
kasumi_clk IN This clock times the hardware module for the Kasumi (encryption)
algorithm (only applicable for EIP-96*w configuration)
kasumif9_clk IN This clock times the hardware module for the Kasumi authentication
algorithm (only applicable for EIP-96*w configuration)
ghash_clk IN This clock times the hardware module for the GHASH algorithm.
aesxcbc_clk IN This clock times the hardware module for the AES-XCBC algorithm.
sha1_clk IN This clock times the hardware module for the SHA-1 algorithm.
sha256_clk IN This clock times the hardware module for the SHA2-224/256 algorithm.

007-096460-207
Port Name Dirctn Description

hash_clk IN This clock times the hardware module for the MD5, SHA2-384/512 and
SHA-3 algorithms.
crc_clk IN This clock times the hardware module for the CRC algorithms.
chacha_clk IN This clock times the hardware module for the ChaCha20 algorithm (only
applicable for EIP-96*b configuration).
poly_clk IN This clock times the hardware module for the Poly1305 algorithm (only
applicable for EIP-96*b configuration).
sm3_clk IN This clock times the hardware module for the SM3 algorithm (only
applicable for EIP-96*c configuration).
sm4_clk IN This clock times the hardware module for the SM4 algorithm (only
applicable for EIP-96*c configuration).
Clock Enable signals
core_clk_en OUT Clock enable for core_clk.
aes_clk_en OUT Clock enable for aes_clk.
des_clk_en OUT Clock enable for des_clk.
arc4_clk_en OUT Clock enable for arc4_clk
(only applicable for EIP-96*s configuration)
snow_clk_en OUT Clock enable for snow_clk
(only applicable for EIP-96*w configuration)
zuc_clk_en OUT Clock enable for zuc_clk
kasumi_clk_en OUT Clock enable for kasumi_clk
kasumif9_clk_en OUT Clock enable for kasumif9_clk
ghash_clk_en OUT Clock enable for ghash_clk.
aesxcbc_clk_en OUT Clock enable for aesxcbc_clk.
sha1_clk_en OUT Clock enable for sha1_clk.
sha256_clk_en OUT Clock enable for sha256_clk.
hash_clk_en OUT Clock enable for hash_clk.
crc_clk_en OUT Clock enable for crc_clk.
chacha_clk_en OUT Clock enable for chacha_clk.
(only applicable for EIP-96*b configuration)
poly_clk_en OUT Clock enable for poly_clk.
(only applicable for EIP-96*b configuration)
sm3_clk_en OUT Clock enable for sm3_clk.
(only applicable for EIP-96*c configuration)
sm4_clk_en OUT Clock enable for sm4_clk.
bc0_clk_en1 OUT Clock enable for external block cipher BC0.
prng_busy2 OUT When active, indicates that the (internal) PRNG is busy. This signal can
be used to determine whether the main clock can be switched off.
1
The external block cipher BC0 is not present inside the EIP-96 and therefore the EIP-96 has no related input clock
signal for BC0 on its interface.
2
Only present for internal PRNG.

007-096460-207
4.3 Standard EIP-96 external Interfaces

Note: This section is only applicable for the standard EIP-96 configurations, so the EIP-96i, EIP-96ie, EIP-
96ies, and EIP-96is.
The block diagram shown in Figure 4 shows multiple external interfaces to transfer tokens, context data and
packet data of the standard EIP-96. All the interfaces are shown in Figure 4. It is important to note that in all
of these interfaces, data is transferred across each data bus in little-endian format. This means that for byte
oriented data streams: B0 (byte 0) must be provided to bits [7:0] of a tcm_xx_wdata bus and read from bits
[7:0] of a tcm_xx_rdata bus. Likewise, B1 should be represented on bits [15:8], B2 on bits [23:16], B3 on bits
[31:24], B4 on bits [7:0], etc...
There are three sets of DMA data request interfaces; these can be connected to one DMA controller or to
separate single DMA interfaces that access the corresponding memory. Data requested via one of the DMA
interfaces, must be written to the corresponding TCM slave interface.
Besides the three DMA-TCM interfaces, two token interfaces are available, one for input token loading and
one for output (result) token passing. There are two external RAM interfaces, one for storing input packets
and the other for storing output (transformed) packets. There is the target TCM interface through which the
engine can be configured. Besides configuration, this interface can be used for debugging purposes since all
internal token and context registers can be read via this interface.
Refer to Table 10 in the next section for a description of all interface signals.
INPUT OUTPUT
PACKET BUFFER RAM PACKET BUFFER RAM
INTERFACE INTERFACE
ob_dpram_wdata_a[31:0]
Ib_dpram_wdata_a[31:0]
ob_dpram_rdata_b[31:0]
Ib_dpram_rdata_b[31:0]
ob_dpram_addr_a[8:0]
ob_dpram_addr_b[8:0]
Ib_dpram_addr_a[8:0]
Ib_dpram_addr_b[8:0]
ob_dpram_we_a[3:0]
Ib_dpram_cs_a
ob_dpram_cs_b
Ib_dpram_cs_b
ob_dpram_cs_
EIP96
tcm_di n_cs req tcm_do ut_cs
TCM TCM
tcm_di n_ad dr wb ls tcm_do ut_ad dr
DATA INPUT DATA OUTPUT
INTERFACE req da ta INTERFACE
tcm_di n_wd ata input req req output tcm_do ut_rda ta
di n_dma_req pre- wb ls ack post- do ut_dma_req
select
fetch da ta da ta store
DMA di n_dma_type processing da ta req req processing do ut_dma_type DMA
+ ack ack +
INPUT DATA di n_dma_in t_ad dr module ack wb ls wb ls module do ut_dma_in t_ad dr OUTPUT DATA
RAM packet processing RAM
REQUEST di n_dma_ext_ad dr da ta da ta do ut_dma_ext_ad dr
REQUEST
Control module Control
INTERFACE INTERFACE
di n_dma_gra nt ack ack do ut_dma_gra nt
context
data
tcm_ctx_cs
tcm_ctx_wri te
TCM tcm_ctx_ad dr TCM
CONTEXT context module
INTERFACE tcm_ctx_wd ata
control
control
control
control
control
data
tcm_ctx_rda ta
result
result
result
instr.
ctx_dma_req
token_wri te
DMA ctx_dma_type RESULT
token_ou t_do ne
CONTEXT ctx_dma_in t_ad dr
control module TOKEN
REQUEST ctx_dma_ext_ad dr token_da ta_ou t CONTROL
INTERFACE fifo_full
ctx_dma_gra nt INTERFACE
ctx_up d_ou t_wri te
ctx_up d_ou t_type
ctx_up d_ou t_id
token_in_done
token_data_in
tcm_sl_wdata
prn g_res_av
tcm_sl_rdata
prn g_res_rd
tcm_sl_write
tcm_sl_addr
ctx_sel_ack
ctx_sel_req
token_read
prn g_erro r
ctx_up d_id
fifo_empty
tcm_sl_cs
prn g_res
reset_n
interrupt
clk
CONTEXT INPUT TCM PRNG / CLOCK, RESET

UPDATE TOKEN TARGET DRBG AND INTERRUPT
INTERFACE CONTROL INTERFACE INTERFACE SIGNALS
INTERFACE
Figure 4 EIP-96 Block Diagram

007-096460-207
4.3.1 Signal descriptions

Table 10 below describes each of the interfaces used by the EIP-96 along with a description of each signal.
All TCM and DMA address busses in this table represent bytes addresses; however most of them will and
must always be word aligned.
Table 10 EIP-96 Interface Signal Descriptions
Interface Signals Dir. Function / Description

Reset and Interrupt Signals
reset_n IN The asynchronous low active reset signal is used to reset the EIP-96.
reset_n = ‘0’: asynchronous reset. Current operation is terminated.
reset_n = ‘1’: normal operation resumes after 2 clock cycles.
interrupt OUT General interrupt output (OR of all active interrupts)
proc_idle OUT Debug output, IDLE indication. Signal is asserted for one cycle if the core
goes from an active state to IDLE.
ctx_done OUT Debug output, CTX_DONE indication. Signal is asserted for one cycle if
the core is done with the active context record, refer to A.2.4.4.
TCM Target Interface (For timing diagram, refer to paragraph 4.3.3)
tcm_sl_cs IN Select control interface.
tcm_sl_write IN Write enable, only valid if tcm_sl_cs is active
tcm_sl_addr[9:0] IN Control register address, only valid if tcm_sl_cs is active
tcm_sl_wdata[31:0] IN Write data bus, only valid if tcm_sl_cs and write are active.
tcm_sl_rdata[31:0] OUT Read data bus, only valid one cycle after an active tcm_sl_cs and
inactive write.
TCM Context Interface (For timing diagram, refer to paragraph 4.3.3)
tcm_ctx_cs IN Select context interface.
tcm_ctx_write IN Write enable, only valid if tcm_ctx_cs is active.
tcm_ctx_addr[N-1:0]3 IN Context address, only valid if tcm_ctx_cs is active
tcm_ctx_wdata[31:0] IN Write data bus, only valid if tcm_ctx_cs and write are active
tcm_ctx_rdata[31:0] OUT Read data bus, only valid one cycle after an active tcm_ctx_cs and
inactive write.
TCM Data Input Interface (For timing diagram, refer to paragraph 4.3.3)
tcm_data_in_cs IN Select data input interface.
tcm_data_in_addr[10:0] IN Input RAM address (modulo RAM size), only valid if tcm_data_in_cs is
active.
tcm_data_in_wdata[31:0] IN Write data bus, only valid if tcm_data_in_cs is active
TCM Data Output Interface (For timing diagram, refer to paragraph 4.3.3)
tcm_data_out_cs IN Select data output interface.
tcm_data_out_addr[10:0] IN Output RAM address (modulo RAM size), only valid if tcm_data_out_cs
is active.
tcm_data_out_rdata[31:0] OUT Read data bus; only valid on rising clock after tcm_data_out_cs is valid.
Input Token Control Interface (For timing diagram, refer to paragraph 4.3.2)
token_in_done IN Pulse indicating a token is finished (active during write of last token
word)
token_fifo_empty IN Indicates that the sending FIFO has an input token data word available.
Token_data_in and token_in_done are now valid.
token_data_in[31:0] IN Input token data bus. Sending FIFO should make data on this bus valid
when both token_fifo_empty is deasserted (cleared to ‘0’) and
token_read is asserted (set to ‘1’).
token_read OUT Indicates that the input token FIFO is able to receive a new token word.
If three tokens are active in the EIP-96 this signal becomes inactive,
even if not all internal token registers are used.

007-096460-207

Result Token Control Interface (For timing diagram, refer to paragraph 4.3.2.)
token_fifo_full IN Indicates that the receiving FIFO is full and cannot accept a new token
word.
token_write OUT Indicates that the data on the token_data_out and the
token_out_done signal are valid and can be read.
token_out_done OUT Indicates that the data on the token_data_out is the last token data
word.
token_data_out[31:0] OUT Result token data bus. Data is valid when token_write is active.
DMA Context Request Interface (For timing diagram, refer to paragraph 4.3.4)
ctx_dma_grant IN Context DMA request is granted
ctx_dma_req OUT Context DMA is requested
ctx_dma_type[7:0] OUT Bits [7,6,5,4,2,1,0]: reserved (available for debugging purpose only)
Bit [3]: Direction –
If ‘1’, the EIP-96 requests data transfer from the EIP-96 to the external
system.
If set to ‘0’, data transfer into the EIP-96 is requested.
ctx_dma_ext_address[63:0] OUT External context address (from token). When 32-bit addressing is used,
the upper 32-bits are always forced to zero.
ctx_dma_int_address[10:0] OUT Internal context address. Should be used by external logic when
ctx_dma_req is high.
ctx_dma_length[10:0] OUT Requested DMA length.
ctx_dma_err[1:0] IN Context read DMA error. Valid when tcm_ctx_cs is active.
ctx_dma_err[0] indicates DMA error.
ctx_dma_err[1] indicates ECC error.
Context Update Interface (For timing diagram, refer to paragraph 4.4.9)
If only a single EIP-96 is instantiated, use the values indicated below for the inputs, the outputs can be left open. 1
ctx_sel_ack IN Acknowledge selection request. When multiple EIP-96 cores are
instantiated the default value must be ‘0’ and only when an
instantiation requests a selection it should be acknowledge. Only a
single instantiation may be acknowledged at the same time.
Else force this signal to ‘1’.
ctx_upd_out_write IN Write an update to the interface context registers. The signal should be
asserted when the type and data are both available from the selected
EIP-96 instantiation.
By default this signal must be set to ‘0’.
ctx_upd_out_id[63:0] IN Identifier for the context update. Only observed when the
ctx_upd_out_write signal is active (‘1’). The value on this bus must be a
copy of the ctx_upd_id[63:0] bus from the acknowledged EIP-96
instantiation. By default this signal must be set to ‘0’.
ctx_upd_out_type[N-3:0]3 IN Indicates the type of data that must be updated. Only observed when
the ctx_upd_out_write signal is active (‘1’). The value on this bus must
be a copy of the tcm_ctx_addr[N-1:2]3 bus from the acknowledged EIP-
96 instantiation. The address must correspond to the data that is read
from that address. By default this signal must be set to ‘0’.
ctx_upd_out_data[31:0] IN Update data. Only observed when the ctx_upd_out_write signal is
active (‘1’). The value on this bus must be a copy of the tcm_ctx_rdata
bus from the acknowledged EIP-96 instantiation. By default this signal
must be set to ‘0’.
ctx_sel_req OUT The EIP-96 requests a context update that must be shared over all
(relevant) instantiated EIP-96 cores.
This signal is only asserted when the EIP-96 input token has the ‘CT’ bit
set to ‘1’.
ctx_upd_id[63:0] OUT Identifier for the context update. Only valid when the ctx_sel_req signal
is active (‘1’).

007-096460-207

DMA Input Data Request Interface (For timing diagram, refer to paragraph 4.3.4)
din_dma_grant IN Data in DMA request is granted
din_dma_error IN An error occurred during the DMA (is only observed while grant is
‘inactive’ (de-asserted). The error bit (E0) in the result token will be set.
din_dma_type[2:0] OUT Bits[1:0] :reserved.
Bit[2]: set to ‘1.’ by the EIP-96 to indicate that the current DMA request
is the last read data request for this packet. (Read from external system,
write to EIP-96.)
din_dma_req OUT Data in DMA is requested.
din_dma_ext_address[31:0] OUT External start address of requested data block.
din_dma_int_address[10:0] OUT Internal start address of requested data block
din_dma_length[10:0] OUT Requested DMA length.
DMA Output Data Request Interface (For timing diagram, refer to paragraph 4.3.4)
dout_dma_grant IN Data out DMA request is granted.
dout_dma_error IN An error occurred during the DMA (is only observed while grant is
‘inactive’ (de-asserted). The error bit (E15) in the result token will be
set.
dout_dma_req OUT Data out DMA is requested.
dout_dma_type[2:0] OUT Bits [1:0] :reserved
Bit[2]: set to ‘1’ by the EIP-96 to indicate that the current DMA request
is the last write data request for this packet. (Read from EIP-96, write to
external system).
dout_dma_ext_address[31:0] OUT External start address of available memory space.
dout_dma_int_address[10:0] OUT Internal start address of data block.
dout_dma_length[10:0] OUT Requested DMA length.
Packet Input Buffer RAM Interface (For timing diagram, refer to paragraph 4.3.6)
ib_dpram_cs_a OUT Active high select signal for port A. Port A is write-only. When CS_A
asserted, the core expects the data present on WDATA_A to be written
to ADDR_A the same cycle that CS is asserted.
ib_dpram_addr_a[8:0] OUT Address of data to be written to RAM
ib_dpram_wdata_a[31:0] OUT Write data.
ib_dpram_cs_b OUT Active high select signal for port B. Port B is read-only. When CS_B
asserted, the core expects to be able to accept data from ADDR_B in
the cycle following the assertion of CS_B, on bus RDATA_B.
ib_dpram_addr_b[8:0] OUT Word address of data to be read from RAM. The core expects one
address location to address 32 bits of data.
ib_dpram_rdata_b[31:0] IN Read data.
Packet Output Buffer RAM Interface (For timing diagram, refer to paragraph 4.3.6)
ob_dpram_cs_a OUT Active high select signal for port A. Port A is write-only. When CS_A
ob_dpram_we_a[3:0] OUT Active high byte enable for port A. WE_A=4'b0001 indicates that byte 0
(bits 7:0) of WDATA_A need to be written to address ADDR_A in the
output packet buffer.
ob_dpram_addr_a[8:0] OUT Word address of data to be written to RAM. The core expects one
ob_dpram_wdata_a[31:0] OUT Write data.
ob_dpram_cs_b OUT Active high select signal for port B. Port B is read-only. When CS_B
ob_dpram_addr_b[8:0] OUT Address of data to be read from RAM.
ob_dpram_rdata_b[31:0] IN Read data.

007-096460-207

External PRNG Interface (For timing diagram, refer to paragraph 4.3.7.) 2
prng_res_rd OUT Ready for Data In.
When asserted High indicates that the EIP-96 engine is ready to receive
new data from the external PRNG (DRBG). If and only if prng_res_av is
High, the available prng_res, prng_error inputs are sampled and
transferred to the corresponding internal engine registers.
prng_error[2:0] IN PRNG error. Valid when prng_res_av is active.
prng_error[0] indicates init error – the PRNG requires an initial seed.
prng_error[1] indicates duplicate error – the PRNG generated a
duplicate.
prng_error[2] indicates reseed error – the PRNG requires a reseed.
prng_res_av IN When asserted High indicates that prng_res, prng_error are available.
prng_res[127:0] IN PRNG data. Valid when prng_res_av is active.
External Block Cipher BC0 Interface
bc0_data_in_av OUT Data in available. When asserted HIGH, indicates that
bc0_ata_in[127:0] is valid and ready to be copied to the crypto core in
the wrapper. Can be continuously active. To avoid that the same input
block is processed twice, this signal is asserted LOW immediately after
the clock cycle in which both bc0_data_in_av and bc0_rfd_in are HIGH
when there is no new input data.
bc0_iv_av OUT IV available. When asserted HIGH indicates that bc0_iv_in[127:0] is
valid and ready to be copied to the crypto core in the wrapper.
bc0_key_av OUT Key available. When asserted HIGH indicates that bc0_key_in[255:0] is
bc0_mode_av OUT Mode available. When asserted HIGH indicates that bc0_mode_in[5:0]
is valid and ready to be copied to the crypto core in the wrapper.
bc0_rfd_out OUT Ready for data out.
When asserted HIGH indicates that the EIP-96 engine is ready to
retrieve new data from the output busses of the crypto core in the
wrapper. This can be continuously active.
Is HIGH for at least one cycle after retrieving all desired output data to
clear bc0_data_out_av and allow the core to output the next result, as
soon as that result becomes available.
bc0_rfd_in IN Ready for data in.
When HIGH this indicates that the crypto core in the wrapper is ready
to receive new input information. Must be a continuously active level
that falls off when the core cannot receive any more data.
When HIGH, all available bc0_xxx_in data must be transferred to the
corresponding internal crypto core registers. If and only if
bc0_data_in_av is HIGH, actual operation is started in the next clock
cycle, in which case bc0_rfd_in has to go LOW.
bc0_data_out_av IN Output available.
When HIGH this indicates that the crypto core in the wrapper has
finished processing a data block and that the output data is available on
the wide busses, ready to be retrieved by the EIP-96 engine. Must be a
continuously active level that falls off after seen bc0_rfd_out and the
core has no more output data.
bc0_mode_in[6:0] OUT Mode Input bus.
Is valid when bc0_mode_av is asserted HIGH. Refer to bc0_rfd_in for a
description of when the Mode select signals are copied into the crypto
engine's internal mode registers. May have any arbitrary value when
bc0_mode_av is LOW.
bc0_mode_in[0] (select en/decrypt):
'0' selects decrypt operation,

007-096460-207

'1' selects encrypt operation.
bc0_mode_in [2:1] (select rounds parameter):
'00' selects a rounds value 0,
'11' selects a rounds value 3.
bc0_mode_in [5:3] (select mode of operation):
'000' selects ECB mode of operation,
'001' selects CBC mode of operation,
'010' selects CTR mode of operation,
'011' selects OFB mode of operation.
'100' selects CFB mode of operation.
All other values are “reserved, do not use”.
bc0_mode_in [6] (not used)
Customer only need to use the mode signals for the functionality
supported in the Customer blockcipher.
bc0_data_in[127:0] OUT Data Input bus.
Is valid when bc0_data_in_av is asserted HIGH. This data has to be
copied into the crypto core in the wrapper when an actual operation is
started (see bc0_rfd_in). May have any arbitrary value when
bc0_data_in_av is LOW.
bc0_iv_in[127:0] OUT IV Input bus
Is valid when bc0_iv_av is asserted HIGH. This data has to be copied
into the crypto core's internal bc0_iv_reg when bc0_rfd_in is HIGH.
May have any arbitrary value when bc0_iv_av is LOW.
bc0_key_in[255:0] OUT Key Input bus
Is valid when bc0_key_av is HIGH. This data has to be copied into the
crypto core’s internal bc0_key_reg when bc0_rfd_in is HIGH. May have
any arbitrary value when bc0_key_av is LOW.
bc0_data_out[127:0] IN Data Output bus.
Valid when bc0_data_out_av is HIGH. Holds the cipher/plaintext result
of the crypto core’s last en/decrypt operation.
bc0_iv_out[127:0] IN IV Output bus.
Valid when bc0_data_out_av is HIGH. Holds the IV for the next non-ECB
mode en/decrypt operation of the crypto engine.
1
Use of the context update interface is only applicable when instantiating multiple EIP-96 cores in parallel
2
Absent for internal PRNG.
3
For support of XL masks, the internal address width N = 12 bit, for smaller masks N = 11 bit.
A DMA scheduler can be used to combine the three DMA interfaces. Context requests have priority,
followed by data requests. The length of the data DMA requests is programmable; a minimum, maximum
and preferred block size can be programmed.

007-096460-207
4.3.2 Token FIFO Interfaces

The FIFO input and output interfaces are straightforward handshake interfaces, each with an extra signal
indicating the last token word. The following figures shows example interface timing for the Input Token
Control (FIFO input interface, Figure 5) and Result Token Control (FIFO output interface, Figure 6). In these
figures, the example input and result tokens show a size of four dwords.
Single Read Three consecutive Reads
T0 T1 T2 T3 T4 T5 T6 T7
clk
fifo_empty
token_in_done
token_read
data_in[31:0] Data 0 Data 1 Data 2 Data 3
Clock data in register Clock data in register
Figure 5 FIFO input interface read timing
Single Write Three consecutive Writes
T0 T1 T2 T3 T4 T5 T6 T7
clk
token_write
token_out_done
fifo_full
data_out[31:0] Data 0 Data 1 Data 2 Data 3
Figure 6 FIFO output interface write timing

007-096460-207
4.3.3 TCM Interface

The EIP-96 has four TCM interfaces all having the same timing. Figure 7 and Figure 8 reflect the timing of
these four TCM interfaces (Target, Context, Data Input and Data Output). The signal naming in the figures is
generic; e.g. tcm_cs represents tcm_sl_cs, tcm_ctx_cs, tcm_data_in_cs and tcm_data_out_cs. The same is
valid for the other signals. The two figures show the interface timing for read and write transfers to/from
the TCM interfaces.
Note that only the Target and Context interface are bidirectional and have tcm_write signal to indicate the
direction of the transfer. The Data Input interface is a write only interface, it is assumed that all transfers
are writes, therefore it has no tcm_write signal and no tcm_rdata bus, only Figure 8 applies for the Data
Input Interface. The Data Output interface is a read only interface, it is assumed that all transfers are reads,
therefore it has no tcm_write signal and no tcm_wdata bus, only Figure 7 applies for the Data Output
Interface.
Single read Two consecutive reads
T0 T1 T2 T3 T4 T5 T6
clk
tcm_cs
tcm_addr Addr 0 Addr 1 Addr 2
tcm_write
tcm_rdata[31:0] 0x00000000 Data 0 0x00000000 Data 1 Data 2 0x00000000
Read data from register Read data from register
Figure 7 TCM bus read timing
Single Write Two consecutive Writes
T0 T1 T2 T3 T4 T5 T6
clk
tcm_cs
tcm_write
tcm_wdata[31:0] Data 0 Data 1 Data 2
Clock data into register Clock data into register
Figure 8 TCM bus write timing

007-096460-207
4.3.4 DMA Request Interface

The EIP-96 has three DMA request interfaces all having the same timing. Figure 9 reflects the timing of
these three DMA interfaces (Context Request, Data Input Request and Data Output Request). The signal
naming in the figures is generic; e.g. dma_req represents ctx_dma_req, din_dma_req and dout_dma_req.
The same is valid for the other signals.
Figure 9 below shows a possible scenario for two subsequent DMA request/grant operations.
clk
dma_req
dma_type[x:0] 0x2 0x4
dma_ext_addr[31:0] PNTR PNTR+0x10
dma_int_addr[10:0] int_addr int_addr+0x10
dma_length[10:0] 0x10 0x10
dma_grant may not become active before the last

dma_grant data transfer over the TCM interface is finished
Figure 9 DMA request/grant timing

It is allowed to assert ‘dma_grant’ in the same cycle as the last data transfer belonging to the currently
active DMA request. Basically the TCM interface (see Section 4.3.3) and the DMA request interface are
decoupled, that is, the external interface can assert tcm_cs at any time after acknowledging the dma_req,
resulting in an access to/from one of the internal registers of the EIP-96. It is the responsibility of the
external system to make sure that the synchronization between the DMA request interface and the TCM
interface remains intact. The EIP-96 uses the dma_grant signal to determine when it is ‘safe’ to use the
input buffer data or reuse the output buffer locations for which the DMA transfer has just completed (see
Section 4.3.5).
Values for dma_type, dma_ext_addr, and dma_int_addr are taken or calculated from token fields. See next
section for details.
Note: The DMA addresses and dma_length are in bytes, however the databusses are 32-bits wide.
Therefore, the DMA requests will always be word aligned, meaning that the internal DMA address
and dma_lengths are always a multiple of 4 bytes. When reading, unused bytes in the last word
are ignored internally, based on the length in the input token. The result token indicates the valid
bytes in the last word of the returned packet.
Note: The theoretical maximum DMA length is 2044 bytes, but is limited due to the packet length,
maximum transfer size programmed in the ‘Input transfer Control/Status Register’ and the
available space in the input data buffer.
4.3.5 DMA Interface and TCM (Master) Interface Collaboration

The following EIP-96 TCM (master) interfaces are paired to a corresponding DMA request interface:
• Packet data input
• Packet data output
• Context (in and output combined)
The EIP-96 issues a DMA request on an interface to indicate the need for data transfer on that interface.
Actual data movement is driven by the external system (chip select, address, etc. are inputs to the EIP-96).
The EIP-96 only requests a transfer of a given size if it can actually accept or supply that data
unconditionally; hence, the backpressure signals typically present on a TCM bus (TCM_wait) are not used on
the EIP-96.

007-096460-207
De-asserting the DMA grant signal on an active dma_req indicates that the requested DMA transfer is
active; the grant signal may not be reasserted (return to active) before the last data transfer for this DMA
request is complete. The DMA grant signal must be de-asserted immediately after acknowledging the
request and must remain inactive while the data is transferred. The EIP-96 expects that all addresses
starting from the DMA start address (dma_int_addr), and covered by the DMA transfer length, are written
to the EIP-96 (or read from the EIP-96) before the DMA grant signal is asserted.
The EIP-96 expects that a DMA request is granted on the positive clock edge while both dma_req and
dma_grant are ‘active’ (high) simultaneously.
In the figure below, ‘T1’ indicates the first clock cycle after dma_grant becoming inactive, that the core
could reassert the dma_req output. This means that if the external system keeps dma_grant high, the EIP-
96 expects that request to be granted the clock edge immediately following T1, when both dma_grant and
dma_req are asserted.
The dma_grant signal needs to be asserted for at least one cycle to indicate to the EIP-96 that the current
dma request is completed. So functionally (inside the EIP-96) the grant is also used to indicated the DMA
operation is completed and the EIP-96 received the requested data.
The tcm_cs signal for the first transfer may only be set to ‘1' at least one clock cycle after the clock cycle
where dma_grant is going low but can also be set a number of cycles later (see the Figure 10). As indicated,
the internal DMA address needs to be provided on the tcm_addr bus and incremented with four for each
individual access. Despite the use of these addresses, the EIP-96 will never read out-of-order or skip any
input or result data. However, for context accesses where result context data is stored in an external
memory location, the start address is most likely in the middle of context, since only a few fields require an
update. Additionally, the given dma_length may be lowered while a DMA transfer is active: this allows the
EIP-96 to shorten the ongoing DMA transfer based on information which is only available after the DMA
transfer has already started.
clk
dma_req T1
dma_type 0x0 0x0 0x0 0x8
dma_ext_addr 0x0 PNTR 0x0 PNTR+0x10
dma_int_addr 0x0 int_addr 0x0 int_addr+0x10
dma_length 0x0 0x10 0x0 0x10
dma_grant grant may not go up before

the last data transfer
tcm_cs
tcm_addr 0x0 0x0 int_addr +0x4 int_addr+0x8 +0xC 0x0
tcm_wdata 0x0 D0 D1 0x0 D2 D3 0x0
Figure 10 TCM master and DMA request interface cooperation

The EIP-96 uses the following fields from the input token (see section 7.2) to calculate the address to use on
the dma_ext_address bus when requesting data:
• din_dma_ext_address: 2nd token word, input packet pointer.
• dout_dma_ext_address: 3rd token word, output packet pointer/identifier.
• ctx_dma_ext_address: 4th token word, context packet pointer.

007-096460-207
When setting up a new packet data (din/dout) DMA request, the EIP-96 will keep track of the amount of
packet data read/written to determine the next offset from the packet pointer.
The value supplied on the ctx_dma_type[7,6,5,4,2,1,0] output signals are reserved and should be ignored
by the external system. The ctx_dma_type[3] signal indicates the required data transfer direction for
context data transfers. This signal is controlled by the “ Direction” bit, bit [11] of the CONTEXT_ACCESS token
instruction.
4.3.6 Packet Buffer Interface Timing

Figure 11 shows the timing behavior for the write port (port A) of each packet buffer RAM interface, both
input buffer (Packet Input Buffer RAM) and output buffer (Packet Output Buffer RAM). Figure 12 shows the
timing behavior for the read port (port B) of each packet buffer RAM interface, both input buffer (Packet
Input Buffer RAM) and output buffer (Packet Output Buffer RAM).
The signal naming in the figures is generic; e.g. dpram_cs_a represents ib_dpram_cs_a and
ob_dpram_cs_a. The same is valid for the other signals. Note that for port A of the Packet Input Buffer
RAM, no write enable signal is present and all 4 bytes of a word are written together.
Clk
dpram_cs_a
dpram_we_a[3:0] 0xF 0x3 0xC
dpram_addr_a[8:0] 0x15 0x2 0x9
dpram_wdata_a[31:0] 0xAAAA 0x..BB 0xCC..
Store 0xAAAA at address 0x15

Store 0xBB in lower 2 bytes of
word located at address 0x2
Store 0xBB in upper 2 bytes of

Figure 11 Packet buffer RAM interface write timing
Clk
dpram_cs_b
dpram_addr_b[8:0] 0x15 0x2 0x9
dpram_rdata_b[31:0] 0xAAAA 0xBBBB 0xCCCC
EIP96 accepts data EIP96 accepts data

from address 0x15 from address 0x2
EIP96 accepts data

from address 0x9
Figure 12 Packet buffer RAM read timing

007-096460-207
4.3.7 External PRNG Interface Timing

The EIP-96 has a single external PRNG interface. Figure 13 reflects the timing of this PRNG interface.
Single Two consecutive
Read Reads
T0 T1 T2 T3 T4 T5 T6
clk
prng_res_av
prng_res[127:0] Data 0 Data 1 Data 2
prng_res_rd
prng_error[2:0] Error 0 Error 1 Error 2
Clock data into Clock data into

register register
Figure 13 EIP-96 external PRNG read timing
4.4 EIP-96-f external interfaces

Note: This section is only applicable for the EIP-96 configurations with FIFO interfaces, so the EIP-96i-f,
EIP-96ie-f, EIP-96ies-f, and EIP-96is-f.
The EIP-96-f uses no input buffers and – for the small buffer configurations – a limited sized output buffer,
which affects certain functionality when compared to the standard configurations. This chapter describes
the physical hardware differences from the standard EIP-96 due to the FIFO interfaces as well as the
consequences of the small output buffer. These can be summarized as follows:
• The input buffer interface is removed.
• The width (address lines) of the output buffer is smaller.
• The output buffer address lines automatically wrap at 320 bytes.
• The ‘packet header update’ functionality is restricted. Result data can only be appended.
In the standard EIP-96 configurations, both input and output data buffers have a size of 2048 bytes. In the
FIFO interface configuration (EIP-96-f), the input buffer is removed and for small buffer configurations the
output buffer is limited to 320 bytes in size. These changes limit the width of the output memory address
bus and disable the registers for configuring the input and output DMA.
Since the size of the small output buffer is very limited, the header update functionality cannot be used. The
functionality of the INSERT_REMOVE_RESULT instruction (further referred as the IRR instruction) to update
data in the output buffer does not work. Therefore, tokens using this instruction must use another mode of
this instruction, described as follows.
For a regular sized packet, the header must stream out before the end of the packet is processed. This
means that for the three cases that need header updates, the result data must be appended instead of
using it to update the header. This new scenario matches the original case for large packets, packets
exceeding 1500 bytes; the EIP-96-f with small buffers needs to append the result data since the packet
being processed cannot finish if the packet header did not stream out.

007-096460-207
The three cases where the EIP-96-f needs to append result data are:
1. IPsec ESP inbound transport packets, where the IP header should be updated with length, checksum
and next header information after de-padding of the packet.
2. IPsec AH outbound packets, where the AH header should include the calculated ICV over the complete
packet.
3. IPsec ESP inbound tunnel packets, where the decapsulated IPv4 header should be updated with
Checksum bits after de-padding of the packet, as a result of updating the ECN bits.
In these cases, the EIP-96-f with small buffers corrects the packet, only with <empty> gaps in field locations
that need updating.
Please refer to Section 8.6.1 for details on the IRR instruction and data formatting of packet headers and
appended data. Only these cases, where data must be appended, apply to this configuration having a small
data output buffer.
4.4.1 Signal descriptions

Table 11 below shows the signals of all interfaces of the EIP-96-f along with a description of each signal,
except the clocking related signals that are already described in Section 4.2. All TCM and DMA address
busses in this table represent bytes addresses; however, most of them will and must always be word
aligned.
Attention: Optional FIFO interface for context

The context interface is in both configurations available as a DMA/TCM interface, where the
EIP-96 requests a context from a specific memory address and updates fields in that same
context based on that address. On customer request the EIP-96-f is optionally available with a
context FIFO interface. In that case, the context DMA, context TCM and Context Update
interfaces from Table 11 are replaced by two FIFO interfaces, one for each direction, to allow
reading and writing. Please refer to Appendix E for details on this interface.
Table 11 EIP-96-f Interface Signal Descriptions

Reset, and Interrupt Signals
reset_n IN The asynchronous low active reset signal is used to reset the EIP-96-f.
reset_n = ‘0’: asynchronous reset. Current operation is terminated.
reset_n = ‘1’: normal operation resumes after 2 clock cycles.
interrupt OUT General interrupt output (OR of all active interrupts)
TCM Target Interface (For timing diagram, refer to paragraph 4.4.2.)
tcm_sl_cs IN Select control interface.
tcm_sl_write IN Write enable, only valid if tcm_sl_cs is active.
tcm_sl_addr[9:0] IN Control register address, only valid if tcm_sl_cs is active.
tcm_sl_wdata[31:0] IN Write data bus, only valid if tcm_sl_cs and write are active.
tcm_sl_rdata[31:0] OUT Read data bus, only valid one cycle after an active tcm_sl_cs and
inactive write.
Context TCM Interface (For timing diagram, refer to paragraph 4.4.4.)
tcm_ctx_cs IN Select context interface.
tcm_ctx_write IN Write enable, only valid if tcm_ctx_cs is active.
tcm_ctx_addr[N-1:0]4 IN Context address, only valid if tcm_ctx_cs is active.
tcm_ctx_wdata[31:0] IN Write data bus, only valid if tcm_ctx_cs and write are active.
tcm_ctx_rdata[31:0] OUT Read data bus, only valid one cycle after an active tcm_ctx_cs and
inactive write.

007-096460-207

Context DMA Interface (For timing diagram, refer to paragraph 4.4.5.)
ctx_dma_grant IN Context DMA request is granted.
ctx_dma_req OUT Context DMA is requested.
ctx_dma_type[7:0] OUT Bits [7,6,5,4,2,1,0]: reserved (available for debugging purpose only)
Bit [3]: Direction;
If ‘1’, the EIP-96 requests data transfer from the EIP-96 to the external
system.
If set to ‘0’, data transfer into the EIP-96 is requested.
ctx_dma_ext_address[63:0] OUT External context address (from token). When 32-bit addressing is used,
the upper 32-bits are always forced to zero.
ctx_dma_int_address[10:0] OUT Internal context address. Should be used by external logic when
ctx_dma_req is high.
ctx_dma_length[10:0] OUT Requested DMA length
ctx_dma_err[1:0] IN Context read DMA error. Valid when tcm_ctx_cs is active.
ctx_dma_err[0] indicates DMA error.
ctx_dma_err[1] indicates ECC error.
Context Update Interface (For timing diagram, refer to paragraph 4.4.9)
If only a single EIP-96 is instantiated, use the values indicated below for the inputs, the outputs can be ignored 1
ctx_sel_ack IN Acknowledge selection request. When multiple EIP-96 core are
instantiated the default value must be ‘0’ and only when an
instantiation requests a selection it should be acknowledge. Only a
single instantiation may be acknowledged at the same time.
Else force this signal to ‘1’.
ctx_upd_out_write IN Write an update to the interface context registers. The signal should be
asserted when the type and data are both available from the selected
EIP-96 instantiation.
By default this signal must be set to ‘0’.
ctx_upd_out_id[63:0] IN Identifier for the context update. Only observed when the
ctx_upd_out_write signal is active (‘1’). The value on this bus must be a
copy of the ctx_upd_id[63:0] bus from the acknowledged EIP-96
instantiation. By default this signal must be set to ‘0’.
ctx_upd_out_type[N-3:0]4 IN Indicates the type of data that must be updated. Only observed when
the ctx_upd_out_write signal is active (‘1’). The value on this bus must
be a copy of the tcm_ctx_addr[N-1:2]4 bus from the acknowledged EIP-
96 instantiation. The address must correspond to the data that is read
from that address. By default this signal must be set to ‘0’.
ctx_upd_out_data[31:0] IN Update data. Only observed when the ctx_upd_out_write signal is
active (‘1’). The value on this bus must be a copy of the tcm_ctx_rdata
bus from the acknowledged EIP-96 instantiation. By default this signal
must be set to ‘0’.
ctx_sel_req OUT The EIP-96 requests a context update that must be shared over all
(relevant) instantiated EIP-96 cores.
This signal is only asserted when the EIP-96 input token has the ‘CT’ bit
set to ‘1’.
ctx_upd_id[63:0] OUT Identifier for the context update. Only valid when the ctx_sel_req signal
is active (‘1’).
Data Input Interface (For timing diagram, refer to paragraph 4.4.6.)
data_in[31:0] IN Input data bus. Sending FIFO should provide valid data on this bus when
data_fifo_empty is cleared to zero.
data_in_fifo_empty IN If zero, indicates that the sending FIFO has an input data word available.
If this is signal is set to zero the data on the data_in bus is valid.
If one the sending FIFO has no data available.
data_in_done IN If one, indicates that the data on the data_in bus is the last data word
of the packet. This signal is valid if data_in_fifo_empty is set to zero.

007-096460-207

If zero, the data word provided on the data_in bus is not the last data
word of the packet.
data_in_error IN This input may be set to one (‘1’) if an error occurred during the data
transfer. The error bit (E0) in the result token will be set if this
(data_in_error) signal is asserted with data_in_done or with a data
transfer, meaning data_in_fifo_empty is zero (‘0’) and data_in_read is
one (‘1’).
data_in_read OUT If one, indicates that the EIP-96-f is able to receive a new data word.
If zero, the EIP-96-f is not ready to receive a new data word.
Data Output Interface (For timing diagram, refer to paragraph 4.4.7.)
data_out_fifo_full IN If zero, indicates the receiving FIFO is ready to accept data.
If one, indicates that the receiving FIFO is full and cannot accept a new
data word.
data_out[31:0] OUT Result data bus. Data is valid when data_out_write is active (set to
one).
data_out_write OUT If one, indicates that the data on the data_out bus and data_out_done
signal are valid and can be read.
If zero, the EIP-96-f has no data available.
data_out_done OUT If one, indicates that the data on the data_out bus is the last data word
of the packet. This signal is valid if data_out_write is active (set to one).
If zero, the data word provided on the data_out bus is not the last data
word of the packet.
data_out_align[1:0] OUT Shows the number of valid bytes on the data_out bus when
data_out_done is set. The value of this bus is always zero if
data_out_done is zero.
A value of 2’b00 represents 4 valid bytes.
data_out_dummy OUT If one, indicates that the output data is a dummy word and can be
ignored. This signal is valid if both data_out_write and data_out_done
signals are active. A dummy output word is provided for empty packets
only and can be used for synchronization reasons.
Providing a dummy word is optional and can be disabled during
initialization. Refer to zero_length_result_packet bit of the
EIP96_TOKEN_CTRL_STAT register (C.1.1.1).
data_out_idf [31:0] OUT Identifier for the output data. Is valid when data_out_write is active.
Input Token Control Interface (For timing diagram, refer to paragraph 4.4.3.)
token_in_done IN Pulse indicating a token is finished (active during write of last token
word).
token_fifo_empty IN Indicates that the sending FIFO has an input token data word available.
Token_data_in and token_in_done are now valid.
token_data_in[31:0] IN Input token data bus. Sending FIFO should make data on this bus valid
when both token_fifo_empty and token_read are active.
token_read OUT Indicates that the input token FIFO is able to receive a new token word.
If three tokens are active in the EIP-96 this signal becomes inactive,
even if the FIFO is not full.
Result Token Control Interface (For timing diagram, refer to paragraph 4.4.3.)
token_fifo_full IN Indicates that the receiving FIFO is full and cannot accept a new token
word.
token_write OUT Indicates that the data on the token_data_out and the
token_out_done signal are valid and can be read.
token_out_done OUT Indicates that the data on the token_data_out is the last token data
word.
token_data_out[31:0] OUT Result token data bus. Data is valid when token_write is active.

007-096460-207

Packet Output Buffer RAM Interface (For timing diagram, refer to paragraph 4.4.8.)
ob_dpram_cs_a OUT Active high select signal for port A. Port A is write-only. When CS_A
ob_dpram_we_a[3:0] OUT Active high byte enable for port A. WE_A=4'b0001 indicates that byte 0
(bits 7:0) of WDATA_A need to be written to address ADDR_A in the
output packet buffer.
ob_dpram_addr_a[n:0] 3 OUT Word address of data to be written to RAM. The core expects one
ob_dpram_wdata_a[31:0] OUT Write data
ob_dpram_cs_b OUT Active high select signal for port B. Port B is read-only. When CS_B
ob_dpram_addr_b[n:0] 3 OUT Address of data to be read from RAM
ob_dpram_rdata_b[31:0] IN Read data
External PRNG Interface (For timing diagram, refer to paragraph 4.4.9.) 2
prng_res_rd OUT Ready for Data In.
When asserted High indicates that the EIP-96 engine is ready to receive
new data from the external PRNG (DRBG). If and only if prng_res_av is
High, the available prng_res, prng_error inputs are sampled and
transferred to the corresponding internal engine registers.
prng_error[2:0] IN PRNG error. Valid when prng_res_av is active.
prng_error[0] indicates init error – the PRNG requires an initial seed.
prng_error[1] indicates duplicate error – the PRNG generated a
duplicate.
prng_error[2] indicates reseed error – the PRNG requires a reseed.
prng_res_av IN When asserted High indicates that prng_res, prng_error are available.
prng_res[127:0] IN PRNG data. Valid when prng_res_av is active.
External Block Cipher BC0 Interface
bc0_data_in_av OUT Data in available. When asserted HIGH, indicates that
bc0_data_in[127:0] is valid and ready to be copied to the crypto core in
the wrapper. Can be continuously active. To avoid that the same input
block is processed twice, this signal is asserted LOW immediately after
the clock cycle in which both bc0_data_in_av and bc0_rfd_in are HIGH
when there is no new input data.
bc0_iv_av OUT IV available. When asserted HIGH indicates that bc0_iv_in[127:0] is
bc0_key_av OUT Key available. When asserted HIGH indicates that bc0_key_in[255:0] is
bc0_mode_av OUT Mode available. When asserted HIGH indicates that bc0_mode_in[5:0]
is valid and ready to be copied to the crypto core in the wrapper.
bc0_rfd_out OUT Ready for data out.
When asserted HIGH indicates that the EIP-96 engine is ready to
retrieve new data from the output busses of the crypto core in the
wrapper. This can be continuously active.
Is HIGH for at least one cycle after retrieving all desired output data to
clear bc0_data_out_av and allow the core to output the next result, as
soon as that result becomes available.
bc0_rfd_in IN Ready for data in.
When HIGH this indicates that the crypto core in the wrapper is ready
to receive new input information. Must be a continuously active level
that falls off when the core cannot receive any more data.
When HIGH, all available bc0_xxx_in data must be transferred to the
corresponding internal crypto core registers. If and only if

007-096460-207

bc0_data_in_av is HIGH, actual operation is started in the next clock
cycle, in which case bc0_rfd_in has to go LOW.
bc0_data_out_av IN Output available.
When HIGH this indicates that the crypto core in the wrapper has
finished processing a data block and that the output data is available on
the wide busses, ready to be retrieved by the EIP-96 engine. Must be a
continuously active level that falls off after seen bc0_rfd_out and the
core has no more output data.
bc0_mode_in[6:0] OUT Mode Input bus.
Is valid when bc0_mode_av is asserted HIGH. Refer to bc0_rfd_in for a
description of when the Mode select signals are copied into the crypto
engine's internal mode registers. May have any arbitrary value when
bc0_mode_av is LOW.
bc0_mode_in[0] (select en/decrypt):
'0' selects decrypt operation,
'1' selects encrypt operation.
bc0_mode_in [2:1] (select rounds parameter):
'11' selects a rounds value 3.
bc0_mode_in [5:3] (select mode of operation):
'000' selects ECB mode of operation,
'001' selects CBC mode of operation,
'010' selects CTR mode of operation,
'011' selects OFB mode of operation.
'100' selects CFB mode of operation.
All other values are “reserved, do not use”.
bc0_mode_in [6] (not used)
Customer only need to use the mode signals for the functionality
supported in the Customer blockcipher.
bc0_data_in[127:0] OUT Data Input bus.
Is valid when bc0_data_in_av is asserted HIGH. This data has to be
copied into the crypto core in the wrapper when an actual operation is
started (see bc0_rfd_in). May have any arbitrary value when
bc0_data_in_av is LOW.
bc0_iv_in[127:0] OUT IV Input bus
Is valid when bc0_iv_av is asserted HIGH. This data has to be copied
into the crypto core's internal bc0_iv_reg when bc0_rfd_in is HIGH.
May have any arbitrary value when bc0_iv_av is LOW.
bc0_key_in[255:0] OUT Key Input bus
Is valid when bc0_key_av is HIGH. This data has to be copied into the
crypto core’s internal bc0_key_reg when bc0_rfd_in is HIGH. May have
any arbitrary value when bc0_key_av is LOW.
bc0_data_out[127:0] IN Data Output bus.
Valid when bc0_data_out_av is HIGH. Holds the cipher/plaintext result
of the crypto core’s last en/decrypt operation.
bc0_iv_out[127:0] IN IV Output bus.
Valid when bc0_data_out_av is HIGH. Holds the IV for the next non-ECB
mode en/decrypt operation of the crypto engine.
1
Use of the context update interface is only applicable when instantiating multiple EIP-96 cores in parallel
2
Absent for internal PRNG.
3
For small buffer configurations n = 6, else n = 8.
4
For support of XL masks, the internal address width N = 12 bit, for smaller masks N = 11 bit.

007-096460-207
4.4.2 Target TCM Interface

The EIP-96-f has a single target TCM interface. Figure 14 and Figure 15 reflect the timing of this TCM
interface. The signal naming in the figures is generic, e.g., tcm_cs represents tcm_sl_cs. The same is valid for
the other signals.
The two figures below show the interface timing for read and write transfers to/from the TCM interfaces.
Single read Two consecutive reads
T0 T1 T2 T3 T4 T5 T6
clk
tcm_cs
tcm_write
tcm_rdata[31:0] 0x00000000 Data 0 0x00000000 Data 1 Data 2 0x00000000
Read data from register Read data from register
Figure 14 EIP-96-f TCM bus read timing
Single Write Two consecutive Writes
T0 T1 T2 T3 T4 T5 T6
clk
tcm_cs
tcm_write
tcm_wdata[31:0] Data 0 Data 1 Data 2
Clock data into register Clock data into register
Figure 15 EIP-96-f TCM bus write timing
Note: This interface is equal to the target interface of the standard EIP-96.

007-096460-207
4.4.3 Token FIFO Interfaces

The token FIFO input and output interfaces are straightforward handshake interfaces, each with an extra
signal indicating the last token word. The following figures shows example interface timing for the Input
Token Control (Token input FIFO interface, Figure 16) and Result Token Control (Token output FIFO
interface, Figure 17).
Single Read Three consecutive Reads
T0 T1 T2 T3 T4 T5 T6 T7
clk
fifo_empty
token_in_done
token_read
data_in[31:0] Data 0 Data 1 Data 2 Data 3
Figure 16 EIP-96-f Token input FIFO interface read timing
T0 T1 T2 T3 T4 T5 T6 T7
clk
token_write
token_out_done
fifo_full
Figure 17 EIP-96-f Token output FIFO interface write timing

In Figure 16 and Figure 17, the example input and result tokens show a size of four dwords.
Note: These two token interfaces are the same as the token interfaces of the standard EIP-96.

007-096460-207
4.4.4 Context Interface

The EIP-96-f has one DMA request interfaces. Figure 18 reflects the timing of the Context Request Interface.
The signal naming in the figures is generic; e.g. dma_req represents ctx_dma_req. The same is valid for the
other signals.
Figure 18 below shows a possible scenario for two subsequent DMA request/grant operations.
clk
dma_req
dma_type[x:0] 0x2 0x4
dma_ext_addr[63:0] PNTR PNTR+0x10
dma_int_addr[10:0] int_addr int_addr+0x10
dma_length[10:0] 0x10 0x10
dma_grant may not become active before the last

dma_grant data transfer over the TCM interface is finished
Figure 18 DMA request/grant timing

It is allowed to assert dma_grant in the same cycle as the last data transfer belonging to the currently active
DMA request. Basically the TCM interface (see Section 4.3.3) and the DMA request interface are decoupled,
that is, the external interface can assert tcm_cs at any time at any time after acknowledging the dma_req,
resulting in an access to/from one of the internal registers of the EIP-96-f. It is the responsibility of the
external system to make sure that the synchronization between the DMA request interface and the TCM
interface remains intact. The EIP-96-f uses the dma_grant signal to determine when it is ‘safe’ to use the
input buffer data or reuse the output buffer locations for which the DMA transfer has just completed (see
Section 4.4.5).
Values for dma_type, dma_ext_addr, and dma_int_addr are taken or calculated from token fields. See next
section for details.
Note: The DMA addresses and dma_length are in bytes, however the databusses are 32-bits wide.
Therefore the DMA requests will always be word aligned, meaning the internal DMA address and
dma_length are word aligned, except for the last DMA of a packet. The length of the last DMA can
be byte aligned, however the next transfer (which is the first DMA of the next packet) will still have
a 32-bit aligned internal DMA address.
4.4.5 DMA Interface and TCM (Master) Interface Collaboration

The EIP-96-f Context TCM (master) interface is paired to a corresponding DMA request interface:
The EIP-96-f issues a DMA request on an interface to indicate the need for data transfer on that interface.
Actual data movement is driven by the external system (chip select, address, etc. are inputs to the EIP-96-f).
The EIP-96-f only requests a transfer of a given size if it can actually accept or supply that data
unconditionally; hence, the backpressure signals typically present on a TCM bus (TCM_wait) are not used on
the EIP-96-f.
De-asserting the DMA grant signal on an active dma_request indicates that the requested DMA transfer is
active; the grant signal may not be reasserted (return to active) before the last data transfer for this DMA
request is complete. The DMA grant signal must be de-asserted immediately after acknowledging the
request and must remain inactive while the data is transferred. The EIP-96-f expects that all addresses
starting from the DMA start address (dma_int_address), and covered by the DMA transfer length, are
written to the EIP-96-f (or read from the EIP-96-f) before the DMA grant signal is asserted.

007-096460-207
The EIP-96-f expects that a DMA request is granted on the positive clock edge while both dma_req and
dma_grant are active (high) simultaneously.
In the figure below, ‘T1’ indicates the first clock cycle after dma_grant becoming inactive, that the core
could reassert the dma_req output. This means that if the external system keeps dma_grant high, the EIP-
96-f expects that request to be granted the clock edge immediately following T1, when both dma_grant and
dma_req are asserted.
The dma_grant signal needs to be asserted for at least one cycle to indicate to the EIP-96 that the current
dma request is completed. So functionally (inside the EIP-96-f) the grant is also used to indicated the DMA
operation is completed and the EIP-96-f received the requested data.
The tcm_cs signal for the first transfer may only be set to ‘1' at least one clock cycle after the clock cycle
where dma_grant is going low but can also be set a number of cycles later (see the Figure 10). As indicated,
the internal DMA address needs to be provided on the tcm_addr bus and incremented with four for each
individual access. Despite the use of these addresses, the EIP-96-f will never read out-of-order or skip any
input or result data. However, for context accesses where result context data is stored in an external
memory location, the start address is most likely in the middle of context, since only a few fields require an
update.
clk
dma_req T1
dma_type 0x0 0x0 0x0 0x8
dma_ext_addr 0x0 PNTR 0x0 PNTR+0x10
dma_int_addr 0x0 int_addr 0x0 int_addr+0x10
dma_length 0x0 0x10 0x0 0x10
dma_grant grant may not go up before

the last data transfer
tcm_cs
tcm_addr 0x0 0x0 int_addr +0x4 int_addr+0x8 +0xC 0x0
tcm_wdata 0x0 D0 D1 0x0 D2 D3 0x0
Figure 19 TCM master and DMA request interface cooperation

The EIP-96-f uses the following fields from the input token (see Section 7.2) to calculate the address to use
on the dma_ext_address bus when requesting data:
• ctx_dma_ext_address: 3rd or 4th token word, context packet pointer.
When setting up a new packet data (din/dout) DMA request, the EIP-96-f will keep track of the amount of
packet data read/written to determine the next offset from the packet pointer.
The value supplied on the ctx_dma_type[7,6,5,4,2,1,0] output signals are reserved and should be ignored
by the external system. The ctx_dma_type[3] signal indicates the required data transfer direction for
context data transfers. This signal is controlled by the “Direction” bit, bit [11] of the CONTEXT_ACCESS
token instruction.

007-096460-207
4.4.6 Data input FIFO interface

Figure 20 below shows an example timing diagram of the new Data Input FIFO Interface, when
data_in_read and data_in_fifo_empty are both active (set to ‘1’); data is transferred over the data_in bus
from the sending FIFO to the EIP-96.
Figure 20 EIP-96-f Data Input FIFO interface timing diagram

The number of beats (32-bit data transfers) per packet on the input side MUST match the input packet
length in the token header (in 32-bit words, rounded-up if byte aligned).
For optimal performance, the data_in_fifo_empty signal should never be asserted (set to ‘1’) while
processing a packet.
Note that the packet data must always be aligned to a 32-bit boundary, even if the previous packet ended
misaligned. If a packet ends misaligned (length modulo 4 is not zero), the remaining bytes (transferred
together with the last valid bytes) are ignored by the EIP-96. The next packet must start aligned again.
4.4.7 Data output FIFO interface

The figure below shows an example timing diagram of the new Data Output FIFO Interface, if
data_out_write and data_out_fifo_full are both active (set to ‘1’) data is transferred over the data_out bus
from the EIP-96 to the receiving FIFO. data_out_done indicates when the last data word from a packet is
transferred over the bus.
T0 T1 T2 T3 T4 T5 T6 T7
clk
data_out_write
data_out_done
data_out_fifo_full
data_out_align[1:0] 0 Data 3
0 0
valid bytes
Figure 21 EIP-96-f Data Output FIFO interface timing diagram

007-096460-207
Note that the packet data is always aligned to a 32-bit boundary, even if the previous packet ended
misaligned. Since the EIP-96 can append result data to the packet (e.g. ICV for AH outbound and IPv4 header
information for ESP inbound transport), the EIP-96 can provide more data on the output than indicated by
the result packet length. The amount of appended result data is not included in the result packet length, but
indicated by a dedicated field in the result token. Please refer to Chapter 10 for details on the result token
format.
4.4.8 Output Packet Buffer Interface Timing

Figure 22 shows the timing behavior for the write port (port A) of the output packet buffer RAM (Packet
Output Buffer RAM). Figure 23 shows the timing behavior for the read port (port B) of the output packet
buffer RAM (Packet Output Buffer RAM).
The signal naming in the figures is generic; e.g. dpram_cs_a represents ob_dpram_cs_a. The same is valid
for the other signals. Note that for port A of the Packet Input Buffer RAM, no write enable signal is present
and all 4 bytes of a word are written together.
Note: This interface is functionally the same as the data output buffer interface of the standard EIP-96.
Only the address width and maximum address differ in the case of “small buffer” configurations.
Clk
dpram_cs_a
dpram_we_a[3:0] 0xF 0x3 0xC
dpram_addr_a[6:0] 0x15 0x2 0x9
dpram_wdata_a[31:0] 0xAAAA 0x..BB 0xCC..
Store 0xAAAA at address 0x15

Store 0xBB in lower 2 bytes of
Store 0xCC in upper 2 bytes of

Figure 22 EIP-96-f Packet buffer RAM interface write timing
Clk
dpram_cs_b
dpram_addr_b[6:0] 0x15 0x2 0x9
dpram_rdata_b[31:0] 0xAAAA 0xBBBB 0xCCCC
EIP96 accepts data EIP96 accepts data

from address 0x15 from address 0x2
EIP96 accepts data

from address 0x9
Figure 23 EIP-96-f Packet buffer RAM read timing

007-096460-207
For FIFO interface configurations with small buffers, the output buffer size is restricted to 320 bytes. This
means that the internal address range of the data output RAM is limited from 7’h00 up to 7’h4F (or in
decimal numbers, in the range of 0 and 79 32-bit words, allowing access to 80 32-bit words). Consequently,
the FIFO interface configuration with small buffers does not generate addresses outside this range on the
Packet Output Buffer RAM Interface. Figure 24 shows an example of this wrapping at the read side of the
FIFO.
T-1 T0 T1 T2 T3 T4 T5 T6 T7 T8 T9 T10
clk
ob_dpram_cs_b
ob_dpram_addr_b[6:0] 0x4E 0x4F 0x00 0x01 0x02
ob_dpram_rdata_b[31:0] D0 D1 D2 D3 D4
Address is wrapped.
It exceeds 0x4F after the increment with one
Figure 24 EIP-96-f Example of address wrapping of the small buffer RAM access
4.4.9 External PRNG Interface Timing

The EIP-96-f has a single external PRNG interface. Figure 25 reflects the timing of this PRNG interface.
Single Two consecutive
Read Reads
T0 T1 T2 T3 T4 T5 T6
clk
prng_res_av
prng_res[127:0] Data 0 Data 1 Data 2
prng_res_rd
prng_error[2:0] Error 0 Error 1 Error 2
Clock data into Clock data into

register register
Figure 25 EIP-96-f external PRNG read timing
4.5 Context update Interface timing

A context update interface is available for both configuration types EIP-96 and EIP-96-f, or more explicitly all
configurations except the non-standard (-cf configuration) as listed in Appendix E. Use of this interface is
only required when instantiating multiple EIP-96 engines in one design and these multiple engines process
packets for the same context (SA-record). In this case, the EIP-96 instantiations must share their context
updates to make sure pre-fetched and active SA all get the latest sequence number data.

007-096460-207
Attention: The use of the context update interface is mandatory when instantiating multiple EIP-96 cores
in one design and these instantiations process packets for the same context (SA-record).
Context sharing is only applicable for protocol (IPsec, DTLS) type of sequence number
generation and checking plus sequence number and sequence number masks updates.
Therefore, operations that inherit other context information from packet to packet must be
processed on the same instantiation of the EIP-96. This involves cipher operations with SSL
and TLS1.0, where the result IV or state from one packet must be used to process the next.
It is advised -for performance reasons- not to use the context update interface when instantiating only a
single EIP-96 core. The default values to tie-off this interface can be found in Table 10 and Table 11 for the
EIP-96 and EIP-96-f respectively. Outputs can be left unconnected.
The remainder of this section assumes instantiation of multiple EIP-96 cores and the required interface
behavior.
The EIP-96 can be configured to share its updates with other instantiations of the EIP-96 potentially using
the same Context Record. This configuration is done on a per-packet basis and all packets using the same
context (SA) must use the same token setting. If the Context Type (‘CT’) bit in the input token (bit [18] of the
token header word) is set, the EIP-96 takes the following actions.
Outbound packets having a sequence number in the Context Record:

• After fetching the context, the EIP-96 asserts the ctx_sel_req signal to request a global context update.
• Once acknowledged, via ctx_sel_ack, the sequence number is updated automatically inside the EIP-96
and a DMA is requested in a regular fashion.
Inbound packets having a sequence number in the Context Record:

• After execution of the packet, instead of verifying the sequence number, the EIP-96 asserts the
ctx_sel_req signal to request a global context update (assuming the packet token contains the required
instructions).
• Once acknowledged, via ctx_sel_ack, the sequence number is verified automatically inside the EIP-96
and a DMA is requested in a regular fashion to update sequence number and mask. Depending on
which parts of the mask must be updated, multiple DMA transfers may be required for XL masks.
• If multiple DMAs are required, the EIP-96 keeps the ctx_sel_req signal asserted also in between these
DMAs to enforce an “atomical” update on all receiving instances. Note that, until the request is
acknowledged, other instances may manipulate the same context under the control of an external
context update arbiter.
Generic behavior after the above actions:

• After granting the DMA, the tcm_ctx_cs should be asserted to read the indicated data.
• This select should trigger the global update managed by an external component that drives all
ctx_upd_out_* signals:
• ctx_upd_out_write is a clocked version of tcm_ctx_cs, ctx_upd_out_id should be a copy of the
ctx_upd_id output bus of the acknowledged EIP-96 instantiation,
• ctx_upd_out_type[N-3:0] should be a clocked version of tcm_ctx_addr[N-1:2], where N=12 when
supporting XL masks, N=11 otherwise,
• ctx_upd_out_data should be a copy of the tcm_rdata bus.
• The above step should be repeated as for each tcm_ctx_cs asserted for this DMA access.
• All signals must be provided to all instantiations of the EIP-96, including itself.
• To allow proper address increments while updating contexts, the address ranges are grouped according
to the upper 3 bits of the address busses (tcm_ctx_addr[N-1:N-3], resp. ctx_upd_out_type[N-3:N-5]).

007-096460-207
This grouping defines the address writing and fetching modes, allowing efficient, tailored, updating of
the context records.
• After execution of the DMA, the grant should be asserted to indicate the DMA is completed. As a result,
the EIP-96 deasserts ctx_sel_req. Note that while the ctx_sel_req signal is asserted, additional DMA
may be requested by this EIP-96 instance.
• After completion of the final DMA in a sequence of DMAs, ctx_sel_req is deasserted, and another
instantiation can be acknowledged.
Note: Once an EIP-96 is acknowledged (ctx_sel_ack asserted to ‘1’) the acknowledge may not be
deasserted, unless the ctx_sel_req is inactive. If this requirement is not satisfied, Context Records
get corrupted.
Figure 26 shows an example timing diagram of the intended behavior of the context update interface and
the relation with the applicable DMA and TCM signals. There are several relations and dependencies. After
assertion of the ctx_sel_req signal the EIP-96 waits for the acknowledge (assertion of ctx_sel_ack) before
asserting the ctx_dma_req signal.
There are two requirements for the external system that goes along with the abovementioned signals.
tcm_ctx_cs may only be asserted one cycle after granting the dma request (ctx_dma_req) signal. Only after
(or with) deassertion of the ctx_sel_req signal the ctx_sel_ack signal may be deasserted.
4.6 Internal Modules

This section describes the main EIP-96 internal modules shown in Figure 4. This figure shows the interfaces
to the internal memory cells used by the EIP-96.
4.6.1 Input fetch and output store modules

The input fetch and output store modules interface between the external interface and the internal
processing pipeline. The purpose of these two modules is to decouple differences in latency and burst
behavior between the processing pipeline and the external data interfaces. In the standard EIP-96 these two
modules have a 2 KB buffer memory to accommodate (in most cases) an entire Ethernet packet. In EIP-96’s
with data FIFO interfaces only the output store module has a buffer. For FIFO interface configurations with
small buffers, this RAM is 320 bytes in size and is used to hold padding that has to be removed and also to
prevent immediate stalling of the processing pipeline when the output interface stalls.
The EIP-96 has these memory interfaces on the outside to allow them to be connected easily to memory
cells from the customer's target technology. The interface to these memories is described in the port list of
the EIP-96. In the EIP-96-f configurations only a data output memory needs to be connected.
4.6.2 Preprocessing module

The preprocessing module executes all operation data and IP header instructions. See Section 7.1. These
instructions control the basic packet data flow through the packet processing module. In addition the
preprocessing module is responsible for all pre-transform (i.e., before processing by the crypto- or hash
operations) packet modifications. This includes operations to perform NAT or checksum updates.
Preprocessing operations, controlled by token instructions include (list is not exhaustive):
• IP header modifications,
• Length field updates,
• TTL field updates,
• NextHeader (NH) / Protocol field updates,
• IP header checksum updates.
• NAT, NAPT,
• NAT-T decapsulation,

007-096460-207
• ESP/AH header insertion/extraction,

• IV insertion/extraction,
• (block cipher) pad insertion,
• Extended sequence number insertion,
• ICV insertion (ESP only, in the ESP trailer).

007-096460-207
4.6.3 Postprocessing module

The postprocessing module executes the postprocessing subset of token instructions (insert/remove result
and replace instructions). It also performs the pad removal operation if so required by the token instruction
options, and operations requiring modifications to packet data already in the output buffer.
Postprocessing operations include (list is not exhaustive):
• (block cipher) pad removal
• IP header updates (transport mode only)
• Length
• NH
• Checksum
• ICV insertion in packet header (AH only)
Note that modifications to a decapsulated packet may result in another packet that needs further
processing.
Note: Note also that ICV insertion for AH, and IP header updates, can only be done by the EIP-96 if the
packet fits completely in the output buffer. Otherwise the EIP-96 will issue an update notification
(refer to Chapter 9, Context ), and the data to be used for the update will be attached to the end of
the packet. Refer also to the use of the “Type of Output” field in the Input Token Definition
(Section 7.2.1.1.6).
4.6.4 Packet processing module

The packet processing module contains the actual crypto and hash algorithms that can be invoked for
packet data encryption, decryption and hashing. This module instantiates the standard versions of the
Rambus Security IP cryptographic cores. Dataflow through this module is controlled by the processing of
instructions contained in the input token (see Chapter 7).
4.6.5 Context module

The context module contains registers for the currently active context as well as the cache registers for the
context for the next packet. The module itself has no active function and is under control of the control
module.
4.6.6 Control module

The Control module has three major functions:
• Coordinating data fetch and store operations.
• Token/Instruction decoding and control of the packet processing module’s datapath.
• Context swap and update control, including duplicate context handling.
• Result token construction and output.
The control module executes the CONTEXT_ACCESS and VERIFY_FIELDS instructions. The CONTEXT_ACCESS
instruction may eventually result in context DMA requests. The VERIFY_FIELDS instructions determine the
content of the status field in the result token. Note that the VERIFY_FIELDS instruction works closely with
the preprocessor RETRIEVE instruction and the postprocessor INSERT_REMOVE_RESULT instruction.

007-096460-207
clk
ctx_sel_req
ctx_upd_id[63:0] 0x12345678ABCDEF0
ctx_dma_type[x:0] 0x8
ctx_dma_int_addr[10:0] int_addr
ctx_dma_req
ctx_sel_ack
ctx_dma_grant
tcm_ctx_cs
tcm_ctx_addr[x:0] int_addr int_addr+0x4 int_addr+0x8
tcm_ctx_rdata[31:0] D0 D1 D2
ctx_upd_out_write
ctx_upd_out_id[63:0] 0x12345678ABCDEF0
ctx_upd_out_type[8:0] int_addr int_addr+0x4 int_addr+0x8
ctx_upd_out_data[31:0] D0 D1 D2
Figure 26 Context update interface example timing diagram

There are several restrictions to the instruction sequence in the input token when using this interface,
please refer to section 7.2.1.1.4 for details.

007-096460-207
5 Initialization
Before the EIP-96 can be used for packet processing, the Host must initialize its configuration registers. This
section will discuss some general principles and methods for initializing and using the EIP-96 efficiently.
General concepts are presented here; details on the registers used for configuration can be found in
Appendix C.
5.1 Protocol enables

The first decision to be made relates to the protocol and algorithm support. By default, all implemented
cryptographic protocols and algorithms in the EIP-96 are enabled. Individual algorithms as well as protocol
support can be disabled through the Protocol/Algorithm Enable register, see Appendix C.1.1.2. This allows
software on the Host system to determine the hardware capabilities. If an algorithm is disabled and the
software tries to use that algorithm, an error will be generated.
5.2 Context Fetch Modes

The second decision relates to the context fetching. The EIP-96 supports two modes for context fetching:
Address mode: In Address mode, the context fields are fetched from the Context Record Address Map
shown in Section 9.1, always starting from Context Control Word 0. Irrelevant fields may
be filled with dummy values. The number of context words fetched is indicated by the
Context_Size (in dwords) located in the Context Control Register. See Appendix C.1.2.1. This
fetch mode can be used when size of the context is fixed, independent of the algorithm
and mode used.
Control mode: In Control mode, the context fields are fetched from a ‘customized’ Context Record based
on the control bits in the context control words. Control mode optimizes the context
fetch by supporting a ‘customized’ Context Record layout containing only relevant fields
(abutted to each other) for the requested operation.
When bit ‘C’ in the Input Token Header is set (see Section 7.2.1.1.7), the fetch does not include the Context
Control Words 0/1 since these were fetched with the token. The fetch begins after Context Control Word 1
(at starting address 0x02) with a length defined by the ‘context length’ field in Context Control Word 0.
When bit ‘C’ in the Input Token Header is not set, the fetch begins with Context Control Word 0 and number
of fetched context words is indicated by the Context_Size (in dwords) located in the Context Control Register,
similar to address mode.
This fetch mode allows for using an optimal Context Record size and reducing the overhead caused by
fetching unused fields.
Table 12 outlines how the selection of the Context Fetch Mode is arbitrated between settings of the Context
Control Register, bits [9:8] and the Context Control Word 1, bit [31].
Table 12 Context fetch control
Context Control Context Control Context Fetch Mode

Register, Bits [9:8] Word 1, Bit [31]
[00] x address mode
[01] x address mode
[10] x control mode (default)
[11] 0 control mode
[11] 1 address mode
Refer to Appendix C.1.1.4 for a description of the Context Control Register and Appendix B for the Context
Record definition.

007-096460-207
5.3 Buffer Control

In the EIP-96 standard configurations, both input and output data buffers have a size of 2048 bytes. In the
FIFO interface configuration, EIP-96-f, the input buffer is not present and – for configurations with small
buffers – the output buffer is limited to 320 bytes in size. These changes limit the width of the output
memory address bus and disabled the registers for configuring the input and output DMA.
The next two sections describe the buffer control capabilities for these two configurations.
See Appendix C.1.3 for a description of the Buffer Control registers.
5.3.1 Standard EIP-96 buffer control

The standard EIP-96 contains an input and output data buffer to decouple the system bus data transfer
from the actual data processing. Two Buffer Control Registers are used to specify when the EIP-96 should
begin to transfer packet data, and what transfer size should be used to DMA data over the system bus.
Three variables control the transfer size:
• Minimum transfer size: The minimum number of dwords that must be transferred to/from the
in/output buffer per DMA transfer. The low-level threshold that can be used to prevent many small
data transfers on the system bus.
• Maximum transfer size: The maximum number of dwords that may be transferred to/from the
in/output buffer per DMA transfer. Can be used to limit the length of the burst operation on the system
bus.
• Transfer size mask: Masks the number of available dwords to obtain an optimal transfer size. This
mask can be used to prevent that inefficient transfers are setup. The number of available dwords is
AND-ed (masked) with the contents of transfer size mask, effectively rounding the value of available
dwords to the nearest block size as indicated by transfer size mask. For example: for a bus system that
favors transfers having a length that equals multiples of 8 dwords, transfer size mask should be
initialized with the value 8’b11111000.
The combination of minimum, maximum transfer size and transfer size mask works as follows:
The core sets up a DMA transfer as close as possible to maximum transfer size, depending on the remaining
bytes that need to be sent/retrieved, rounded down to the nearest block boundary indicated by transfer
size mask. However, this is never smaller than minimum transfer size, unless the transfer comprises the
remaining bytes of a packet in which the minimum transfer size boundary may be violated to allow the
buffer to empty itself.
Example:
Assume the core starts processing an input packet of length 170 bytes (1360 bits). Also, assume the
following values are set for the input buffer control registers. Note that these are NOT the register’s default
values.
• Minimum transfer size: 16 bytes (4 dwords)
• Maximum transfer size: 128 bytes (32 dwords)
• Transfer size mask: 8’b11111110 (align to 2-dword byte boundaries)
Finally, assume that at the start of this example, the input buffer of the EIP-96 has room left for 37 dwords
(150 bytes). This number changes while data is being read in and while the core is processing, so for the
sake of this example, assumptions are made for room available in the input buffer. The actual number of
bytes processed by the core while the input data transfer is going on depends on many factors, including
the algorithm selected and the state of output buffer. It would complicate this example too much if the
actual behavior of the core were taken into account here.

007-096460-207
In this situation, the core will set up, in succession:

1. One maximum size read transfer of 128 bytes (32 dwords). Assume that the input buffer bytes available
after this step is 25.
2. One transfer of size 24 (25 masked by transfer size mask). Assume that the input buffer bytes available
after this step is 3 (total bytes read: 152).
3. Next, the core waits for at least 16 bytes of room (minimum transfer size) to become available, and sets
up a read access accordingly, repeating until the full packet is consumed. In this example, this takes one
other (minimum sized) read accesses. This causes the last two bytes of the packet to remain for the last
transfer.
4. Finally, the last two bytes are read in a final transfer, to finish the packet input.
5.3.2 EIP-96-f Buffer Control

The input buffer transfer control and status register is removed in this configuration and returns zero on a
read.
The output buffer transfer control and status register is still available, however it is read-only. The control
part of this register is forced to a fixed value. The DMA functionality is not available and does not influence
the external behavior of the output FIFO interface. For a FIFO interface configuration with small buffers, the
“Available dwords” status fields return the number of available dwords in the 80 dwords (320 bytes) sized
output buffer.
5.4 Packet Processing Modes

The EIP-96 packet-processing module contains all crypto and hashing blocks including a programmable
interconnect mechanism for these blocks, which allows for various processing modes.
The packet-processing mode is controlled by the ‘Type of Packet’ field in the context control word 0 (See
Section 9.2). All possible configurations of the datapath are shown in the figures below.
direction
crossbar packet processor
output output
input Blocked
hash
crypto Blocked
Figure 27 Packet processor with ToP=4’b000x
packet processor packet processor

direction direction
crossbar crossbar
output output
input output input hash output

digest M M
hash Hash context U Blocked U
X X
crypto Blocked crypto Crypto
Figure 28 Packet processor with ToP=4’b001x (left) and with ToP=4’b010x (right)

007-096460-207
packet processor packet processor

direction direction
crossbar crossbar
output output
hash
input only output output
hash input digest
M M
Hash context U hash Hash context U
X X
encrypt-then-hash
decrypt-then-hash
crypto Crypto crypto Crypto
Figure 29 Packet processor with ToP=4’b011x (left) and with ToP=4’b111x (right)
Note: Due to system complexity, these figures represent the functional behavior of the system and not
the actual physical implementation.
As shown in the figures above, the input data can be directed to three possible destinations within the
packet processor (crypto, hash and/or output), defined by ‘Type of destination’ field (ToD) of the token
instruction, refer to Table 20. Output of the packet processor is always passed to the post-processor
module. The table below describes the relation between ‘Type of destination’ field of the instruction and
‘Type of Packet’ field (ToP) of context control word 0.
In summary, the ToD field determines where the input data should be made available in the packet
processor (the crypto block and/or the hash block and/or passed to the output). The ToP field in the context
configures the datapath within the packet processor itself, enabling crypto and hash blocks when needed
and determining the order of these operations.
Table 13 Relation between ‘Type of Destination’ and ‘Type of Packet’ fields
‘Type of destination’ field ‘Type of Operation

Crypto Hash Output Packet’ field
0 0 1 xxxx Pass data to the output
0 1 0 xx1x Pass data to the hash engine
xx0x Remove data
0 1 1 xx1x Pass data to the hash engine and also to the output
xx0x Pass data to the output
1 0 0 x1xx Pass data to the crypto engine;
Encrypted/decrypted data are ignored
x0xx Remove data
1 0 1 x1xx Pass data to crypto engine and after encryption/decryption
pass to the output
x0xx Pass data to the output
1 1 0 000x Remove data
001x Pass data only to the hash engine
x10x Pass data to the crypto engine;
Encrypted/Decrypted data are ignored
011x Pass data to the crypto engine;
Encrypted/decrypted data are passed to the hash engine
111x Pass data to the crypto engine and pass the same data to the
hash engine;
Encrypted/Decrypted data are ignored

007-096460-207
‘Type of destination’ field ‘Type of Operation

1 1 1 Packet’
000xfield Pass data to the output
001x Pass data to the output and at the same time to the hash
x10x Pass data to the crypto engine and after
encryption/decryption pass to the output.
011x Pass data to the crypto engine;
Encrypted/decrypted data are passed to the hash engine and
to the output.
111x Pass data to the crypto engine and pass the same data to the
hash engine;
Encrypted/decrypted data are passed to the output.
Note: : x = don’t care.

007-096460-207
6 Pseudo Random Number Generator

By default, the EIP-96 is configured without an internal PRNG. In that case, the (pseudo) random data must
be made available to the EIP-96 via the external PRNG interface, complying with the applied interfacing
protocol. See (4.3.7, 4.4.9). The remainder of this chapter assumes the presence of an internal PRNG.
6.1 Purpose
This EIP-96 optionally includes an ANSI X9.17 compliant Pseudo Random Number Generator (PRNG) that
provides a pseudo random data for generating keys, Initialization Vectors (IVs), etc.
The PRNG provides up to 16-bytes of data at a time, enabling the generation of random IVs for DES, Triple-
DES, AES, SM4 and BC0 on a per packet basis without slowing down the system. The DES block within the
PRNG uses a 64-bit LFSR as input data.
Unlike true random number generators, which exploit the randomness that occurs in some physical
phenomena, pseudo random number generators are devices or algorithms that output statistically
independent and unbiased numbers. In general, a PRNG is a deterministic algorithm that for a given truly
random binary sequence (provided as a combination of the seed and key registers), outputs a binary
sequence which “appears” to be random.
6.2 Functional Description

The operation of the EIP-96 internal PRNG is based on the “ANSI X9.17, Annex C example pseudo-random
key and IV generation algorithm”. The PRNG can generate 64-bit or 128-bit pseudo-random numbers. A
128-bit result is generated by running the operation for 64-bit numbers twice, returning the result in the
PRNG_RES0_L/H and PRNG_RES1_L/H registers. When a 64-bit result is requested, only
PRNG_RES0_L/H is used. A 64-bit result is generated as follows:
I = ede * K ( DT )
R = ede * K ( I  V ).
And, a new V is generated by:
V = ede * K ( R  I ).
Here, ede means encryption-decryption-encryption as one form of a Triple-DES operation (see Figure 30). A
ciphertext C is calculated from a plaintext P, by the following formula:
C = E K 0 [ DK1 [ E K 0 [ P]]].
The key pair K0 and K1 are reserved only for the generation of keys, so they should not be the same as any
previously known values.
K0 K1 K0
P E D E C
Figure 30 Multiple encryption with triple DES using two keys.

The algorithm consists of three Triple-DES operations which use the same key pair *K. A schematic overview
of the algorithm is provided below in Figure 31.

007-096460-207
K0,K1
Key0/1
DT Triple- I Triple- Triple-

LFSR DES 1 XOR DES 2 XOR DES 3
V R
Seed Result
Figure 31 Schematic overview of the pseudo-random algorithm specified by ANSI X9.17

Input to the first Triple-DES operation is a secret value DT (DT stands for date/time). Since DT must be
updated on each pseudo-random number generation, it is the output of an LFSR.
Output of the first Triple-DES operation is the intermediate value I, which is stored for later use.
Input to the second Triple-DES operation is the exclusive-or operation of I with a secret seed value V, which
can be an arbitrary number.
Output of the second Triple-DES operation is the vector R, the pseudo-random number that we are
interested in.
Input to the third Triple-DES operation is the exclusive-or operation of the intermediate value I with R.
Output of the third Triple-DES operation is an updated seed value that is stored and used as input for the
next second Triple-DES operation on the next key generation.
All numbers are 64-bit wide except for the key pair that consists of two 56-bit keys.
6.3 Performance
The PRNG can produce a new 64-bit pseudo random number every 83 system clock cycles, or a 128-bit
pseudo random number every 165 system clock cycles. See Table 14 below.
Table 14 PRNG Performance
Random Bit Rate # clock cycles 500 MHz

128-bit Pseudo Random number word rate 165 387 Mbits/sec
Note: When the EIP-96 is using AES, SM4 or BC0, the PRNG should generate 128-bit numbers and hence
bit[2] of the PRNG Control Register must be set to '1' in order to get sufficiently strong random
data. For (3)DES, this bit may be set to '0' but in a typical case where DES, SM4, BC0 and AES are
used, it is recommended to set this bit to '1' and leave it at this value. Refer to Section C.2.2.

007-096460-207
7 Input Token Definition

7.1 Introduction
The EIP-96 processes packets using the instructions from an input token. The token, read via a dedicated
interface, consists of a header and a set of instructions (commands). Information in the token header
initiates and controls the packet data and context fetching. The instructions that follow the token header
control the packet processing itself, a process that is started when both context and packet data are
available. Bypass data can be located at the end of the token after the processing instructions, where it will
be passed to the result token without modification.
A token header must always contain a fixed set of three dwords. These header fields contain general
information that is required for every packet such as pointers to the packet data (optional for EIP-96-f
configurations) and context and packet length.
The token has a minimum size of four dwords. Although the token length is unlimited, a token length is
typically in the range of 10 and 30 dwords.
7.2 Input Token Diagram
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
– – U IV C ToO RC CT CP IP input packet length
input packet pointer (optional for EIP-96-f configurations)
output packet pointer/identifier
transform record pointer / context pointer (lower 32-bit)
MSW of transform record pointer / context pointer (higher 32-bit) (optional, default uses 32-bit pointer)
context control 0 (optional)
context control 1 (optional)
IV0..1..2..3 (optional)
U-word - Optional debug options, must all be set to ‘0000’ checksum (optional)
processing instructions
bypass token data (optional)
Note: All bits marked ‘-’are reserved and should be set to ‘0’.
7.2.1 Input Token Header

The Input Token Header consists of the initial three resp. four (required) dwords plus the optional dwords
that may include the context control words [1:0], the IV [3:0], and a 16-bit checksum.
7.2.1.1 Token Control Word

(token dword [0], required)
This section describes the fields of the Token Control Word, the first dword of the input token.
7.2.1.1.1 Input packet length
This field must equal the number of packet bytes that needs to be fetched and processed by the EIP-96. The
maximum packet length supported by the EIP-96 is 100k bytes. Note that the input packet length, including
the length of all insert instructions of the token should also not exceed this value.

007-096460-207
7.2.1.1.2 IP (Input packet Pointer available, EIP-96-f only)

This bit is only applicable for EIP-96-f configurations and is reserved (and must be set to zero) for the
standard EIP-96 configurations.
When this bit is zero, the input packet pointer field is available in the input token. When this bit is set to one
(for EIP-96-f configurations only) the input packet pointer field is not part of the input token, meaning that
the output packet pointer/identifier field is the second field of the token.
7.2.1.1.3 CP (Context Pointer 64-bit extension)
If this bit is zero, the transform record pointer / context pointer is 32-bit and uses only a single 32-bit word
in the token header.
If this bit is set to one, the transform record pointer / context pointer is extended from the default 32-bit to
64-bit. This means the context pointer uses two sequential words in the token header, where the 32 least
significant bits are located in the first word.
7.2.1.1.4 CT – (Context Type)
Only relevant when parallel operating engines are employed in combination with system level SA
management; it is suggested to set this bit to ‘0’ when only one engine is employed.
For systems containing multiple instances of the engine, it is possible for one context to be used by several
engines simultaneously. If in this case the use of the shared context also requires it to be updated after the
packet processing operation, then the Context Record needs to be protected from use by other engines, in
particular the part of the context that may be changed as a result of such an update. This bit controls the
outbound sequence number update autonomously and ignores potential context access processing
instructions. For inbound it consumes the sequence number verification until the processing is completed.
Only when executing the context access instruction the verification of the sequence number is performed.
Setting this bit results in three potential actions:
1. All CONTEXT_ACCESS instructions with FP bits set to ‘00’ are ignored (thus not executed).
2. For outbound packets with a sequence number:
The sequence number result is returned via the context interface directly after the fetch of the Context
Record. The size of the access equals the length of the sequence number field that is 0, 1 or 2 32-bit
words. The offset in the external Context Record is defined by the seq_num_offset field in the context. This
field is located as last word of the Context Record.
3. For inbound packets with a sequence number:
With the VERIFY_FIELDS instruction the sequence number verification is cached (when the sequence
number bit is set to ‘1’) and not executed. Only with execution of the corresponding
CONTEXT_ACCESS instruction, the check is executed and the result is directly returned via the
context interface. The EIP-96 assumes that the instruction with STAT bits set to ’11’ (bits [18:17] of the
CONTEXT_ACCESS instruction) is the instruction that must be executed along with the check. In
parallel, the context update interface is enabled. The latter, including the sequence number
verification, will NOT happen when no CONTEXT_ACCESS instruction with the STAT bits set to ‘11’ is
available.
Note: Before and during execution of the increment (outbound packets) or the verification (check) of the
sequence number (inbound packets) and during the return of the result (result write) to the
external Context Record the EIP-96 has its ctx_sel_req signal asserted. Only after assertion of the
ctx_sel_ack input signal the EIP-96 executes the increment or check and result write.
Note: If the CT bit is used (set to ‘1’), all signals of the context update interface (refer to Table 10, Table
11 and section 4.5) must be connected properly to maintain context (SA) coherency.

007-096460-207
7.2.1.1.5 RC – Reuse Context

00: no reuse, always load context via context cache, default case.
In this case the EIP-96 never updates the pre-fetched context.
01: reuse context.
This value MUST be set in case of duplicate contexts (see below), unless automatic
context reuse is selected.
10: automatic context reuse detection based on context pointer.
If this option is selected the EIP-96 automatically selects reuse when the current context
pointer matches with the context pointer of the previous packet. This option is suggested
when each context has its unique external address pointer.
11: force update before next load, no cache use allowed.
This setting will cause the EIP-96 to skip the context pre-fetch for the next packet, writing
out any context updates for the current packet before going out and reading the context
back from external memory for use by the next packet. The EIP-96 requires the temporal
ordering of these types of accesses in the external system: the context update must have
been completed before the context read is started. This mode is present for debugging
purposes.
The Reuse Context bits are relevant in situations where two subsequent packets have to make use of the
same Context Record, and the tokens used for these packets include context update instructions (referred
to as the ‘duplicate context’ situation). In this case, the EIP-96 must be instructed to not only update the
context in external memory (through DMA) but also the pre-fetched context that the EIP-96 has already
stored internally. In case of context reuse, the EIP-96 will not fetch the context for the next packet.
The EIP-96 purposely does not look at the context pointer fields in the packet tokens to determine that
subsequent packets make use of the same context; since for some memory systems, this may not be valid.
A typical example of a context update would be in case of ESP inbound operations, where the sequence
number and sequence number mask fields need to be updated in the context to allow successful anti-replay
checking. In the same way, for ESP outbound operation the sequence number itself is typically stored in
context.
Note: Systems that have the EIP-96-cf integrated (refer to Appendix E), must NOT provide context data
for packets that reuse context. For EIP-96-cf configurations with ARC4 special attention is required
in cases where the context is reused. If an ARC4 stateful operation is performed and the ARC4
state was NOT saved (bit 12 of context control word 1 is zero) the EIP-96-cf will always request the
ARC4 state, even if the Context Record itself is not fetched due to context reuse. Note that this
case - loading a state while not having saved it - is not a practical scenario but it is possible. In all
other cases where the context is reused and therefore not loaded, the ARC4 state will also be
reused (if needed) and therefore not fetched.
7.2.1.1.6 ToO – Type of Output
These bits must be set to reflect the behavior of any postprocessing instructions that may be present in the
token. These bits control the moment at which the EIP-96 allows the packet data to be read from the output
buffer. When one of the postprocessing instructions requires an update to the header of the packet (as
would be the case for AH operations), then the packet must remain in the packet buffer until the complete
packet has been processed. If the packet is larger than the EIP-96 internal packet buffer, then the update to
the header is appended to the end of the packet data. In this case, the result token will signal type and
amount of update data via the packet info fields, bits [31:22] of the 2 nd output (result) token word. Note
that the packet length field in the result token does not include this additional update data.
If the token contains postprocessing instruction(s) requiring packet header updates, then one of the header
update options MUST be set. It is allowed to use one of the header update options even if no header update
instructions are present; this causes the EIP-96 to hold the packet in its internal buffer until it is completely
processed. This allows the ToO bits to be set independently of the packet length at the expense of a slight
performance hit.

007-096460-207
Note that in case the EIP-96 is instructed to do the header update in its internal RAM, but the packet is too
large to fit into the EIP-96 output buffer, then the EIP-96 will still revert to appending the result to the
packet.
7.2.1.1.6.1 ToO[1:0]
00: no header update.
This setting is normally used if no header update instructions are present in the token.
Note: If header update instructions are still present in the token, they are discarded by the EIP-
96 and no header updates will take place.
01: header update – small packets only.
This setting causes the EIP-96 to hang on to the result packet data, to attempt to update
the packet header immediately. In case the packet is too large to fit into the EIP-96
internal result packet buffer, the EIP-96 starts writing out the packet data after the result
packet is equal to or exceeds the size of 1792 bytes (including padding bytes that are not
yet removed), and the EIP-96 will revert to appending the result data at the end of the
packet data.
10: append result to packet.
This setting prevents the EIP-96 from updating the packet header in its internal packet
buffer. Writing out of the packet data can start as soon as enough data is available. The
update data is appended to the end of the packet.
11: header update and result appending.
This setting is required if the token contains instructions for both a header update as well
as result data to be appended to the packet. The EIP-96 will keep the packet data in its
internal packet buffer (under the same conditions as listed for option ‘01’) until the ‘STAT’
bits of one of the postprocessing instructions (see Appendix 8.3) indicates that the last
header update instruction has been processed. Update data from any postprocessing
instruction, following the ‘last header update’ postprocessing instruction, will be
appended to the packet. Packet data output will commence after the ‘last header update’
bits have been seen.
The ToO bits affect the operation of the INSERT_REMOVE_RESULT and REPLACE_BYTE instructions. Refer to
Section 8.6, Postprocess Instructions.
7.2.1.1.6.2 ToO[2]
Bit 2 of the Type of Output field is used to indicate pad removal options. This bit may only be set for
inbound operations. If the bit is set, the padding type in the Context Record must be one of the following:
PKCS#7, RTP, IPsec, TLS, or SSL.
0: no pad removal
1: remove and (optionally) verify pad
Note: Accidental use of this bit for outbound operations can result in unwanted pad removal or an error
situation, if no padding is found.
Note: In the case of TLS1.3 padding, removal of padding with a size that exceeds the output buffer
restrictions is not possible. This will be reported in the result token, see Section 10.
7.2.1.1.7 C: Context control words present in token
Setting this bit forces the EIP-96 to read the context control words (normally, the first two words of the
Context Record) from the token (context control0 and context control1).
Providing the token control words in the token has implications on the context fetch. The standard EIP-96
configurations automatically handle this situation. However, for EIP-96 configurations with a FIFO based
context interface (refer to Appendix E), the EIP-96 does not expect the context control words to be provided
via the context FIFO input interface. So when providing a token with context control words in EIP-96-f
configurations, the context (provided via the context interface) must start with the first field after the two
command words.

007-096460-207
Setting both control words to all zeroes causes the EIP-96 to bypass the entire packet without attempting to
fetch a Context Record from external memory. This provides a slight (bypass) performance increase over a
token specifying only a bypass instruction. This means that in the latter case, the EIP-96-f configurations do
not expect a context to be provided on the context input interface.
The context control words in the token are formatted identically to the command words in the Context
Record (see Section 9.1).
7.2.1.1.8 IV: Usage and Selection
Table 15 shows typical examples of how the IV registers can used for six types of crypto operations:
DES/3DES-CBC, AES/SM4/BC0-CTR, AES/SM4/BC0-ICM, AES/SM4/BC0-CBC and ChaCha20. Note that in the
EIP-96, IV fields (IV0 through IV3) can be taken from four possible sources:
• Context Record,
• PRNG,
• Input Token,
• Input Packet – indirectly via Input Token processing instruction.
• For AES-XTS limited loading options are available, refer to section 7.2.1.1.8.3 for more details.
Table 15 IV Register Usage
CCW1 [11:10] IV format

Encryption IV Sources
CCW1 [4] XOR enable

Token Control [28:26]
algorithm
Crypto Mode [2:0]
IV3/IV2/IV1/IV0
(mode)
CCW1 [2:0]
CCW1 [8:5]
IV[2:0]
IV0 IV1 IV2 IV3
DES/3DES-CBC Input Input not used not used 000 001 000 0 0
packet1 packet1 0 0
PRNG PRNG not used not used 001 001 000 0 0
0 0
Context Context not used not used 000 001 001 0 0
record record 1 0
Input token Input token not used not used 110 001 000 0 0
0 0
AES-CTR2 / Input Input Input Input 000 110 000 0 0
SM4/BC0-CTR packet1 packet1 packet1 packet1 0 0
32’h0000000 000 010 000 0 0
1 0 0
PRNG PRNG PRNG PRNG 001 110 000 0 0
0 0
(nonce) Input Input 32’h0000000 000 010 000 0 0
Context packet1 packet1 1 1 1
record PRNG PRNG 32’h0000000 001 010 000 0 0
1 1 1
sequence sequence 32’h0000000 000 010 000 1x 0
nbr nbr 1 1
Context Context Context 000 110 111 0 0
record record record 1 0
32’h0000000 000 010 011 0 0
1 1 1
Input token packet1 packet1 1 0 1

007-096460-207
[2:0]
CCW1 [8:5]
IV3/IV2/IV1/
Mode [2:0]
[11:10] IV
[4]
Control
[28:26]
Crypto
enable
format
IV[2:0]
Token
CCW1
algorithm
XOR
IV0
CCW1
CCW1
(mode)
PRNG PRNG 32’h0000000 101 010 000 0 0

1 0 1
sequence sequence 32’h0000000 100 010 000 1x 0
nbr nbr 1 0
Context Context Input token 100 110 111 0 0
record record 0 0
32’h0000000 100 010 011 0 0
1 0 1
Context packet1 packet1 1 1 1
record XOR seq nbr XOR seq nbr
Context Context 32’h0000000 000 010 011 0 1
record record 1 1 1
XOR seq nbr XOR seq nbr
Input token packet1 packet1 1 0 1
Context Context 32’h0000000 100 010 011 0 1
record record 1 0 1
AES-ICM / Input Input Input Input 000 011 000 0 0
SM4/BC0-ICM packet1 packet1 packet1 packet1 with 0 0
16’h0000
PRNG PRNG PRNG PRNG with 001 011 000 0 0
16’h0000 0 0
Context Context Context Context 000 011 111 0 0
record record record record with 1 0
16’h0000
AES-CBC / Input Input Input Input 000 001 000 0 0
SM4/BC0-CBC packet1 packet1 packet1 packet1 0 0
PRNG PRNG PRNG PRNG 001 001 000 0 0
0 0
Context Context Context Context 000 001 111 0 0
record record record record 1 0
Input token Input token Input token Input token 111 001 000 0 0
0 0
ChaCha204 Input Input Input Input 000 0xx 000 0 0
packet1 packet1 packet1 packet1 0 0
32’h0000000 000 1xx 000 0 0
0 0 0
PRNG PRNG PRNG PRNG 001 0xx 000 0 0
0 0
32’h0000000 001 1xx 000 0 0
0 0 0
Context Context Context Context 000 0xx 111 0 0
32’h0000000 000 1xx 111 0 0
0 1 0
Context Context Context Context 000 0xx 111 1 1

007-096460-207
[2:0]
CCW1 [8:5]
IV3/IV2/IV1/
Mode [2:0]
[11:10] IV
[4]
Control
[28:26]
Crypto
enable
format
IV[2:0]
Token
CCW1
algorithm
XOR
IV0
CCW1
CCW1
(mode)
XOR seq nbr XOR seq nbr 32’h0000000 000 1xx 111 1 1
0 1 0
Kasumi (f8) Context Context not used not used 000 001 001 0 0
record record 1 0
Input token Input token not used not used 110 001 000 0 0
0 0
SNOW and ZUC Input token Input token Input token Input token 111 001 000 0 0
(UEA) 3 0 0
1
The IV words loaded from the Input Packet are retrieved from the input data stream with a RETRIEVE instruction;
please refer to this instruction for more details.
IVs sourced from input packet are typically used for inbound (decrypt) type operations, where the IVs are sent
along with the packet data (for example, ESP decapsulation). Internally generated IVs are typically used for
outbound (encrypt) operations.
2
AES-CTR is the underlying crypto algorithm for AES-GCM and AES-CCM. Therefore, generally, the same IV loading
mechanism applies. By exception, AES-CCM used in TLS 1.2/1.3 requires loading a shifted IV, see CCW1[21]
setting in section 9.2.2.
3
For SNOW and ZUC (UIA), non-zero bit alignment may be required. For an example, refer to the EIP-96
Operations Manual with Token Examples [2].
4
ChaCha20 is the underlying crypto algorithm for ChaCha20-Poly1305 AEAD. One-Time-Key calculations (CCW1[2]
equals ‘1’) require initialization of IV3 to 32’h00000000, since IV3 is used as the initial ChaCha20 block counter.
For the default IV loading option per algorithm, refer to the EIP-96 Operations Manual with Token Examples [2].
7.2.1.1.8.1 Selecting IV Source

The EIP-96 engine’s internal IV register (128 bits) is initially written using the IV fields (IV0 through IV3) of
the Context Record during a context fetch operation. Each IV field can then be modified (overwritten)
before the internal IV register is actually used with encrypt or decrypt operations. The IV field modification
options are described in this section.
In the EIP-96, selecting IV field modification options is done by using the following bits:
• Three ‘IV’ bits in the Input Token Control Word, bits [28:26],
• Two ‘IV format’ bits of the Context Control Word 1, bits [11:10].
• One ‘XOR enable’ bit of the Context Control Word 1, bit [4] (AEAD ciphers only).
The ‘IV’ bits of the input token control word provide for the options identified in Table 16 below. Since the
‘IV format’ options (bits [11:10] in Context Control Word 1) can modify the IV source further, please refer to
Section 7.2.1.1.8.2, “Summary of Possible IV Selection Result Scenarios” following this table.
Note that in addition to the ‘IV format’ field, the IV3 ‘counter value’ may also be modified according to the
‘Crypto Mode’ field setting, (bits [2:0] of Context Control Word 1), by automatically initializing this counter
value to 32’h00000000, 32’h00000001 or 16’h0000. Refer to Section 9.2.
Table 16 Selecting IV Source using Input Token Control Word
Input Token Control IV Field Source Modification

Word bits [28:26] (after initial IV fetch from Context Record)
000 No IV source modification is required. All IV fields reflect the Context Record values.
No IV data taken from the input token or the PRNG.
001 Source all IV fields from the PRNG; if the PRNG is not ready, packet processing must be
held.
010 Source IV3 field from the input token and keep the Context Record values for the
other IV fields.

007-096460-207
011 Source IV3 field from the input token and use PRNG for other IV fields.
100 Source IV0 and IV3 fields from the input token and keep the context values for the
other IV fields.
101 Source IV0 and IV3 fields from the input token and use PRNG for other IV fields.
110 Source IV0 and IV1 fields from the input token and keep the context values for the
other IV fields.
111 Source all four IV fields from the input token.
7.2.1.1.8.2 Summary of Possible IV Selection Result Scenarios

The figures below show how the two ‘IV format’ bits of the Context Control Word 1, bits [11:10] are used
with the three ‘IV’ bits in the first dword of Input Token, bits [28:26] described above, to further modify the
IV source selection, yielding eight possible Result IV scenarios. Some result scenarios can be usefully
extended for the case where the ‘XOR enable’ bit is set, i.e. Context Control Word 1, bit [4] is set to ‘1’, and
a stream cipher is selected.
128-bit IV register
IV0 / Nonce IV1 IV2 IV3
after context load à
128-bit IV register
after Load IV option
(000) with ‘IV format
bits set to:
‘00’:
Full IV mode à
‘01’:
Counter mode à
From context
seq. num. 1 seq. num. 0
byte swap byte swap

‘10’:
Original sequence IV0 Sequence number IV3
number mode à
Incremented
‘11’: byte swap byte swap

Incremented sequence
Number mode à
IV0 Sequence number IV3
(outbound only)
Figure 32 Result IV using IV [2:0] = 3'b000 with IV format [11:10], XOR disabled

007-096460-207
basis:
IV 0 / Nonce IV1 IV2 IV 3
Full IV mode à
From context From context
seq num 1 seq num 0
byte swap byte swap
XOR XOR
RR
128 -bit IV register
(000 ) with ‘IV format
bits set to :
‘01’/’10’:
Original sequence IV0 Sequence number XOR {IV1, IV2} IV 3
number mode à
Figure 33 Result IV using IV [2:0] = 3'b000, IV format [11:10]=’10’, XOR enabled
basis:
IV 0 / Nonce IV1 IV2 IV 3
Full IV mode à
Incremented Incremented
seq num 1 seq num 0
byte swap byte swap
XOR XOR
bits set to :
‘11’:
number modeà IV0 Sequence number XOR {IV1, IV2} IV 3
(outbound only)

007-096460-207
128-bit IV register
128-bit IV register
bits set to:
‘00’:
PRNG output
Full IV mode à
‘01’:
IV0 / Nonce PRNG output IV3
Counter mode à
From context
byte swap byte swap

‘10’:
Original sequence PRNG output Sequence number PRNG output
number mode à
Incremented
byte swap byte swap

‘11’:
Number mode à PRNG output Sequence number PRNG output
(outbound only)
Figure 35 Result IV using IV [2:0] = 3'b001 with IV format [11:10] , XOR disabled
128-bit IV register
128-bit IV register
bits set to:
‘00’:
IV0 / Nonce IV1 IV2 Token IV word
Full IV mode à
‘01’:
IV0 / Nonce IV1 IV2 Token IV word
Counter mode à
From context
byte swap byte swap

‘10’:
Original sequence IV0 / Nonce Sequence number Token IV word
number mode à
Incremented

Number mode à IV0 / Nonce Sequence number Token IV word
(outbound only)

007-096460-207
basis:
IV 0 / Nonce IV1 IV2 Token IV word
Full IV mode à
seq num 1 seq num 0
byte swap byte swap
XOR XOR
RR
bits set to :
‘01’/’10’:
Original sequence IV0 / Nonce Sequence number XOR {IV1, IV2} Token IV word
number mode à
basis:
IV 0 / Nonce IV1 IV2 Token IV word
Full IV mode à
seq num 1 seq num 0
byte swap byte swap
XOR XOR
bits set to :
‘11’:
number modeà IV0 / Nonce Sequence number XOR {IV1, IV2} Token IV word
(outbound only)

007-096460-207
128-bit IV register
128-bit IV register
bits set to:
‘00’:
PRNG output Token IV word
Full IV mode à
‘01’:
IV0 / Nonce PRNG output Token IV word
Counter mode à
From context
byte swap byte swap

‘10’:
Original sequence PRNG output Sequence number Token IV word
number mode à
Incremented
byte swap byte swap

‘11’:
Number mode à PRNG output Sequence number Token IV word
(outbound only)
128-bit IV register
128-bit IV register
bits set to:
‘00’:
1st token IV word IV1 IV2 2nd token IV word
Full IV mode à
‘01’:
Counter mode à
From context
byte swap byte swap

‘10’:
Original sequence 1st token IV word Sequence number 2nd token IV word
number mode à
Incremented

Number mode à 1st token IV word Sequence number 2nd token IV word
(outbound only)

007-096460-207
basis:
Full IV mode à
seq num 1 seq num 0
byte swap byte swap
XOR XOR
RR
bits set to :
‘01’/’10’:
Original sequence 1st token IV word Sequence number XOR {IV1, IV2} 2nd token IV word
number mode à
basis:
Full IV mode à
seq num 1 seq num 0
byte swap byte swap
XOR XOR
bits set to :
‘11’:
number modeà 1st token IV word Sequence number XOR {IV1, IV2} 2nd token IV word
(outbound only)

007-096460-207
128-bit IV register
128-bit IV register
bits set to:
‘00’:
token IV word PRNG output token IV word
Full IV mode à
‘01’:
token IV word PRNG output token IV word
Counter mode à
From context
‘10’:
Original sequence token IV word Sequence number token IV word
number mode à
‘11’: reserved
128-bit IV register
128-bit IV register
bits set to:
‘00’:
token IV word token IV word IV2 IV3
Full IV mode à
‘01’:
token IV word token IV word IV2 IV3
Counter mode à
From context
byte swap byte swap

‘10’:
Original sequence token IV word Sequence number IV3
number mode à
Incremented

Number mode à token IV word Sequence number IV3
(outbound only)

007-096460-207
basis:
Token IV word Token IV word IV2 IV 3
Full IV mode à
seq num 1 seq num 0
byte swap byte swap
XOR XOR
RR
bits set to :
‘01’/’10’:
Original sequence Token IV word Seq nbr XOR {Token IV word, IV2} IV3
number mode à
basis:
Token IV word Token IV word IV2 IV 3
Full IV mode à
seq num 1 seq num 0
byte swap byte swap
XOR XOR
bits set to :
‘11’:
number modeà Token IV word Seq nbr XOR {Token IV word, IV2} IV3
(outbound only)

007-096460-207
128-bit IV register
128-bit IV register
bits set to:
‘00’:
token IV word token IV word token IV word token IV word
Full IV mode à
‘01’:
token IV word token IV word token IV word token IV word
Counter mode à
From context
byte swap byte swap

‘10’:
Original sequence token IV word Sequence number token IV word
number mode à
Incremented
byte swap byte swap

‘11’:
Number mode à token IV word Sequence number token IV word
(outbound only)
basis: Token IV word Token IV word

Token IV word Token IV word
Full IV mode à
seq num 1 seq num 0
byte swap byte swap
XOR XOR
RR
bits set to :
‘01’/’10’:
Original sequence Token IV word Sequence nbr XOR {Token IV word} Token IV word
number mode à

007-096460-207
basis:
Token IV word Token IV word Token IV word Token IV word
Full IV mode à
seq num 1 seq num 0
byte swap byte swap
XOR XOR
bits set to :
‘11’:
number modeà Token IV word Sequence nbr XOR {Token IV word} Token IV word
(outbound only)
7.2.1.1.8.3 XTS tweak load options

In configurations with AES-XTS support, the EIP-96 supports AES-XTS encryption/decryption for the
following use cases:
• Full sector encryption/decryption. All required pre-calculations are performed by the EIP-96.
• Encryption/decryption of 128-bit blocks at the beginning of the sector. The pre-calculations are
performed by the EIP-96 and the result state of the crypto operation is stored in the context for future
continuation.
• Continuation of encryption/decryption of 128-bit blocks in the middle (or at the end) of a sector. The
crypto state is loaded from the context and the block number is provided via the token. After the
operation, the updated crypto state is stored in the context for future continuation. If the operation is
performed on the final part of the sector, it is not needed to save the crypto state.
• When the size of the data block is not a multiple of 16 bytes, CTS is applied. If the packet is smaller than
16 bytes, no CTS is applied and the packet is internally padded with zeroes towards a 16-byte block and
then encrypted/decrypted with XTS. This is because CTS requires at least 17 bytes of data.
If all these use cases share the same key pair (Key 1 and Key 2), only one Context Record needs to be
created and the rest is controlled via the input token.
In Table 17 the XTS loading options are shown. The EIP-96 will use the loaded values to calculate Tj. T0
represents the tweak value for the first data block of a unit with 128-bit tweak ‘i’.

007-096460-207
Table 17 XTS tweak value load options
N Mode Loaded Formal Source

values representation / Context IV [127:0] Token
calculation of Hash (Context or immediate
required Tj Digest 0 Token) [127:0]
1 XTS i and key2 (j=0) T0 = Ekey2(i) Key 2 i 0
2 XTS i, j and key2 Tj = E key2(i)  j Key 2 i j
3 XTS T0 (j=0) T0 - T0 0
4 XTS T0 and j Tj = T0 j - T0 j
5 XTS Tj Tj - Tj 0
6 XTS Tj-1 and 1 Tj = Tj-1 - Tj-1 1
7 XTS Tj-x and x Tj = Tj-xx = T0  j - Tj-x x
Note that the big endian value ‘j’ must be provided in a little endian fashion to the 128-bit immediate field
of the input token, for example a ‘j=1’ should be assigned to bits [127:96] as 0x01000000 and a ‘j’ of
0x12345 should be assigned to bits [127:96] as 0x45230100. The other 96 bits ([95:0]) must be set to zero in
this case).
Only 32 bits of the token immediate field are used to supply ‘j’ so the range of ‘j’ is limited to 232-1. The
specified maximum in IEEE specification for XTS [0] is 2128-2. To use the EIP-96 with a ‘j’ that is larger than
232-1, the host should calculate the intermediate tweak value (Tj = T0 × αj) and load this value as indicated in
the table. When loading a pre-calculated Tweak (Tj) the value of ‘j’ must be set to 0.
If ‘j’ is zero for a specific XTS operation, loading of the 128-bit immediate field from the token can be
skipped since ‘j’ is forced to zero internally. This reduces the size of the input token.
Attention: For XTS when providing a ‘j’, the calculation of Tj on the EIP-96 takes ‘j’ clock cycles. For very
large values of ‘j’ it may be faster to pre-calculate Tj on the host.
7.2.1.1.9 U: Upper layer header function.

This bit must always be set to ‘0’, except for debugging purposes and for support of a few special use cases:
• When using ZUC/SNOW UIA algorithms in combination with non-zero bit alignment, i.e. the data length
is not an exact multiple of bytes. In that case, when the ‘U’ bit is set to ‘1’, the bit alignment must be
provided in bits[2:0] of the checksum value supplied by the token, where the remainder bits[31:3] of
the checksum value and the ‘U’-word must be set to all zeroes.
• If this ‘U’ bit is set to ‘1’, the checksum register in the EIP-96 context space is written with the checksum
value supplied from the token (bits[15:0]). The checksum value in context space can then be used to
either, compare against the checksum in the packet header or it can be inserted in the packet header.
See Sections 8.4.3, INSERT Instruction and 8.4.6, RETRIEVE Instruction.
• When the ‘U’ bit is set, in combination with a selected XL mask (replay protection), bits[23:21] of the
available token word provides the reduced mask selection for the provided inbound packet. The
reduced mask will limit the replay protection to a smaller amount than the originally selected XL mask.
See section 7.2.1.8 and Table 18.
• In addition, when the ‘U’ bit is set, several other bits in the range [31:16] (the ‘U’-word) of the available
token word provide several debugging options when the EIP-96 is embedded in Rambus more complex
packet engines, such as EIP-97 and EIP-197. These bits MUST be set to all zeroes (0x0000), when using
the ‘U’-bit for debugging purposes with the checksum field. Refer to Appendix A.2.4.1 for more
information on the related debugging features.
For information about the ‘U’-word and for examples and more details of these special use cases, refer to
the EIP-96 Operations Manual with Token Examples [2]

007-096460-207
7.2.1.1.10 [31:30]: Reserved bits

The token header word has the two most significant bits reserved, these bits ([31:30]) must be set to ‘00’.
Setting these bits to a non-zero value has effect on processing and can result in corrupted results. Using
non-zero values can result in modifications of the dma_type values for data accesses and can remove a
bypass field in the result token. Alike the ‘U’ bit [29], bit [30] provides a debugging option when the EIP-96 is
embedded in Rambus more complex packet engines, such as EIP-97 and EIP-197.
7.2.1.2 Input packet pointer

(token dword [1], required for standard EIP-96, optional for EIP-96-f)
This is the address used by the standard EIP-96 when setting up a DMA transfer request for reading in data
for the input packet. Depending on the previous DMA request for this packet, the standard EIP-96 will
increment the address by the length of the previous DMA transfer, there addresses increments will be
sequential and it will never skip or re-read any address, see Section 4.3.5.
The EIP-96-f has a FIFO interface, therefore this pointer is not used by the EIP-96-f. The input pointer is
completely ignored by the EIP-96-f, thus this pointer can optionally be removed from the input token for
efficiency. In EIP-96-f configurations the availability of the input packet pointer depends on IP, bit [17], in
the input token header. Refer to Section 7.2.1.1.2 for more details on this bit.
7.2.1.3 Output packet pointer/identifier

Header location:
• If the ‘IP’ bit is set to ‘0’: token dword [2], required;
• If the ‘IP’ bit is set to ‘1’: token dword [1], required.
This is the address used by the standard EIP-96 when setting up a DMA transfer request for writing out data
to the output packet. Depending on the previous DMA actions for this packet, the standard EIP-96 will
increment the address by the length of the previous DMA transfer, see Section 4.3.5.
The EIP-96-f has a FIFO interface, therefore this pointer is not used by the EIP-96-f. The output pointer is not
used as pointer, but it is copied to the result token. It can therefore be used for any purpose, e.g.
identification or allowing the user to move 32-bits of data from the input to the output token without
affecting the processing of the EIP-96-f. The identifier is also made available as a FIFO interface sideband
data output signal, data_out_idf, please refer to Table 11.
In both the input and result token of the standard EIP-96, the output packet pointer/identifier is located on
the third dword location of the token.
Note: If the input packet pointer is not part of the input token (for EIP-96-f configurations with token
header bit [17] set to one) this word is token dword [1])
7.2.1.4 Context data pointer

Header location:
• If the ‘IP’ bit is set to ‘0’: token dword [3], required; and dword [4], optional (if the ‘CP’ bit is set to ‘1’).
• If the ‘IP’ bit is set to ‘1’: token dword [2], required; and dword [4], optional (if the ‘CP’ bit is set to ‘1’).
This is the address used by the EIP-96 when setting up a DMA transfer for reading in context data for the
packet. See Sections 4.3.4/4.3.5 and 4.4.4/4.4.5.
The context data pointer can be 32-bit or 64-bit wide. If 32-bit addressing is used, the context pointer is
located in token dword [3] only. If CP, bit [18] of the token header is set to one, 64-bit context addressing is
enabled, in that case the upper 32-bit of the context address are located in dword [4].
The EIP-96 only sets up one read access for a context, and optionally one or more write accesses, depending
on the number of context update instructions in the token. The EIP-96 will internally add the offset from the
token instruction to the context data pointer to arrive at the right address in the context for context update
operations. The standard EIP-96 uses this address for its external DMA address; the EIP-96-f provides this
address as first data word.

007-096460-207
Note: If the input packet pointer is not part of the input token (for EIP-96-f configurations with token
header bit [17] set to one) this word is token dword [2] and optionally also [3])
7.2.1.5 Context Control Words [1:0]

(optional)
Optionally, the Context Control Words [1:0] may be placed in the token at (depending on ‘IP’ and ‘CP’ bit)
dword location [6:5], or [5:4], or [4:3] respectively. This is selected by setting the ‘C’ field in the first dword
of a token header. Refer to Section 7.2.1.1.7.
7.2.1.6 IV [3:0]
(optional)
Optionally (refer to Table 16), IV [3:0] may be placed in the input token at the next four available dword
locations, [n+3:n], where n is 3, 4, 5, 6 or 7, depending on ‘IP’, ‘CP’ and ‘C’ bit.
7.2.1.7 Checksum
(optional)
Optionally, a 16-bit checksum may be placed in the input token in the lower 16-bit range at the next
available dword location [n], where n in [3:11]. See 7.2.1.1.9.
7.2.1.8 U-word
The EIP-96 engine’s internal static bitmask (currently 1024 bit is supported) is initially written using the
static bitmask fields (lmask0 to lmask 31) of the Context Record during a context fetch operation. The active
bitmask range can then be reduced to a smaller width, according to Table 18, before the internal static
bitmask is actually used with bitmask dependent operations. The bitmask limitation options are described in
this section.
Table 18 Reduced bitmask coding
U-word[23:21] Reduced mask
3’b000 No reduction, keeping original XL mask size

3’b001 64
3’b010 128
3’b011 256
3’b100 512
3’b101 1024
others reserved
Using a reduced bitmask when the Context Record is defined with an XL bitmask has some interesting
consequences:
1. While a packet may be rejected being out-of-window with a “small” reduced mask, it may be accepted
lateron being in-window if a larger or full-sized mask is applied. The rejection will not lead to a mask
update, leaving the bit position as it was.
2. Similarly, while a packet may be rejected being out-of-window with a “small” reduced mask, it may be
rejected for being replayed lateron if a larger or full-sized mask is applied (and the sequence number
was accepted before).
3. Updates of the sequence number may lead to clearing portions of the mask – regardless of which
reduced mask was selected – up to the full-sized mask. So, context updates (of the bitmask) are not
necessarily limited by using a reduced mask.

007-096460-207
Optionally, debugging information may be placed in the input token in the remaining upper 16-bit range, i.e.
bits [31:16], in the dword which is shared with the optional Checksum. Refer to Appendix A.2.4.1 for more
information on the related debugging features.
7.2.1.9 Processing instructions

(1 instruction minimum)
Refer to the following Chapter 8, Processing Instructions, for a detailed discussion and definition of all
Processing Instructions supported by the EIP-96.
7.2.1.10 Bypass token data

(optional)
This field contains data that must be bypassed from the input token to the result token and may have any
length between 0 and 10 dwords. The first bypass data word must contain the bypass opcode.

007-096460-207
8 Processing Instructions
8.1 Instruction Types
There are five types of processing instructions. The first two types (Operational Data and IP Header
Instructions) are executed by the EIP-96 preprocessor and may occur in any order. These preprocessor
instructions create the different data streams for crypt, hash and output.
The third type execute on the result data stream by the EIP-96 post process module. Instructions of Type 3
can be mixed with the Type 1 and 2 instructions. Type 3 instructions can modify or append result data fields
in the output packet.
Note: Types 1, 2, and 3 instructions are also referred to as Data Processing Instructions, since these are
the only instructions “executed” by the pre and postprocessors.
Type 4 instructions are executed by the EIP-96 control module and may only occur after Types 1, 2, and 3
instructions.
Type 5 instructions are also executed by the EIP-96 control module and may occur before or after all the
Types 1, 2, and 3 instructions, which means not in between.
Type 4 and 5 instructions are executed in the control module and do not affect the result data. Only Context
Records and result tokens contain the results of these instructions.
The following subsections group the processing instructions under their appropriate instruction type. Also
shown are the key fields used by each instruction.
8.1.1 Operational Data Instructions (Type 1)

The following operational data instructions are executed by preprocessor:
• DIRECTION,
• PRE_CHECKSUM,
• INSERT,
• INSERT_CTX,
• REPLACE,
• RETRIEVE,
• MUTE.
8.1.2 IP Header Instructions (Type 2)

The following IP header instructions are executed by preprocessor:
• IPV4_CHECKSUM,
• IPV4,
• IPV6.
8.1.3 Postprocess Instructions (Type 3)

After packet processing, the EIP-96 can perform the following instructions:
• INSERT_REMOVE_RESULT,
• REPLACE_BYTE,
• RESERVED.
8.1.4 Result Instructions (Type 4)

• VERIFY_FIELDS
8.1.5 Context Control Instructions (Type 5)

• CONTEXT_ACCESS

007-096460-207
8.1.6 Special Instructions (Type 6)

• BYPASS
8.2 Instruction Sequencing

Token processing instructions are restricted to the sequencing shown below:
Sequencing of Instructions:
Context Control Instructions with the ‘result type’ field equal to ‘00’
(See Note 2)
Data Processing Instructions (Instruction Types 1, 2 and 3)
(See Note 1)
Context Control Instructions with the ‘result type’ field equal to ‘00’
(See Note 2)
Result Instructions (Instruction Type 4)
Context Control Instructions (Instruction Type 5)
Special Instructions (Instruction Type 6)
Notes:
1. Data Processing Instructions are all instructions executed by the pre/post-processor.
2. ‘Result type’ = ‘00’ refers to Context Control Instructions that always execute, and therefore have
their ‘F’ and ‘P’ instruction fields set to ‘0’. (Refer to Section 8.8.). Typical use cases only require
context control instruction at the end of a token after the Result Instructions.
8.2.1 Sequencing Rules

Context Control Instructions may never be mixed with the Data Processing Instructions.
The Result Instructions must be located after the Data Processing Instructions.
A token may contain only one Result Instruction.
Context Control instructions that occur after data processing instructions and before the Result Instruction,
must have field ‘result type’ equal to ‘00’ (execute always). Refer to Section 8.8.
8.3 Instruction Format

The general format of all token processing instructions is described in this section.
Instruction Format
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
opcode instruction dependent fields STAT length / offset
data (optional)
8.3.1 length/pointer
8.3.1.1 length
If a length field applies, indicates the number of bytes that are to be processed by the instruction. For Type
1 instructions, the length field must be greater than zero.
8.3.1.2 offset
If an offset field applies, it is the offset into the output stream. All data bytes are written into the data
stream starting at this offset position.

007-096460-207
8.3.2 STAT
8.3.2.1 STAT definition for Type 1 and 2 instructions
The status field is used to make sure cryptographic and authentication operations are completed. As long as
the status bits are zero, all data streams expect to receive more data after execution of this instruction. If
the hash status bit (bit 17) is set, the current instruction passes the last hash data. If the last data bit (bit 18)
is set, the current instruction has operated on the last data bit from the datapath through the packet-
processing engine.
Encoding of the STAT field for Type 1 and 2 instructions:
00: processing
01: last hash data for hash engine
10: last data for packet processing
11: last hash data for hash engine and last data for packet processing
8.3.2.2 STAT definition for Type 3 instructions

For the Insert result (opcode: 1011) and replace (opcode: 1100) instruction these bits will be used
differently:
If the checksum status bit (bit 17) is set, the modification does not modify the checksum calculated by the
postprocessing.
If the last insert bit (bit 18) is set, this instruction will be the last instruction that inserts data into the data
stream. After execution of this instruction, it is not required for this packet to hold data in the packet buffer.
Encoding of the STAT field for postprocessing instructions:
00: checksum modification and not last insert instruction
01: no checksum modification required
10: last insert header instruction; remaining postprocess instructions are append data
11: no checksum modification required and last ‘insert header’ instruction
The use of the last insert bit (for postprocessing instructions) is optional; it can improve the performance.
8.3.3 instruction dependent fields

The definition of fields within bits [27:19] is dependent on the instruction used. Therefore, for details on
how these bits are used, refer the specific instructions in Section 8.4.
8.3.4 opcode
Each instruction has a unique operation code (opcode). The following table provides a complete list of
instruction operation codes. The opcodes for reserved instructions may not be used.

007-096460-207
Table 19 Instruction Operation Codes
Operation Code Instruction (section) Instruction Type

0000 DIRECTION (8.4.1)
0001 PRE_CHECKSUM (8.4.2)
0010 INSERT (8.4.3)
1001 INSERT_CTX (8.4.4) Operational Data Instruction (Type 1)
0011 REPLACE (8.4.5)
0100 RETRIEVE (8.4.6)
0101 Mute (8.4.7)
0111 IPV4 (with checksum untouched) (8.5.1) IP Header Instruction (Type 2)
0110 IPV4_CHECKSUM (8.5.2)
1000 IPV6 (8.5.3)
1010 INSERT_REMOVE_RESULT (8.6.1) Postprocessing Instruction (Type 3)
1011 REPLACE_BYTE (8.6.1.5)
1100 reserved (8.6.3) n/a
1101 VERIFY_FIELDS (8.7.1) Result Instruction (Type 4)
1110 CONTEXT_ACCESS (8.8.1) Context_Control Instruction (Type 5)
1111 BYPASS_TOKEN_DATA (8.9) Special Instruction (Type 6)
8.3.5 Data (optional)

The data appended to an instruction must be specified in little-endian format. All data words to be inserted
are concatenated after the instruction. The length field indicates the number of bytes that needs to be
inserted into the data stream, which equals the data appended after the instruction in the token.
8.4 Operational Data Instructions

8.4.1 DIRECTION Instruction
This instruction does not modify any data; it only passes a number of bytes to the crypto engine, hash
engine, output buffer, or combinations of these. The ‘length’ field (in bytes) indicates the amount of packet
data to be transferred by this instruction. The ‘t.o.dest.’ field determines the destination(s). The “L” bit can
be used to indicate the last block for the crypto or hash engines; this bit can optionally be used to improve
performance in the case of a block cipher and must be used in case of stream ciphers and GCM.
Attention: Token instructions sending data to the crypto engine (meaning instructions having the crypto
engine bit set in the type of destination field, bit [26] in most instructions) must be following
each other directly. That is, the input to the crypto engine must be provided as a single,
uninterrupted, block of data. There cannot be instructions ‘in between’ sending data to
destinations, other than the crypto engine. The crypto engine cannot handle any data
alignment issues that may occur if intermediate data handling instructions occur between two
instructions targeting the crypto engine.
DIRECTION
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
opcode L t.o.dest. origin STAT length
0 0 0 0 – – – – 0 – – – – – – – – – – – – – – – – – – – – – – –

007-096460-207
length: Refer to Section 8.3.1.1, for a description of this field.

STAT: Refer to Section 8.3.2.1, for a description of this field.
origin: The origin field must be set to ‘00000’. By exception, a value of 01111 can be used for single pass
inbound SSL/TLS/DTLS operations with block ciphers, refer to Section 8.4.8.
t.o.dest.: Type of destination
Table 20 Types of destination
Value Type of destination Use Example

000 reserved n/a
001 output only (for bypass data) IP header
010 hash engine only extended sequence number
011 hash engine and output protocol header
100 crypto engine only n/a
101 crypto engine and output encrypt only payload
110 crypto engine and hash engine n/a
111 crypto engine, hash engine and output ESP payload
L (Last): When the ‘L’ bit is set, and the crypto data bit (bit 26) in the ‘t.o.dest.’ field is also set, then this is
the last crypto data block. In the case of CTR or ICM mode, the ‘L’ bit must be set for the last block; for all
other modes this bit is optional.
When the ‘L’ bit is set, and the hash bit (bit 25) in the ‘t.o.dest.’ field is also set, while the crypto bit (bit26) is
NOT set, then this is the last hash data before crypto data. The ‘L’ bit is only required for a GHASH (GCM)
operation where the AAD data needs to be hashed in a separate operation before the crypto data is hashed.
opcode: Refer to Section 8.3.4, for a description of this field.
8.4.2 PRE_CHECKSUM Instruction

The PRE_CHECKSUM instruction is used to update 16-bit checksums during preprocessing. This instruction is
typically used in performing NAT operations where checksum updating is required to reflect updated IP
addresses or port numbers.
PRE_CHECKSUM
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
opcode L t.o.cmd. origin STAT checksum update value
0 0 0 1 – 1 1 1 0 1 0 1 0 0 0 – – – – – – – – – – – – – – – – –
checksum update value: This value must be the difference between the old checksum value and the new
desired checksum value. The checksum update value is generated as follows:
XOR original values with 0xFFFF (invert). Use this result to perform a 16-bit ‘ADD with carry’ with the
‘checksum update value’ field of the PRE_CHECKSUM instruction. The result of this calculation is then XOR’d
with 0xFFFF and replaces the original value in the data stream.
origin: The origin field must be set to ‘01010’.
t.o.cmd. (type of command): This field must be set to ‘111’.
L (Last): The description for the ‘L’ field is the same as in Section 8.4.1, DIRECTION Instruction.
Note that when PRE_CHECKSUM is used with IP protocol, L is always set to ‘0’, since the checksum is never
last.

007-096460-207
8.4.3 INSERT Instruction

The INSERT instruction is used to insert data into the data stream before the data enters the packet
processing module. The INSERT instruction inserts data from the internal register bank, such as the context
registers or data directly from the token following the instruction (also referred to as an INSERT immediate).
The data source to be inserted is selected by the origin field.
Note that in Table 22, some of the internal registers are ordered to allow multiple fields to be inserted with
one instruction. For example, the registers highlighted in yellow (SPI, sequence number result, and IV0
through IV3) are typically inserted with one instruction.
In addition to inserting data into the data stream, the INSERT instruction can also insert one of several types
of padding, zero padding, PKCS#7, Constant, RTP, IPsec, TLS, SSL, or TFC. Padding is applied if the two most
significant bits of the origin field are set to ‘00’.
INSERT
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
opcode L t.o.dest. padding/origin STAT extended length / insert value length
0 0 1 0 – – – – – – – – – – – – – – – – – – – – – – – – – – – –
length: Refer to Section 8.3.1.1, for a description of this field. Note that when padding is inserted, this field
indicates the total number of the padding bytes.
Example: To add 14 IPsec padding bytes, length field and next header, specify
the length value of 16 (0x10 in hexadecimal). To add 20 bytes of SSL or TLS
padding and length field, specify the length value of 21 (0x15 in hexadecimal).
extended length / insert value: Depending on the value of the padding/origin field, this field is interpreted
as either the ‘extended length’ (the upper 8 bits of the length value) or the ‘insert value’ (the value to be
used for certain padding modes, e.g. Constant, RTP, and SSL.
padding/origin: The INSERT instruction uses the padding/origin field for one of two possible purposes,
padding or origin.
1. Padding Use: MSbs = ‘00’

If the two MSbs, bits [23:22], are ‘00’, then the three LSBs, bits [21:19], indicate the type of padding to be
used.
For Constant, RTP, SSL, IPsec padding: bits [16:9] contain the value that needs to be inserted.
In case of Constant, RTP and SSL padding, the insert value represents the constant padding value. The
location of the inserted value is indicated by the value ‘99’ in the examples below.
For TFC, the full 17 bits are used to indicate the length.
Possible padding values for this field are listed in the following table:

007-096460-207
Table 21 Padding Values for INSERT Instruction
Padding Type Padding Sequence

00000: zero padding 00-00-00-00-00-00
Note: This padding type can also be used to insert a number of ‘0’ bytes (1 to 511) into
the data stream.
00001: PKCS#7 06-06-06-06-06-06
00010: Constant 99-99-99-99-99-99
00011: RTP 99-99-99-99-99-06
00100: IPsec1 01-02-03-04-04-99
(in this case, ‘99’ should contain the NH value from the original datagram)
00101: TLS 05-05-05-05-05-05
00110: SSL 99-99-99-99-99-05
00111: TFC2 00-00-…-00-00-…00-00
The ‘extended length’ field applies to this padding selection.
1
To create a packet that uses IPsec padding filled with zeroes (00-00-00-00-04-NH), two token instructions should
be used:
1. INSERT the SSL pad (length is 4+1=5 bytes), to insert the sequence (00-00-00-00-04)
2. INSERT 1 byte from token, where 1 byte is a NH value.
2
To create a packet that uses TLS1.3 padding filled with zeroes (TB-00-00-00-00), two token instructions should be
used:
1. INSERT 1 byte from token, where 1 byte is a TB value (TLS1.3 inner type byte).
2. INSERT the TFC pad (length is 4 bytes), to insert the sequence (00-00-00-00). Up to 2^14 bytes may be padded.
2. Origin Use: MSbs = not ‘00’

Possible origin values for this field are listed in the following table:
Table 22 ‘Origin’ Field Encoding for Preprocessing Instructions
‘origin’ field INSERT Instruction - Internal Register(s) to be inserted R/W status

value
01000 seq_num result – copy of 10011 R/W
for outbound, this is the incremented result of the sequence number from
context.
01001 extended sequence number result R/W
for inbound, this is an estimation based on sequence number from context
and retrieved sequence number data.
for outbound, this is the incremented result of the 64-bit sequence number
from context.
Note: This origin value should be used for inserting the IPsec extended
sequence number into the data stream for use by the hash engine.
01010 seq_num (from context) R
general purpose register 0 (EIP-96*x and EIP-96*w configurations only) W
01011 extended sequence number (from context) R
01100 seq_num (from context) – copy of 01010 R
01101 general purpose register 3 (EIP-96*x and EIP-96*w configurations only) W
01110 Reserved -
01111 retrieved length correction byte. See Section 8.4.8.1. R
10000 general purpose register 0 R/W
10001 general purpose register 1 R/W
10010 SPI W – SPI result

007-096460-207
if length is 8, SPI and seq_num result is inserted. R – SPI active

if length is 16 or 24, SPI, seq_num result, and IV are inserted.
10011 seq_num result R/W
10100 IV0 – first IV word R/W
10101 IV1 – second IV word R/W
10110 IV2 – third IV word R/W
10111 IV3 – fourth IV word R/W
11000 SPI result register R
11001 checksum – 16-bit checksum value optionally located in the 16 LSBs of input R/W
token.
11010 checksum – 16-bit checksum value (from context) R
checksum – 16-bit calculated checksum value from the checksum registers W
11011 Indicates that this is an ‘INSERT (immediate)’ instruction. See Section -
8.4.3.1.
11100 hash result digest from hash engine. R/W
Note: Can be any length up to 16 dwords (512 bits).
11101 Intermediate inner hash result digest (idigest) from hash engine. Only R
available for HMAC digests precompute operations while using the
CONTEXT_ACCESS instruction, see Section 8.8.1.
Note: Can be any length up to 16 dwords (512 bits).
11110 - 11111 reserved -
If the length exceeds the fields of one origin type, it will continue with the next field that is located on the
next origin location. Be aware that after the fourth hash word, the fifth up to the 16 th hash-word are read.
t.o.dest. - type of destination: The values for the ‘t.o.dest.’ field are the same as those listed in Section
8.4.1, DIRECTION Instruction.
8.4.3.1 INSERT Instruction Example – INSERT (immediate)

The INSERT (immediate) instruction inserts data immediately following the instruction into the data stream.
It is identified by the value ‘5b11011’ in the ‘origin’ field.
INSERT (immediate)
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 0 1 0 – – – – 1 1 0 1 1 – – 0 0 0 0 0 0 0 0 – – – – – – – – –
data
data
length: Refer to Section 8.3.1.1 for a description of this field.

STAT: Refer to Section 8.3.2.1 for a description of this field.
origin: The value of ‘5b11011’ indicates that this is an INSERT (immediate) instruction.
data: Refer to Section 8.3.5 for a description of this field.

007-096460-207
8.4.3.2 INSERT Instruction Example – NOP

The following INSERT instruction can be used as NOP or dummy instruction.
NOP
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
opcode L t.o.dest. padding/origin STAT reserved
0 0 1 0 0 0 0 0 0 0 0 0 0 – – 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0
This instruction does not process any data and takes exactly one clock cycle to process. Note that the
sequencing rules must still be respected and that since the ‘t.o.dest’ is zero (the crypto-bit is not set) the
cryptographic data stream may not be interrupted with this NOP instruction.
8.4.4 INSERT_CTX Instruction

This instruction is intended to insert:
1. Data from token to the output stream, and at the same time, write these data to the Context Record.
2. Data from Context Record to the output stream, and at the same time, write these data to another
location in Context Record.
INSERT_CTX
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
opcode L t.o.dest. origin STAT context dest. reserved length
1 0 0 1 – – – – – – – – – – – – – – – – 0 0 0 0 – – – – – – – –

context_dest: Indicates destination in the Context Record. When this field is zero, no write to the Context
Record is performed.
origin: Indicates origin of data.
t.o.dest: Destination in the datapath.
Note: When using the INSERT_CTX instruction to read fields from the context that were updated by a
previous instruction, another instruction must be used prior to the INSERT_CTX instruction. This
can be any instruction or simply the NOP instruction. This assures that the EIP-96 has time to
commit the updated context values before they can be read.

007-096460-207
8.4.5 REPLACE Instruction

The REPLACE instruction operates similarly to the INSERT instruction, except that it overwrites the input
data in the data stream instead of inserting it. The REPLACE instruction is used to overwrite data in the data
stream before the data enters the packet processing module.
REPLACE
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 0 1 1 – – – – – – – – – – – 0 0 0 0 0 0 0 0 – – – – – – – – –

origin: Refer to the origin field description in Table 22 ‘Origin’ Field Encoding for Preprocessing Instructions.
Origin values 00000-00111, 01100, 01111 and 11101-11111 are not applicable for the REPLACE instruction.
Two additional origins are available for this instruction only.
‘origin’ field value INSERT Instruction - Internal Register(s) to be inserted

01101 Increment current value, one byte from the input data stream is incremented with
‘1’.
“length” field must be set to one (17’h00001) using this origin
01110 Decrement current value, one byte from the input data stream is decremented with
‘1’.
“length” field must be set to one (17’h00001) using this origin
8.4.6 RETRIEVE Instruction

The purpose of the RETRIEVE instruction is to retrieve ‘length’ bytes of data from the input data stream,
starting from the point where the previous instruction stopped processing, and send this data to a different
location or simply removed from the data stream.
Note that these instructions differ from the INSERT_REMOVE_RESULT and instruction that modify the
output data stream (see Section 8.6)
RETRIEVE
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 1 0 0 – – – – – – – – – – – 0 0 0 0 0 0 0 0 – – – – – – – – –

origin: Refer to the origin field description in Table 22 ‘Origin’ Field Encoding for Preprocessing Instructions.
Origin values 00000-00111, 01100-01111 and 11101-11111 are not applicable for the RETRIEVE instruction.

007-096460-207
The following subsections show three examples of the RETRIEVE instruction.
8.4.6.1 RETRIEVE (copy, store, and pass) Instruction Example

This RETRIEVE instruction copies data from the input data stream, stores the data in context registers
(destination register controlled by the ‘origin’ field) and then passes the same data to the processing engine
(under control of the ‘type of destination’ field).
RETRIEVE
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 1 0 0 – – – – – – – – – – – 0 0 0 0 0 0 0 0 – – – – – – – – –
8.4.6.2 RETRIEVE (remove and store) Instruction Example

This RETRIEVE instruction removes data from the input data stream and only stores data in the context
registers. Note that the ‘L’ and ‘t.o.dest.’ fields are set to all zeroes. The origin field is used to indicate which
context registers need to be overwritten.
RETRIEVE
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 1 0 0 0 0 0 0 – – – – – – – 0 0 0 0 0 0 0 0 – – – – – – – – –
8.4.6.3 RETRIEVE (remove only) Instruction Example

This RETRIEVE instruction simply removes data from the input data stream and does not store the data or
pass the data to the processing engine. The ‘L’ and ‘t.o.dest.’ fields are set to zeroes and ‘origin’ field is set
to 11011.
RETRIEVE
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 1 0 0 0 0 0 0 1 1 0 1 1 – – – – – – – – – – – – – – – – – – –
8.4.7 MUTE Instruction

The MUTE instruction performs a bitwise AND of the input data from the packet with the mask data
immediately following the MUTE instruction.
The MUTE instruction typically sends data to two destinations at the same time. This first destination
specified by the ‘t.o.dest.’ field receives the muted version of the data, and the second destination specified
by the ‘t.o.dest.2’ field receives the original, unmuted data. Typically the ‘t.o.dest.’ destination is always set
to ‘010’ (hash engine) and the ‘t.o.dest.2’ destination is always set to ‘001’ (the output data stream).
The length field indicates the number of bytes to be muted, up to 508 bytes. The specified length must be a
multiple of four bytes, (bits [1:0] = ‘00’).

007-096460-207
MUTE
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
opcode r t.o.dest. r t.o.dest.2 M STAT length
0 1 0 1 0 0 – – 0 0 – – 1 – – 0 0 0 0 0 0 0 0 – – – – – – – 0 0
mask0
….
mask(n-1)
length: The length field indicates the number of bytes to be muted, up to 508 bytes. The specified length
must be a multiple of four bytes, (bits [1:0] = ‘00’).
M: Indicates that the mask is appended to the instruction. If M is set to zero, no mask fields are supplied
and the instruction assumes that ‘length’ bytes of zeroes are to be used as mask values. M = ‘0’ could be
used with IPv6 extension headers that contain complete 32-bit words to be muted.
t.o.dest.2 – type of destination 2: The values for the ‘t.o.dest.’ field are the same as those listed in Section
8.4.1, DIRECTION Instruction, except destination to the crypto engine is not allowed (bit [22] must be set to
‘0’). Typically, this field is always set to ‘001’ (output). This destination receives the original, unmuted data.
r: Reserved, set to ‘0’.
8.4.1, DIRECTION Instruction, except destination to the crypto engine is not allowed (bit [26] must be set to
‘0’). Typically, this field is always set to ‘010’ (hash engine). This destination receives the muted version of
the data.
r: Reserved, set to ‘0’.
opcode: Refer to Section 8.3.4 for a description of this field.
mask: The mask data immediately following the MUTE instruction to be used in the bitwise AND operation
with the input packet data. Refer to Section 8.3.5.
Note: If the same value is set for both destination fields, the MUTE instruction will send both muted and
unmuted data to the same destination.
8.4.8 Single pass SSL/TLS/DTLS extensions

The above pre-processor instructions have two additional options that must be used for single pass inbound
SSL/TLS/DTLS operations with block ciphers.
Refer to the EIP-96 Operations Manual with Token Examples [2] for details and SSL/TLS/DTLS token
examples that use these features.
Note: It is not advised to use these features other than for the inbound SSL/TLS/DTLS operations with
block ciphers.
If SSL depadding is selected in the context (bit [13] of context control word 1), it is possible to decrypt bytes
before the actual packet processing. To close the pre-packet decryption, a direction, retrieve or insert
instruction with the ‘L’ bit set to one should be used. In this instruction all ‘t.o. dest’ bits must be set to zero.
The pre-packet decryption operation must be closed in this way to allow proper processing of the actual
packet by resetting the internal cipher state machine and reloading the IV. This feature should only be used
with block cipher operations and not in combination with GHASH.
The second option is applicable if a length value is retrieved by the post-processor, it can be used to
correct/update length fields. When using this option, the retrieved length is stored in a local pre-processor
register and can be used for future corrections. In parallel, the length field of the direction is incremented
with a previously calculated value. This operation is identified by using ‘01111’ instead of zeroes as origin
field in the direction instruction. This special feature should only be used if a length-value is already

007-096460-207
retrieved by the post-processor. If this is not the case, using a non-zero length in the origin field of the
direction instruction will result in unexpected behavior.
This operation is intended to correct the instruction such that only the decrypted payload length is sent to
the hash engine and the decrypted authentication result is retrieved from the packet.
If a length is stored in the pre-processor, the pointer in the IRR instructions that removes data from the
output stream is incremented with the stored value.
8.4.8.1 INSERT Instruction Example – INSERT (retrieved length correction byte)

This special case of the INSERT instruction inserts two bytes into the data stream. These two bytes are the
result of the following calculation.
‘data value’-field from instruction (bits [15:0]) minus retrieved (padding) length from pre-packet operation.
The inserted value is the byte swapped result of the subtraction, where it is forced to zero, when the
subtraction decrements below zero. This option is intended to insert the original payload length of the
SSL/TLS/DTLS packet into the data stream.
This operation is identified by the value ‘5b01111’ in the ‘origin’ field of the insert instruction.
INSERT (corrected length correction byte)
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
opcode L t.o.dest. origin STAT - data value (byte swapped)
0 0 1 0 – – – – 0 1 1 1 1 – – 0 – – – – – – – – – – – – – – – –
The result of the subtraction is not only inserted in the data stream, but also saved into an internal pre-
processor register, such that it can be used by another instruction.

007-096460-207
8.5 IP Header Instructions

There are three IP header instructions.
• IPv4 (with checksum untouched)
• IPv4_CHECKSUM (checksum updated)
• IPv6
All instructions involve only the first words of the IP header. In the case of IPv4, the first three words are
processed by the IP Header instruction, while in the case of IPv6 only the first two words are processed.
8.5.1 IPv4 Instruction

The IPv4 instruction processes the first three words of the IPv4 header and passes them according to the
destination specified in ‘t.o.dest.’ field. It inserts the length and protocol fields of the instruction into the
corresponding fields in the IP header. If the ‘D’ field of the instruction is set to ‘1’, it decrements the IPv4
‘time to live’ field. The Figure 50 illustrates which IPv4 header fields are inserted, updated, or untouched.
IPv4 (with checksum untouched)

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
opcode D t.o.dest. protocol length
0 1 1 1 – – – – – – – – – – – – – – – – – – – – – – – – – – – –
length: The value (in little-endian format) to be placed in the ‘length’ field of the IPv4 header. The IPv4
instruction takes care of the byte swapping.
protocol: The value to be placed in the ‘protocol’ field of the IPv4 header.
t.o.dest.: Destination for the processed header words. The values for the ‘t.o.dest.’ field are the same as
those listed in Section 8.4.1, DIRECTION Instruction.
D – ‘time to live’ decrement: The IPv4 ‘time to live’ value is decremented when ‘D’ is set to ‘1’.
Modifications
4-bits
32-bits
version IHL type of service length
identifier flags fragment offset
time to live protocol checksum
replaced with the value

updated
from the instruction
Figure 50 IPv4 (with checksum untouched) Instruction: datagram modifications

For the complete IPv4 header datagram, please refer to Table 23.

007-096460-207
8.5.2 IPv4_CHECKSUM Instruction

IPv4 checksum instruction processes the first three words of the IP header and passes them according to
the ‘t.o.dest.’ field. It inserts the length and protocol fields of the instruction into the corresponding fields in
the IP header. It also updates the IPv4 checksum and if the ‘D’ field of the instruction is set to ‘1’,
decrements the IPv4 ‘time to live’ field. Figure 51 illustrates which IPv4 header fields are inserted or
updated. Compared to the IPv4 instruction listed in the previous paragraph, the only difference is the
update of the CHECKSUM field.
Note: Please note that this instruction updates the checksum in the IPv4 header based on the original
checksum in the header and the changes of the length, protocol and ‘time to live’ fields. It does
not completely recalculate the IPv4 checksum.
IPv4_CHECKSUM
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
opcode D t.o.dest. protocol length
0 1 1 0 – – – – – – – – – – – – – – – – – – – – – – – – – – – –
length: The value (in little-endian format) to be placed in the ‘length’ field of the IPv4 header. The IPv4
instruction takes care of the byte swapping.
protocol: The value to be placed in the ‘protocol’ field of the IPv4 header.
D – ‘time to live’ decrement: The IPv4 ‘time to live’ value is decremented when ‘D’ is set to ‘1’.
Modifications
4-bits
32-bits
version IHL type of service length
time to live protocol checksum

updated
Figure 51 IPv4_CHECKSUM Instruction: datagram modifications


007-096460-207
8.5.3 IPv6 Instruction

IPv6 instruction processes the first two words and passes them according to the destination specified by the
‘t.o.dest.’ field. It inserts the instruction’s payload length and next header fields in the corresponding fields
of the IPv6 header. The ‘D’ field determines if the IPv6 ‘hop limit’ value is decremented.
Figure 52 illustrates which fields of the IPv6 header are removed, inserted, or updated.
IPv6
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
opcode D t.o.dest. next header payload length
1 0 0 0 – – – – – – – – – – – – – – – – – – – – – – – – – – – –
payload length: The value (in little-endian format) to be placed in the ‘payload length’ field of the IPv6
header. The IPv4 instruction takes care of the byte swapping.
next header: The value to be placed in the ‘next header’ field of the IPv6 header.
D – ‘hop limit’ decrement: The IPv6 ‘hop limit’ value is decremented when ‘D’ is set to ‘1’.
Modifications
4-bits
32-bits
version traffic class flow label
payload length next header hop limit

optionally decremented
Figure 52 IPv6 Instruction: datagram modifications


007-096460-207
8.6 Postprocess Instructions

Postprocessing instructions are used to modify packet data after the packet has been processed by the
packet processing module, see Figure 4. Typically this includes updating packet headers, for example,
inserting the ICV in the AH header or adding/removing data from the packet. Postprocessing instructions
are executed by the postprocessing module.
There are two postprocess instructions, the INSERT_REMOVE_RESULT instruction and the REPLACE_BYTE
instruction.
The REPLACE_BYTE instruction can be used to replace a single byte in the output data stream with a value
from the instruction.
Please note that both instructions have limited functionality in the EIP-96-f small buffer configurations due
to the minimal sized output buffer. These two instructions can only append result data in the EIP-96-f,
where the two instructions can also update fields in the packet in the standard EIP-96 or EIP-96-f with large
buffers.
8.6.1 INSERT_REMOVE_RESULT (IRR) Instruction

The INSERT_REMOVE_RESULT instruction (also referred to as the IRR instruction) can be used as an INSERT
or REMOVE operation. It can take result data from the hash result registers or the status registers and
INSERT (actually replace) this data in the appropriate fields of the output data stream or append it to the
end of the data stream. This same instruction can also be used to REMOVE a hash compare value from the
decrypted data stream starting from any byte.
The IRR instruction functions as a remove_result operation when all of the following fields are set to ‘0’: ‘L’,
‘NH’, ‘CS’ and ‘P’. Otherwise, this instruction functions as an insert_result operation for updating the length,
next header, and checksum fields in IPv4 or IPv6 headers (refer to Section 8.6.1.2).
The IRR instruction is typically used to update certain fields in the output packet with the new values. The
common ‘use case’ is the insertion of the ICV when performing AH outbound operations or updating the IP
header fields when performing ESP inbound (transport and tunnel mode) operations.
However, in the EIP-96-f configurations with small buffers, the IRR instruction is not able to perform
updates of the header data in the output buffer. This logic is disabled for these configurations because of
the minimum sized data output buffer. Instead, the input token must use a special mode of this instruction
to append the data for update to the end of the packet. A module external to the EIP-96-f small buffer
configuration must inspect the output token, which contains information about the data that is appended.
This module must be aware of the protocol ‘use case’ and must replace the required fields using
information from the appended data. These actions are similar to those for ‘jumbo’-frames in the standard
EIP-96. Please refer to the EIP-96 Operations Manual with Token Examples [2] document for the specific AH
outbound and ESP inbound transport and tunnel mode tokens that can be used within the EIP-96-f
configurations.
Using the IRR instruction to remove an encrypted block of zeroes from the output buffer (used in AES-
GCM/GMAC/CCM modes) is not affected in the EIP-96-f and remains the same.
Ordering and alignment of appended data to the output data stream: When using the IRR instruction to
append updated IP header fields to the end of the output data stream, the field order and byte alignment is
fixed. When more than one of the ‘L’, ‘NH’, ‘CS’ fields are to be appended to the data stream, the updated
fields (if selected) will always be appended in the following order: ‘length’ field if selected, then ‘next
header’ field if selected, and finally the ‘checksum’ field if selected. These fields are always appended as 32-
bit dwords with byte alignment within the dword as follows for IPv4:

007-096460-207
MSb Alignment of Appended IP Header Fields (IPv4) LSb

1stappended dword if 16’h0000 ‘total length’ (IPv4)
selected (‘L’== 1’) dword bits [15:0]
2nd appended dword if 16’h0000 ‘protocol’ (IPv4) 8’h00
selected (‘NH’== 1’) dword bits [15:8]
3rd appended dword if 16’h0000 ‘checksum field’ (IPv4 only)
selected(‘CS’== 1’) dword bits [15:0]
For all other cases (IPv6) the alignment is as follows:

MSb Alignment of Appended IP Header Fields (IPv6) LSb
1stappended dword if 16’h0000 ‘payload length’ (IPv6)
selected (‘L’== 1’) dword bits [15:0]
2nd appended dword if 16’h0000 8’h00 ‘next header’ (IPv6)
selected (‘NH’== 1’) dword bits [7:0]
8.6.1.1 INSERT_REMOVE_RESULT Instruction (remove_result operation)

This section describes the INSERT_REMOVE_RESULT instruction functioning as a remove_result operation.
The remove_result operation is specifically used for the removal of the hash result or an encrypted value
(see description of bit 17 of the Context Control Word1 below) from the output data stream, allowing for
the subsequent use of the removed value by the VERIFY_FIELDS instruction. This differs from the RETRIEVE
instruction, which can only extract data from the input data stream.
Note that the postprocessing module can only buffer one instruction at a time; execution of the current
postprocess instructions must be completed before the next instruction can be passed to the
postprocessing module. Therefore, the order of these instructions within the token is important, specifically
in case of the remove_result operation in combination with additional postprocessing instructions.
The remove_result operation needs to wait in the postprocessing module for the actual data to be removed
before passing through this module. The control module continues processing instructions from the token,
but if an additional postprocessing instruction is encountered, further instruction processing in the control
module is halted until the postprocessing module has successfully finished with its current remove_result
operation. Only then can the postprocessor module accept the new postprocessing instruction, allowing the
control module to continue processing.
When constructing tokens, also be aware of the following. The remove_result operation contains an offset
to a location in the packet data stream. If the remove_result operation is provided to the postprocessing
module after this offset location in the data stream has already passed through the postprocessing module,
(for example, due to other instructions blocking further instruction processing), then this outdated
remove_result operation will never trigger. This will prevent the EIP-96 from completing the operation on
the current token, which will cause the EIP-96 to stop processing packets, until eventually the timeout
counter triggers and a result token with error code E14 (refer to Chapter 9, Context ) is returned. Note that
for this error to occur, the timeout counter must be activated.
The remove_result operation is ‘context sensitive’ in the sense that the behavior of the operation changes
depending on the context of the packet currently being processed. The context bit in question is the
‘encrypt hash result’ bit, bit [17] of context control word 1 from the packet context. The reason for this
different behavior is explained as follows:
Context Control Word1, bit 17, encrypt hash result = ‘1’
If this bit is set to ‘1’, the remove_result operation will remove an encrypted value from the data stream. In
this case, the operation is specifically meant for use with GHASH module (used in AES-GCM/GMAC
algorithms) or XCBC module (used in AES-CCM algorithm). Note that the ‘encrypt hash result’ bit may only
be used in combination with one of these modes. Both modes require the result of the hash operation to be
XOR-ed with an encrypted value to generate the actual ICV (integrity check value).

007-096460-207
Therefore, in the case of a GHASH (AES-GCM) or XCBC (AES-CCM) with the ‘encrypt_hash_result’ bit set to
‘1’, the following instructions are used to generate the ICV. Refer to the EIP-96 Operations Manual with
Token Examples [2].
1. A remove_result instruction is used to schedule removal of the first block (16 bytes) of the encrypted
input data and storing it to internal registers, while the rest of the data stream is processed and the
final hash result is calculated. The instruction will be executed after passing all packet data through the
crypto engines.
Note: The first encrypted block cannot be used for encrypting data since doing so would open up the
possibility of an attack on the nonce. Instead, this block is used to encrypt the final hash result.
Note: The ‘length’ field MUST be set to 16 (AES block size) for this mode to operate correctly.
2. The following INSERT instruction is used to pass the first encrypted block to the post processor. This
operation inserts 16 bytes of zeroes (AES block size) and performs an XOR with the first encrypted block
in the data stream. This results in passing the first encrypted block directly to the EIP-96 postprocessor,
for later encrypting (XOR’ing with) the hash result.
Once the final hash result is computed, it is encrypted (XOR-ed with the internally stored encrypted block of
zeroes). This XOR operation is enabled by the ‘encrypt hash result’ bit.
The result digest can be used by subsequent VERIFY_FIELDS or INSERT instructions as usual.
Context Control Word1, bit 17, encrypt hash result = ‘0’
In this case the remove_result operation is used to extract the hash result from the inbound (to be
decrypted) data stream, after decryption by the EIP-96. This is only relevant for protocols that specify the
hash result to be encrypted after the plaintext payload data, such as SSL or TLS.
Note: SSL and TLS require hash-then-encrypt for packet processing, automatically encrypting the hash
result, unlike encrypt-then-hash operation for the IPsec outbound ESP transform.
IRR (remove_result operation)

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
opcode L NH CS length STAT P offset in the output data stream
1 0 1 0 0 0 0 – – – – – – – – 0 – – – – – – – – – – – – – – – –
offset in the output data stream: Removal starts at location specified by offset value in this field. This
pointer is optionally (inbound SSL/TLS/DTLS with block ciphers) incremented internally when length
corrections are applied in the pre-processor. Refer to Section 8.4.8 for more details.
P: The REMOVE_RESULT instruction requires the ‘P’ field to be set to ‘0’.
Length: The ‘length’ field indicates the number of bytes to be removed; this can be 12, 16, 20 or 32 bytes. If
the length field is zero (6’b00_0000): 64 bytes will be removed.
L, NH, CS: The REMOVE_RESULT instruction requires the ‘L’, ‘NH’, and ‘CS’ fields to be set to ‘0’.

007-096460-207
8.6.1.2 INSERT_REMOVE_RESULT Instruction (insert_result operation)

This section describes the INSERT_REMOVE_RESULT (IRR) instruction functioning as an insert_result
operation. In the EIP-96-f configurations with small buffers this instruction can only be used to append data
to the packet for updates before an offset of 255 bytes.
The insert_result operation is typically used to update:
1. length, next header, and checksum fields in IPv4 or IPv6 headers in the output data stream, when
processing an inbound transport mode ESP packet
2. hash result field in AH headers in the output data stream, when processing an outbound mode AH
packet
3. ECN and checksum fields in IPv4 or IPv6 headers in the output data stream, when processing an
inbound tunnel mode ESP packet. Refer to 8.6.1.5 for this special version of IRR.
For details on AH/ESP tunnel/transport mode packets, refer to the list of RFC in Section F.2.
Note: The name of this instruction can be somewhat confusing as it can append, but also replace existing
data from the output data stream. It should not be confused with the REPLACE instruction, which
operates on packet data in input data stream, before the data is submitted to the packet
processing module, or the INSERT instruction, that actually does add data to the input data stream.
The insert_result operation strictly operates on the output data stream, after packet processing.
IRR Instruction (insert_result operation) General Format

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Opcode L NH CS Length STAT P offset in output stream
1 0 1 0 – – – – – – – – – – – 1 – – – – – – – – – – – – – – – –
P: The insert_result operation requires this field to be set to ‘1’.

length: Indicates the hash result length or the relative location of the next header field or the relative
location of the checksum field, if no NH is available. A length of zero (6’b00_0000) is not allowed when
indicating a relative location for next header or checksum.
CS: If set to ‘1’, indicates that the packet header Checksum field needs to be updated to match the actual,
processed, packet.
NH: If set to ‘1’, indicates that the IPv4/IPv6 packet header ‘Protocol’/’Next Header’ field needs to be
updated to match the actual, processed, packet.
L: If set to ‘1’, indicates that the packet header ‘length’ field needs to be updated to match the actual,
processed, packet.
offset in output stream: Indicates the location of the hash result in the packet or the location of the length
field (byte pointer). If bits [15:8] are all set to ‘1’ (0xff) the data is always appended to the end of the packet,
rather than inserted (see Note 2 below). For default aligned appending, the eight least significant bits of the
offset must be set to 0xfe.

007-096460-207
Notes:
1. The insert_result operation should only be used for updating data in (as opposed to after) the
output data stream. If data must be appended due to output buffer overflow, or if instructed by the
‘ToO’ field in the token command word, see Section 7.2.1.1.6, then this is done aligned to a 32-bit
boundary. Also this is done after the packet and the applicable field in the result token are set, even
if the packet data did not end on a 32-bit boundary. Appending (as opposed to updating) hash
result data after the data stream (possibly misaligned), according to the applicable protocol, should
be done using an INSERT or REPLACE instruction (for example, IPsec ESP) with the ‘t.o.dest.’ field
set to ‘output only’.
2. These instructions with the exception of remove_result operation must always be located after the
instruction Types 1 and 2.
3. If used for updating IPv4 fields, it is required that an IPv4_CHECKSUM instruction is performed
earlier, to actually pass an initial checksum value that the new length and protocol (next header)
fields are then added into. This can very well be a dummy IPv4_CHECKSUM instruction, i.e. with
lengh=0 and protocol=0. Refer to 8.5.2 for more information on this instruction.
8.6.1.3 INSERT_REMOVE_RESULT Instruction (insert_result operations):

This section provides the list with INSERT_REMOVE_RESULT (IRR) instructions, to perform the following
specific insert_result operations. The combinations in this list are allowed and result in the correct result
packet length. Other combinations should not be used.
1. Insert hash result (default AH outbound case),
2. Insert length, next header, and checksum (default IPv4 case),
3. Insert modified length and next header without checksum modification (default IPv6 case),
4. Insert length and next header with checksum modification,
5. Insert modified length without checksum modification,
6. Insert next header with checksum modification,
7. Insert next header without checksum modification,
8. Insert next header and checksum,
9. Insert checksum.
Where:
• ‘length’ = IPv4 total packet length
• ‘modified length’ = ‘length’ value modified to equal IPv6 ‘payload length’
• ‘checksum’ = update IPv4 packet header ‘checksum’ field
• ‘checksum modification’ = update internal checksum register only
Note: The inserted length is corrected based on the checksum setting. IPv4 is assumed with checksum
insertion or modification (bit[17] in the IRR instruction set to ‘0’).
8.6.1.3.1 IRR Instruction Example (Insert Hash Result operation)
This operation example inserts the hash result (if available) at the location indicated by the ‘offset in output
stream’ field. The presence of this instruction in the token requires that a previous instruction with the
‘hash done’ bit of the ‘STAT’ field to be set - STAT[0] (bit [17] of a preprocessing instruction). Otherwise, an
error will be generated since the hash operation was not completed. Note that if no hash operation was
specified for the current packet, this operation will insert zeroes in the data stream.
This insert_result operation example is typically used to insert an AH header ICV field in the case of
outbound mode.
IRR Instruction Example (Insert Hash Result operation)

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
opcode L NH CS length STAT P offset in output stream
1 0 1 0 0 0 0 – – – – – – – 1 1 – – – – – – – – – – – – – – – –

007-096460-207
offset in output stream: The location in the output data stream to insert the hash result. If this field is set to
0xfffe, the hash result is appended to the packet. This appending is always 32-bit aligned, regardless of the
byte alignment at the end of the packet. This field may not have any values larger than 0xff00, except for
0xfffe. For packets that do not fit in the EIP-96’s output packet buffer or when using the EIP-96-f with small
buffers, the result is automatically appended to the packet.
P: This operation requires this field to be set to ‘1’.
STAT[0]: This bit must be set to ‘1’. Since this operation does not modify the packet header, it does not
update the internally calculated header checksum. Therefore, the STAT[0] must be set to ‘1’, indicating that
no checksum update is required as a result of this operation.
L, NH, CS: This operation requires the ‘L’, ‘NH’, and ‘CS’ fields to be set to ‘0’.
length: The ‘length’ field indicates the length of the inserted hash result.
Notes: When updating (inserting or appending) a hash result, a length of zero (6’b00_0000) results in an
update of 64 bytes.
• Figure 53 applies to packets that are less than 1792 bytes in length. For larger packets, the 12-byte
ICV field is appended to the packet by default, in which case Figure 54 applies.
Byte alignment within 32-bit words
Bit 31
B8 B9 B10 B11
B2 B3
B6 B7
B3
B2
IP header AH header packet data
B0 B1
B4 B5
B1
B0
Bit 0
Hash result (ICV) calculated by EIP-96 and inserted in the

AH header ICV field (starting with Byte 0)
Figure 53 IPv4 inserted field - insert_hash_result operation - AH header ICV field

Appended Data
ICV
Bit 31
B9 B10 B11
B3
B7
B3
B2
B6
B2
IPv4 header AH header packet data
B1
B5
B1
B0
B4
B8
B0
Bit 0
Hash result (ICV) calculated by EIP-96

(starting with Byte 0)
Figure 54 IPv4 appended field – insert_hash_result_operation – AH header ICV field

007-096460-207
8.6.1.3.2 IRR Instruction Examples (modifying IP header using insert_result operations)

The insert_result operation can also be used to modify IP header fields ‘L’, ‘NH’, and ‘CS’. The following
subsections present IRR Instruction examples that modify the IP header using insert_result operations. Since
these example operations always modify the IP header, updating the internal checksum is always required,
and is enabled by setting the STAT[0] bit to ‘0’ in the instruction.
8.6.1.3.2.1 Insert_Result Operation Example (Insert Length, Next Header and Checksum)
This insert_result operation example is typically used for normal IPv4 header updates, in the case of
inbound ESP transport mode. In this example, each of the ‘L’, ‘NH’, and ‘CS’ fields is enabled, set to ‘1’. The
operation assumes that the ‘next header’ and ‘checksum’ fields are in adjacent fields in the IPv4 header. See
Figure 55. The ‘checksum’ field immediately follows the ‘protocol’ field, which is updated with the next
header value.
This instruction inserts the actual packet length (calculated by the EIP-96 after processing) at the location
indicated by the ‘offset in output stream’ field. The ‘length’ field indicates the positive offset relative to
‘offset in output stream’ field where the next header value is to be inserted (IPv4 ‘protocol’ field); the
checksum is inserted immediately next to this location. The next header value used for the insertion is
retrieved from the padding. See Figure 57.
The inserted checksum is the result of the addition of the current checksum value (calculated so far by the
EIP-96) plus length and next header, where next header is added to the 8 MSbs of checksum. In the IPv4
header, the location of the ‘checksum’ field (immediately adjacent to ‘protocol’ field) and the way the
‘protocol’ field must be added to checksum, is fixed and corresponds to the order of these fields.
In IPv6, this operation updates only ‘payload length’ and ‘next header’ fields. The payload length is inserted
at the location pointed by the ‘offset in output stream’ field. The ‘length’ field must reflect the actual size of
the IPv6 packet header for this packet. The contents of the length field are subtracted from the (EIP-96
internally calculated packet length) in bytes to obtain the actual ‘payload length’ to be inserted in the
header. See Figure 59.
In IPv4 and IPv6, if all bits in the ‘offset in output stream’ field are set to one, the applicable updated fields
are appended to the packet. This appending is 32-bit aligned, regardless of the byte alignment at the end of
the packet.
IRR Instruction Example (Insert Length, Next Header, and Checksum)

In this example, the inserted length is the ‘total length’. This is the ‘result packet length’ field in the result
token. This must be equal to the required value in the IPv4 ‘total length’ field; otherwise the wrong length
will be inserted. Therefore, when inserting data in front of the IP header, make sure that appropriate
postprocessing of the result packet is done to correct the length field (and checksum if needed) in the IP
header.

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 0 1 0 1 1 1 – – – – – – – 0 1 – – – – – – – – – – – – – – – –
offset in output stream: The location in the output data stream to insert the actual packet length calculated
by the EIP-96 after packet processing. If this field is set to 0xfffe, appropriate fields are appended to the
packet. See Figure 58 (IPv4) and Figure 60 (IPv6). This field may not have any values larger than 0xff00,
except for 0xfffe. For packets that do not fit inside the EIP-96’s output packet buffer or when using the EIP-
96-f with small buffers, the result is automatically appended to the packet.
P: This operation requires this field to be set to ‘1’.
STAT[0]: This bit must be set to ‘0’, indicating that a checksum update is required as a result of this
operation.

007-096460-207
L, NH, CS: This operation requires the ‘L’, ‘NH’, and ‘CS’ fields to be set to ‘1’.
length: The ‘length’ field indicates the positive offset relative to ‘offset in output stream’ field where the
next header value is to be inserted; the checksum is inserted immediately next to this location.
4-bits
32-bits
version IHL type of service total packet length
time to live protocol header checksum
source address
destination address
option
payload
Figure 55 IPv4 header datagram
Table 23 Little-endian representation of IPv4 header datagram
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Length byte 1 (LSB) Length byte 0 (MSB) type of service version IHL
frag offset part 1 flags frag off. part 0 identifier byte 1 identifier byte 0
checksum byte 1 checksum byte 0 protocol time to live
source address byte 3 source address byte 2 source address byte 1 source address_0
dest. address byte 3 dest. address byte 2 dest. address byte 1 dest. address byte 0

007-096460-207
4-bits
32-bits
version traffic class flow label
payload length next header hop limit
source address
destination address
payload
Figure 56 IPv6 header datagram
Table 24 Little-endian representation of IPv6 header datagram
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
flow label nibble flow label nibble flow label nibble flow label nibble traffic class flow label nibble traffic class
version
3 4 1 2 nibble 1 0 nibble 0
hop limit next header payload length byte 1 (LSB) payload length byte 0 (MSB)
source address byte 3 source address byte 2 source address byte 1 source address byte 0

007-096460-207

‘protocol’ field updated with instruction ‘next header’ value
Bit 31
B3
check-
length
total
sum
B2
packet data
B1
P
B0 IPv4 header
Bit 0
Start value = instruction ‘length’ field = 6'h07
Start value = instruction ‘offset in output stream’ field = 16'h0002
Figure 57 IPv4 updated fields - insert_result operation - ‘L’, ‘NH’, ‘CS’ and ‘P’ fields selected
Note: Figure 57 applies to packets that are less than 1792 bytes in length (before removing padding) with
standard EIP-96 configurations. For larger packets or with EIP-96-f configurations, updated fields
are appended to the packet by default, in which case Figure 58 applies.
‘protocol’ field updated with instruction ‘next header’ value

Appended Data
Bit 31
B3
16'b00
16'b00
16'b00
B2
IPv4 header packet data
B1 P check-
length
total
sum
B0 8'b0
Bit 0
Actual packet length calculated by EIP-96

Update checksum value calculaed by EIP-96
Figure 58 IPv4 appended updates - insert_result operation - ‘L’, ‘NH’ and ‘CS’ fields selected
Note: Figure 58 applies to packets that are equal to or larger than 1792 bytes in length (before removing
padding) or when using an EIP-96-f configuration. Figure 58 also applies to packets processed with
an insert_result operation with the instruction ‘length’ field = 0xfffe. Appended updated data
always starts on a 32-bit aligned position. See Table 25 below.

007-096460-207
Table 25 32-bit, little-endian representation of appended IPv4 data
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
reserved reserved Length byte 1 (LSB) Length byte 0 (MSB)
reserved reserved protocol reserved
reserved reserved checksum byte 1 checksum byte 0
Bit 31
B3 IPv6 header
payload NH
B2
packet data
B1
length
B0
Bit 0
Start value = instruction ‘offset in output stream’ field = 16'h0004
Figure 59 IPv6 updated fields - insert_result operation - ‘L’, ‘NH’ fields selected and ‘length’ =
0x28
Note: Figure 59 applies to packets that are less than 1792 bytes in length (before removing padding) with
standard EIP-96 configurations. For larger packets or with EIP-96-f configurations, updated fields
are appended to the packet by default, in which case Figure 60 applies. This figure also applies to
packets processed with an insert_result operation with the instruction ‘length’ field = 0xfffe.
Appended updated data always starts on a 32-bit aligned position.
Appended
Data
Bit 31
B3
16'b00
24'b00
B2
IPv6 header packet data
payload
B1
length
B0 NH
Bit 0
‘offset in output stream’ = 16,hFFFE = append

to packet on a 32-bit boundary
Figure 60 IPv6 appended updates - insert_result operation - ‘L’, ‘NH’ fields selected and
‘length’ = 0x28

007-096460-207
Table 26 32-bit, little-endian representation of appended IPv6 data
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
reserved reserved payload length byte 1 (LSB) payload length byte 0 (MSB)
reserved reserved reserved Next header
The following insert-result operation examples are similar to this example with one of more options
disabled. The diagrams above are applicable to the following sections.
If multiple insert_result operations are used and data is appended to a packet, the order of the appended
data will be in the order of the operations in the token.
8.6.1.3.2.2 Insert_Result Operation Example (Insert Modified Length and Next Header with
Checksum Modification)
There is currently no actual ‘use case’ for this operation.
This operation updates the ‘payload length’ field of an IP packet header with the length of the result packet.
The payload length is inserted at the location pointed by the ‘offset in output stream’ field.
This operation updates the ‘next header’ field of an IP packet header. The next header value is retrieved
from the padding and is inserted at the ‘length’ number of bytes from the ‘payload length’ field.
This operation will update the internal checksum value but will not insert the checksum immediately next to
the ‘protocol’ field as is appropriate for IPv4 header. To insert the checksum later, a separate insert_result
operation must be used. Refer to Section 8.8, Insert_Result Operation Example (Insert Checksum).
Example:
To update the ‘length’ and ‘next header’ fields in the IPv4 header located in front of the packet, the ‘offset
in output stream’ field value must be 16h’0002 and ‘length’ field value must be 6h’07 as shows in Figure 57.
Insert Modified Length and Next Header with Checksum Modification

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 0 1 0 1 1 0 – – – – – – – 0 1 – – – – – – – – – – – – – – – –
8.6.1.3.2.3 Insert_Result Operation Example (Insert modified Length and Next Header w/o
Checksum Modification)
This insert_result operation example is typically used to update an IPv6 header in the case of inbound ESP
transport mode.
This operation updates the ‘payload length’ and ‘next header’ fields of an IPv6 packet header. The payload
length is inserted at the location pointed by the ‘offset in output stream’ field. The ‘length’ field must reflect
the actual size of the IPv6 packet header for this packet. The contents of the ‘length’ field are subtracted
from the (EIP-96 internally calculated packet length) in bytes to obtain the actual payload length value to be
inserted in the header. The next header value is retrieved from the padding and is inserted immediately
after the inserted payload length.
The internally calculated checksum is not updated, as indicated by STAT[0] bit set to ‘1’.

007-096460-207
Insert Modified Length and Next Header w/o Checksum Modification

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 0 1 0 1 1 0 – – – – – – – 1 1 – – – – – – – – – – – – – – – –
8.6.1.3.2.4 Insert_Result Operation Example (Insert Next Header and Checksum)

This operation inserts the next header and checksum field. The next header is inserted at the location
pointed by the ‘offset in output stream’ field. The ‘length’ field of the instruction indicates the positive
offset to the checksum in the data stream. The next header value is retrieved from the padding.
This operation updates the internally calculated checksum before inserting the checksum in the data
stream.
Insert Next Header and Checksum

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 0 1 0 1 1 1 – – – – – – – 0 1 – – – – – – – – – – – – – – – –
8.6.1.3.2.5 Insert_Result Operation Example (Insert Modified Length and Checksum)

This operation updates the ‘payload length’ an IPv6 packet header. The payload length is inserted at the
location pointed by the ‘offset in output stream’ field. The ‘length’ field must reflect the actual size of the
IPv6 packet header for this packet. The contents of the ‘length’ field are subtracted from the (EIP-96
internally calculated packet length) in bytes to obtain the actual payload length value to be inserted in the
header.
The inserted checksum is the result of the addition of the current checksum value plus inserted modified
length.
Insert Modified Length and Checksum

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 0 1 0 1 0 1 – – – – – – – 0 1 – – – – – – – – – – – – – – – –
8.6.1.3.2.6 Insert_Result Operation Example (Insert modified Length w/ or w/o Checksum

Modification)
This operation updates the ‘payload length’ an IPv6 packet header. The payload length is inserted at the
location pointed by the ‘offset in output stream’ field. The ‘length’ field must reflect the actual size of the
IPv6 packet header for this packet. The contents of the ‘length’ field are subtracted from the (EIP-96
internally calculated packet length) in bytes to obtain the actual payload length value to be inserted in the
header.
If P is ‘0’ the modification is added to the postprocessing checksum, otherwise (P=1) the modification is
added to the preprocessing checksum and is the postprocessing checksum overwritten with the result.
The STAT[0] field indicates if the internally calculated checksum is updated. If STAT[0] = ‘0’, the internal
checksum register is updated. If STAT[0] = ‘1’, the internal checksum register is not updated.

007-096460-207
Insert Modified Length w/ or w/o Checksum Modification

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 0 1 0 1 0 0 – – – – – – – 0/1 1 – – – – – – – – – – – – – – – –
8.6.1.3.2.7 Insert_Result Operation Example (Insert Next Header w/ or w/o Checksum

Modification)
This operation inserts a next header value at the location pointed by the ‘offset in output stream’ field. The
length field of this instruction can be zero.
If P is ‘0’ the modification is added to the postprocessing checksum, otherwise (P=1) the modification is
added to the preprocessing checksum and is the postprocessing checksum overwritten with the result.
The STAT[0] field indicates if the internally calculated checksum is updated. If STAT[0] = ‘0’, the internal
checksum register is updated. If STAT[0] = ‘1’, the internal checksum register is not updated.
Insert Next Header w/ or w/o Checksum Modification

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 0 1 0 0 1 0 – – – – – – – 0/1 1 – – – – – – – – – – – – – – – –
8.6.1.3.2.8 Insert_Result Operation Example (Insert Checksum)

This operation inserts checksum field. The checksum is inserted at the location pointed by the ’offset in
output stream” field.
The inserted checksum is the result of the addition of the current checksum plus inserted fields before this
instruction.
Insert Checksum
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 0 1 0 0 0 1 – – – – – – – 0 1 – – – – – – – – – – – – – – – –
8.6.1.4 Summary append options

Since the appended data is not included in the packet length of the result token, these lengths can vary. The
total amount of appended data can be the sum of the number of appended hash bytes, together with the
appended individual words (Length, NH, Checksum, BYTE). However in the typical use cases these will never
be available together. The BYTE appending is typically only used for debugging purposes and will not be
used in practice.
Only for ESP inbound transport mode with IP header processing or AH outbound operations data needs to
be appended. For ESP inbound the appended fields are either: Length, NH and Checksum (IPv4) or Length
and NH (IPv6), meaning at most 3 words (12-bytes) are appended.
For AH outbound operations the hash result needs to be appended. The length can vary, dependent on the
algorithm. The next table shows the default ICV lengths for AH operations

007-096460-207
Table 27 Typical ICV lengths for authentication operations with IPsec
Algorithm IANA string Length (in bytes)

MD5 AUTH_HMAC_MD5_96 12
SHA-1 AUTH_HMAC_SHA1_96 12
GMAC AUTH_AES_xxx_GMAC 16
SHA2-256 AUTH_HMAC_SHA2_256_128 16
Summarized it means that the maximum length of appended data is 4 words for EIP-96i and EIP-96is
configurations and 8 words for the EIP-96ie and EIP-96ies configurations. For the latter two the maximum is
also 4 when SHA2-384/512 are not used with HMAC. Also, for these typical uses cases only one IRR
(insert/append result instruction) is required.
Since the data is appended aligned to a 32-bit word the length in the length field of the result descriptor is
at most 35 bytes less than the amount of written output bytes, assuming these standard use cases.
8.6.1.5 INSERT_REMOVE_RESULT Instruction (ip_tunfix operation)

This section describes the INSERT_REMOVE_RESULT (IRR) instruction functioning as an ip_tunfix operation.
The ip_tunfix operation is typically used to update ECN and - consequently - checksum fields in
decapsulated IPv4 or IPv6 headers in the output data stream, when processing an inbound tunnel mode ESP
packet. The effect of the operation depends on the static register settings of EIP96_ECN_TABLE and
EIP96_ECN_ERR_CFG, refer to Section C.4.
For details on ESP tunnel mode packets, refer to [RFC6040].
IRR Instruction (insert_result operation) General Format
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Opcode L NH CS Length STAT P offset in output stream
1 0 1 0 0 1 – 0 0 0 0 E1 E0 – – 0 – – – – – – – – – – – – – – – –
P: The ip_tunfix operation requires this field to be set to ‘0’.

length: The lowest two bits of the length field are used to indicate the value of the 2 outer ECN bits (E1,
E0), which are found by external outer header parsing. The upper 4 bits of the length field are reserved and
must each be set to ‘0’.
CS: If set to ‘1’, and the inner header is detected to be IPv4, this indicates that the IPv4 packet header
Checksum field needs to be updated to match the actual, processed, packet. Note that this is performed in
the output buffer, so the checksum update may be appended 'as usual' for packets that do not fit into the
output buffer (with the apropriate 'C' bit set in the result token).
If the inner header is not IPv4, the CS bit is ignored.
Note that the IPv4 packet header Checksum is updated in case the ECN bits of the inner IP header are
changed.
NH: If set to ‘1’, indicates that the ECN bits from the instruction (E1, E0) will be combined with the inner IP
header ECN bits extracted from the TOS byte lower 2 bits (for IPv4) or bits [5:4] for IPv6, according to the
table programmed into the EIP96_ECN_TABLE registers. This same table provides the (programmable) CLE
errorcode for any combination of inner and outere ECN bits, which is placed in the CLE field in the result
token.
L: Must be set to ‘0’.
offset in output stream: Indicates the location of the first byte of the inner IP header in the output stream.

007-096460-207
Notes:
1. When the IP_TUNFIX instruction determined that the inner IP header is NOT an IPv4 or IPv6 header
(based on the IP header version field in bits [7:4] of the first byte of the header, this should be 4 for
IPv4 and 6 for IPv6), it will NOT do any updates. This is optionally reflected by a CLE errorcode in
the result token, depending on the settings in the EIP96_ECN_ERR_CFG register.
2. This instruction must always be located after the instruction Types 1 and 2.
8.6.2 REPLACE_BYTE Instruction

The REPLACE_BYTE instruction overwrites one byte of data in the output data stream. The byte used to
overwrite is located in the instruction’s ‘data byte’ field. The byte to be overwritten is located by the ‘offset
in output stream’ field.
The REPLACE_BYTE instruction can also be used to append one byte of data in the output data stream. This
is done by setting the ‘offset in output stream’ field to 0xFFFE. In this case, a full dword is appended to the
output data stream with the instruction’s ‘data byte’ field located in bits [7:0] of the dword, with dword bits
[31:8] set to zero. Note also that the ‘B’ bit in the result token will be set, indicating that the data is
appended.
Please note that in the EIP-96-f small buffer configurations only the latter option of this instruction is
available. The REPLACE_BYTE instruction can only be used to append a single byte due to the limited output
buffer size.
REPLACE_BYTE
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
opcode data byte D STAT R offset in output stream
1 0 1 1 – – – – – – – – 0 – – 0 – – – – – – – – – – – – – – – –
offset in output stream: The offset to the data byte in the output data stream to be overwritten.
R: When set to ‘0’, this instruction is a REPLACE_BYTE instruction.
D: dummy, reserved. Set to ‘0’.
data byte: The byte of data to be used to overwrite a byte in the output data stream or appended to the
data stream.
8.6.3 Reserved Instructions

The opcodes for reserved instructions may not be used.
RESERVED
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
opcode
1 1 0 0 – – – – – – – – – – – – – – – – – – – – – – – – – – – –

007-096460-207
8.7 Result Instructions

The VERIFY_FIELDS Instruction is currently the only Result instruction.
8.7.1 VERIFY_FIELDS Instruction

This instruction verifies Context Record fields or other retrieved values against other retrieved or calculated
values. These values can be the hash result, padding, checksum, SPI, or sequence number. Comparison of
retrieved, calculated and/or context values can only be done for inbound packets, or for detection of
Sequence Number Rollover in case of outbound packets.
The VERIFY_FIELDS instruction must always be the last instruction after data processing instructions. It
cannot be followed by additional data processing instructions. It can only be followed by a Context Control
Instruction.
This instruction is responsible for generating error codes E9 through E13. See Table 34 for error code
descriptions. If no VERIFY_FIELDS instruction is used, these error conditions are not detected.
VERIFY_FIELDS
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
opcode S SP CS P reserved STAT H length
1 1 0 1 – – – – – – – – – 1 1 0 0 0 0 0 0 0 0 0 0 – – – – – 0 0
length: Indicates the number of hash result bytes that needs to be compared, valid values are:
0001100: 12 bytes
0010000: 16 bytes
0010100: 20 bytes (SHA-1, SHA-2, SHA-3 and SM3 only)
0011000: 24 bytes (SHA-2, SHA-3 and SM3 only)
0110000: 48 bytes (SHA-2 and SHA-3 only)
1000000: 64 bytes (SHA-2 and SHA-3 only)
H: Set this bit to ‘1’ to verify the hash result.
STAT: This field must always be set to ‘11’.
reserved: Reserved. These bits should be set to ‘0’.
P: Set this bit to ‘1’ to verify padding. (Set to ‘1’ only if the padding type allows verification.)
CS: Set this bit to ‘1’ to verify the checksum.
SP: Set this bit to ‘1’ to verify the retrieved SPI.
S: Set this bit to ‘1’ to verify the sequence number. Refer to Appendix B.4.3 ‘Sequence number check’.

007-096460-207
8.8 Context Control Instructions

The CONTEXT_ACCESS Instruction is currently the only Context Control instruction.
8.8.1 CONTEXT_ACCESS Instruction

The CONTEXT_ACCESS instruction is used to update fields in the external Context Record. The ‘offset’ field is
an external relative offset pointing to the base address of the Context Record. The ‘origin’ field a second
offset pointing to the internal field(s) that need to be updated.
In IPsec, this instruction is typically used to update the ‘sequence number’ of the Context Record, and, for
an inbound packet, the ‘sequence number mask’ fields. Optionally, the IV fields can also be updated using a
separate CONTEXT_ACCESS instruction.
If XL masks are part of the Context Record, updating the entire mask might be costly in processing time, so
the instruction allows skipping the update for some parts of the mask which are unchanged. The EIP-96
computes the skipping regions internally.
Moreover, the actual length of the XL mask can’t be fitted in the 4-bit length field, so a special coding of the
length is applied in case of XL masks, see its definition below.
For HMAC digests precomputing, available as a single-pass operation, this instruction is used to update the
inner and outer digests of the Context Record, where one CONTEXT_ACCESS instruction is used to copy the
inner digest from the temporary digest location with origin = b11101, and a second CONTEXT_ACCESS
instruction is used to copy the outer digest from the digest result location with origin = 0b11100.
The CONTEXT_ACCESS instruction is only executed after all EIP-96 processing completes (preprocessing,
packet engine processing and postprocessing), unless both the ‘F’ and ‘P’ fields are set to zero, in which case
the CONTEXT_ACCESS instruction can be executed at any time.
Using the ‘F’ and ‘P’ fields (together referred to as the ‘result type’ field) the CONTEXT_ACCESS instruction
can be selectively executed if a packet passes or fails. If the ‘result type’ field is set to ‘01’, the instruction
will be executed if the packet passed. If the ‘result type’ field is set to ‘10’, the instruction will be executed if
the packet failed.
CONTEXT_ACCESS
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
result
type
opcode length origin STAT res U F P D reserved offset
1 1 1 0 – – – – – – – – – – – 0 0 – – – – 0 0 0 – – – – – – – –
data (optional), max = 1 dword
Offset: The (32-bit word) offset in the Context Record.

reserved: Reserved bits must be set to ‘0’.
D: Direction. In the EIP-96 this bit MUST be set to '1', this indicates the CONTEXT_ACCESS instruction results
in the EIP-96 updating the external Context Record, also known as a ‘context write’ operation to the
external Context Record.
Note: In standard (protocol) scenarios the ‘context read’ operation (D-bit set to zero) is not used. In the
EIP-96-cf configurations only ‘context write’ operations are allowed. The ‘context read’ operations
should not happen to make sure that there are only sequential fetches from the context input FIFO
that are initiated by the EIP-96-cf itself.

007-096460-207
F and P: Fail and Pass bit combinations. Together, these bits are also referred to as the ‘result type’ field.
00: Execute the CONTEXT_ACCESS instruction immediately. When both bits are set to ‘00’,
this instruction can be executed anytime, even before packet processing.
When the token header word has the ‘CT’ bit set to ‘1’, all instructions with F and P set to
‘00’are ignored and therefore not executed. Setting ‘CT’ to ‘1’ results in an autonomous
sequence number update, initiated and controlled by the EIP-96. For outbound
operations with the ‘CT’ bit set to ‘1’ the sequence number update instruction is not
required, however when it is available, it must have the F and P bits set to ‘0’.
01: Execute the CONTEXT_ACCESS instruction only if all EIP-96 processing has completed
successfully, (without errors).
10: Execute the CONTEXT_ACCESS instruction only if all EIP-96 processing has completed
unsuccessfully. In this case, the VERIFY_FIELDS instruction resulted in one of more of the
following errors: error codes E9 through E13; see Table 34 for error code descriptions.
Executing the CONTEXT_ACCESS instruction in these cases could be useful in debugging or
keeping statistical data.
11: Execute the CONTEXT_ACCESS instruction only if all EIP-96 processing has completed,
successfully or unsuccessfully.
U: – Use token data when processing this instruction. There can only be one dword of data immediately
following the token instruction. The ‘origin’ field must be set to ‘11011’ and ‘length’ field must be ‘0001’ in
this case.
res: Reserved, must be set to ‘00’.
STAT: = 11 – last instruction, the use of this field is optional, except when enabling the ‘CT’ bit in the token
header. If the ‘CT’-bit in the token header is set to ‘1’, the use of the STAT bits for context update
instructions is required. If a token must execute non-sequence number related updates, these must be done
with STAT bits set to ‘00’. For inbound operations, the sequence number and mask update instruction must
be the last instruction and must have STAT bits set to ‘11’.
origin: The ‘origin’ field is an offset pointing to the internal Context Record field(s) that need to be updated.
All internal registers can be read for insertion into the external Context Record. Note that only general-
purpose, IV, sequence number (and mask) internal registers are writable using this instruction. Typically,
only read actions are required to update the external Context Record.
Note that in Table 28, some of the internal registers are ordered to allow multiple fields to be inserted with
one instruction. For example, the registers highlighted in yellow (sequence number result and sequence
number mask, or IV0 through IV3) are typically written to the external Context Record with one instruction.
Table 28 ‘Origin’ Field Encoding for CONTEXT_ACCESS Instruction
‘origin’ field value Context Record Fields

00000 Reserved
00001 Reserved
00010 Reserved
00011 Reserved
00101 sequence number
00110 sequence number mask (length can be 2 or 4)
00111 reserved (sequence number mask 2nd word)
01000 reserved (sequence number mask 3th word)
01010 sequence number 1,2
01011 extended sequence number
01100 sequence number mask (length can be 2 or 4)
01101 reserved (sequence number mask 2nd word)

007-096460-207
10000 sequence number (for automatic writing only) 1,2

10001 reserved (extended sequence number (for automatic writing only))
10010 general purpose register 0 (note: different origin compared to INSERT
instr.)
10011 general purpose register 1 (note: different origin compared to INSERT
instr.)
10100 IV0
10101 IV1
10110 IV2
10111 IV3
11000 hash result count
11001 ARC4 I/J-pointer (EIP-96is / EIP-96ies)
11010 ARC4 State Record (EIP-96is / EIP-96ies)
length is don’t care and will be forced to 64 (32-bit words)
offset is don’t care and will be ignored:
External DMA address is the ARC4 State Record pointer from the Context
Record
11011 from token (see U, bit #15)
11100 hash result digest from hash engine.
Note: Can be any length up to 16 dwords (512 bits). 3
11101 Intermediate inner hash result digest (idigest) from hash engine. Only
available for HMAC digests precompute operations while using the
CONTEXT_ACCESS instruction.
Note: Can be any length up to 16 dwords (512 bits). 3
11110 Reserved
11111 Reserved
1
If an extended context format (with large sequence number mask Ext_CTX_Format) is selected, the sequence
number and mask are located at the end of the Context Record. In that case these origins automatically translate
the access to these locations. Consequently, an update with a length larger than 6 context words will result in
reading additional sequence number mask words beyond the 4th mask word, upto the 8th mask word (for 256-bit
masks) or the 12th mask word (for 384-bit masks). The maximum value of the length field, when using these
origins, (default=01010) is 14.
2
Also if an XL context format (with large sequence number mask Ext_CTX_Format) is selected, the sequence
number and mask are located at the end of the Context Record. The update length of the (sequence number
and) XL mask however does not fit in the 4-bit length field of the instruction. In that case the length value may
be set to 0, and is automatically translated to the maximum required length, depending on which parts of the
mask are updated. If the length value is set to 15, the full mask is updated, regardless of which mask bits require
updating.
3
If the selected ‘origin’ field is hash result digest (11100) or hash idigest (11101), a length of 16 exceeds the width
of the length-field. To achieve an update with length 16 (for SHA-512): a length of ‘0’ must be selected in the
instruction. This results in a transfer length of 16 (32-bit) words. This latter option is only available in the EIP-
96ie* configurations (that include SHA-512).
length – The ‘length’ field indicates the number of dwords that need to be transferred. For XL masks
(defined by the setting in CCW0, see 9.2) a special coding for this field is devised: length = ‘1111’ will result
in a full XL mask transfer; length = ‘0000’ will result in an optimized transfer of changed mask words, with
possibly some overhead of unchanged mask words. The optimized transfer might even split the mask
transfer in upto 2 separate DMA’s instead of a single DMA, for wide apart changed mask words – but it is
still implemented as an atomic action to make sure the integrity of the mask update is preserved.

007-096460-207
8.9 Bypass Token Data – Special Instruction

It is possible to append token data to the result token without observation by the EIP-96. This special
instruction can be used to bypass data from the input token through to the result token. If used, it must
always be the last instruction.
This data stream must start with four bits set to one (opcode). As a result, only 28 bits are available in the
first dword. The maximum length is 10 dwords, including the opcode bits, or 12 dwords in the case that no
sequence number is appended. The actual length is retrieved from the token length. All token data after
seeing the BYPASS_TOKEN_DATA opcode (‘1111’) is considered as token bypass data until the end of the
token, unless the seq_append bit is set, see 9.2.1. The end of the token is automatically detected via the
token interface.
BYPASS_TOKEN_DATA
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
opcode data
1 1 1 1 data (28 bits only)
data (optional), maximum of 11 dwords beyond the initial 28 bits above

007-096460-207
9 Context Record
9.1 Context Record Format
The context data contains processing parameters and keying data. The first two words of the Context
Record contain the options and information about the available fields in the Context Record. The sequence
of fields within a Context Record is fixed, however; when the Context Fetch Mode is set to Control Mode
not all fields are needed (see also Appendix C.1.2.1). The length of some fields is variable. For example, the
length of the inner and outer digest registers indicated by Word k, Word l, depends on the selected options
and algorithms in the first two context words (Context Control Words 0 and 1).
Table 29 describes the default Context Record Address Map for use when Context Fetch Mode is set to
Address Mode. Note that this Context Record is 0x35 words (53 decimal) in length. Table 31 describes an
example Context Record used with Context Fetch Mode set to Control Mode.
Note: All Context Record fields that represent integer values are to be specified in little-endian format.
Therefore, the least significant bit of the value must end up at the bit location with the lowest
index. The following fields are treated as integers: context_length in Context Control Word 0,
digest_cnt, SPI, and sequence number.
Table 29 Context Record Address Map for Context Fetch Mode = Address Mode
Word# Name Description Addr1

Basic Basic Large Large Large
Ext Ext1 Ext2
Word 0 Control Word 0 Processing control word 0x00 0x00 0x00 0x00 0x00
(Can optionally be placed in token
In this case, this field is not used.)
Word 1 Control Word 1 Processing control word 0x01 0x01 0x01 0x01 0x01
(Can optionally be placed in token
In this case, this field is not used.)
Word 2 Key 0 All crypto algorithms 0x02 0x02 0x02 0x02 0x02
Word 3 Key 1 All crypto algorithms 0x03 0x03 0x03 0x03 0x03
Word 4 Key 2 3 0x04 0x04 0x04 0x04 0x04
3DES / AES / SM4 / BC0 / ARC4 /
ChaCha20 / Kasumi / SNOW / ZUC
Word 5 Key 3 3DES / AES / SM4 / BC03 / ARC4 / 0x05 0x05 0x05 0x05 0x05
ChaCha20 / Kasumi / SNOW / ZUC
Word 6 Key 4 3DES / AES{192,256} / BC03 / 0x06 0x06 0x06 0x06 0x06
ChaCha20
Word 7 Key 5 3DES / AES{192,256} / BC03 / 0x07 0x07 0x07 0x07 0x07
ChaCha20
Word 8 Key 6 AES{256} / BC03 / ChaCha20 0x08 0x08 0x08 0x08 0x08
Word 9 Key 7 AES{256} / BC03 / ChaCha20 0x09 0x09 0x09 0x09 0x09
Word k Digest 0_0 / All hash algorithms 0x0A 0x0A 0x0A 0x0A 0x0A
(k <= 10) K2_0 / (other/XCBC/GHASH)
H_KEY_0
Word k+1 Digest 0_1 / All hash algorithms 0x0B 0x0B 0x0B 0x0B 0x0B
K2_1 / (other/XCBC/GHASH)
H_KEY_1
Word k+2 Digest 0_2 / All hash algorithms 0x0C 0x0C 0x0C 0x0C 0x0C
H_KEY_2
Word k+3 Digest 0_3 / All hash algorithms 0x0D 0x0D 0x0D 0x0D 0x0D
H_KEY_3

007-096460-207

Ext Ext1 Ext2
Word k+4 Digest 0_4 / SHA1 / SHA24 / SM3 / XCBC / 0x0E 0x0E 0x0E 0x0E 0x0E
K3_0 HMAC SHA34 / Keyed-hash SHA34
Word k+5 Digest 0_5 / SHA24 / SM3 / XCBC / 0x0F 0x0F 0x0F 0x0F 0x0F
Word k+6 Digest 0_6 / SHA24 / SM3 / XCBC 0x10 0x10 0x10 0x10 0x10
Word k+7 Digest 0_7 / SHA24 / SM3 / XCBC / 0x11 0x11 0x11 0x11 0x11
Work k+8 Digest 0_8 SHA-384/512 / XCBC6 / - - 0x12 0x12 0x12
HMAC SHA34 / Keyed-hash SHA34
Work k+12 Digest 0_12 SHA-384/512 / - - 0x16 0x16 0x16
Word l Digest 0_16 / HMAC MD5, SHA1, SHA24, SM3 / 0x12 0x12 0x1A 0x1A 0x1A
Digest 1_0 / basic hash / XCBC4 / Poly1305 /
digest_count5 / HMAC SHA34 / Keyed-hash SHA34
K1_0
Word l+1 Digest 0_17 / HMAC MD5, SHA1, SHA24, SM3 / 0x13 0x13 0x1B 0x1B 0x1B
Digest 1_1 / XCBC4 / Poly1305 /
Word l+2 Digest 0_18 / HMAC MD5, SHA1, SHA24, SM3 / 0x14 0x14 0x1C 0x1C 0x1C
K1_2 HMAC SHA3-224/256/384 /
Keyed-hash SHA3-224/256/384
Word l+3 Digest 0_19 / HMAC MD5, SHA1, SHA24, SM3 / 0x15 0x15 0x1D 0x1D 0x1D
K1_3 HMAC SHA3-224/256/384 /
Word l+4 Digest 0_20 / HMAC SHA1, SHA24, SM3 / 0x16 0x16 0x1E 0x1E 0x1E
Digest 1_4 / XCBC 192/256 / Poly1305 /
K1_4 HMAC SHA3-224/256/384 /
Word l+5 Digest 0_21 / HMAC SHA24, SM3 / 0x17 0x17 0x1F 0x1F 0x1F
Digest 1_5 / XCBC 192/256 / Poly1305 /
K1_5 HMAC SHA3-224/256/384 /

007-096460-207

Ext Ext1 Ext2
Word l+6 Digest 0_22 / HMAC SHA24, SM3 / 0x18 0x18 0x20 0x20 0x20
Digest 1_6 / XCBC 192/256 / Poly1305 /
K1_6 HMAC SHA3-224/256/384 /
Word l+7 Digest 0_23 / HMAC SHA24, SM3 / 0x19 0x19 0x21 0x21 0x21
Digest 1_7 / XCBC 192/256 / Poly1305 /
K1_7 HMAC SHA3-224/256/384 /
Word l+8 Digest 0_24 / HMAC SHA2-384/512 / - - 0x22 0x22 0x22
Digest 1_8 HMAC SHA3-224/256/384 /
Digest 1_9 HMAC SHA3-224/256/384 /
Digest 1_10 HMAC SHA3-224/256/384 /
Digest 1_11 HMAC SHA3-224/256 /
Keyed-hash SHA3-224/256
Word l+16 Digest 0_32 HMAC SHA3-224/256 / - - - - 0x2A2
Word l+17 Digest 0_33 HMAC SHA3-224/256 / - - - - 0x2B2
Word l+18 Digest 0_34 HMAC SHA3-224 / - - - - 0x2C2
Keyed-hash SHA3-224
Word l+19 Digest 0_35 HMAC SHA3-224 / - - - - 0x2D2
Keyed-hash SHA3-224
Word m SPI / Version IPsec / SSL,TLS,DTLS 0x1A 0x1A 0x2A 0x2A2 -2
(m <= 26) (upper 2B)
Word n seq. number 0 IPsec / SSL,TLS,DTLS 0x1B 0x20 0x2B 0x30 0x30
(n <= 27)
Word n+1 seq. nbr 1 IPsec with ext. seq. nbrs / 0x1C 0x21 0x2C 0x31 0x31
(extended) SSL,TLS,DTLS
Word n+2 SN mask 0 IPsec inbound 0x1D 0x22 0x2D 0x32 0x32
Word n+3 SN mask 1 IPsec inbound 0x1E 0x23 0x2E 0x33 0x33
Word n+4 SN mask 2 IPsec inbound with ext. seq. 0x1F 0x24 0x2F 0x34 0x34
numbers
Word n+5 SN mask 3 IPsec inbound with ext. seq. 0x20 0x25 0x30 0x35 0x35
numbers

007-096460-207

Ext Ext1 Ext2
Word n+6 SN mask 47 IPsec inbound with ext. seq. - 0x26 - 0x36 0x36
numbers
numbers
numbers
numbers
Word n+10 SN mask 88 IPsec inbound with ext. seq. - 0x2A - 0x3A 0x3A
numbers
Word n+11 SN mask 98 IPsec inbound with ext. seq. - 0x2B - 0x3B 0x3B
numbers
Word n+12 SN mask 108 IPsec inbound with ext. seq. - 0x2C - 0x3C 0x3C
numbers
Word n+13 SN mask 118 IPsec inbound with ext. seq. - 0x2D - 0x3D 0x3D
numbers
Word n+14 SN mask IPsec inbound with ext. seq. - 0x2E.. - 0x3E.. 0x3E..
.. n+33 12 .. 319 numbers 0x41 0x51 0x51
Word p IV 0 / NONCE Optional for all crypto operations. 0x21 0x1B 0x31 0x2B2 -2
(p <= 33) Can optionally be placed in token.
Word p+1 IV 1 Optional for all crypto operations. 0x22 0x1C 0x32 0x2C2 -2
Can optionally be placed in token.
Word p+2 IV 2 Optional for all crypto operations. 0x23 0x1D 0x33 0x2D2 -2
Word p+3 IV 3 Optional for all crypto operations. 0x24 0x1E 0x34 0x2E2 -2
Word q ARC4 State Optional for ARC4 (EIP-96*s*) 0x25 0x2E 0x35 0x3E 0x3E
(q <= 37) Record pointer
Word q+1 ARC4 I/J Optional for ARC4 (EIP-96*s*) 0x26 0x2F 0x36 0x3F 0x3F
pointer [15:0]
Word r Seq. number Defines the 32-bit word offset of 0x25 / 0x1F 0x35 / 0x2F 0x2F
offset10 the sequence number in this 0x271 0x371
(bits [7:0]) Context Record. 1 1

007-096460-207

Ext Ext1 Ext2
1
The Large addresses (Large, Large Ext1., Large Ext2.) are used for EIP-96*e* and EIP-96*k* configurations (thus
including SHA-512 or SHA3); The Basic addresses (Basic, Basic Ext) are used for all other configurations.
The Extended addresses (Basic Ext., Large Ext1, Large Ext2) are used when the Extended Context Format bit defined
in CCW0[15] is set to 1b, see decision table, Table 30, refer to section 9.2.1.
2
The Large Ext2 addresses are used for operations which use HMAC SHA3-224/256 or Keyed-hash SHA3-224/256:
this cannot be combined with SPI, sequence number, sequence number mask and/or IV, due to overlap with the
extra SHA3 digest registers in the limited address space.
3
BC0 is an external block cipher using 256-bit keys, controlled comparably to AES-256.
4
For SHA2: all digest sizes SHA-224/256/384/512;
For SHA3: all digest sizes SHA3-224/256/384/512;
For XCBC: all key sizes XCBC-MAC 128/192/256
5
The digest_count is only applicable when selected for basic hash/HMAC operations for the purpose of
continuation, refer to CCW1[9] in section 9.2.2.
6
For support of continuation (XCBC-MAC)
7
When extended sequence number mask (mask larger than 128 bits) is available and enabled.
8
When extended sequence number mask (mask larger than 256 bits) is available and enabled.
9
When extra large (XL) sequence number mask (mask larger than 384 bits) is available and enabled.
10
This field is needed when the ‘CT’-bit in the token is used. Refer to section 7.2.1.1.4 for details on the use of the
‘CT’-bit related to the sequence number offset and refer to the description of bits [30:24] of the Context Control
Word 1 for the alternative location of this offset in section 9.2.2.
11
Second address is used when ARC4 is available (configurations EIP-96*s*).
The choice for the Address set (the rightmost column in Table 29 above) can be made clear using below
decision table, Table 30.
Table 30 Decision Table for Address Set for Context Fetch Mode = Control Mode
CCW0[15] SHA3-224/256 Configurations All other

with 96*e* and 96*k* Configurations
HMAC/Khash
0 X Large Basic
1 0 Large Ext1 Basic Ext
1 1 Large Ext2 Basic Ext
9.1.1 Context Record Example

Table 31 shows an example of a reduced Context Record using Context Fetch Mode = Control Mode in
combination with setting the ‘C’ bit in Input Token Header. This example supports the transform specified
by ESP-DES-NULL. Since Control Words 0/1 are already fetched from the input token, the context fetch
begins at 0x02 and continues through 0x05 and including only fields Key 0/1, SPI and sequence number 0.

007-096460-207
Table 31 Example Context Record Address Map for Context Fetch Mode = Control Mode
Word# Name Description Addr

Word 0 Control Word 0 (This word was already fetched with the token) 0x00
Word 1 Control Word 1 (This word was already fetched with the token) 0x01
Word 2 Key 0 All crypto algorithms 0x02
Word m (<=26) SPI IPsec 0x04
Word n (<=27) sequence number 0 IPsec 0x05
9.2 Context Control Words

The Context Control Words 0 and 1 determine how the rest of the Context Record is to be used for
processing a packet. Either these control words are the first two words of the Context Record, or they can
be inserted in the token.
In the latter case, an optimal utilization of the data bus used to transfer the Context Record data is
provided, since the length of the context is known upfront. This allows the EIP-96 to fetch only the amount
of context data required, instead of defaulting to the maximum context size as programmed in the
Context_Size field of the Context Control Register, default set to 0x35 words, 53 words (decimal). See
Appendix C for details. In addition to the context size, a set of packet-based options can be enabled in the
context control words. These optional fields can be implemented differently for each packet using the same
Context Record.
Table 32 Context Control Words layout
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Crypto_Algorithm
Ext_CTX_Format
Hash_Algorithm
Context_Size
Seq_Append
Digest_Type
(optional)
Mask_1
Mask_0
packet-based
Seq
SPI
key
ToP
options
ARC4/XTS_Stateful / IV_shift
Macsec seq_num_chk / dir.

(optional) seq_num_ptr av.
seq_num_ptr (32b words)
Crypto_Alg_Extended
enable pre-packet op.

Disable_Mask_Upd
Encrypt_Hash_Res
context fetch mode
Seq_Num_Option
Feedback Mode
Crypto Mode
Hash_Store
crypto store
Pad_Type
digest cnt
IV format
reserved
IV3
IV2
IV1
IV0
/
In the table, the orange fields indicate whether the value is part of the context. The yellow fields indicate
the length and modes of operation. The grey fields are reserved (with the exception of Context_Size and
packet-based options, see below). If the fields are not appended to the token, the fields can be loaded from the
context.
The packet-based options and Context_Size fields are intended to be used if the context control words are
supplied in the input token, indicated by an active ‘C’ bit in the token control word (token word 0, see
7.2.1.1.7). However if the context control words are read directly from the Context Record the packet based
options bits are not applicable.

007-096460-207
9.2.1 Context Control Word 0 Field Encoding
CCW0[3:0] – ToP: Type of Packet:

Type_Of_Packet Operation performed
0000b null operation outbound
0001b null operation inbound
0010b outbound hash operation
0011b inbound hash operation
0100b outbound cryptographic operation
0101b inbound cryptographic operation
0110b outbound encrypt-then-hash operation
0111b inbound decrypt-then-hash operation
1000b – 1101b reserved, do not use
1110b outbound hash-then-encrypt operation
1111b inbound hash-then-decrypt operation
CCW0[7:4] – packet-based options:

0000: default
–––1: Restart hash using the initial hash digests. The hash algorithm’s initial digest value is
used to start the hash. Or:
HMAC precompute. If HMAC is the selected digest type and any of the supported hash
algorithms (MD5, SHA1, SHA2, SM3) is selected.
––1–: Do not finish the hash operation. The input hash data length must be aligned with the
block size, applicable for the selected hash operation. The hash operation is stopped only
after processing of the last data block. After the last hashed data block, normally padding
is added, in this case we do not.
–1––: Force an initialize of counter. For AES/SM4/BC0-CTR with crypto mode set to ‘010’, the
counter value is initialized to 32’h00000001. For AES/SM4/BC0-ICM the counter value is
initialized to 16’h0000. Or:
HMAC precompute digests store. If HMAC precompute is selected, the digests are stored
in their idigest and odigest location in the context record.
1–––: ARC4 / XTS Initialize. Or:
HMAC precompute with large key. If HMAC precompute is selected and the key size is
larger than the block size of the used hash algorithm, the key requires to be hashed first,
before being processed further.
Restart_Hash Operation performed

Restart_Hash When HMAC Precompute is not selected
0b Use hash digest(s) as stored in Context Record.
Note: For SHA3 hash operations, since intermediate digests are not stored, the hash
operation can’t be restarted.
1b Restart hash using the hash algorithm’s initial hash digest(s).
Note: This option can only be chosen when the ‘Context’ Control Words are supplied in the
EIP-96 input token.

007-096460-207
HMAC_Precompute When any of the supported Hash algorithms with HMAC digest type is selected
0b Use hash digest(s) as stored in Context Record.
1b Precompute the HMAC digests. The Hash Key should be provided as input data, while the
Context Record contains the usual context information, where any of the supported Hash
algorithms (MD5, SHA1, SHA2, SM3) must be selected, in combination with the HMAC digest
type. The HMAC precompute operation can also be performed as initial part of a combined
crypto-hash operation in basic and protocol modes.
Note: For SHA3 HMAC operations the initial HMAC digests precompute operation is neither
required nor supported.
EIP-96 input token.
Finish_Hash Operation performed

0b Finish hash operation after padding last data block.
1b Do not finish the hash operation. The input hash data length must be a multiple of the block
size (blocksize SHA2-224/256, SM3: 512 bits; SHA2-384/512: 1024 bits).
Note: For SHA3 hash operations, since intermediate digests are not stored, the hash
operation must be finished.
EIP-96 input token.
Init_CTR_ICM / Operation performed

HMAC_precomp store
Init_CTR_ICM When HMAC Precompute is not selected
0b Use CTR/ICM mode counter states as stored in Context Record.
1b Initialize CTR mode counter to 32’h00000001, initialize ICM mode counter to 16’h0000.
Note: This option can only be chosen when the ‘Context’ Control Words are supplied in
the EIP-96 input token.
HMAC_Precompute_Store When HMAC_Precompute is selected
0b Do not store the HMAC digests in the context record.
1b Store the precomputed HMAC digests in the context record. The designated locations in
the context record are the internal registers for the idigest and odigest values.
Note: This option can only be chosen when the ‘Context’ Control Words are supplied in
the EIP-96 input token.
ARC4/XTS_Initialize Operation performed

/ HMAC_precomp
large keys
ARC4_Initialize When ARC4 is selected (only for EIP-96*s* configurations)
0b Do not initialize ARC4.
1b Initialize ARC4 from the key in the Context Record.
EIP-96 input token.
XTS_ Initialize When AES-XTS is selected (only for EIP-96*x* configurations)
0b Do not initialize AES-XTS (no pre-calculation using AES encryption).
1b Initialize AES-XTS using AES encryption.
EIP-96 input token, and therefore is used to control XTS pre-calculation on per-packet
basis.

007-096460-207
HMAC_Precompute When HMAC_Precompute is selected

_Large_Keys
0b The size of the Hash Key is less or equal to the block size of the selected hash algorithm.
1b The size of the Hash Key is beyond the block size of the selected hash algorithm. The provided
Hash Key itself will be hashed first, as required by the HMAC algorithm. Please refer to B.2.
Note: This option overrules ARC4_Initialize and XTS_Initialize.
EIP-96 input token.
CCW0[13:8] – context_size:
Context_Size
Note: This field, when provided in the token, is only applicable when the Context Fetch Mode = Control Mode and
bit ‘C’ is set in the EIP-96 Input Token Header.
Note: In the context record, this field MUST be programmed with the correct context size (coding), otherwise this
may cause unpredictable behavior and/or poor performance.
In case the ext_ctx_format is selected (see CCW0[15]) while CCW0[13] is set to 0b, a special coding for the context
size applies, to allow support for Extra Large bitmasks (exceeding 384-bit, see CCW0[31:30]). See Table 33.
If CCW0[31:30] = 01b, an extra 32 words for the 1024-bit mask are added to the length represented in CCW0[12:8].
This field specifies the length in number of 32-bit words of a customized Context Record, over-riding the
context_size field of the PE_n_EIP96_CONTEXT_CTRL register (see section C.1.2.1). The length specified here does
not include the first ‘two’ words (Context Control Words 0 and 1), since these have already been provided with the
input token. Therefore, the new context is fetched starting at word address 0x02 (immediately after Context Control
Word 1).The maximum value of this field is 0x3F (63 words), which allows records of 65 words, including the two
command words.
With the introduction of XL masks (bitmasks which exceed 384 bits), the definition of the context_size is
transformed to enable representing any practicle context record size, according to below Table 33.
Here it can be seen that the coding only deviates from the straightforward coding under these conditions:
1. The configuration must support XL masks, and
2. Extended Format is selected (CCW0[15] = 1b), and
3. MSB of the context_size equals 0 (CCW0[13] = 0b).
Table 33 Coding of the context_size field
Applicable CCW0 fields context size (in 32-

bit words)
Format
CCW0[15] CCW0[13] CCW0[31:30] CCW0[9:8] CCW0[13:8] Configurations
with XL masks
x x xx x 000000b 0
Basic
0 x xx x N N
Extended 1 1 xx x N N
1 0 01b 10b 000010b 32+32+2 = 66
1 0 01b 11b 000011b 32+48+2 = 82
XL
1 0 01b 0xb 0xxx0xb reserved
1 0 M ≠ 01b x 0xxxxxb reserved

007-096460-207
CCW0[14] – seq_append:
Seq_Append
When using the EIP-96 as a standalone core, this bit must be set to zero.
When set to one, and the sequence number append feature is enabled (see C.1.1.2), the sequence number is
appended to the result token.
Note: This feature should only be used when the EIP-96 is integrated in the EIP-197.
Several conditions must be satisfied to prevent errors in the result token and to allow successful appending of the
sequence number.
When this bit is set, one or two words sequence number (depending on the sequence number size) are added to the
result token as final words. Therefore, the EIP-96 input token may only have up to 10 bypass words, otherwise the
appended words won’t be visible in the result token. The length of the result token bypass field is increased with two
when this option is selected.
The bits [21:20] of the result token word7 indicate the appended sequence number size. These bits override the
existing value of these bits provided via the token bypass instruction.
00b: No sequence number appended to the output token
01b: 32-bit sequence number is appended
10b: 64-bit sequence number is appended
11b: Reserved
When ESN is selected (64-bit sequence numbering) and the sequence number checking is disabled, the EIP-96 still
estimates the 32 most significant bits of the extended sequence number (ESN) upon retrieval of the 32 LSB of the
sequence number from the processed packet. This is done together with a sequence number update after
processing. This estimation is required to allow a roll-over of the 32 MSB. To do a proper estimation of the ESN, the
EIP-96 assumes a replay window size of 1024-bits. The Context Record is always updated after successful
authentication with the 64-bit sequence number composed from the 32-bit sequence number from the processed
packet and the estimated ESN. If authentication fails, no update is done. In this mode it is assumed that no mask is
available.
Note: The sequence number append feature cannot be used together with the VERIFY_FIELDS sequence number
instruction.
Note: Only the 256-bit and larger masks allow 64-bit sequence number append. Smaller bit masks would only allow
‘no appending’ or ‘32-bit sequence number append’.
CCW0[15] – ext_ctx_format:
Ext_CTX_Format
Extended context format.
This bit is supported by the standard availability of sequence number masking, of at least 256-bit.
If this bit is set to 1b, the sequence number and all potential sequence number mask words are added at the end of
the Context Record on a fixed location. Refer to Table 29 for more details on the location of the sequence number
fields.
This bit changes the meaning of Seq, Mask0 and Mask1 bit-fields in the Context Control Word 0 (bits [31:28]); refer
to the description of these bits for details.
CCW0[16] – key:
Key Key operation
0b No key is loaded.
1b The key in the Context Record is loaded to be used by the crypto algorithm selected in the
Crypto_Algorithm and Crypto_Alg_Ext fields.

007-096460-207
CCW1[20] and CCW0[20:17] – crypto_algorithm:

Crypto_Alg_Ext Crypto_Algorithm Symmetric crypto algorithm used
0b 0000b DES
0b 0001b ARC41 without ARC4 State Support
(EIP-96*s only, otherwise ‘reserved, do not use’)
0b 0010b 3-DES
0b 0011b Kasumi (EIP-96*w only, otherwise ‘reserved, do not use’)
0b 0100b reserved, do not use
0b 0101b AES -128 / AES-XTS-128 (if configuration supports AES-XTS)
0b 1000b ChaCha20 (EIP-96*b only, otherwise ‘reserved, do not use’)
0b 1001b SNOW (EIP-96*w only, otherwise ‘reserved, do not use’)
0b 1010b-1011b reserved, do not use
0b 1100b ZUC (EIP-96*w only, otherwise ‘reserved, do not use’)
0b 1101b SM4 (EIP-96*c only, otherwise ‘reserved, do not use’)
1b 0000b reserved, do not use
1b 0001b ARC41 with ARC4 State Support
(EIP-96*s only, otherwise ‘reserved, do not use’)
1b 1100b-1111b BC02, key-select 00b-11b
1
For ARC4, CCW1[20] denotes the ARC4_IJ_Pointer availability, stating if ARC4 I/J pointers and the ARC4 State are
part of the Context record, see below description of CCW1[20].
2
A widebus interface for an external block cipher BC0 that should be controlled similar to AES-256, i.e. having a
256-bit crypto key and similar crypto modes.
CCW0[22:21] – digest_type:
Digest_Type Digest used
00b Use the algorithm’s initial digest. In this case, no digests are stored in the Context Record.
Use for Poly1305 when combined with ChaCha20 One-Time Key precalculation.
01b Use the inner digest of the Context Record. In this case, only the precomputed inner digest is
available in the Context Record. For SHA-3, the Keyed-hash algorithm is selected. Refer to
section B.2.
10b Use for hash algorithms AES-GCM, AES-XCBC-MAC and Poly1305: In this case, one or more key
fields are available in Context Record, see sections B.2.6 and B.2.7.
Use for CRC-32 algorithm: Loading of initial state for CRC-32 is controlled via bit [0] of the
packet-based options field: ‘1’ = start from value 0, ‘0’ = start from digest field of the Context
Record.
11b Use for HMAC. The precalculated inner and outer digest values must be made available in the
Context Record for MD5, SHA1, SHA2, SM3. For SHA-3, the original key (limited to block size) is
available in the Context Record

007-096460-207
CCW0[26:23] – hash_algorithm:
Hash_ Algorithm Digest_Type(s) Hash algorithm used Digest length (32-bit words)
0000b 00b/01b MD5 (basic) 4
10b CRC-32 15
11b MD5-HMAC 2x4
0001b 00b/01b reserved, do not use -
10b AES-XCBC-MAC1 (128-bit key) 3x4
11b 2 (2x)5
SHA-1-SSL-MAC
0010b 00b/01b SHA-1 (basic) 5
10b AES-XCBC-MAC1 (192-bit key) (2x4)+8
11b SHA-1-HMAC 2x5
0011b 00b/01b SHA2-256 (basic) 8
10b AES-XCBC-MAC1 (256-bit key) (2x4)+8
11b SHA2-256-HMAC 2x8
0100b 00b/01b SHA2-224 (basic) 8
10b GHASH 4
11b SHA2-224-HMAC 2x8
0101b 00b/01b SHA2-5123 (basic) 16
10b ZUC4 4
11b 3 2x16
SHA2-512-HMAC
0110b 00b/01b 3 16
SHA2-384 (basic)
10b 4 4
SNOW 3G
11b 3 2x16
SHA2-384-HMAC
0111b 00b/01b 10 8
SM3 (basic)
10b 4 4
Kasumi f9
11b 10 2x8
SM3-HMAC
1000b-1010b 00b-11b Reserved
1011b 00b SHA3-2566 (basic) 8
01b 6 34 (block size)
Keyed-hash SHA3-256
10b 7 0
Reserved
SHA3-256-HMAC
1100b 00b 6 8
SHA3-224 (basic)
Keyed-hash SHA3-224
10b 7 0
Reserved
SHA3-224-HMAC
1101b 00b 6 16
SHA3-512 (basic)
Keyed-hash SHA3-512
10b 7 0
Reserved
SHA3-512-HMAC

007-096460-207
Hash_ Algorithm Digest_Type(s) Hash algorithm used Digest length (32-bit words)
1110b 00b 6 16
SHA3-384 (basic)
Keyed-hash SHA3-384
10b 7 0
Reserved
SHA3-384-HMAC
1111b 00b 8,9 4
Poly1305
01b/11b Reserved -
10b 9 4
Poly1305
1
AES-XCBC-MAC uses separate AES-CBC encrypt-only core. The key length is for the encryption key K1; other keys
used in the algorithm (K2 and K3) are always 128 bits. The AES-CCM mode uses key lengths of 128-bit, 192-bit
and 256-bit.
2
SHA-1-SSL-MAC is a dedicated SHA-1-MAC algorithm used only for SSL. This option is available by default in all
configurations.
3
SHA2-512 and SHA2-384 are only available in EIP-96*e configurations and ‘reserved, do not use’ in other
configurations.
4
Kasumi, SNOW 3G and ZUC are only available in the EIP-96iew and EIP-96iesw configurations and ‘reserved, do
not use’ in other configurations.
5
CRC-32 digest length is 32-bit long (1 x 32-bit word), while in the Context Record, 4 x 32-bit words are required.
6
SHA-3 hash functions are only available in EIP-96*k configurations and ‘reserved, do not use’ in other
configurations.
7
Hash continuation is not supported for SHA-3.
8
Poly1305 when ChaCha20 is used for One-Time Key precalculation: The R key and S key are not fetched from the
context, see B.2.4.
9
Poly1305 MAC functions are only available in EIP-96*b configurations and ‘reserved, do not use’ in other
configurations.
10
SM3 functions are only available in EIP-96*c configurations and ‘reserved, do not use’ in other configurations.
CCW0[27] – spi:
SPI Key operation
0b No SPI[31:0] or SSRC[31:0] fields are present in the Context Record.
1b Either the SPI[31:0] or SSRC[31:0] identification fields are present in the Context Record.
CCW0[29:28] – seq:
Ext_CTX_Format1 Seq Counter size Indication
0b 00b N/A Sequence number data is not present in the Context Record. Hence,
if a token instruction checks for or uses the sequence number,
results are unpredictable.
0b 01b 32-bit Sequence number [31:0] field is present in the Context Record.
1b 11b Reserved Reserved
1
Extended Context Format, refer to CCW0[15]

007-096460-207
CCW0[30] and CCW0[31] – mask_0 and mask_1:

XL_CTX_ Ext_CTX_ Mask_1 Mask_0 Window Fields present
Format2 Format1 size
0b 0b 0b 0b no mask Mask fields are not present in the Context Record. Hence,
available if sequence number verification uses the mask, results
are unpredictable.
0b 0b 0b 1b 64 The ‘sequence number mask 0’ and ‘sequence number
mask 1’ fields are present in the context.
0b 0b 1b 0b 32 The ‘sequence number mask 0’ and ‘sequence number
mask 1’ fields are present in the context.
0b 0b 1b 1b 128 The ‘sequence number mask 0’ through ‘sequence
number mask 3’ fields are present in the context.
0b 1b 0b 0b 64 64-bit sequence number mask
1b 1b 0b 0b - Reserved
1
Extended Context Format, refer to CCW0[15], CCW0[13] (=11b)
2
ExtraLarge Context Format, refer to CCW0[15], CCW0[13] (=10b)
9.2.2 Context Control Word 1 Field Encoding
CCW1[2:0] and CCW1[4:3] – crypto_mode and feedback_mode:

Crypto_ FB_ (3-)DES AES mode ChaCha20 Kasumi/ SM4/BC0
Mode Mode4 mode SNOW/ZUC mode
000b any (3-)DES- AES-ECB 64-bits counter, 256- Basic/reserved/ SM4/BC0-ECB
ECB bits key Basic
001b any (3-)DES- AES-CBC 64-bits counter, 128- f8/128-EEA1/ SM4/BC0-CBC
CBC bits key 128-EEA3
010b any reserved, AES-CTR (init 32-bits counter, 256- reserved, do SM4/BC0-CTR
do not counter1 to 1) bits key not use (init ctr1 to 1)
use
011b any reserved, AES-ICM (init 32-bits counter, 128- reserved, do SM4/BC0-ICM
do not counter2 to 0) bits key not use (init ctr2 to 0)
use
100b any (3-)DES- AES-OFB 64-bits counter, 256- reserved, do SM4/BC0-OFB-
OFB bits key, OTK generate3 not use 128
(init counter to 0)
101b 00b (3-)DES- AES-CFB-128 64-bits counter, 128- reserved, do SM4/BC0-CFB-
CFB-64 bits key, OTK generate3 not use 128
01b/ reserved, reserved, do not (init counter to 0) reserved, do
10b/ do not use not use
11b use

007-096460-207
Crypto_ FB_ (3-)DES AES mode ChaCha20 Kasumi/ SM4/BC0

Mode Mode4 mode SNOW/ZUC mode
110b any reserved, AES-CTR 32-bits counter, 256- reserved, do SM4/BC0-CTR
do not (load/reuse bits key, OTK generate3 not use (load/reuse
use counter1) (init counter to 0) counter1)
111b 01b/ reserved, reserved, do not 32-bits counter, 128- reserved, do reserved, do
10b/ do not use bits key, OTK generate3 not use not use
11b use (init counter to 0)
00b AES-XTS 5
1
AES/SM4/BC0-CTR mode uses a 32-bits counter.
2
AES/SM4/BC0-ICM mode uses a 16-bits counter.
3
CCW1[2] implies OneTimeKey (OTK) generation by the ChaCha20 module. The Poly1305 algorithm must be selected
as hash operation to receive the generated key-pair (s and r). See Section B.2.4. A ChaCha20 32-bits block counter is
supported for this purpose, initialized to 0.
4
CCW1[3] implies AEAD mode of operation, in conjunction with Poly1305. Additionally, it can imply TLS1.3 padding,
see Table 37.
CCW1[4] implies Nonce derivation by applying IV XOR sequence number. This XOR_enable can only be used in non-
feedback modes: AES/DES/SM4/BC0 with CFB/OFB do not support XOR_enable. See Section.7.2.1.1.8.2
5
AES-XTS (automatic CTS for misaligned blocks), modes 1-7 in Table 17. For more details, see Section B.2.8.
CCW1[4:0] – ARC4_key_length:
ARC4_Key_Len ARC4 key length1
00101b 5 Bytes2
00110b 6 Bytes2
00111b 7 Bytes2
01000b 8 Bytes2
01001b 9 Bytes2
01010b 10 Bytes2
01011b 11 Bytes2
01100b 12 Bytes2
01101b 13 Bytes2
01110b 14 Bytes2
01111b 15 Bytes2
10000b 16 Bytes
1
ARC4 is only available on the EIP-96is and EIP-96ies configurations.
2
The context must always contain 4 (32-bit) words of ARC4 key material if ARC4 is selected. If this field indicates a
shorter key length, only the first N bytes of the key will be used. For example using an ARC4 key of five bytes,
only the first key word and bits [7:0] of the second key word contain valid key data that is used by the ARC4-
core.

007-096460-207
CCW1[8:5] – IV[3:0]:
IV_3 IV_2 IV_1 IV_0 IV words present and loaded1
0b 0b 0b 0b No IV words are part of the Context Record
0b 0b 0b 1b IV0 (= IV[31:0])
0b 0b 1b 0b reserved, do not use
0b 0b 1b 1b IV1 + IV0 (= IV[63:0])
0b 1b 1b 0b IV2 + IV1 (= IV[95:32])
0b 1b 1b 1b IV2 + IV1 + IV0 (= IV[95:0])
1b 0b 0b 1b IV3 and IV0 (=IV[127:96] and IV[31:0])
1b 1b 1b 0b IV3 + IV2 + IV1 (= IV[127:32])
1b 1b 1b 1b IV3 + IV2 + IV1 + IV0 (= IV[127:0])
1
IV0 is also used for NONCE, IV3 is also used to store the counter for AES/SM4/BC0-CTR, AES/SM4/BC0-
ICM and ChaCha20 modes.
CCW1[9] – digest_count:
Digest_Count Operation
0b No digest count is stored in the Context Record.
Alternatively, when SHA-3-Keyed-hash (only available on the EIP-96k) is the selected
algorithm, the key length is equal to the block size of the specified SHA-3 algorithm – the key
being available in the digest words of the Context Record.
1b A digest count is stored in the Context Record (in the first word following the first hash digest)
– this count holds the number of 512-bit blocks1 that are already processed by the hash
engine.
Alternatively, when SHA-3-Keyed-hash (only available on the EIP-96k) is the selected algorithm
in context control word 0 “hash_algorithm”/”digest_type”, the key length is provided in bits
[31:24] of the last digest word2 in the Context Record.
1
For SHA2-384/512 (available in EIP-96ie / EIP-96ies configurations), where the block size equals 1024 bits, the
digest count word still holds the number of processed bits in 512-bit units, meaning that the field is incremented
by 2 for each block processed.
2
For SHA3-512, the last digest word is Word l+1, for SHA3-384 this is Word l+9, for SHA3-256 this is Word l+17, for
SHA3-224 this is Word l+19, refer to Context Record Address Map for Context Fetch Mode = Address Mode Table
29.

007-096460-207
CCW1[11:10] and CCW1[4] – IV_format and XOR enable:

IV_Format XOR_enable2 IV operation for non-feedback modes of
AES/(3-)DES/SM4/BC0/ChaCha20 1
00b 0b/1b Full IV mode.
01b 0b Counter mode.
1b Original sequence number mode with XOR, the non-incremented 64 bit sequence
number is Byte-swapped within each 32 bit half and XOR-ed to the IV1 and IV2 fields
of the context.
For inbound operations with sequence number provided via the packet, any One-
Time-Key operation is only started after the XOR operation is done.
10b 0b Original sequence number mode, the non-incremented 64 bit sequence number is
Byte-swapped within each 32 bit half and then placed in the IV1 and IV2 fields of the
context.
1b Original sequence number mode with XOR, the non-incremented 64 bit sequence
of the context.
Any One-Time-Key operations can be started immediately
11b3 0b Incremented sequence number mode, the incremented 64 bit sequence number is
Byte-swapped within each 32 bit half and then placed in the IV1 and IV2 fields of the
context.
1b Incremented sequence number mode with XOR, the incremented 64 bit sequence
of the context.
Any One-Time-Key operations can be started immediately
1
See the “IV: Usage and Selection” section 7.2.1.1.8.
2
XOR_enable can only be used in non-feedback modes: AES/DES/SM4/BC0 with CFB/OFB do not support
XOR_enable.
3
Can be used for outbound operations only
CCW1[12] – crypto_store:
Crypto_Store Operation
0b Do not store updated IV values and ARC4 I/J pointers back in internal context registers (the
latter for EIP-96is / EIP-96ies configurations only).
1b Store updated IV values and ARC4 I/J pointers back in internal context registers (the latter for
EIP-96is / EIP-96ies configurations only) – CONTEXT_ACCESS instructions must be used to write
these registers (and ARC4 state) out to the Context Record (if needed and applicable). When
AES-XTS is selected (EIP-96iex / EIP-96ieswx / EIP-96ieswxk) the Tweak value is stored.
CCW1[13] – enable_prepacket_operation:
enable pre-packet Operation
op.
0b default, for regular operations this bit must be set to zero
1b Enables the option to perform a decryption operation ahead of the actual packet processing. If
this bit is set to 1, it is possible to re-initialize the datapath such that it restarts the crypto
processing FSM and reloads the original IV. The datapath re-initialization is executed with
propagation of the ‘Last’-bit in a token instruction.
Refer to Section 8.4.8 for more details.
Note: This bit only needs to be set to 1 for (single pass) inbound SSL/TLS/DTLS operations
that use block cipher encryption. For these operations, decryption of the last two data
blocks needs to be done ahead of the actual packet processing to retrieve the padding
length. After decryption of the last two data blocks of the packet to determine the
padding length (and thus the location of the hash result), the datapath needs to be re-
initialized when the processing of the packet is started.
Note: It is not recommended to set this bit for operations other than inbound SSL/TLS/DTLS
with block ciphers.

007-096460-207
CCW1[16:14] – padding_type:
Pad_Type5 AEAD_mode4 Padding type used
000b 0b Zero padding
001b 0b PKCS7 padding
010b 0b Constant SSL padding 3
011b 0b RTP padding
100b 0b IPsec padding, returned value is next header 2
101b 0b TLS1.0, TLS1.1, TLS1.2 padding
1b TLS1.3 padding
110b 0b SSL padding (no check) 3
111b 0b IPsec padding, returned value is next header 2,
no pad sequence check on removal 1
1
The use case for this setting is when an inbound packet contains IPsec padding filled with arbitrary data. The EIP-
96 will then remove the padding sequence using the length defined by ‘pad length’ byte. This is different from
code 100b, where first the padding sequence is verified and then the padding is removed only when the
sequence is correct and the ‘pad length’ byte matches the ‘sequence length’.
2
Returned next header value will be placed in result token.
3
Removal and checking of SSL padding can only be selected if SSL padding is constant, followed by the padding
length (eg. 90-90-90-03), however SSL does not explicitly define the padding fields to be constant. If an inbound
packet does not necessarily has constant SSL padding, the removal can only be done by the depadding logic of
the EIP-96 when no check is done on the padding. In this case pad type ‘110’ should be selected.
4
The AEAD_mode is defined by CCW1[3], and only for non-feedback modes: AES/DES/SM4/BC0 with CFB/OFB do
not support AEAD_mode. For non-listed combinations of Pad_Type and AEAD_mode, the used padding type is
‘reserved, do not use’.
5
This padding type defines the type to verify, in case of inbound operations. Must be set to 000b for outbound
operations.
CCW1[17] – encrypt_hash_result:
Encrypt_Hash_Res Operation (applicable to AES-GCM and AES-CCM processing only)
0b The generated hash result is not encrypted, creating the ICV (integrity check value) directly.
See the description of the INSERT_REMOVE_RESULT instruction in section 8.6.1.1.
1b The generated hash result is encrypted to create the ICV (integrity check value). See the
description of the INSERT_REMOVE_RESULT instruction in section 8.6.1.1.
This bit MUST be kept 0b when not performing AES-GCM or AES-CCM operations.
CCW1[18] – macsec_seqnumcheck or dir:

macsec seq_num_chk / Wireless algorithm selected Operation indicated
dir. (direction) (Kasumi f9, SNOW, ZUC)
0b No regular sequence number verification (for
inbound) is enabled
Yes DIRECTION bit set to 0 in Authentication
operation
1b No Enables MACsec specific sequence number
checking. The sequence number mask
(lowest 32-bit) is considered as a 32-bit
integer instead of an N-bit sliding window.
Refer to Section B.4 for more details on
MACsec sequence number checking.
Yes DIRECTION bit set to 1 in Authentication
operation

007-096460-207
CCW1[19] – hash_store:
Hash_Store Operation
0b Calculated hash digests are not stored in the internal digest result registers.
1b Calculated hash digests are stored in the internal digest result registers – a CONTEXT_ACCESS
instruction must be used to write these registers out to the Context Record (if needed).
CCW1[20] – ARC4_ij_pointer – crypto_alg_ext:

ARC4_IJ_Pointer / ARC4 state support / Crypto algorithm extension
Crypto_Alg_Extended
ARC4_IJ_Pointer When ARC4 is selected by CCW0[20:17] equal 0001b (only for EIP-96*s* configurations)
0b None – the Context Record does not contain the ARC4 I/J pointers and the ARC4 State
Record pointer.
1b ARC4 I/J pointers and ARC4 State Record pointer are available in the Context Record. The I/J
pointers are stored in bits [15:0] of a full word that is unused in bits [31:16].
Crypto_Alg_Extended When non-ARC4 is selected
0b-1b This bit extends the crypto_alg_field CCW0[20:17] by 1 bit at the left. The resulting
crypto_alg CCW1[20]andCCW0[20:17] defines the selected crypto algorithm. See definition
for CCW0[20:17]
CCW1[21] – ARC4_XTS_stateful / IV_shift:

ARC4/XTS_Stateful ARC4 / XTS / IV_shift handling
/ IV_shift
ARC4_Stateful When ARC4 is selected (only for EIP-96*s* configurations)
0b Stateless processing: ARC4 State Records and I/J pointers are not loaded and stored so every
packet must start afresh from the given key (the ARC4_Initialize bit in the first Context Control
Word must be set for this mode to generate a starting state from the key in the Context
Record).
1b Stateful processing: ARC4 State Records and I/J pointers are loaded and stored so
continuation of an ARC4 stream encrypt/decrypt is possible (the ARC4_Initialize bit in the first
Context Control Word must be used for the first packet to initialize the state from the key in
the Context Record).
XTS_Stateful When AES-XTS is selected (only for EIP-96*x* configurations)
0b Stateless processing: enable IV pre-calculation using AES encryption with Key 2 for every new
packet based on provided ‘i’ and ‘j’ values (see Table 17).
With this setting, the stateful processing (skipping of the AES pre-calculation) cannot be
enabled per packet. If this is not desired, the stateful processing must be selected (1b) and
XTS_Initialize bit must be used per packet basis.
1b Stateful processing: skip IV pre-calculation using AES encryption and load Tx from the context
or token (see Table 17).
The XTS_Initialize bit in the first Context Control Word must be used to enable pre-calculation
for the first blocks of the sector.
IV_shift When AES-CCM is selected
0b Use default IV location (IV1 and IV2) for the sequence number insertion. This setting
corresponds with AES-CCM for IPsec-ESP (specified in RFC4309) and it specifies L=4, which
means that the width of the 'counter' in the IV block is 4 bytes. As a result, the Nonce and IV
parts are word-aligned:
IV block1 = 1 flags byte + 3 salt bytes + 8 IV bytes + 4 counter bytes.
1b Use shifted IV location for the sequence number insertion. This setting corresponds with AES-
CCM for TLS 1.2/1.3 (specified in RFC6655, RFC5116), and it specifies L=3. This means that the
'counter' part of an IV block is 3 bytes, so that the IV part of 8 bytes is not word aligned:
IV block1 = 1 flags byte + 4 salt bytes + 8 IV bytes + 3 counter bytes.
Note that this option allows nonce generation from the 64-bit sequence number or extracting
it from the packet data stream.
1
Definition and examples of the AES-CCM IV block can be found in [2].

007-096460-207
CCW1[22] – seq_num_option, seq_num_rollover, seq_num_store:

Seq_Num_Option Operation (different per direction, ToP[0])
Seq_Num_Rollover For outbound packets only
0b The sequence number rolls over to 0x1 and a token error (E10) is generated.
1b The sequence number rolls over to 0x0 and flags a single error (E10) if the sequence number
is checked. If the error is observed (using the VERIFY_FIELDS instruction), the update is not
executed.
Seq_Num_Store For inbound packets with extended sequence numbers only
0b A full 64-bit sequence number is not available and the Estimated Sequence Number (upper 32
bits) must be calculated by the hardware. This mode of operation is required for IPsec with
extended sequence numbers.
1b The full 64-bit sequence number is located in the packet (as with SSL/TLS) or context and can
be stored directly into the sequence number result registers.
CCW1[23] – disable_mask_update:
Disable_Mask_Upd Operation (for inbound packets only)
0b Update the sequence number mask during inbound sequence number verification.
1b Do not update the sequence number mask during inbound sequence number verification. This
allows checking out-of-order packets within a programmable window size without replay
protection.
CCW1[30] and CCW1[29:24] – seq_num_ptr_av and seq_num_ptr:

Context Control These bits are used for various purposes in various use cases
Word 1 [30:24]
0000000b… Reserved for future options.
0111111b
1000000b Reserved, should not be used.
{1, [29:24]} When bit [30] is set to ‘1’ and bits [29:24] are non- zero, these bits [29:24] represent the
sequence number pointer ('seq_num_ptr’). The 6 bits are a 32-bit offset from the context base
address to the sequence number field in the Context Record. If bit [30] is zero, it is assumed
the seq_num_ptr is located in the context as separate word after the last valid context word.
The use of this offset is only applicable for outbound packets with a sequence number in the
Context Record that use the ‘CT’ bits in the token header (refer to section 7.2.1.1.4). If the ‘CT’
bit is not set, the seq_num_ptr is not required.
CCW1[31] – fetch_mode:
Fetch_Mode Context Record mode
0b ‘Control mode’ – only relevant fields stored and fetched. May be overruled by bits [9:8] of the
PE_n_EIP96_CONTEXT_CTRL register (see section C.1.2.1).
1b ‘Address mode’ – fixed Context Record layout. May be overruled by bits [9:8] of the
PE_n_EIP96_CONTEXT_CTRL register (see section C.1.2.1).

007-096460-207
10 Result Token Definition

The EIP-96 generates a result token for every input token. The result token contains the following fields
resulting from packet processing:
Result Token
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
E14
E13
E12
E11
E10
result packet length

E9
E8
E7
E6
E5
E4
E3
E2
E1
E0
E15
L N C B hash bytes H CLE reserved bypass data

reserved pad info 1 pad info 0
bypass token data (optional: maximum of 10 words, or 10 + maximum of 2 words seq.num.append)
Result Packet Length:

The result packet length equals the length of the packet that is written out of the EIP-96, not including the
appended result fields (see to the ‘packet info fields’ in result token).
Error Codes:
The table below lists the meaning of the different error codes returned by the EIP-96. It is possible to have
multiple error codes in one packet. If one or more fatal error (highlighted in yellow) occurs, the packet will
not be processed correctly and should be dropped. A fatal error only occurs if the input token or Context
Record is incorrect. Alternatively, instead of these all one-hot Error Codes, the error fields may be defined
to represent “Detailed Error Codes”, see Table 36 below.
Table 34 Result Token Error Codes
Error Code Description

E0 Packet length error: token instructions versus input or input DMA fetch
E1 Token error, unknown token command/instruction
E2 Token contains too much bypass data
E3 Cryptographic block size error (ECB, CBC)
E4 Hash block size error (basic hash only) or PRNG error
E5 Invalid command/algorithm/mode/combination or context read DMA error
E6 Prohibited algorithm or context read ECC error
E7 Hash input overflow (basic hash only)
E8 TTL / HOP-limit underflow
E9 Authentication failed
E10 Sequence number check failed / Sequence number roll-over detected
E111 SPI check failed / Sequence number early roll-over detected
E12 Checksum incorrect
E13 Pad verification failed
E14 Time-out - FATAL ERROR, (see note below)
E15 Output DMA error (not applicable for EIP-96-f configurations)
1
When register EIP96_SEQ_NUMnn_THR is available and set to a value unequal to ‘0’, Result token field ‘E11’
represents a ‘note’ when the related sequence number for an outbound packet has reached the given threshold
value, see Appendix C.1.6, C.1.6.2.

007-096460-207
Two errors in the result token have a different behavior in the EIP-96-f configurations:
1. In the standard EIP-96, error E0 occurs either when the pre-processor detects a wrong length
(instruction lengths, version packet length) or if the input DMA fetch reports an error. The latter cannot
happen in the EIP-96-f but a similar case is detected and reports the same error instead. If
data_in_done is asserted before the number of written words matches with the packet length field
from the input token, the EIP-96-f will trigger E0.
2. Error E15 cannot occur in the EIP-96-f, and is therefore always zero in that case.
Errors E4, E5 and E6 have different meaning when E14 bit is set. When this is the case, E4 indicates a PRNG
error, E5 indicates a context read DMA error and E6 a context read ECC error. Refer to Table 35.
Table 35 Result Token E14, E6, E5 and E4 errors
{E14, E6, E5, E4} Description
0--- E4: If set to ‘1’: Hash block size error (basic hash only)
E5: If set to ‘1’: Invalid command/algorithm/mode/combination
E6: If set to ‘1’: Prohibited algorithm
1000 Time-out fatal error.
This error should never occur in the EIP-96 when processing regular operations/tokens.
The timeout counter runs if no data movement within the EIP-96 is detected and fires
after this situation has persisted for a fixed number of clock cycles (approximately 1000
clock cycles). The actual number of clock cycles is dependent on the EIP-96 core
configuration.
1010 Context read DMA error. The EIP-96 has an indication from the external system that
context cannot be read due to DMA error.
1100 Context read ECC error. The EIP-96 has an indication from the external system that
context is corrupted as detected by the external ECC logic.
1110 Both context read DMA and ECC error
10011 PRNG error. The EIP-96 has an indication from the external system that the external PRNG
(DRBG) requires an initial seed, reseed, or that a duplicate was produced.
1
Only defined for external PRNG (DRBG).
Detailed Error Codes:

The table below lists the meaning of the different detailed error codes returned by the EIP-96. These
detailed error codes are only present in the output token, when bit 30 in register
EIP96_TOKEN_CTRL_STAT is set to ‘1’, upon encountering an error.
Detailed error codes are marked by result token field ‘E14’ being set to ‘1’. Hardware errors detected by the
EIP-96 are marked by result token field ‘E7’ being set to ‘0’. When the EIP-96 is embedded in Rambus more
complex packet engines, such as EIP-197, the Firmware could insert errors using the ‘U-word’ described in
section 7.2.1.1.9. Firmware detected errors are marked by result token field ‘E7’ being set to ‘1’ and
overrule the hardware detected detailed errors. For firmware detailed error codes the u-word bits [30:24]
are used, see appendix A.2.4.1.
It is possible to have multiple error codes in one packet detected and returned if at least one of the errors is
in the range {E8,…,E13}. In that case, one or more error code flags in the range {E8,…,E13} are set, while
{E6,…,E0} denotes the detailed error code of the first encountered error.
If one or more fatal errors (highlighted in yellow) occur, the packet will not be processed correctly and
should be dropped. A fatal error only occurs if the input token or Context Record is incorrect.

007-096460-207
Table 36 Result Token Detailed Error Codes
HW Error Code Field Code Description

(E14=1,E7=0) {E6…E0}
E0_0 0x01 Packet length error: token processing error.
E0_1 0x02 Input DMA fetch error.
E0_2 0x03 Packet transfer error 1: transfer of the packet is done, but remaining length is
not zero.
E0_3 0x04 Packet transfer error 2: transfer of packet not done, but remaining length is
zero.
E0_4 0x05 Packet transfer error 3: transfer of packet is done, but with error
E1_0 0x06 Packet unrelated token processing instruction error: more instructions available
than allowed by type.
E1_1 0x07 Packet related token read error 1: more token words available, while expecting
2.
E1_2 0x08 Packet related token read error 2: more token words available, while expecting
1.
E2 0x30 Token contains too much bypass data.
E3 0x09 Cryptographic block size error.
E4 0x0F Hash block size error (basic hash only).
E5_0_05 0x10 Invalid crypto algorithm.
E5_0_1 0x11 Invalid hash algorithm.
E5_0_2 0x12 Prohibited hash algorithm.
E5_1_0 0x13 Reserved (invalid combination with AES).
E5_1_1 0x14 Invalid non-feedback combination with DES.
E5_1_2 0x15 Invalid feedback combination with DES.
E5_1_3 0x16 Invalid non-feedback combination with wireless algorithm.
E5_1_4 0x17 Invalid feedback combination with wireless algorithm.
E5_1_5 0x18 (obsolete)
E5_1_6 0x19 Reserved operation without ARC4 selected.
E5_1_7 0x1A XTS selected without AES.
E5_1_8 0x1B Reserved operation selected.
E5_2_0 0x1C IV selection prohibited.
E5_3_0 0x1D Reserved.
E5_3_1 0x1E Operation with CFB invalid.
E5_3_2 0x1F Operation with OFB invalid.
E5_3_31 0x20 Context cache read DMA error.
2 0x40 Context cache read ECC error.
E6_0
E6_1 0x41 Prohibited algorithm.
E7 0x47 Hash input overflow (basic hash only)
E8_0 0x48 TTL / HOP-limit underflow for IPv4 without checksum update
E8_1 0x49 TTL / HOP-limit underflow for IPv4 with checksum update
E8_2 0x4A TTL / HOP-limit underflow for IPv6
E9 0x4F Authentication failed
E10_0 0x50 Hash fails for extended sequence numbers or 48-bit sequence numbering
E10_1 0x51 MACsec type of sequence number check fails.
E10_2 0x52 Rollover of next inbound sequence number from context.
E10_3 0x53 Next inbound sequence number check fails – window miss.
E10_4 0x54 Next inbound sequence number check fails – in high word of sequence number.
E10_5 0x55 Rollover of next inbound extended sequence number.

007-096460-207
E10_6 0x56 Next calculated sequence number check fails.

E10_7 0x57 Cached sequence number check fails.
E11_0 0x5D Sequence number early roll over detected (regarded as “note”).
E11_1 0x5E SPI check failed.
E12 0x5F Checksum incorrect.
E13_0 0x61 Pad verification failed - Padding length does not match detected padding.
E13_1 0x6B Pad verification failed - Padding length exceeds packet size
E13_2 0x6C Pad verification failed - Padding of selected type zero-padding, constant
padding, TFC padding cannot be removed
E13_3 0x6D Pad verification failed - Padding doesn't match padding type
E13_4 0x6E Pad verification failed - More padding than allowed by padding type
E13_5 0x6F Pad verification failed - Outbound padding can not be removed
E14_0 0x68 Time-out - malformed instruction sequence - postprocessor replace instruction
E14_7 0x62 Time-out - malformed instruction sequence - postprocessor update instruction
E14_8 0x63 Time-out - preprocessor unable to accept input data
E14_9 0x64 Time-out - preprocessor unable to finish packet after completion of input data
E14_10 0x65 Time-out - packet engine unable to finish packet after completion of input data
E14_11 0x66 Time-out - crypto process unable to finish packet after completion of input data
E14_12 0x67 Time-out - hash process unable to finish packet after completion of input data
E14_13 0x69 Time-out - postprocessor unable to finish packet after completion of input data
E14_14 0x6A Time-out - packet engine unable to accept input data
E14_13 0x20 Context cache read DMA error.
3 0x40 Context cache read ECC error.
E14_2
3 0x60 Context cache read DMA error and ECC error.
E14_3
4 0x38 PRNG reseed required error.
E14_4
4 0x58 PRNG duplicate error.
E14_5
4 0x78 PRNG initial seed required error.
E14_6
1
Same detailed error code as E14_1.
2
Same detailed error code as E14_2.
3
Coding is the same as for ECC and DMA errors according to normal (all one-hot) error codes, see Table 35.
4
Only available for external PRNG.
5
Coincidently, the detailed error code for E5_0_0 (0x10) displays the same value in the error fields {E14…E0} as
the normal error code for PRNG error, see Table 35.
Packet Info Fields – (H, hash byte, B, C, N, and L):

If the packet length is equal to or exceeds 1792 bytes, including padding bytes that are not yet removed (the
output packet buffer size: 2048 minus 256), or for a minimally sized buffer of 320 bytes, the result data
must be appended to the output packet in the output buffer before the packet is actually written out. For
example, updating the IPv4 header fields after stripping the padding (length field, protocol, and checksum).
For each header field, one dword is appended to the packet. Possible header fields are:
• Result packet length (IPv4 inbound) or payload length (IPv6 inbound),
• Next header field, retrieved from de-padding (IPv4 or IPv6 inbound),
• A re-calculated checksum after replacing length and next header (IPv4 inbound),
• The hash result, the number of bytes indicated by ‘hash bytes’ field (AH outbound),
• Generic byte(s).

007-096460-207
The ‘packet info fields’ are composed of the following fields:

CLE: CLE error code (Classification errors), forwarded from the input token ‘Optional debug
options’ field [20:16], or as a result of an ip_tunfix operation. Please refer to the
insert_remove_result instruction in Section 8.6.1.5.
H: Hash byte(s) appended (as a result of an insert_result instruction); the number of
appended bytes is indicated by the ‘Hash bytes’ field.
Hash bytes: The number of appended hash bytes. Please refer to the insert_result instruction in
Section 8.6.1.3.1).
B: Generic byte(s) appended (as a result of a REPLACE_BYTE instruction)
C: Checksum appended (as a result of an insert_result instruction)
N: Next header field appended (as a result of an insert_result instruction)
L: Length field appended (as a result of an insert_result instruction)
Bypass Data:
This field indicates the length of the result token bypass data in dwords. Valid values are from 0 to 12 (i.e.
10 + maximum of 2 appended seq_num words).
Output Packet Pointer/identifier:
This is a direct copy of the ‘output packet pointer/identifier’ from the input token. Refer to 7.2.1.3 for
details.
Pad Info 0 and Pad Info 1:
Definition of these fields depend on the applied padding type, as outlined in Table 37 below.
Table 37 Pad Info Fields Definition
Context Control Context Control Word Pad Info 1 Pad Info 0

Word 1, Bit [3] 1 1 Bits [16:14]
0 all pad_length next_header
1 2 pad_long, pad_length_hi pad_length_lo
0b101
others reserved, do not use reserved, do not use
1
AEAD_mode, only defined for stream ciphers.
2
In combination with AEAD_mode being set to 1b, this defines TLS1.3 padding.
Next Header:
The ‘next_header’ field contains the ‘next header’ result value intended for updating the IP header,
specifically, the IPv4 ‘protocol’ field or IPv6 ‘next header’ field. This value is retrieved during de-padding.
The ‘next header’ field is only applicable to IPsec padding;
When a pre-packet crypto operation is enabled (required for SSL/TLS/DTLS inbound processing with block
ciphers) and a processing error occurs, this field contains the retrieved padding length (the result of the pre-
packet decryption operation). Processing errors will only occur if the retrieved padding length is larger than
the actual encrypted payload, such that internal length calculations over- and/or underflow.
In all other cases, this field is set to zero (8’h00).
Pad Length:
The ‘pad_length’ field contains the number of detected (and removed) padding bytes. Applicable padding
types are PKCS#7, RTP, IPsec, TLS (1.0, 1.1, 1.2) and SSL. Otherwise, this field is set to zero (8’h00).
Pad long, Pad Length Hi, Pad Length Lo:
The ‘pad_long’ bit is the most significant bit of Pad Info 1, and denotes if the TLS1.3 padding is removed
from the inbound packet (pad_long equals 0b), or not (pad_long equals 1b). The detected (and possibly
removed) pad_length[14:0] is defined by concatenating ‘pad_length_hi[6:0]’ and ‘pad_length_lo[7:0]’.
Padding with size pad_length > 256 bytes is not removed from the inbound packet.

007-096460-207
Bypass Token Data:

The bypass token data is appended to the token, whether an error is reported or not, except when its
length exceeds the maximum token bypass length (10 words in case a sequence number is appended,
otherwise 12 words, reporting error code E2). The instruction for appending bypass token data is defined in
section 8.9.
Sequence Number Append:
The sequence number (length equals 1 or 2 words, depending on the extension) can optionally be appended
to the result token. This is controlled by bit 14 in Context Control Word 0, see section 9.2.1.

007-096460-207
A Pre and Postprocessing by Host Software

A.1 Preprocessing
Incoming packets must be preprocessed in order to generate a proper token for the EIP-96. During
preprocessing, the following operations should be considered and executed when applicable.
• FCS: Verify the 32 bit CRC of Ethernet frame.
• Ethernet hdr: Assure that the destination MAC address in the Ethernet header matches with the
device’s MAC address.
• Ethernet hdr: Assure that the protocol type specified in the Ethernet header is either IPv4 (0x0800) or
IPv6 (0x86dd).
• Ethernet hdr: Store the size of the Ethernet header in order to insert the exact Ethernet length when
removing the Ethernet header later.
• IPv4 hdr: If the Ethernet Type field indicates IPv4, verify that the version field in the IPv4 hdr has the
value 4. If not 4, then drop and do not send to EIP-96, since packet is obviously corrupt.
• IPv4 hdr: Examine the IHL-field to determine if IPv4 options are available.
• IPv4 hdr (optional): For ECN (Explicit Congestion Notification) the ‘Type of Service’ field could be copied
from inner to outer header (and vice versa) for tunnel modes.
• IPv4 hdr: The packet length field should be stored in order to pass proper payload lengths to several
EIP-96 token commands
• IPv4 hdr: The protocol field should be stored to insert into IPv4chksum commands
• IPv4 hdr: The checksum should be validated before passing the packet to the EIP-96. The IPv4chksum
command can update the checksum, but does not verify its correctness.
• IPv4 hdr (AH transport only): Determine what options are mutable according to AH.
• IPv6 hdr: If the Ethernet Type field indicates IPv6, verify that the version field in the IPv6 hdr has the
value 6. If not 6, then drop and do not send to EIP-96, since packet is obviously corrupt.
• IPv6 hdr (optional): For ECN (Explicit Congestion Notification) the ‘Traffic Class’ field could be copied
from inner to outer header (and vice versa) for tunnel modes.
• IPv6 hdr: The payload length field should be stored in order to pass proper payload lengths to several
EIP-96 token commands.
• IPv6 hdr: Next header field should be stored to insert into IPv6 command and/or insert commands.
For an extensive set of example tokens, refer to document EIP-96 Operations Manual with Token Examples
[2].

007-096460-207
A.2 Postprocessing
A.2.1 Result Token
After the EIP-96 completes processing of a token, a result token is generated. If no errors occurred during
processing, output data will also be available.
For result token examples, refer to document EIP-96 Operations Manual with Token Examples [2].
A.2.2 Appended Data

When the EIP-96 is done with processing of a token, data is sometimes appended to the packet. When
appended data occurs, the result token gives information on what is appended, however it does not give
information in what order data is appended.
There are three instructions that cause different append bits to be set in the result token:
• result instruction with L, NH, CS bits not set -> hash bytes defined
• result instruction with L, NH and/or CS bits set -> L, NH and/or CS bit set
• replace instruction with undefined data to append -> B bit set
The order data is appended to the output data is the order the instructions were provided in the token. For
the result instruction with L, NH and/or CS bits set, the appended data order is always Length-NH-checksum.
As explained in Section 8.6.1.4 the appended fields are limited to a couple of use cases, therefore it is
assumed that all fields (when available as appended data) are always in the same order, since they are
appended by a single instruction.
A.2.3 Suggested Postprocessing Operations

During postprocessing the following operations should be considered and executed when applicable.
• Result token: verify that no error bits are set.
• Result token: test if Length (L-bit) has been appended. If so, replace the length in the IPv4 / IPv6 header
with the appended length. In the case of IPv6, bear in mind that the length in the IPv6 header is the
payload length and not the packet length.
• Result token: test if the next header (N-bit) has been appended. If so, replace the next header in the
IPv4- or IPv6-header (typically this bit is only set together with the L-bit).
• Result token: test if the checksum bit (C-bit) has been set and therefore a 16-bit checksum has been
appended. The checksum should replace the checksum in the IPv4 header (typically this bit is only set
together with the L- and N-bits)
• Decapsulated packets: Perform a TTL / HOP decrement on every inbound tunnel packet.
• Decapsulated packets (inbound): Copy ECN bits from outer to inner header (if desired).

007-096460-207
A.2.4 Rambus internal debugging options

The following debugging features are described for reference only, but should not be used.
A.2.4.1 The Upper layer header function bit

The Upper layer header function bit in the token header (U-bit, bit [29]).
This bit MUST be set to ‘0’ for normal operations, except for a few special use cases, see 7.2.1.1.9.
If this ‘U’ bit is set to ‘1’, the checksum register in the EIP-96 context space is written with the checksum
value supplied from the token (bits[15:0]). The checksum value in context space can then be used to either,
compare against the checksum in the packet header or it can be inserted in the packet header. See Sections
8.4.3, INSERT Instruction and 8.4.6, RETRIEVE Instruction.
In addition, when the ‘U’ bit is set to ‘1’, the following features are available:
1. In FIFO interface configurations (EIP-96*-f), when bit [16] of the inserted token word is set to ‘1’, the
current input token is considered as a token that is part of a chain of tokens all belonging to the same
packet. For all tokens with this bit set, it is assumed no packet done is received. In addition, these
tokens do NOT return a result token and the packet is not completed. The data processed under the
next token is concatenated to the current packet.
When bit [16] set to ‘0’ it has no effect on the processing. If this feature is used, all packets must have a
length, indicated in the packet_length field in the input token, of at least 4B.
2. In the FIFO interface configuration (EIP-96*-f), when bit [31] of the inserted token word is set to ‘1’, the
first 96B of the packet are redirected over the token output interface, ahead of the actual token. The
token is provided after these 96B. If the token has 4 (or more) bypass words, the first four bypass words
are returned as first token words, followed by the actual token and optional remaining bypass words. A
packet with less then 96B is padded to 96B, still the packet length fields in not affected. If this bit is set
to ‘1’, the ‘Zero length result packet’ configuration bit must be zero (‘0’), meaning the identifier is returned
as data word if the result packet has zero length.
When bit [31] of the inserted token word is set to ‘0’ it has no effect on the processing.
3. When the EIP-96 is embedded in Rambus more complex packet engines, such as EIP-197, the Firmware
could insert “detailed errors” (see section 10) using the ‘U-word’ (see section 7.2.1.8). This insertion of
detailed error information is allowed when detailed errors are enabled: bit 30 in register
EIP96_TOKEN_CTRL_STAT must be set to ‘1’. Detailed errors, which may be provided in the token by
the Firmware when the U-bit is set, are coded in U-word bits [30:24].
A.2.4.2 Bit [30] of the token header word

Bit [30] of the token header word can be used to create an EIP-197 compatible output token.
This bit MUST be set to ‘0’ for normal operations.
In FIFO interface configurations (EIP-96*-f) bit [30] of the EIP-96 input token header can be used to return
an EIP-197 compatible result token. If set to ‘1’, and the result token contains bypass fields, the first 32-bits
of the token bypass data are ‘compressed’ into the first 4 words of the result token and not present as a
separate bypass token data.
• Bits [15:5] of the first bypass data word are placed into a 2nd result token word at location [15:0].
• Bits [4:0] of the first bypass data word are placed into a 2nd result token word at location [20:17].
• Bits [27:16] of the first bypass data word are placed into a 4th result token word at location [27:16].
The result token has the following format (type 1):

007-096460-207
EIP-197 compatible result token (type 1)

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
E14
E13
E12
E11
E10
E9
E8
E7
E6
E5
E4
E3
E2
E1
E0
Optional token Optional
E15
L N C B hash bytes H bypass data
bypass data[4:0] token bypass data[15:5]
Reserved Optional token bypass data[27:16] pad info 1 pad info 0
bypass token data (optional: maximum of 5 words)

If the input token contains one or more bypass words, the first word (word 0) is removed.
The remaining optional words (1..4) are appended as bypass token data (words 0..3).
When bit [30] of the token header word is set and ip_len_delta_en field of the Output Buffer Control Register is
set to 1b, the result token has the following format (type 2):
EIP-197 compatible result token (type 2)
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
E14
E13
E12
E11
E10

E9
E8
E7
E6
E5
E4
E3
E2
E1
E0
Optional token Optional
E15
L N C B hash bytes H bypass data
bypass data[4:0] token bypass data[15:5]
IP_Len_Delta Optional token bypass data[23:16] pad info 1 pad info 0
bypass token data (optional: maximum of 5 words)

If the input token contains one or more bypass words, the first word (word 0) is removed.
The remaining optional words (1..4) are appended as bypass token data (words 0..3).
With type 2 result token, if the result token has fields L=1 and C=N=0, the IP header updates are required to
complete the IP header processing as part of the IPsec ESP inbound transport packet processing. Bits [31:24]
of the 4th result token become the field IP_Len_Delta. This field is calculated in the following way depending
on the IP version:
• IP_Len_Delta = Optional token bypass data[23:16] (in the case of IPv4 header processing).
• IP_Len_Delta = Optional token bypass data[23:16] + 40 (in the case of IPv6 header processing).
A.2.4.3 IRR bypass offset correction in length field

The IRR instruction is defined for IPv4 and IPv6 packets. However, when the EIP-96 is embedded in a system
where it receives packets directly from a physical interface, there may be bypass data in front of the IP
packet. The IRR instruction can correct the updated/inserted IP header length field such that this bypass
length is not included. This property of the IRR instruction may not be used when the EIP-96 is used as
stand-alone IP module. It is therefore considered a debug mode.

007-096460-207
IRR Instruction Example (Insert Length, Next Header, and Checksum) with bypass
In this example the inserted length is the ‘total length’ minus bypass offset. This is the ‘result packet length’
field in the result token minus the offset pointer used in this instruction.
Since the offset in the output stream must point to the length field, by default it is set to 2 for IPv4 and 4 for
IPv6. In case there is bypass data in front of the packet, the “offset in output stream” can be set to the bypass
length plus 2 (for IPv4) or 4 for (IPv6).
The inserted length is corrected based on the checksum setting. IPv4 is assumed with checksum
modification (bit[17] in the IRR instruction set to ‘0’).

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 0 1 0 1 1 x – – – – – – – y 1 – – – – – – – – – – – – – – – –
offset in output stream: The location in the output data stream to insert the actual packet length calculated
by the EIP-96 after packet processing. The offset minus (2 or 4) is subtracted from the inserted length. In the
case of IPv6, also the ‘length’-field value is subtracted from the inserted length. This is assumed to be set to
40 (0x28), representing the IPv6 header length.
If this field is set to 0xfffe, appropriate fields are appended to the packet. For packets that do not fit in the
EIP-96’s output packet buffer or for EIP-96-f small buffer configurations, the result is automatically
appended to the packet. When appending must be forced and an offset correction must be done, the actual
IP header offset can be subtracted from 0xfffe (when it is less then 254 bytes). The difference between
0xfffe and the programmed offset (when larger than 0xff00) is subtracted from the length field that is
appended after the packet. If the offset is odd, which means the LSB (bit[0]) of the ‘offset in the output
stream field’ is one, the appending is done shifted with 1 byte to ease the replacement in the result packet.
STAT[0]: This bit must be set to ‘0’, indicating that a checksum update is required as a result of this
operation. This bit is supposed to be cleared to ‘0’ with IPv4 and set to ‘1’ with IPv6.
CS: If set to ‘1’, this operation requires the checksum field to be updated.
For the description of the other fields, refer to 8.6.1.
A.2.4.4 Token Control Register 2

This register allows adapted behaviour when the EIP-96 is embedded in Rambus more complex packet
engines, such as EIP-97, EIP-196 and EIP-197.
EIP96_TOKEN_CTRL2, Read/Write, 32-bit address offset 0x002C
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
adv_fifo_mode
ctx_done_ctrl
Reserved
Reserved
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

007-096460-207
Bits Name Function

[0] adv_fifo_mode Enable EIP-197 FIFO mode.
When in EIP-197 FIFO mode, the optional Input Packet pointer in the input token is not
present, regardless of the value of the IP bit, see 7.2.1.2.
This allows redefining the IP bit to mean 'NOT Sequence number from token'. i.e. 0b
means that the sequence number is provided by the token, 1b means it is provided by
the context.
Sequence number from token is mutually exclusive with IV from token as it uses the
same input token words. If the IP bit is 0b, the IV field specifies which sequence number
words are present in the input token. IV0 maps to the lower 32 bits and IV3 maps to the
upper 16 or 32 bits. Currently, the only sensible values for the IV field are 3’b010 (32-bit
sequence number only) and 3’b100 (full 64-bit sequence number), see Table 16.
[2:1] Reserved Write with ‘0’, ignore on read.
[3] ctx_done_ctrl Enable EIP-96 Context done pulse.
When set to ‘1’, globally enables to assert the ctx_done output for one cycle, every time
the EIP-96 is done with the context record.

007-096460-207
B Context Record Fields

B.1 Key
All key data is little-endian, meaning B0 of an AES, DES, SM4 or BC0 key is located on bits [7:0] of Key 0, B1
on bits [15:8], etc. If a key is 256-bit long, all eight key words are used. For smaller key sizes, only the first n
words will contain key data.
As an exception, when using ChaCha20 128-bit keys, the key must be located at location Key 0 – Key 3 and
repeated at Key 4 – Key 7.
Word # Name Description Addr

Word 4 Key 2 3DES / AES / ChaCha20 / SM4 / BC0 0x04
Word 5 Key 3 3DES / AES / ChaCha20 / SM4 / BC0 0x05
Word 6 Key 4 3DES / AES{192,256} / ChaCha20 / BC0 0x06
Word 7 Key 5 3DES / AES{192,256} / ChaCha20 / BC0 0x07
Word 8 Key 6 AES{256} / ChaCha20 / BC0 0x08
Word 9 Key 7 AES{256} / ChaCha20 / BC0 0x09
The following is an example from NIST Special Publication 800-38A [Appendix F]. As indicated in the
example, Key data needs to be byte swapped when stored in the Context Record Key fields. The example
below is a detailed diagram specifying the byte order within a Key context word.
Example 1: AES-CBC 128-bit Decrypt.

NIST SP 800-38a:
AES Key In: 2b7e1516 28aed2a6 abf71588 09cf4f3c
IV In: 00010203 04050607 08090a0b 0c0d0e0f
AES Data In: 7649abac 8119b246 cee98e9b 12e9197d
AES Data Out: 6bc1bee2 2e409f96 e93d7e11 7393172a
Context record:
Key 0[31:0]: 16157e2b
Key 1[31:0]: a6d2ae28
Key 2[31:0]: 8815f7ab
Key 3[31:0]: 3c4fcf09
Detailed format of key words:

Example 1: Key 0
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Key 0
Byte 03 Byte 02 Byte 01 Byte 00
0x16 0x15 0x7e 0x2b
0 0 0 1 0 1 1 0 0 0 0 1 0 1 0 1 0 1 1 1 1 1 1 0 0 0 1 0 1 0 1 1

007-096460-207
Example 1: Key 1
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Key 1
0xa6 0xd2 0xae 0x28
1 0 1 0 0 1 1 0 1 1 0 1 0 0 1 0 1 0 1 0 1 1 1 0 0 0 1 0 1 0 0 0
The following is an example from [RFC8439]. Again, as indicated in the example, Key data needs to be byte
swapped when stored in the Context Record Key fields. The example below is a detailed diagram specifying
the byte order within a Key context word.
Example 2: Example and Test Vector for

AEAD_CHACHA20_POLY1305:
Key: 80818283 84858687 88898a8b 8c8d8e8f
90919293 94959697 98999a9b 9c9d9e9f
IV In: 40414243 44454647
Fixed part: 07000000
Counter: 00000000
AAD: 50515253 c0c1c2c3 c4c5c6c7
Plaintext: 4c616469 65732061 6e642047 656e746c ...
Ciphertext: d31a8d34 648e60db 7b86afbc 53ef7ec2 ...
Context record:
Key 0[31:0]: 83828180
Key 1[31:0]: 87868584
Key 2[31:0]: 8b8a8988
Key 3[31:0]: 8f8e8d8c
Key 4[31:0]: 93929190
Key 5[31:0]: 97969594
Key 6[31:0]: 9b9a9998
Key 7[31:0]: 9f9e9d9c
Detailed format of key words:

Example 2: Key 0
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Key 0
0x83 0x82 0x81 0x80
1 0 0 0 0 0 1 1 1 0 0 0 0 0 1 0 1 0 0 0 0 0 0 1 1 0 0 0 0 0 0 0
Example 2: Key 1
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Key 1
0x87 0x86 0x85 0x84
1 0 0 0 0 1 1 1 1 0 0 0 0 1 1 0 1 0 0 0 0 1 0 1 1 0 0 0 0 1 0 0

007-096460-207
B.2 Hash Digest

HMAC algorithm
The hashing procedure is applied to an input message (M) and an authentication key (K). The algorithm used
(with underlying hash function H) is HMAC-SHA-1, HMAC-SHA-2, HMAC-SHA-3, HMAC-SM3 or HMAC-MD5.
After calculating the result digest, it is compared to the received digest (in case of the receiver) to see if they
are the same, or it is appended to the outgoing packet (in case of the sender). If the comparison between
result digest and digest is not successful, the packet is discarded, and an event is logged.
The authentication key K is derived from the Internet Key Exchange procedure.
The result digest is generated as follows:
result digest = HMAC(K, M)
Where: HMAC = H[opad_key || H[ipad_key || M] ]
Where: opad_key = K+ XOR opad
ipad_key = K+ XOR ipad
With: K+ = K padded with zeroes up to the block size if length(K) ≤ blocksize, or
H[K] padded with zeroes up to the block size if length(K) > blocksize
opad = 0x5c, repeated to fill up the block size
ipad = 0x36, repeated to fill up the block size
HMAC Inner and Outer Digest Precalculation

The two padded key values are used to pre-calculate the inner and outer digest that need to be stored in
the Context Record:
outer_digest = H*[opad_key], (stored in the digest1 fields of Context Record)
inner_digest = H*[ipad_key], (stored in the digest0 fields of Context Record)
Note that H* is a basic hash operation that uses the initial digest of the hash algorithm and is not finished. In
other words, H* is the intermediate hash result of a single hash block calculation.
In this case, HMAC (K, M) can be rewritten as:
HMAC = HC[outer_digest, HC[inner_digest, M] ]
Where: HC[int_digest, M] = the hash continuation from intermediate digest int_digest with data
M. This saves one hash round over the padded key that is one hash block in size.
Refer to document [RFC2104].
Note that the precalculation can be performed using a single pass operation, applying the required
functions like H[K], H*[key], and updating the digest0 and digest1 fields of the Context Record with the
proper values and/or providing these fields on the output. Refer to [2] for examples.
HMAC SHA-3
Since an intermediate hash result for SHA-3 – having a size of 1600 bit – exceeds acceptable Context Record
storage limits, the HMAC algorithm for SHA-3 will follow the original result digest calculation scheme,
outlined above. This means that no Precalculation is performed for SHA-3, so the digest fields of the the
Context Record contains K+, which equals the original key value K or H[K], padded with zeroes up to the
block size of the used SHA-3 algorithm.

007-096460-207
Keyed-hash SHA-3
In addition, Keyed-hash is supported, using the SHA-3 algorithm.
The result digest is generated as follows:
result digest = HK(K, M)
Where: HK = H[K || M]
The supported key size |K| ranges from 1 byte to ‘block size’ bytes, where the block size is dependent on
the used SHA-3 algorithm (also see 9.2.1):
• SHA3-224: block size = 144 bytes (1152 bits)
B.2.1 SHA-1, SHA-2, SHA-3

The SHA specifications define the results of a hash calculation as a sequence of 32-bit words:
• W0 through W15 for SHA3-384/512 (only available in EIP-96*k configurations)
• W0 through W7 for SHA3-224/256 (only available in EIP-96*k configurations)
• W0 through W15 for SHA2-384/512 (only available in EIP-96*e configurations)
• W0 through W7 for SHA2-224/256
• W0 through W5 for SHA-1.
The following figure shows how bytes and words from the SHA specification are mapped onto EIP-96
context words. As can be seen, each word in the EIP-96 context is byte-swapped with respect to the original
SHA specifications (SHA is specified from a big-endian point of view).
Result of a SHA operation per the SHA spec.
Word0 Word1 Word2 Word3 ...

b0 b1 b2 b3 b4 b5 b6 b7 b8 b9 b10 b11 b12 b13 b14 b15 ...
b3 b2 b1 b0 b7 b6 b5 b4 b11 b10 b9 b8 b15 b14 b13 b12 ...
Word0 Word1 Word2 Word3 ...

32-bit little endian configuration of EIP-96 context
Figure 61 SHA-1, SHA-2, SHA-3 hash result endianness in context words

007-096460-207
Word # Field name Initialization contents Offset

Word k (<=10) Digest 0_0 / K2_0 / H_KEY_0 Word0 of SHA(ipad) (SHA-1, SHA-224/256) 0x0A
Word0 of SHA-3 (Key) (SHA3-224/256/384/512)
Word k+1 Digest 0_1 / K2_1 / H_KEY_1 Word1 of SHA(ipad) (SHA-1, SHA-224/256) 0x0B
Word k+2 Digest 0_2 / K2_2 / H_KEY_2 Word2 of SHA(ipad) (SHA-1, SHA-224/256) 0x0C
Word k+3 Digest 0_3 / K2_3 / H_KEY_3 Word3 of SHA(ipad) (SHA-1, SHA-224/256) 0x0D
Word k+4 Digest 0_4 / K3_0 Word4 of SHA(ipad) (SHA-1, SHA-224/256) 0x0E
Word k+5 Digest 0_5 / K3_1 Word5 of SHA(ipad) (SHA2-224/256) 0x0F
Word k+6 Digest 0_6 / K3_2 Word6 of SHA(ipad) (SHA2-224/256) 0x10
Word k+7 Digest 0_7 / K3_3 Word7 of SHA(ipad) (SHA2-224/256) 0x11
Word l Digest 1_0 / digest count / K1_0 Word0 of SHA(opad) (SHA-1, SHA2-224/256) 0x12
Word l+1 Digest 1_1 / K1_1 Word1 of SHA(opad) (SHA-1, SHA2-224/256) 0x13
Word l+2 Digest 1_2 / K1_2 Word2 of SHA(opad)(SHA-1, SHA2-224/256) 0x14
Word l+3 Digest 1_3 / K1_3 Word3 of SHA(opad) (SHA-1, SHA2-224/256) 0x15
Word l+4 Digest 1_4 Word4 of SHA(opad) (SHA-1, SHA2-224/256) 0x16
Word l+5 Digest 1_5 Word5 of SHA(opad) (SHA2-224/256) 0x17
B.2.2 SM3
The SM3 specification defines the result of a hash calculation as a sequence of 32-bit words:
• W0 through W7 (only available in EIP-96*c configurations)
The mapping of bytes and words from the SM3 specification onto EIP-96 context words is similar to SHA2-
256, as explained in Section B.2.1.

007-096460-207
B.2.3 MD5
The MD5 algorithm defines the result of a hash operation as a sequence of bytes b15..b0, as follows:
Result of a MD 5 operation per the MD 5 spec, in bit string format , per MD5 spec:
“abcdefghijklmnop”
a b c d e f g h i j k l m n o p
b0 b1 b2 b3 b4 b5 b6 b7 b8 b9 b10 b11 b12 b13 b14 b15
Result of a MD 5 operation per the MD 5 spec, in word A ,B,C,D format, per MD 5 spec:
Word A Word B Word C Word D
Word0 Word1 Word2 Word3

Figure 62 MD 5 hash result endiannes in context words
Note that the MD5 spec already assigns the bytes of the result stream to words A, B, C and D, in a little-
endian fashion (as shown in the figure). The EIP-96 simply assigns Word A to context Word 0, Word B to
context Word 1, etc.

Word k (<=10) Digest 0_0 / K2_0 / H_KEY_0 Word0 (WordA) of MD5(ipad) 0x0A
Word k+1 Digest 0_1 / K2_1 / H_KEY_1 Word1 (WordB) of MD5(ipad) 0x0B
Word k+2 Digest 0_2 / K2_2 / H_KEY_2 Word2 (WordC) of MD5(ipad) 0x0C
Word k+3 Digest 0_3 / K2_3 / H_KEY_3 Word3 (WordD) of MD5(ipad) 0x0D
Word l Digest 1_0 / digest count / K1_0 Word0 (WordA) of MD5(opad) 0x12
Word l+1 Digest 1_1 / K1_1 Word1 (WordB) of MD5(opad) 0x13
Word l+2 Digest 1_2 / K1_2 Word2 (WordC) of MD5(opad) 0x14
Word l+3 Digest 1_3 / K1_3 Word3 (WordD) of MD5(opad) 0x15
B.2.4 Poly1305
The Poly105 algorithm uses a 32-byte one-time authenticator key (OTK), partitioned into two 128-bit keys
as inputs, the R key and the S key. When Poly1305 is used as standalone basic MAC, these keys are loaded
via the Hash Digest 1 field, as indicated in the next diagrams.

007-096460-207
Context – Control Format

B 3 2 1 0
W 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0
Context control words
1
Hash Digest 1
Word # Field name Content Offset

Word l Digest 0_16 / Digest 1_0 / K1_0 Poly1305 r_key (bits [31:0]) 0x1A
Word l+1 Digest 0_17 / Digest 1_1 / K1_1 Poly1305 r_key (bits [63:32]) 0x1B
Word l+2 Digest 0_18 / Digest 1_2 / K1_2 Poly1305 r_key (bits [95:64]) 0x1C
Word l+3 Digest 0_19 / Digest 1_3 / K1_3 Poly1305 r_key (bits [127:96]) 0x1D
Word l+4 Digest 0_20 / Digest 1_4 / K1_4 Poly1305 s_key (bits [31:0]) 0x1E
Word l+5 Digest 0_21 / Digest 1_5 / K1_5 Poly1305 s_key (bits [63:32]) 0x1F
Word l+6 Digest 0_22 / Digest 1_6 / K1_6 Poly1305 s_key (bits [95:64]) 0x20
Word l+7 Digest 0_23 / Digest 1_7 / K1_7 Poly1305 s_key (bits [127:96]) 0x21
Alternatively, when used together with ChaCha20, the EIP-96 can be configured to let the ChaCha20
algorithm generate an OTK, which is provided to the Poly1305 algorithm directly, instead of any key(s)
available in the context record. The OTK will not be made available in the context record.
The Poly1305 algorithm defines the result (TAG) of a MAC operation as a sequence of bytes b15..b0, as
follows:
Result of a poly1305 operation per the Poly1305 spec, in bit string format:
“abcdefghijklmnop”
a b c d e f g h i j k l m n o p
Result of a poly1305 operation per the Poly1305 spec, in Word A,B,C,D format:
Word A Word B Word C Word D
Word 0 Word 1 Word 2 Word 3

Figure 63 Poly1305 MAC result endiannes in context words
Note that the Poly1305 spec already assigns the bytes of the result stream to words A, B, C and D, in a little-
endian fashion (as shown in the figure). The EIP-96 simply assigns Word A to context Word 0, Word B to
context Word 1, etc.

007-096460-207
B.2.5 CRC-32
CRC-32 algorithm is defined in IEEE 802.3. The CRC-32 operation in EIP-96 is supported as hash operation
and can be used stand alone and also in combination with other cipher algorithms. The CRC-32 algorithm
works on byte basis, so supports messages not multiple of 4 bytes.
CRC-32 can be used for a single complete CRC operation. In such case, there is no need for digest fields to
be present in the context.
CRC-32 can also be used in a chained manner: starting from the default state for one packet, saving the
state into the Context Record and loading this state for the next packet. CRC-32 initialization is controlled as
described in section 9.2.1. Note that the intermediate states are "closed", meaning that the actual 32-bit
state is internally XOR-ed with 0xffffffff before it is returned in DIGEST0_0 field in the context record, as if it
were the final CRC-32 result. For proper continuation, this same "closed" state must be provided in
DIGEST0. Consequently, reusing an intermediate CRC-32 state from a different source requires that the host
must first close the CRC-32 intermediate state by XOR-ing with 0xffffffff before providing it to the
DIGEST0_0 field of the context. Likewise, reusing the intermediate CRC-32 state outside the EIP-96 requires
that the host must first reverse the closed CRC-32 state by XOR-ing the DIGEST0_0 value with 0xffffffff
before presenting it elsewhere.
The output of the CRC-32 algorithm is an integer value in little-endian format. The same endianness is used
when inserting the CRC-32 into the packet or saving the CRC-32 result into the Context Record: byte zero
(lowest significant byte) is inserted first and so on.
B.2.6 AES-GCM (GHASH) Precalculation

AES-GCM MAC for IPsec requires that one key is derived from the original AES key (K) that is used as key (H)
for the GHASH operation.
This key (H) is calculated by encrypting a 128-block of zeroes using the AES key (K):
H = E(K, 0128)
The result of the encryption operation will be a 128-bit value for each the GHASH key H. This values need to
be stored in the digest0. Assume the result of an AES encryption is a 128-bit wide bit sequence, with bit [0]
shown at the left-hand side, as per the AES specification, which is stored in 32-bit dwords on a little-endian
machine, as follows:
Result bit stream of AES encryption
0 1 2 3 4 5 6 7 ... 29 30 31 32 33 34 35 36 37 38 39 ... 124 125 126 127
31 30 29 29 ... 2 1 0 Word 1 Word 2 Word 3
Word 0[31:0] (little endian system)
Figure 64 AES-GCM (GHASH) pre-calculation result endianness

The AES results are stored in the context fields, as follows:

007-096460-207

Word k (<=10) Digest 0_0 / K2_0 / H_KEY_0 Word0 of AES(K, 0x0000....) 0x0A
Word k+1 Digest 0_1 / K2_1 / H_KEY_1 Word1 of AES(K, 0x0000....) 0x0B
Word k+2 Digest 0_2 / K2_2 / H_KEY_2 Word2 of AES(K, 0x0000....) 0x0C
Word k+3 Digest 0_3 / K2_3 / H_KEY_3 Word3 of AES(K, 0x0000....) 0x0D
B.2.7 AES-XCBC-MAC Precalculations

AES-XCBC MAC for IPsec requires that three keys be derived from the original AES key, as described below:
K1 = 0x01010101010101010101010101010101 encrypted with Key K
The result of the encryption operation will be a 128-bit value for each key K1, K2 and K3. These values need
to be stored in the digest0 and digest1 fields. Assume the result of an AES encryption is a 128-bit wide bit
sequence, with bit #0 shown at the left-hand side, as per the AES specification, which is stored in 32-bit
machine words on a little-endian machine, as follows:
Result bit stream of AES encryption
0 1 2 3 4 5 6 7 ... 29 30 31 32 33 34 35 36 37 38 39 ... 124 125 126 127
31 30 29 29 ... 2 1 0 Word 1 Word 2 Word 3
Word 0[31:0] (little endian system)
Figure 65 AES XCBC precalculation result endianness

The AES results are stored in the context fields, as follows:
Word k (<=10) Digest 0_0 / K2_0 / H_KEY_0 Word0 of AES(K, 0x0202....) 0x0A
Word k+1 Digest 0_1 / K2_1 / H_KEY_1 Word1 of AES(K, 0x0202....) 0x0B
Word k+2 Digest 0_2 / K2_2 / H_KEY_2 Word2 of AES(K, 0x0202....) 0x0C
Word k+3 Digest 0_3 / K2_3 / H_KEY_3 Word3 of AES(K, 0x0202....) 0x0D
Word k+4 Digest 0_4 / K3_0 Word0 of AES(K, 0x0303....) 0x0E
Word k+5 Digest 0_5 / K3_1 Word1 of AES(K, 0x0303....) 0x0F
Word k+6 Digest 0_6 / K3_2 Word2 of AES(K, 0x0303....) 0x10
Word k+7 Digest 0_7 / K3_3 Word3 of AES(K, 0x0303....) 0x11
Word l Digest 1_0 / digest count / K1_0 Word0 of AES(K, 0x0101....) 0x12
Word l+1 Digest 1_1 / K1_1 Word1 of AES(K, 0x0101....) 0x13
The reason for having K1 'last' is that in the XCBC 'base' specification, K1 is the only key that is actually used
as key input to the AES algorithm; K2 and K3 are only used for XOR operations with AES result data.
Therefore, it can be expected that K2 and K3 will never exceed the size of an AES block (128 bits), whereas
K1 will scale with the key size used for AES in the AES-XCBC algorithm. The current configuration allows this
longer key to be stored in the Context Record without requiring extensive modifications to the existing HW.
At this point however the EIP-96 only support the AES-XCBC method as defined within the IPsec RFC's, using
128-bit AES keys.

007-096460-207
B.2.8 AES-XTS Key2 loading

The AES-XTS algorithm can use two keys, dependent on the mode of operation. When two keys are
required, the second key (Key2) is loaded via the Hash Digest 1 field, as explained below.
Attention: When selecting AES-XTS, it is not allowed to enable a Hash Algorithm, therefore the Type of
Packet (ToP) field must be set to ‘0100’ or ‘0101’. Digest_Type and Hash_Algorithm must be set to
zeroes.

B 3 2 1 0
W 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0
1
Cipher Key
Hash Digest 1
This field is used to load Key2 for the AES-XTS algorithm.
IV fields
The Key 1 must be provided to the Cipher Key field, if key loading is not used. If key loading is used, it is
received via the key loading interface.
The Key 2 must be provided to the Hash Digest 1 field. Size of the field is 4, 6 and 8 x 32-bit words for 128-bit,
192-bit and 256-bit key respectively.
The ‘i’ or Tx (depending on chosen pre-calculation method) must be provided to the IV field. If ‘i’ or Tx is
loaded from the input token, the content of this field is ignored during the operation. If crypto state is saved
to the context, after the operation this field contains the last used Tx.
B.2.9 Wireless algorithm – Authentication modes

B.2.9.1 Kasumi
B.2.9.2 Encryption
The context for encryption consists of only a 64-bit key and optional 64-bit IV.
B 3 2 1 0
W 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0
1
Cipher Key
Optional IV fields

007-096460-207
B.2.9.3 Authentication
Kasumi authentication only uses a digest. Since digests have a minimum size of four words, a 128-bit value
must be provided via the context. In this value the 64-bit kasumi key must be stored, as indicated in the
next diagrams.
B 3 2 1 0
W 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0
1
Digest0[127:0] -- Integrity Key (128-bits)

Word k (<=10) Digest 0_0 / K2_0 / H_KEY_0 Kasumi F9 Key Word 0 (bits [31:0]) 0x0A
Word k+1 Digest 0_1 / K2_1 / H_KEY_1 Kasumi F9 Key Word 1 (bits [63:32]) 0x0B
Word k+2 Digest 0_2 / K2_2 / H_KEY_2 Reserved 0x0C
Word k+3 Digest 0_3 / K2_3 / H_KEY_3 Reserved 0x0D
B.2.9.4 SNOW and ZUC

The EIP-96 only embeds a single SNOW and ZUC module. Therefore SNOW and ZUC can only be used either
to encrypt/decrypt a packet or to authenticate a packet. No combined modes are possible in combination
with SNOW and ZUC.
B.2.9.5 Encryption (UEA)

The SNOW and ZUC algorithms require several parameters to be provided ahead of the actual cipher
operation. All parameters, except for the key, have to be provide via the IV. The EIP-96 supports several IV
loading options. For SNOW and ZUC the IV can be completely from the token or it can be stored in the SA
record and from the token the count bytes are updated.
B 3 2 1 0
W 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0
1
Cipher Key
Optional IV fields

007-096460-207
B.2.9.6 Authentication (Integrity, UIA)

The SNOW and ZUC algorithms require a 128-bit initialization value. This 128-bit value must be stored in the
general purpose registers available via token instructions. A 16 bytes write to the internal context address
5’h0A completes this initialization vector.
Note: Writing the four general purpose registers MUST be the first instruction of the token. Since any
instruction that processes data enables the initialization vector loading from these registers.
B 3 2 1 0
W 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0
1
Digest0[127:0] -- Integrity Key (128-bits)

Word k (<=10) Digest 0_0 / K2_0 / H_KEY_0 SNOW/ZUC UIE Key Word 0 (bits [31:0]) 0x0A
Word k+1 Digest 0_1 / K2_1 / H_KEY_1 SNOW/ZUC UIE Key Word 1 (bits [63:32]) 0x0B
Word k+2 Digest 0_2 / K2_2 / H_KEY_2 SNOW/ZUC UIE Key Word 2 (bits [95:64]) 0x0C
Word k+3 Digest 0_3 / K2_3 / H_KEY_3 SNOW/ZUC UIE Key Word 3 (bits [127:96]) 0x0D
B.3 SPI
The Security Parameter Index to be put in outbound ESP or AH packets or to be verified in the case of
inbound ESP or AH packets. The SPI is not changed by any operation. This is a little-endian number.
B.4 Sequence number processing

B.4.1 Introduction
The EIP-96 contains logic generating sequence numbers and logic to check sequence numbers (replay,
window).
The explicit sequence numbering is used in ESP, AH, DTLS and MACsec operations to specify the anti-replay
sequence value that is placed in the header (outbound), or checked for inbound packets. For SSL/TLS, the
sequence number is not transmitted but used to authenticate and count accepted inbound packets. The
EIP-96 manages this counter value for both inbound and outbound operations.
The sequence number is an integer value represented in little-endian format. The length of the sequence
number is programmable using SEQ field of the Context Record (see Section 9.2).
The sequence number mask (further referred to as ‘mask’) works together with the sequence number. The
mask is used in IPsec, DTLS and MACsec protocols to specify the anti-replay mask value for inbound
operations; it is not used for outbound operations. The sequence number should be the most recent
(highest) sequence number. The mask then represents with a single bit per packet, the number of
sequential packets in the past and whether these have been successfully received (bit set), or not (bit
cleared). Two types of mask implementation exist:
1. Normal masks, with replay protection up to and including 384 bits: The mask field is regarded as a little-
endian string of bits. The bit with the lowest index represents the packet with the most recent
sequence number and is therefore always set to ‘1’. All other bits represent sequential packets in the
past.

007-096460-207
2. XL masks, with replay protection of 2^M, and more than 384 bits, e.g., a 1024-bit mask in case M=10:
The mask field is regarded as a big-endian string of 2^M bits. The bit representing the packet with the
most recent sequence number S has index (S MOD 2^M) and will therefore always be set to ‘1’. All
other bits represent sequential packets in the past. The reason for this different implementation for XL
masks is that it allows to update only some, typically small, portions of the mask, instead of always
having to update the full mask like for "normal masks".
A block diagram of the sequence number logic is illustrated below.
EIP-96
Context RAM
Internal context result of RETRIEVE
memory sequence instruction
context fetch number
Context record overflow
32/48/64-bit
check
counter
CONTEXT_ACCESS
sequence number instruction sequence number increment result sequence
low (seq. num. update) low number high
sequence number sequence number result sequence
Context DMA
high high number low

mask0 IPSec
est imation
CONTEXT_ACCESS
mask1 instruction
(mask update)
mask... result sequence number low
maskN {3,7,11,...} mask0 on/off
mask1 highest packet

received processing mask update
mask.. result on/off
seq.num.
maskN {3,7,11,...}
replay check
result of
sequence
number check
Figure 66 Sequence number processing logic
The sequence number processing logic contains the following components:

• Increment logic. The increment logic is used to auto increment the sequence number and check for
overflow of the increment. Possible boundaries of 32, 48 or 64-bit counter are defined by setting the
SEQ field of the context control word 0. This logic is triggered at the beginning of processing the new
packet but after the fetch/reuse of the context.
• IPsec estimation logic. In the case of an inbound packet with IPsec extended sequence numbering
(ESN), this logic does an estimation of the upper sequence number according to [RFC4303]. This
estimated upper sequence number is used for authentication and later for replay check. The IPsec ESN
estimation is triggered when the origin value 5’b10011 (seq_num result) is written using RETRIEVE
instruction.
The estimation logic can be switched off by setting the ‘ Seq_Num_Store’ bit in the context control word,
allowing all words associated with the sequence number to be provided from the input using the
RETRIEVE instruction.
• Replay check logic. This logic does a replay check within a defined window (32, 64, 128 wide or any
larger supported window size) and an ‘out of the window’ check. In the case of successful replay check
and correct packet processing, the result sequence number and mask are stored back to the context.
• The mask update logic for normal masks can be switched off to allow only an ‘out of the window’ check.
This provides for the implementation of any window size (1-128) by changing the mask value.

007-096460-207
• The XL masks allow a reduced window check and update, the reduction to an 2^L-bit window is
selectable on packet basis between 64 and 2^M bits.
B.4.2 Sequence number overflow

For outbound processing, when a sequence number overflow is detected, a ‘Sequence number roll-over
detected’ error is generated and the sequence number value in the context contains all zeroes, which is the
updated (wrapped around) value.
For inbound processing, when a sequence number overflow is detected, a ‘Sequence number roll-over
detected’ error is generated and the sequence number value in the context contains all ones, which is the
maximum allowed sequence number. This error in combination with settings F=0 and P=1 in the
CONTEXT_ACCESS instruction will not update the sequence number field in the context memory.
Both of these cases are exceptions, and the host should start a new packet with a new Context Record.
Threshold values for the sequence number can be programmed for early detection of sequence number
rollover, see C.1.6 and C.1.6.2.
B.4.3 Sequence number check

Table 38 identifies the processing modes supported with inbound sequence number checking. This table is
applicable if ‘Ext_CTX_Format’ is set to ’0’.
Note that ‘strict-order inbound processing’ rejects packets with sequence numbers less than the highest
received. This is valid when all bits of active mask (Mask0 and Mask1) are set to ‘1’ and the ‘disable mask
update’ bit is also set to ‘1’.
Table 38 Modes with inbound sequence number checking
Sequence Mask Context Control Word 1 Context Control Word 0[31:28]

Numbering (window) disable Seq_Num_ macsec Mask1 Mask0 SEQ1 SEQ0
Mode width mask Store1 seq_num_c
update hk
IPsec normal 64 0 x 0 0 1 0 1
sequence 322 1 0
numbering
128 1 1
IPsec extended 64 0 0 0 0 1 1 1
sequence 32 1 0
numbering
128 1 1
48-bit sequence 64 0 1 0 0 1 1 0
number replay 32 1 0
check
128 1 1
64-bit sequence 64 0 1 0 0 1 1 1
number replay 32 1 0
check
128 1 1
32-bit with only 64max 1 x 0 0 1 0 1
sliding window 128max 1 1
check
48-bit with only 64 max 1 1 0 0 1 1 0
sliding window 128 max 1 1
check
64-bit with only 64 max 1 1 0 0 1 1 1
sliding window 128max 1 1
check

007-096460-207

Numbering
MACsec (window)
32 1 1 1 0 1 0 1
Mode
sequence width
number
checking
1
This bit disables IPsec Extended Sequence number estimation.
2
The 32-bit wide window mode is implemented as a particular case of the 64-bit wide window mode. The host
must set all bits of ‘sequence number mask 1’ field to ‘1’ and the EIP-96 updates only lower 32-bits (‘sequence
number mask 0’) during processing. The value of ‘sequence number mask 1’ is used to reject packets with
sequence number outside of the 32-bit wide (but within the 64-bit wide) window. Other values of sequence
number will be processed as in normal 64-bit wide window.
When ‘Ext_CTX_Format’ is set to ‘1’, the following table applies. This feature (‘Ext_CTX_Format’) should only be
used with IPsec inbound operations and allows an extended mask/replay window width of 256-bits or 384-
bits respectively.
Table 39 Modes with inbound sequence number checking for extended masks

Mode width mask Store seq_num
update _chk
IPsec normal 64 0 x 0 0 0 0 0
sequence 128 0 1
numbering
384 1 0
with extended
mask options 256 1 1
IPsec 64 0 0 0 0 0 0 1
extended 128 0 1
sequence
384 1 0
numbering
with extended 256 1 1
mask options
When the configuration supports XL masks, ‘Ext_CTX_Format’ is set to ‘1’, and the ‘Context_Size’ field is set to
less than 32 [words] except 0, the inbound operation is processed using an XL mask. The following table
applies.
Table 40 Modes with inbound sequence number checking for XL masks

Mode width mask Store seq_num
update _chk
IPsec normal reserved 0 x 0 0 0 0 0
sequence 1024 0 1
numbering
reserved 1 0
with XL mask
options reserved 1 1
IPsec reserved 0 0 0 0 0 0 1
extended 1024 0 1
sequence
reserved 1 0
numbering
with XL mask reserved 1 1
options

007-096460-207
The sequence number check is performed during processing and is reported when the packet is done.
Optionally the context update can be executed or discarded if a check fails.
Note that some RFCs advise to perform an initial sequence number (anti-replay) check before a packet is
processed to prevent a DoS attack. This initial sequence number check can be done outside the EIP-96
before the packet is passed to the EIP-96. When implementing this initial external check, the current
sequence number and mask from the Context Record can be used. Independent of the result, the sequence
number or mask should never be updated externally, however, that packet must be dropped if it is replayed
(check fails). Therefore, there is no need to update the sequence number and mask externally, since this is
done by the EIP-96 if the packet is processed completely and all other checks pass.
B.4.4 IPsec sequence numbering, sliding window

This section describes the operation of IPsec sequence numbering for normal and extended sequence
number masks.
Suppose that the sequence number in the Context Record has the value 2000; the following cases could
happen.
Case 1: A packet with sequence number 2020 is received. This sequence number is in advance of what has
been received so far (2000 was the most recent), so the new sequence number in the Context Record
becomes 2020. In addition, the mask is shifted over (from lowest index to highest index) by 20 bits (2020 -
2000) with zeroes inserted. The least significant bit, now representing the packet with sequence number
2020, is set to ‘1’.
Case 2: A packet with sequence number of 1800 is received, appearing in the past and falls outside the
window. The sequence number and mask are not updated and the packet is to be dropped. The ‘sequence
number check error’ is generated.
Case 3: The packet with sequence number of 1980 is received, appearing in the past but within the window
of 64 (128) packets. The bit with index 20 (2000 - 1980) is set.
• If this bit is already set, then a packet with sequence number 1980 has already been received, so this
packet is dropped. The Context Record is not updated. The ‘sequence number check error’ is
generated. This is a replay protection case.
• If this bit is not set, then a packet with sequence number 1980 has not been previously received. This
fact is recorded by setting the mask bit with index 20 to ‘1’ and updating the Context Record. The
sequence number is not updated.
B.4.5 IPsec sequence numbering, fixed window

This section describes the operation of IPsec sequence numbering for XL sequence number masks.
Suppose that the sequence number in the Context Record has the value 2000; the following cases could
happen.
Case 1: A packet with sequence number 2020 is received. This sequence number is in advance of what has
becomes 2020. In addition, the mask is cleared (i.e. written with zeroes) between bit positions (2000 MOD
2^M) and (2020 MOD 2^M). The bit at position (2020 MOD 2^M), now representing the packet with
sequence number 2020, is set to ‘1’.
Case 2: Assume an XL mask of 2^M = 2^10 = 1024. A packet with sequence number 2060 is received. This
sequence number is in advance of what has been received so far (2000 was the most recent), so the new
sequence number in the Context Record becomes 2060. In addition, the mask is cleared (i.e. written with
zeroes) above bit positions (2000 MOD 2^M = 976) and below (2060 MOD 2^M = 12). The bit at position
(2060 MOD 2^M = 12), now representing the packet with sequence number 2060, is set to ‘1’.
Case 3: A packet with sequence number of 800 is received, appearing in the past and falls outside the
window 2^M, and outside 2^L if a reduced mask is selected. The sequence number and mask are not
updated and the packet is to be dropped. The ‘sequence number check error’ is generated.
Case 4: A packet with sequence number of 1800 is received, with selected reduced mask 2^L = 2^7 = 128.
The packet is appearing in the past and within the window 2^M, but it falls outside the window 2^L = 2^7 =

007-096460-207
128 which is the selected reduced mask. The sequence number and mask are not updated and the packet is
to be dropped. The ‘sequence number check error’ is generated.
Case 5: The packet with sequence number of 1980 is received, appearing in the past but within the window
of 2^M (or 2^L) packets. The bit with index (1980 MOD 2^M) is set.
• If this bit was already set, then a packet with sequence number 1980 has already been received, so this
packet is dropped. The Context Record is not updated. The ‘sequence number check error’ is
generated. This is a replay protection case.
• If this bit was not set, then either
 a packet with sequence number 1980 has not been previously received, or
 a packet with this number was received previously but then fell outside a reduced mask window –
and was dropped accordingly without updating the mask.
This fact is recorded by setting the mask bit with index (1980 MOD 2^M) to ‘1’ and updating the
Context Record. The sequence number is not updated.
B.4.6 MACsec sequence numbering

This section describes the operation of MACsec sequence numbering.
Suppose that the sequence number in the Context Record has the value 2001, and the mask has the value
150; the following cases could happen.
Case 1: The packet with sequence number 2020 is received. This sequence number is in advance of what has
becomes 2021. The mask is never changed/updated with MACsec sequence numbering.
Case 2: The packet with sequence number of 1800 is received, appearing in the past and falls below the
mask, since 2001-150>1800. The sequence number is not updated and the packet is to be dropped. The
‘sequence number check error’ is generated.
Case 3: The packet with sequence number of 1980 is received, appearing in the past but within the mask.
The sequence number is not updated.
B.5 IV
Like Key data, all IV data is little-endian. The IV can be fetched and stored to the IV location in the Context
Record.
If (3)DES is used, IV 0 and 1 contain IV data. For AES/SM4/BC0-CBC and ChaCha20 mode, all four IV words
are valid. For AES/SM4/BC0-CTR mode the Nonce will always be part of the context, stored in the location of
IV 0; optionally IV 1, IV 2 and IV 3 can be used to fetch and store an intermediate IV.

Word p (<=33) IV 0 / NONCE Optional for all crypto operations. 0x31
Can optionally be placed in token .
Word p+1 IV 1 Optional for all crypto operations. 0x32
The following is an example from NIST Special Publication 800-38A [Appendix F]. As indicated in the
example, IV data needs to be byte swapped when stored in the Context Record IV fields. Below the example
is a detailed diagram specifying the byte order within an IV context word.
Example 1: AES-CBC 128-bit Decrypt.

007-096460-207
NIST SP 800-38a:
AES Key In: 2b7e1516 28aed2a6 abf71588 09cf4f3c
IV In: 00010203 04050607 08090a0b 0c0d0e0f
AES Data In: 7649abac 8119b246 cee98e9b 12e9197d
AES Data Out: 6bc1bee2 2e409f96 e93d7e11 7393172a
Context record:
IV 0[31:0]: 03020100 (or NONCE)
IV 1[31:0]: 07060504
IV 2[31:0]: 0b0a0908
IV 3[31:0]: 0f0e0d0c
Example 1: IV 0
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
IV 0
0x03 0x02 0x01 0x00
0 0 0 0 0 0 1 1 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0
For ChaCha20, the mapping of the 32-bit counter and per-packet IV is made consistent with AES-CTR mode.
The incrementing (block-)counter is mapped to IV3, the 96-bit per-packet IV is mapped to IV0, IV1, IV2.
The following is an example from [RFC8439]. As indicated in the example, IV data needs to be byte swapped
when stored in the Context Record IV fields. Below the example is a detailed diagram specifying the byte
order within an IV context word.
Example 2: Example and Test Vector for

AEAD_CHACHA20_POLY1305:
Key: 80818283 84858687 88898a8b 8c8d8e8f
90919293 94959697 98999a9b 9c9d9e9f
IV In: 40414243 44454647
Fixed part: 07000000
Counter: 00000000
AAD: 50515253 c0c1c2c3 c4c5c6c7
Plaintext: 4c616469 65732061 6e642047 656e746c ...
Ciphertext: d31a8d34 648e60db 7b86afbc 53ef7ec2 ...
Context record:
IV 0[31:0]: 00000007 (or NONCE)
IV 1[31:0]: 43424140
IV 2[31:0]: 47464544
IV 3[31:0]: 00000000
Example 2: IV 0
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
IV 0
0x00 0x00 0x00 0x07
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1

007-096460-207
Note that when using CTR, ChaCha20 and ICM mode in their native form (CTR and ChaCha20 require a 32-
bit counter, ICM requires a 16-bit counter), the counter values must be reset. For Counter Mode (CTR) and
ChaCha20, the 32 bits of the counter (IV 3) must be set to represent ‘one’ (0x01000000) and for ICM, the 16
bits of the counter (byte 03 and 02 of IV 3) must be set to zero (0x0000????, where ‘?’ is don’t care and may
be any value). A user has the flexibility to load a different initial counter value. Note that if ChaCha20 is used
to generate a one-time authenticator key for Poly1305, the counter should be set to zero (0x00000000).
However, when loading a counter that has not been reset, be aware that the EIP-96 implements a 32-bit
wide counter that rolls-over to zero at 232-1. When loading a different initial counter value, the user is
responsible for detection or prevention of the counter overflow. When using counter mode as ‘mode of
operation’, the counter should never overflow since it is a potential security risk if the same IV is used twice
(in combination with counter modes). If the reset values are used on a per packet bases, an overflow will
never happen. A packet will not contain over 16*216 bytes that need to be encrypted (in combination with
ICM). For CTR mode a packet can theoretically contain 16*2 32 - 32 payload bytes, before the counter
overflows. For ChaCha20, 64-byte blocks are counted, which is enough for 64*232 bytes.
Refer to Table 15 for the IV loading options.
B.6 ARC4 State Record and I/J pointer

Word q (<=37) ARC4 State Record pointer Optional for ARC4 (EIP-96is / EIP-96ies) 0x35
Word q+1 ARC4 I/J pointer [15:0] Optional for ARC4 (EIP-96is / EIP-96ies) 0x36
The ARC4 State Record pointer points to the ARC4 State Record.
Absolute ARC4 pointer (EIP-96is, EIP-96ies, EIP-96iesw, EIP-96ieswx and EIP-96ieswxk): If this bit [18] in
register EIP96_TOKEN_CTRL_STAT is ‘0’, the ARC4 pointer in the Context Record is a relative pointer from
the base address of the context pointer in the token. If this bit is set to ‘1’, the ARC4-pointer in the Context
Record is an absolute pointer to the ARC4 State Record.
The most significant bit of the ARC4 State Record pointer indicates whether this is an absolute pointer or a
relative pointer. In the latter case, the used external DMA address is the context pointer, incremented with
the ARC4 State Record pointer.
B.7 Examples for most common scenarios

The examples below identify which (context) fields are present in the different operating scenarios. For
protocol operations, typical initialization values have also been supplied in appendix B.7.7
B.7.1 Basic encrypt operation

Field length (in dwords)
Command 2
Key Algorithm dependent (Refer to Section 9.1)
IV Optional and only for CBC and CTR modes: 2 (+2 in case of AES)
B.7.2 Basic hash operation

Command 2
Digest Algorithm dependent (Refer to Section 9.1)

007-096460-207
B.7.3 Combined basic encrypt hash operations

Command 2
Key Algorithm dependent (Refer to Section 9.1)
Digest0 Algorithm dependent(Refer to Section 9.1)
IV Optional and only for CBC and CTR modes: 2 (+2 in case of AES)
B.7.4 IPsec hash only operation

Command 2
SPI 1
Sequence number 1 (+1 in case of extended sequence numbers)
Sequence number Only for inbound packets: 2 (+2 in case of extended sequence numbers)
mask
B.7.5 IPsec encrypt only operation

Command 2
Key Algorithm dependent
SPI 1
mask
B.7.6 IPsec combined encrypt hash operation

Command 2
Key Algorithm dependent
Digest0 Algorithm dependent
Digest1 Only for MD5, SHA-1, SHA-2, SHA-3, SM3: Algorithm dependent
SPI 1
mask
B.7.7 Typical initialization values for IPsec operation

SPI, Keys Value is determined during tunnel setup
Digests Typically contain the results of the precalculated inner- and outer hash digests for HMAC;
refer to Appendix B.2. for more details on digest formatting.
Sequence number 32’b0 or 64’b0 in case of extended sequence numbers. Least significant part of 64-bit
number is located in word 0
Sequence number 64’b1 128’b1. (the ‘1’ bit to appear in word 0, rightmost bit, or bit #0 on the data bus)
mask

007-096460-207
C Register and Memory Map

Note: Together with this document you may also have received an IP-XACT database with register
information. In the case of discrepancies between this document and the IP-XACT file, the latter
should be considered leading. The default/reset value of some registers depends on the actual
configuration and in that case the exact value can be found in the IP-XACT database.
Table 41 Register and Memory Map
Register Register Name R/W Reset Description

Address Default
(byte)
Configuration Registers
TOKEN CONTROL
0x0000 EIP96_TOKEN_CTRL_STAT R/W 0x00004004 Token control / status
0x0004 EIP96_FUNCTION_EN R/W 0xFFFFFFFF Protocol and Algorithm enable
CONTEXT CONTROL
0x0008 EIP96_CONTEXT_CTRL R/W 0x00000235 Context control
0x000C EIP96_CONTEXT_STAT R 0x00000000 Context status
DATA FETCH CONTROL
0x0010 Reserved R 0x00000000
0x0014 EIP96_IN_TRANS_CTRL_STAT R/W See C.1.5.1 Input transfer control / status
0x0018 EIP96_OUT_TRANS_CTRL_STAT R/W See C.1.5.2 Output transfer control / status
0x001C EIP96_OUT_BUF_CTRL R/W 0x00000000 Output buffer control
0x0020 EIP96_SEQ_NUM32_THR R/W 0x00000000 Early detection threshold 32-bit
0x0024 EIP96_SEQ_NUM64_THR_L R/W 0x00000000 Early detection threshold 64-bit
0x0028 EIP96_SEQ_NUM64_THR_H R/W 0x00000000 Early detection threshold 64-bit
0x002C EIP96_TOKEN_CTRL2 R/W 0x00000000 Ext. Token control
0x0030 EIP96_FUNCTION2_EN R/W 0xFFFFFFFF Ext. Protocol and Algorithm enable
0x0034- Reserved R 0x00000000
0x003C
(internal) PRNG
0x0040 PRNG_STAT R 0x00000000 PRNG Status word
0x0044 PRNG_CTRL R/W 0x00000000 PRNG Control
0x0048 PRNG_SEED_L [31:0] W 0x00000000 PRNG Seed value
0x004C PRNG_SEED_H [63:32] W 0x00000000 PRNG Seed value
0x0050 PRNG_KEY_0_L [31:0] W 0x00000000 PRNG Key register 0
0x0054 PRNG_KEY_0_H [63:32] W 0x00000000 PRNG Key register 0
0x0058 PRNG_KEY_1_L [31:0] W 0x00000000 PRNG Key register 1
0x005C PRNG_KEY_1_H [63:32] W 0x00000000 PRNG Key register 1
0x0060 PRNG_RES_0 [31:0] R 0x00000000 Pseudo random result
0x006C PRNG_RES_3 [127:96] R 0x00000000 Pseudo random result
0x0070 PRNG_LFSR_L [31:0] R/W 0x00000000 PRNG Counter register
0x0074 PRNG_LFSR_H [63:32] R/W 0x00000000 PRNG Counter register
0x0078- Reserved R 0x00000000
0x007C

007-096460-207
TOKEN DATA
0x0080 Active Token word 0 R 0x00000000
0x008C Active Token word 3 R 0x00000000
0x009C Active Token word 7 R 0x00000000
0x00A0 Active Token word 8 R 0x00000000
0x00AC Active Token word 11 R 0x00000000
0x00B0 Active Token word 12 R 0x00000000
0x00BC Active Token word 15 R 0x00000000
0x00C0 Next token word0 / Active word16 R 0x00000000
0x00CC Next token word3 / Active word19 R 0x00000000
0x00D0 Next token word4 / Active word20 R 0x00000000
0x00DC Next token word7 / Active word23 R 0x00000000
0x00E0 Next token word8 / Active word24 R 0x00000000
0x00EC Next token word11 / Active word27 R 0x00000000
0x00F0 Next token word12 / Active word28 R 0x00000000
0x00FC Next token word15 / Active word31 R 0x00000000
0x0100 Result token word0 R 0x00000000
0x010C Result token word3 R 0x00000000
0x011C Result token word7 R 0x00000000
0x0120- reserved R 0x00000000
0x013C
CONTEXT
0x0140 Next context CMD0 R 0x00000000
0x0144 Next context CMD1 R 0x00000000
0x0148 Next general-purpose 0 R 0x00000000
0x014C Next general-purpose 1 R 0x00000000
0x0150 Next IV0 R 0x00000000
0x0154 Next IV1 R 0x00000000

007-096460-207
0x0158 Next IV2 R 0x00000000

0x015C Next IV3 R 0x00000000
0x0160 Next Key0 R 0x00000000
0x0164 Next Key1 R 0x00000000
0x0168 Next Key2 R 0x00000000
0x016C Next Key3 R 0x00000000
0x0170 Next Key4 R 0x00000000
0x0174 Next Key5 R 0x00000000
0x0178 Next Key6 R 0x00000000
0x017C Next Key7 R 0x00000000
0x0180 Next Inner Digest0 R 0x00000000
0x018C Next Inner Digest3 R 0x00000000
0x0194 Next Inner Digest5 – SHA2/XCBC R 0x00000000
0x0198 Next Inner Digest6 – SHA2/XCBC R 0x00000000
0x019C Next Inner Digest7 – SHA2/XCBC R 0x00000000
0x01A0 Next Outer Digest0 R 0x00000000
0x01AC Next Outer Digest3 R 0x00000000
0x01B0 Next Outer Digest4 R 0x00000000
0x01B4 Next Outer Digest5 – SHA2 R 0x00000000
0x01B8 Next Outer Digest6 – SHA2 R 0x00000000
0x01BC Next Outer Digest7 – SHA2 R 0x00000000
0x01C0 Next digest count R 0x00000000
0x01C4 Next SPI / SSRC R 0x00000000
0x01C8 Next Sequence number R 0x00000000
0x01CC Next Extended sequence number R 0x00000000
0x01D0 Next Sequence number mask0 R 0x00000000
0x01DC Next Sequence number mask3 R 0x00000000
0x01E0 Reserved R 0x00000000
0x01E4 Next Checksum (16-bit) R 0x00000000
0x01E8 Next I-J pointer – ARC4 (16-bit) R 0x00000000
0x01EC Next ARC4 pointer – ARC4 R 0x00000000
0x01F0- Reserved R 0x00000000
0x01FC
0x0200 Active context CMD0 R 0x00000000
0x0204 Active context CMD1 R 0x00000000
0x0208 Active general-purpose 0 R 0x00000000
0x020C Active general-purpose 1 R 0x00000000
0x0210 IV0 R 0x00000000
0x0214 IV1 R 0x00000000
0x0218 IV2 R 0x00000000
0x021C IV3 R 0x00000000
0x0220 Key0 R 0x00000000
0x0224 Key1 R 0x00000000

007-096460-207
0x0228 Key2 R 0x00000000

0x022C Key3 R 0x00000000
0x0230 Key4 R 0x00000000
0x0234 Key5 R 0x00000000
0x0238 Key6 R 0x00000000
0x023C Key7 R 0x00000000
0x0240 Inner Digest0 R 0x00000000
0x024C Inner Digest3 R 0x00000000
0x0254 Inner Digest5 – SHA2/XCBC R 0x00000000
0x0258 Inner Digest6 – SHA2/XCBC R 0x00000000
0x025C Inner Digest7 – SHA2/XCBC R 0x00000000
0x0260 Outer Digest0 R 0x00000000
0x026C Outer Digest3 R 0x00000000
0x0274 Outer Digest5 – SHA2 R 0x00000000
0x0278 Outer Digest6 – SHA2 R 0x00000000
0x027C Outer Digest7 – SHA2 R 0x00000000
0x0280 digest count R 0x00000000
0x0284 SPI / SSRC R 0x00000000
0x0288 Sequence number R 0x00000000
0x028C Extended sequence number R 0x00000000
0x0290 Sequence number mask0 R 0x00000000
0x029C Sequence number mask3 R 0x00000000
0x02A0 Reserved R 0x00000000
0x02A4 Checksum (16-bit) R 0x00000000
0x02A8 I-J pointer – ARC4 (16-bit) R 0x00000000
0x02AC ARC4 pointer – ARC4 R 0x00000000
0x02B0- Reserved R 0x00000000
0x02BC
0x02C0 Hash result0 R 0x00000000
0x02CC Hash result3 R 0x00000000
0x02D0 Hash result4 R 0x00000000
0x02D4 Hash result5 – SHA-2, SHA-3, SM3 R 0x00000000
0x02D8 Hash result6 – SHA-2, SHA-3, SM3 R 0x00000000
0x02DC Hash result7 – SHA-2, SHA-3, SM3 R 0x00000000
0x02E0 digest count result R 0x00000000
0x02E4 SPI retrieved R 0x00000000
0x02E8 sequence number retrieved R 0x00000000
0x02EC extended sequence number calculate R 0x00000000
0x02F0 Checksum result (16-bit) R 0x00000000

007-096460-207
0x02F4- Reserved R 0x00000000

0x02FC
0x0300 Next Inner Digest8 – SHA-384/512 R 0x00000000
0x0304 Next Inner Digest9 – SHA-384/512 R 0x00000000
0x0308 Next Inner DigestA – SHA-384/512 R 0x00000000
0x030C Next Inner DigestB – SHA-384/512 R 0x00000000
0x0310 Next Inner DigestC – SHA-384/512 R 0x00000000
0x0314 Next Inner DigestD – SHA-384/512 R 0x00000000
0x0318 Next Inner DigestE – SHA-384/512 R 0x00000000
0x031C Next Inner DigestF – SHA-384/512 R 0x00000000
0x0320 Next Outer Digest8 – SHA-384/512 R 0x00000000
0x0324 Next Outer Digest9 – SHA-384/512 R 0x00000000
0x0328 Next Outer DigestA – SHA-384/512 R 0x00000000
0x032C Next Outer DigestB – SHA-384/512 R 0x00000000
0x0330 Next Outer DigestC – SHA-384/512 R 0x00000000
0x0334 Next Outer DigestD – SHA-384/512 R 0x00000000
0x0338 Next Outer DigestE – SHA-384/512 R 0x00000000
0x033C Next Outer DigestF – SHA-384/512 R 0x00000000
0x0340 Inner Digest8 – SHA-384/512 R 0x00000000
0x0344 Inner Digest9 – SHA-384/512 R 0x00000000
0x0348 Inner DigestA – SHA-384/512 R 0x00000000
0x034C Inner DigestB – SHA-384/512 R 0x00000000
0x0350 Inner DigestC – SHA-384/512 R 0x00000000
0x0354 Inner DigestD – SHA-384/512 R 0x00000000
0x0358 Inner DigestE – SHA-384/512 R 0x00000000
0x035C Inner DigestF – SHA-384/512 R 0x00000000
0x0360 Outer Digest8 – SHA-384/512 R 0x00000000
0x0364 Outer Digest9 – SHA-384/512 R 0x00000000
0x0368 Outer DigestA – SHA-384/512 R 0x00000000
0x036C Outer DigestB – SHA-384/512 R 0x00000000
0x0370 Outer DigestC – SHA-384/512 R 0x00000000
0x0374 Outer DigestD – SHA-384/512 R 0x00000000
0x0378 Outer DigestE – SHA-384/512 R 0x00000000
0x037C Outer DigestF – SHA-384/512 R 0x00000000
0x0380 Hash Result8 – SHA-384/512, SHA3-384/512 R 0x00000000
0x0384 Hash Result9 – SHA-384/512, SHA3-384/512 R 0x00000000
0x0388 Hash ResultA – SHA-384/512, SHA3-384/512 R 0x00000000
0x038C Hash ResultB – SHA-384/512, SHA3-384/512 R 0x00000000
0x0390 Hash ResultC – SHA-384/512, SHA3-384/512 R 0x00000000
0x0394 Hash ResultD – SHA-384/512, SHA3-384/512 R 0x00000000
0x0398 Hash ResultE – SHA-384/512, SHA3-384/512 R 0x00000000
0x039C Hash ResultF – SHA-384/512, SHA3-384/512 R 0x00000000
0x03A0- Reserved R/W 0x00000000
0x03BC
INTERRUPT CONTROLLER
0x03C0 AIC_POL_CTRL R 0x0000000F Polarity control
0x03C4 AIC_TYPE_CTRL R 0x0000000F Level/edge control
0x03C8 AIC_ENABLE_CTRL R/W 0x00000000 Interrupt enable control
0x03CC AIC_RAW_STAT / AIC_ENABLE_SET R/W 0x00000000 ‘Raw’ stat. of int./Enable int.
masked

007-096460-207
0x03D0 AIC_ENABLED_STAT / AIC_ACK R/W 0x00000000 Masked stat. of int./Edge detect

ack/
0x03D4 AIC_ENABLE_CLR W - Disable interrupts masked
0x03D8 AIC_OPTIONS R 0x00000004 AIC options register
0x03DC AIC_VERSION R 0x013?36C9 AIC ID/version register
PROTOCOL CONTROL
0x03E0 EIP96_ECN_TABLE0 R/W 0x03020100 ECN Table 0
0x03E4 EIP96_ECN_TABLE1 R/W 0x57010150 ECN Table 1
0x03E8 EIP96_ECN_TABLE2 R/W 0x03025D58 ECN Table 2
0x03EC EIP96_ECN_TABLE3 R/W 0x03030360 ECN Table 3
0x03F0 EIP96_ECN_ERR_CFG R/W 0x99992904 IPsec Tunnel Error Configuration
CONFIGURATION AND VERSION
0x03F4 Reserved R/W 0x00000000
0x03F8 EIP96_OPTIONS R 0x?????000 Type and Configuration
0x03FC EIP96_VERSION R 0x040?9F60 Version register
EXTENDED CONTEXT
0x0400 Next Sequence number large mask0 R 0x00000000 Next Large mask [31:0]
0x0404 Next Sequence number large mask1 R 0x00000000
0x040C Next Sequence number large mask3 R 0x00000000
0x047C Next Sequence number large mask31 R 0x00000000 Next Large mask [1023:992]
0x0480- Reserved R 0x00000000
0x05FC

007-096460-207
0x0600 Sequence number large mask0 R 0x00000000 Current Large mask [31:0]
0x0604 Sequence number large mask1 R 0x00000000
0x060C Sequence number large mask3 R 0x00000000
0x067C Sequence number large mask31 R 0x00000000 Current Large mask [1023:992]
0x0680- Reserved R 0x00000000
0x07FC

007-096460-207
C.1 Configuration registers

The following sections describe the configuration and status registers which apply to the entire EIP-96.
These registers should be initialized prior to packet processing and not be changed during normal operation.
Reserved bits should be written with a zero and should be ignored on a read.
C.1.1 Token Control

C.1.1.1 Token Control / Status Register
EIP96_TOKEN_CTRL_STAT, Read/Write, 32-bit Address offset 0x0000
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Debug Control General Control Allow postponed context reuse Stat Debug status Status (read only)
Zero len.res. packet (EIP-96-f)
Abs. ARC4 ptr (EIP-96is/ies)

Detailed error codes enable
Allow reuse cached context
CT no token wait (EIP-96-f)
Packets to be processed
Time-out counter enable
Optimal context updates
Token location available

Processing held – IDLE
Result token available

Context cache active
Process N packets
Token read active

Hold processing
Result context
Active tokens
Context fetch
Debug mode
Busy
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 1 0 0
Bits Name Function

[1:0] Active tokens Number of tokens located in the EIP-96, result token not included (maximum is two).
[2] Token A new token can be read by the EIP-96.
location
available
[3] Result token A (partial) result token is available in the EIP-96.
available
[4] Token read A token is currently read by the EIP-96.
active
[5] Context The context cache contains a new context
cache active
[6] Context fetch The context cache is currently filled
[7] Result The context cache contains result context data that needs to be updated
context
[13:8] Packets to be Indicates the remaining number of packets to be processed before the processing is held.
processed Valid in debug mode only, see bit [23].
[14] Processing No (part of) tokens are in the EIP-96 and no context update required
held – IDLE
[15] Busy EIP-96 is busy (a context is active)
[16] Optimal Pipelines the context updates. This allows the engines to perform context updates and
context unlocks to be performed after the next packet processing has started
updates
[17] CT no token (EIP-96-f)
wait If this bit is zero, the EIP-96 always waits for active token processing to complete when
reusing a context, anticipating late context updates in the token (safe). If this bit is set to ‘1’,
the EIP-96 will not wait if the CT bit in the token header was set (auto seq update), assuming
no context updates will be present.

007-096460-207
[18] Absolute (EIP-96is and EIP-96ies)

ARC4 pointer If this bit is zero, ARC4 pointers in the Context Record are relative pointers from the base
address of the context pointer in the token. If this bit is set to ‘1’, ARC4-pointers in the
Context Record are absolute pointers to the ARC4 State Record.
[19] Allow reuse If this bit is zero, only two consecutive packets using the same Context Records are reused.
cached This is achieved by either selecting reuse context or automatic context reuse in a token
context (token header bits [21:20] are set to 2’b01 or 2’b10 respectively). When the ‘allow reuse
cached context’ bit is set to one and automatic context reuse is selected in the token (token
header bits [21:20] are set to 2’b10), a cached context of the second last packet can be
reused. This reduces the required context fetches to a minimum.
The use of this feature is restricted and may only be enabled under the following conditions:
• External logic does not rely on fetching of a Context Record, since this option makes the
context fetching dynamic dependent on the actual processing status.
• Original context addresses are not reused or automatic reuse is disabled for a packet that
is using a Context Record for the first time.
When a context is reused, no fetch is done by the EIP-96.
[20] Allow By default the EIP-96 does not reuse Context Records when the engine starts from an IDLE
postponed state, but only when it is active.
context reuse If this bit is set to one, the state of the EIP-96 is ignored, and the reuse detection logic is
enabled for every new packet. This means, if the EIP-96 detects context reuse -even when the
core has been IDLE for many clock cycles- the corresponding Context Record is not fetched.
There is one exception, if the core is hard resetted the EIP-96 never reuses a Context Record.
[21] Zero length (EIP-96-f)
result packet If this bit is zero, the EIP-96 writes out the identifier word via the data output FIFO interface if
the result packet is empty (result length equals zero and no fields appended). If this bit is set
to one, zero length result packets do not provide any data on the data output interface. The
main reason to have this bit set to zero is to have simple synchronization between data and
token, since each packet will be visible on both interfaces. This bit is only available and
applicable in the EIP-96-f configurations; for the standard EIP-96 configurations no DMA is
requested if the result packet is empty.
[22] Time-out Enables the time-out counter that generates an error in case of a “hang” situation. If this bit
counter is not set, the time-out error can never occur. (See Chapter 9).
enable
[23] Debug mode Enables the EIP-96 debug mode. In this mode, a specific number of packets can be processed
while the processing can be stopped after every token.
Debug-only control fields
[29:24] Process N A fixed number of packets will be processed. A write to this register increments the number
packets of packets that will be processed with the written value. Valid values are 0 (minimum) to 63
(maximum), but the sum of Process N packets and Packets to be processed may not exceed 63.
[30] Detailed error Enables returning the detailed error codes in the result token, instead of the all one-hot
codes enable encoded normal error codes. (see Table 36)
[31] Hold Stops processing packets after the currently loaded token. If this bit is cleared, the number of
processing packets that needed to be processed is continued.

007-096460-207
C.1.1.2 Extended Token Control Register

Note: This register is only available for the EIP-96 configurations with FIFO interfaces, so the EIP-96*-f
configurations. Otherwise, this register is “Reserved”.
EIP96_TOKEN_CTRL2, Read/Write, 32-bit address offset 0x002C

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
context_done_if_ena
fetch_ovs_chk_dis
prep_ovs_chk_dis
seq_append_ena
adv_fifo_mode
Reserved
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
Bits Name Function

[0] adv_fifo_mode When set to ‘1’, globally enables FIFO mode, no input packet pointer in token. Legacy
IP bit = ‘0’ indicates sequence number in token mode, ‘1’ = IV in token mode.
Note: only defined for configurations with FIFO interface, EIP-96*-f. Otherwise write
with zero, ignore on read.
[1] prep_ovs_chk_dis A setting of ‘1’ indicates that the preprocessor oversize check is disabled. Instead of
generating a length error (E0), the excess data is just silently flushed.
Note: only defined for configurations with FIFO interface, EIP-96*-f. Otherwise write
with zero, ignore on read.
[2] fetch_ovs_chk_dis A setting of ‘1’ indicates that the fetch oversize check is disabled. Instead of generating
a length error (E0), the excess data is just silently flushed.
[3] context_done_if_ena A setting of ‘1’ enables the context_done interface.
[4] seq_append_ena A setting of ‘1’ enables the seq. number append feature. See CCW0[14] in Table 32.
[31:5] Reserved Write with zero, ignore on read.
C.1.1.3 Protocol/Algorithm Enable Register

This register allows software on the Host system to determine the hardware capabilities that it can access.
The CRC is always enabled.
EIP96_FUNCTION_EN, Read/Write, 32-bit address offset 0x0004
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
ARC4(EIP-96is / EIP-96ies)
AES-XCBC-MAC
hash-only / null
AES-CTR/ICM
HMAC SHA-2
HMAC SHA-1
hash-decrypt
hash-encrypt
decrypt-hash
encrypt-hash
basic SHA-2
basic SHA-1
encrypt-only
GCM-HASH
HMAC MD5
3DES-CBC
3DES-OFB
3DES-ECB
3DES-CFB
Kasumi-F9
basic MD5
DES-CBC
DES-OFB
AES-CBC
DES-ECB
AES-OFB
DES-CFB
AES-ECB
AES-CFB
AES-XTS
Wireless
SHA-3
1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

007-096460-207
Bits Name Function

[31:0] - A setting of ‘1’ indicates that the protocol or algorithm is enabled.
A ‘0’ setting indicates that it is disabled and therefore inaccessible.
If a disabled algorithm is selected in the context, an error will be generated.

007-096460-207
C.1.1.4 Extended Protocol/Algorithm Enable Register

This register allows software on the Host system to determine the hardware capabilities that it can access in
addition to the ones from (EIP96_FUNCTION_EN).
EIP96_FUNCTION2_EN, Read/Write, 32-bit address offset 0x0030
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
external BC0
ChaCha20
Reserved
Poly1305
SM4
SM3
1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
Bits Name Function

[4:0] - A setting of ‘1’ indicates that the protocol or algorithm is enabled.
A ‘0’ setting indicates that it is disabled and therefore inaccessible.
If a disabled algorithm is selected in the context, an error will be generated.
[31:5] Reserved
C.1.2 Context Control

C.1.2.1 Context Control Register
This register configures the context size and context fetching mode.
EIP96_CONTEXT_CTRL, Read/Write, 32-bit address offset 0x0008
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Reserved Mode Size
address mode
control mode
Reserved Context_Size (dwords)
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 1 - 0 1 0 1
Bits Name Function

[7:0] Context_Size Indicates the size (in dwords) of the context that must be fetched. Valid values range from
0x02 for only the control words, to 0x35 (or 0x37, or 0x3E, refer to Section 9.1) for all context
words (records without XL masks), or 0x52 for records including XL masks. The fetch modes in
which this register is used are described in Section 5.2. The reset value is the default context
size applicable for the specific configuration. This is 0x25 for EIP-96i and EIP-96is
configurations and 0x35 for EIP-96ie and EIP-96ies configurations.
[8] Address When set to ‘1’ (with bit 9 set to ‘0’) 1, selects a fetch of the Context Record as defined in
Mode Section 9.1, always starting from Control Word 0. Refer to Section 5.2.
[9] Control Mode When set to ‘1’ (with bit 8 set to ‘0’) 1, selects a fetch of only relevant context fields. Refer to
Section 5.2.
[31:10] Reserved
1
If both bits [9:8] are set to ‘1’, control of the Context Fetch Mode is passed to bit [31] of Control Word 1.

007-096460-207
C.1.2.2 Context Status Register

This register provides the context status of the currently active packet.
EIP96_CONTEXT_STAT, Read-only, 32-bit address offset 0x000C
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Status Active Packet Errors
(Active) Packet Processing
NextPacketCurrentState
# Available Tokens
Error Recovery
Result Context
Active Context
Next Context
CurrentState
Reserved
Reserved
Reserved
E14
E13
E12
E11
E10
E9
E8
E7
E6
E5
E4
E3
E2
E1
E0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
Bits Name Function

Active Packet Errors
[0] E0 Packet length error: token instructions versus input or input DMA fetch
In the standard EIP-96 error E0 occurs when either the pre-processor detects a wrong length
(instruction lengths, version packet length) or if the input DMA fetch reports an error. This
latter can not happen in the EIP-96-f, however a similar case is detected and reports the
same error instead. If data_in_done is asserted before the number of written words matches
with the packet length field from the input token the EIP-96-f will trigger E0.
[1] E1 Token error, unknown token command/instruction
[2] E2 Token contains too much bypass data.
[3] E3 Cryptographic block size error
[4] E4 Hash block size error (basic hash only)
[5] E5 Invalid command/algorithm/mode/combination
[6] E6 Prohibited algorithm
[7] E7 Hash input overflow (basic hash only)
[8] E8 TTL / HOP-limit underflow
[9] E9 Authentication failed
[10] E10 Sequence number check failed / Sequence number roll-over detected
[11] E11 SPI check failed
[12] E12 Checksum incorrect
[13] E13 Pad verification failed
[14] E14 Time-out - FATAL ERROR
[15] Reserved
Status
[17:16] Available The number of available tokens is the sum of new, active and result tokens that are available.
Tokens
[18] Active Active context indicates that a context is active.
Context
[19] Next Context Next context indicates that a new context is (currently) loaded.
[20] Result If set to ‘1’, indicates that a result context data needs to be stored. Result context and next
Context context cannot be both active.
[21] Error If set to ‘1’, indicates that an existing error condition has not yet been properly handled to
recovery completion. Note that the next packet context and data fetch can be started. In addition,
error bits may still be active due to the previous packet.
[22] Reserved

007-096460-207
[23] Reserved
[27:24] (Active) Packet processing current state reflects the current state of the packet processing for the
Packet active packet. It is out of the scope of this document to provide the detailed state encoding.
Processing This field is read-only and should be treated as ‘reserved’.
Current State
[31:28] Next Packet Next packet current state reflects the current state of the next packet. It is out of the scope of
Current State this document to provide the detailed state encoding. This field is read-only and should be
treated as ‘reserved’.
C.1.3 Data Fetch Control

The next two registers control the input buffer write and output buffer read processes. In the standard EIP-
96 configurations, both input and output data buffers have a size of 2048 bytes. These registers can be used
to optimize data transfers between the 2k-byte memories of the standard EIP-96 and memory across a
system bus.
In the EIP-96-f small buffers configuration, the input buffer is removed and the output buffer restricted to
320 bytes. These changes disable the registers for configuring the input and output DMA.
Due to these different behavior and access capabilities, the descriptions of the next two registers are split-
up in two parts, the first sub-section (Appendix C.1.4) describes the registers for the standard EIP-96, the
next sub-section (Appendix C.1.5) describes the registers for the EIP-96-f.
C.1.4 Standard EIP-96 Input and Output transfer Control/Status Register

C.1.4.1 Input transfer Control/Status Register
EIP96_IN_TRANS_CTRL_STAT, Read/Write, 32-bit address offset 0x0014

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Control Status
Transfer size mask (dwords) Max transfer size (dwords) Min transfer size (dwords) Available dwords
1 1 1 1 1 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 1 1 1 1 1 1 1 1
Bits Name Function

[7:0] Available Indicates the number of 32-bit entries that are available (free) in the buffer.
dwords
[15:8] Min. transfer Indicates the minimum number of 32-bit words that must be transferred per DMA transfer
size request. If the minimum transfer size is set to zero, at least one dword will be transferred per
DMA transfer request.
[23:16] Max. transfer Indicates the maximum number of 32-bit words that may be transferred per DMA transfer
size request. If the maximum transfer size is set to zero, up to 0x100 dwords (or 256 decimal
dwords) may be transferred.
[31:24] Transfer size Masks the number of available 32-bit entries (available dwords) to obtain an optimal transfer
mask size. This mask can be used to prevent that inefficient transfers are set up. The mask must
consist of a number of ones followed by a number of zeroes (it must be possible to write it
like: {{N{1’b1}}, {8-N{1’b0}}}). The maximum transfer size overrules the masked transfer size.
If the minimum size is set to zero, it is forced to ‘1’. If the maximum size is set to zero the maximum transfer
size is 29.
The mask will be forced such that a valid mask is created where a transfer of the minimum transfer size is
possible.
C.1.4.2 Output Transfer Control/Status Register

007-096460-207
EIP96_OUT_TRANS_CTRL_STAT, Read/Write, 32-bit address offset 0x0018

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Control Status
1 1 1 1 1 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 1 1 1 1 1 1 1 1
Bits Name Function

[7:0] Available Indicates the number of 32-bit entries that are available (free) in the buffer.
dwords
[15:8] Min. transfer Indicates the minimum number of 32-bit words that must be transferred per DMA transfer
size request. If the minimum transfer size is set to zero, at least one dword will be transferred per
DMA transfer request.
[23:16] Max. transfer Indicates the maximum number of 32-bit words that may be transferred per DMA transfer. If
size the maximum transfer size is set to zero, up to 512 dwords may be transferred.
[31:24] Transfer size Masks the number of available 32-bit entries (available dwords) to obtain an optimal transfer
mask size. This mask can be used to prevent that inefficient transfers are setup. The maximum
transfer size overrules the masked transfer size.

007-096460-207
C.1.4.3 Output Buffer Control Register
EIP96_OUT_BUF_CTRL, Read/Write, 32-bit address offset 0x001C

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Reserved Output bytes
block_update_append
Reserved Hold output data Reserved
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
Bits Name Function

[7:3] Hold output data This setting holds a minimum amount of packet data in the output buffer until the
EIP-96 completed the processing of the packet. The value represents a number of
64-bit data blocks that must be held in the packet output buffer (for each individual
packet) before it is provided on the output. This value may be programmed from
zero up to 16 blocks (thus 0 to 128 bytes).
[31] block_update_append This field controls what happens with the IP header updates if they cannot be
applied internally by the EIP-96 because of the output packet being larger than the
size of the output buffer or internal updates are not supported.
0b – The EIP-96 appends the IP header updates to the end of the output packet.
1b – The EIP-96 does not append the IP header updates to the end of the output
packet while the L, N and C flags in the result token indicate which IP header updates
need to be completed.
The background for this feature lies in a scenario where the EIP-96 is used in a look-aside environment
where the source and destination packet are overlapping (thus using a shared memory location). If the EIP-
96 is inserting data in front of or in the packet header it can happen that this result data byte stream is
larger and available in the output buffer sooner than it reads the last packet bytes from the input packet.
Therefore, if a system uses in-place transforms it is suggested to program this field to a value equal to the
maximum number of inserted header bytes for the required protocols. For the typical use cases, the
maximum is 64 bytes (40 IPv6 tunnel header bytes and 24 ESP header bytes) which requires 0x08 to be
programmed to the Hold output data field).

007-096460-207
C.1.5 EIP-96-f Input and Output transfer Control/Status Register

The Input Buffer Transfer/Control and Status register (EIP96_IN_TRANS_CTRL_STAT) is not available in
this configuration and returns zero on a read.
The Output Buffer Transfer/Control and Status register (EIP96_OUT_TRANS_CTRL_STAT) is still available.
The DMA functionality is not available and does not influence the external behavior of the output FIFO
interface. For small buffer configurations, the ‘Available dwords’ status fields return the number of available
dwords in the 80-dword (320 bytes) sized output buffer, or 512-dword (2048 bytes) for large buffer
configurations.
C.1.5.1 Input Transfer Control/Status Register
Reserved, 32-bit address offset 0x0014

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Control Status
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
Note: The reset value of this register depends on the EIP-96 configuration. For the non-FIFO
configuration the value is 0xFE080207. For the FIFO (-f) configuration the value is 0x00000000.
C.1.5.2 Output Transfer Control/Status Register
EIP96_OUT_TRANS_CTRL_STAT, Read/Write, 32-bit address offset 0x0018

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Fixed Status
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
Note: The reset value of this register depends on the EIP-96 configuration. For the non–FIFO
configuration the value is 0xF88008FF. For the FIFO (-f) configuration with small buffers the value
is 0xFE40044F.
Bits Name Function

[7:0] Available Indicates the number of dwords entries that are available (free) in the data output buffer.
dwords Note that, for small buffer configurations, the buffer has 80 locations of which one location is
always available to allow for misaligned internal writes
[15:8] Min. transfer Indicates the minimum number of dwords that is transferred per beat (a beat is a sequence
size of dword transfers provided on the output interface without stalling). If the minimum
transfer size is set to zero, at least one dword will be transferred per DMA transfer request.
[23:16] Max. transfer Indicates the maximum number of dwords that can be transferred per beat.
size
[31:24] Transfer size Transfer size mask: Masks the number of available dword entries to obtain an optimal
mask transfer size. Since this implementation has a FIFO interface, a beat can have any length and
therefore the mask contains all ones, allowing all beat sizes.

007-096460-207
C.1.5.3 Output Buffer Control Register
EIP96_OUT_BUF_CTRL, Read/Write, 32-bit address offset 0x001C

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Reserved Output bytes
block_update_append
ip_len_delta_en
Reserved Hold output data Reserved
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
Bits Name Function

[7:3] Hold output data This setting holds a minimum amount of packet data in the output buffer until the EIP-
96 completed the processing of the packet. The value represents a number of 64-bit
data blocks that must be held in the packet output buffer (for each individual packet)
before it is provide on the output. This value may be programmed from zero up to 16
blocks (thus 0 to 128 bytes).
[30] ip_len_delta_en This field is applicable only if bit [30] of the input token header is set (‘Result Token
Compression’ mode) which is described in Appendix A.2.4.2.
0b - The ‘IP_Len_Delta’ field is not present in the EIP-197 compatible result token
(type 1)
1b - The ‘IP_Len_Delta’ field is present in the EIP-197 compatible result token
(type 2).
[31] block_update_append This field controls what happens with the IP header updates if they cannot be applied
internally by the EIP-96 because of the output packet being larger than size of the
output buffer or internal updates are not supported.
0b – The EIP-96 appends the IP header updates to the end of the output packet.
1b – The EIP-96 does not append the IP header updates to the end of the output
packet while the L, N and C flags in the result token indicate which IP header updates
need to be completed.
The background for this feature lies in a scenario where the EIP-96 is used in a look-aside environment
where the source and destination packet are overlapping (thus using a shared memory location). If the EIP-
96 is inserting data in front of or in the packet header it can happen that this result data byte stream is
larger and sooner available in the output buffer than it reads the last packet bytes from the input packet.
Therefore, if a system uses in-place transforms it is suggested to program this field to a value equal to the
maximum number of inserted header bytes for the required protocols. For the typical use cases, the
maximum is 64 bytes (40 IPv6 tunnel header bytes and 24 ESP header bytes) which requires 0x08 to be
programmed to the ‘Hold output data’-field).

007-096460-207
C.1.6 Sequence Number Thresholds

C.1.6.1 Sequence Number 32-bit Threshold Register
EIP96_SEQ_NUM32_THR, Read/Write, 32-bit address offset 0x0020

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Threshold
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
Bits Name Function

[31:0] Threshold 32-bit threshold value applicable for 32-bit sequence numbers, outbound-only.
Setting the threshold unequal to 0 will generate error bit E11, once the sequence number
equals or exceeds the threshold value. In that case, bit E11 must not be regarded an ‘error’,
but rather a ‘note’.
When set or kept to all zeroes, E11 will have its default meaning.
This feature can be used for early detection of the sequence number rollover event, when setting it a
number of packets below the rollover point.
C.1.6.2 Sequence Number 64-bit Threshold Register
EIP96_SEQ_NUM64_THR_L, Read/Write, 32-bit address offset 0x0024

EIP96_SEQ_NUM64_THR_H, Read/Write, 32-bit address offset 0x0028
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Threshold Low [31:0]
Threshold High [63:32]
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
Bits Name Function

[63:0] Threshold 64-bit threshold value applicable for 64-bit sequence numbers, outbound-only.
Setting the threshold unequal to 0 will generate error bit E11, once the sequence number
equals or exceeds the threshold value. In that case, bit E11 must not be regarded an ‘error’,
but rather a ‘note’.
When set or kept to all zeroes, E11 will have its default meaning.
This feature can be used for early detection of the sequence number rollover event, when setting it a
number of packets below the rollover point.

007-096460-207
C.2 PRNG Registers

The following sections describe the command and status registers that apply to the PRNG subsystem.
Attention: These register descriptions are only valid for an internal PRNG subsystem. In case of an
external PRNG subsystem, these registers are “Reserved”.
C.2.1 PRNG Status Register (PRNG STAT)

PRNG STAT, Read-only, 32-bit address offset 0x0040
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Result Ready
Busy
Reserved
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
Bits Name Function

[0] Busy Indicates the PRNG is busy generating a Pseudo-Random Number.
Set to ‘1’ by hardware at the moment the Enable bit PRNG_CTRL[0] is set to ‘1’. This bit is
automatically cleared to ‘0’ by hardware when a valid pseudo-random number is written to
the output registers.
In Auto mode this bit is cleared after a number has been generated, and the PRNG is waiting
for the EIP-96 to use the Pseudo-Random number.
A write has no effect.
Note that this bit is also set in case the Auto mode is selected (Auto bit is one), when the
PRNG is busy.
[1] Result Ready Indicates a valid Pseudo-Random Number is available in the result register.
Set to ‘1’ by hardware when the result register PRNG_RES is written. This bit is
automatically cleared to ‘0’ by hardware when the PRNG is enabled for the next operation.
A write has no effect.
Note that this bit is only set when the PRNG is controlled by software, so the Auto bit is zero.
[31:2] Reserved Always read as zero.
The difference between the Busy bit and Result Ready bit is that the Result Ready bit is mode-dependent and
only set in Manual mode (Auto bit is ‘0’), where the Busy bit is mode independent.
C.2.2 PRNG Control Register (PRNG_CTRL)

PRNG_CTRL, Read/Write, 32-bit address offset 0x0044
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Result 128
Enable
Auto
Reserved
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

007-096460-207
Bits Name Function

[0] Enable Enables the generation of a new Pseudo-Random Number.
If set to ‘1’, the PRNG starts the generation of a Pseudo-Random Number.
When Bit [1] Auto is set to ‘0’, this enable bit is automatically cleared to ‘0’ by hardware when
the PRNG starts an operation.
When Bit [1] Auto is set to ‘1’, this enable bit starts the continuous generation of pseudo-
random numbers
Setting Bit [0] to ‘0’ has no effect. Always read as zero.
[1] Auto Enables the automatic generation of Pseudo-Random Numbers.
If set to ‘1’, the PRNG will start the automatic generation of 128-bit Pseudo-Random
Numbers when Bit [0] Enable is set to ‘1’. This is a continuous operation until the Auto bit is
cleared.
If set to ‘0’, the PRNG will stop after the generation of one Pseudo-Random Number.
The Auto bit may only be cleared when the Busy bit in the PRNG_STAT register is zero. This
mode can be used for generating IVs for DES, AES, SM4 and BC0 algorithm. The length of the
IV is automatically adjusted for the algorithm. The PRNG is under control of the EIP-96 and
generates a new IV when required.
On a read the Auto bit always returns the last written value.
[2] Result 128 Enables the generation of 128-bit Pseudo-Random Numbers.
If set to ‘1’, the PRNG fills both 64-bit, result registers, starting with the lower 64 bits
(PRNG_RES0_L/H), ending with the upper 64 bits (PRNG_RES1_L/H). Note that this option
reduces the performance by half.
If cleared to ‘0’, the PRNG will fill only the lower 64 bits of the result register
(PRNG_RES0_L/H).
On a read, the Result 128 bit always returns the last written value.
[31:3] Reserved A write has no effect. Always read as zero.
C.2.3 PRNG Seed Register (PRNG_SEED_L/H)

The PRNG must be seeded with a 64-bit random number by writing a secret 64-bit seed value (V) to this
register. This seed is needed once after reset; the EIP-96 then automatically updates V with the output of
the third Triple-DES operation.
PRNG_SEED_L, Write-only, 32-bit address offset 0x0048

PRNG_SEED_H, Write-only, 32-bit address offset 0x004C
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
PRNG Seed Low [31:0]
PRNG Seed High [63:32]
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
Bits Name Function

[63:0] PRNG Seed 64-bit random seed.
When the Host reads this register, it returns zeroes.
Note: It is recommended that an external RNG be used to generate the 64-bit random number used to
'seed' the PRNG Seed Low and High registers.

007-096460-207
C.2.4 PRNG DES Key Registers (PRNG_KEY0_L/H, PRNG_KEY1_L/H)

The following registers contain the 64-bit secret key pair that is used for Triple-DES operations. The DES keys
are 64-bits long, but this includes 8 parity-check bits (bits on positions 0, 8, 16, 24, 32, 40, 48 and 56). The
key registers are implemented using a 56-bit maximum length LFSR implementation, ignoring the parity bits.
The key registers are updated (LFSR changes to next value) after every PRNG operation.
Attention: The Key registers should not contain all zeroes because the LFSR will not get out of this state
and an all-zero key is considered a “weak key” for DES.
PRNG_KEY0_L, Write-only, 32-bit address offset 0x0050

PRNG_KEY0_H, Write-only, 32-bit address offset 0x0054
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
PRNG DES Key0 Low [31:0]
PRNG DES Key0 High [63:32]
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
Bits Name Function

[63:0] PRNG Key0 64-bit Triple-DES key K0.
When the Host reads this register, it returns an undefined value.
PRNG_KEY1_L, Write-only, 32-bit address offset 0x0058

PRNG_KEY1_H, Write-only, 32-bit address offset 0x005C
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
PRNG DES Key1 Low [31:0]
PRNG DES Key1 High [63:32]
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
Bits Name Function

[63:0] PRNG Key1 64-bit Triple-DES key K1.
When the Host reads this register, it returns an undefined value.

007-096460-207
C.2.5 PRNG Output Registers (PRNG_RES0_L/H, PRNG_RES1_L/H)

The following registers contain two generated pseudo-random numbers, the result R of the PRNG
processing. The two result registers can be concatenated to form one unique 128-bit result. The contents of
the result registers are valid when the Busy bit, PRNG_STAT[0], is ‘0’ or interrupt int_prng_done is HIGH.
PRNG_RES0_L, Read-only, 32-bit address offset 0x0060

PRNG_RES0_H, Read-only, 32-bit address offset 0x0064
PRNG_RES1_L, Read-only, 32-bit address offset 0x0068
PRNG_RES1_H, Read-only, 32-bit address offset 0x006C
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
PRNG Res0 Low, PRNG Output [31:0]
PRNG Res0 High, PRNG Output [63:32]
PRNG Res1 Low, PRNG Output [95:64]
PRNG Res1 High, PRNG Output [127:96]
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
Bits Name Function

[63:0] PRNG Res0 64-bit output result R0.
A write to any of the bits has no effect.
[127:64] PRNG Res1 64-bit output result R1.
A write to any of the bits has no effect.
C.2.6 PRNG LFSR Registers (PRNG_LFSR_L/H)

The Linear Feedback Shift Register (LFSR) contains a unique input DT as plaintext input for the first Triple-
DES operation. The register is implemented using a 64-bit maximum length LFSR implementation. The
register is updated (LFSR changes to next value) after every PRNG operation.
Attention: The LFSR registers should not contain all zeroes because the LFSR will not get out of this state
and therefore submit a constant all-zero value into the PRNG.
PRNG_LFSR_L, Read/Write, 32-bit address offset 0x0070

PRNG_LFSR_H, Read/Write, 32-bit address offset 0x0074
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
PRNG LFSR Low, DT [31:0]
PRNG LFSR High, DT [63:32]
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
Bits Name Function

[63:0] PRNG LFSR 64-bit output result DT.
When the Host reads this register, it returns the current value of the LFSR.

007-096460-207
C.3 Interrupt Controller Registers

The EIP-96 includes an EIP-201 Advanced Interrupt Controller (AIC) module that manages all interrupt
sources and drives the interrupt output pin.
C.3.1 Interrupt sources

The EIP-96 internal interrupts are edge triggered and active-high. Table 42 lists the interrupt sources.
Table 42 AIC interrupt sources
Bit Name Description

0 Input DMA Error Set if input fetch engine did not properly receive all packet data
1 Output DMA error Set if output store engine did not properly store all packet data
2 Packet processing An OR of the packet errors of type E0 up to E7 (refer to Table 34 in Chapter
10 for details on these errors)
3 Packet timeout A copy of the packet error E14 (see Table 34 in Chapter 10)
C.3.2 Polarity Control Registers

This register reflects the polarity for each individual interrupt.
AIC_POL_CTRL (Read-only), Byte Address Offset 0x03C0

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
reserved polarity_control
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1
Bits Name Type Function

[3:0] polarity_control RO Individual polarity (high level/rising edge or low level/falling edge) control bits per
interrupt input:
0b = Low level/falling edge
1b = High level/rising edge
[31:4] reserved RO Bits should be ignored on a read.
C.3.3 Type Control Registers

This register reflects the signal type for each individual interrupt.
AIC_TYPE_CTRL (Read-only), Byte Address Offset 0x03C4

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
reserved type_control
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1

007-096460-207

[3:0] type_control RO Signal type (level or edge) control bits for each interrupt input:
0b = level (the interrupt source level determines the raw status).
1b = edge (the interrupt source is connected to an edge detector and the edge
detector output determines the raw status).
C.3.4 Enable Control Registers
AIC_ENABLE_CTRL (Read/Write), Byte Address Offset 0x03C8

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
reserved enable_control
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

[3:0] enable_control R/W Individual enable control bits per interrupt input:
0b = Disabled.
1b = Enabled.
[31:4] reserved R/W Bits should be written with 0 and ignored on a read.
C.3.5 Raw Source Status Registers and Enable Set Registers
AIC_RAW_STAT (Read-only), Byte Address Offset 0x03CC

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
reserved raw_status
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1

[3:0] raw_status RO These bits reflect the status of the interrupts after polarity control and optional
edge detection (before masking with bits in AIC_ENABLE_CTRL registers):
0b = Inactive.
1b = Pending.
AIC_ENABLE_SET (Write-only), Byte Address Offset 0x03CC

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
reserved enable_set
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

007-096460-207

[3:0] enable_set WO Individual interrupt enable bits per interrupt input:
0b = No effect.
1b = Set the corresponding bit in the AIC_ENABLE_CTRL register, enabling the
interrupt.
After writing a 1b, there is no need to write a 0b.
[31:4] reserved WO Bits should be written with 0.
C.3.6 Enabled Status Registers and Acknowledge Registers
AIC_ENABLED_STAT (Read-only), Byte Address Offset 0x03D0

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
reserved enabled_status
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1

[3:0] enabled_status RO These bits reflect the status of the interrupts after polarity control and optional
edge detection, gated with bits in AIC_ENABLE_CTRL registers:
0b = Inactive.
1b = Pending.
AIC_ACK (Write-only), Byte Address Offset 0x03D0

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
reserved ack
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

[3:0] ack WO Used to clear edge-detect interrupts:
0b = No effect.
1b = Acknowledge the interrupt signal, clears the edge detector and status bit.

007-096460-207
C.3.7 Enable Clear Registers
AIC_ENABLE_CLR (Write-only), Byte Address Offset 0x03D4

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
reserved enable_clear
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

[3:0] enable_clear WO Individual interrupt disable bits per interrupt input:
0b = No effect.
1b = Clear the corresponding bit in the AIC_ENABLE_CTRL register, disabling the
interrupt.
C.3.8 Options Registers
AIC_OPTIONS (Read-only), Byte Address Offset 0x03D8

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
reserved nr_of_inputs
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0

[5:0] nr_of_inputs RO The number of interrupt request inputs.
For the AIC this number is fixed at 4

007-096460-207
C.3.9 Version Registers
AIC_VERSION (Read-only), Byte Address Offset 0x03DC

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
reserved major_version minor_version patch_level eip_number_complement eip_number
0 0 0 0 ? ? ? ? ? ? ? ? ? ? ? ? 0 0 1 1 0 1 1 0 1 1 0 0 1 0 0 1

[7:0] eip_number RO These bits encode the Rambus EIP number for the AIC. As the AIC is officially called
the EIP-201, this field contains the value 201 (decimal) or 0xC9.
[15:8] eip_number_ RO These bits simply contain the complement of bits [7:0] (0x36), used by a driver to
complement ascertain that the AIC_VERSION register is indeed read.
[19:16] patch_level RO These bits encode the hardware patch level for this module and start at value 0 on
each minor release update.
[23:20] minor_version RO These bits encode the minor version number for this module.
[27:24] major_version RO These bits encode the major version number for this module.
C.4 Protocol Control

These registers are used to provide programmable settings for handling protocols.
C.4.1.1 ECN Table Registers

These registers configure the ECN transformations and resulting CLE for IPsec tunnel mode inbound packets,
when applying the IP_TUNFIX token instruction, refer to 8.6.1.5.
After the IP_TUNFIX instruction determined the applicable inner IPsec protocol, and the IP_TUNFIX 'NH' bit
is set to '1', the ECN bits from the instruction will be combined with the ECN bits extracted from the packet,
according to the table programmed into the EIP96_ECN_TABLE registers. The table will return
replacements for those ECN bits in the output stream, and a corresponding CLE error value that may
optionally be generated in the output token.
EIP96_ECN_TABLE0, Read/Write, 32-bit address offset 0x03E0
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
OuterECN_InnerECN = 00_11 00_10 00_01 00_00
Reserved
Reserved
Reserved
Reserved
error out error out error error out

out
0 0 0 0 0 0 1 1 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0

007-096460-207

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
01_11 01_10 01_01 01_00
Reserved
Reserved
Reserved
Reserved
error out error out error out error out
0 1 0 1 0 1 1 1 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 1 0 1 0 1 0 0 0 0

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
10_11 10_10 10_01 10_00
Reserved
Reserved
Reserved
Reserved
0 0 0 0 0 0 1 1 0 0 0 0 0 0 1 0 0 1 0 1 1 1 0 1 0 1 0 1 1 0 0 0
EIP96_ECN_TABLE3, Read/Write, 32-bit address offset 0x03EC

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
11_11 11_10 11_01 11_00
Reserved
Reserved
Reserved
Reserved
0 0 0 0 0 0 1 1 0 0 0 0 0 0 1 1 0 0 0 0 0 0 1 1 0 1 1 0 0 0 0 0
Bits Name Function

[1:0] out ECN value to replace the ECN bits in the output for OuterECN_InnerECN
[6:2] error Specific result token ECN error code to generate for OuterECN_InnerECN.
A value of all zeroes means no error, any other value is used as CLE error code, written to
the result token.
[7] Reserved Write with zeroes, ignore on read.
[31:8] ... Repeated definitions for the other InnerECN values
C.4.1.2 ECN IP Tunnel Error Configuration Register

This register configures the optional CLE values for IPsec tunnel mode inbound packets, when applying the
IP_TUNFIX token instruction, refer to 8.6.1.5.
This register can be used to enable the checks of the
1. extracted inner IP header value against fixed values for IPv4 and IPv6,
2. extracted NH value against the corresponding programmable reference value(s).
When enabled and a mismatch is detected, the corresponding programmed CLE value will be written to the
result token.

007-096460-207
EIP96_ECN_ERR_CFG, Read/Write, 32-bit address offset 0x03F0

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
InvNHErrEn
InvIPErrEn
ProtoIPv6
ProtoIPv4
Reserved
Reserved
InvalidNHCLE InvalidIPCLE
1 0 0 1 1 0 0 1 1 0 0 1 1 0 0 1 0 0 1 0 1 0 0 1 0 0 0 0 0 1 0 0
Bits Name Function

[7:0] ProtoIPv4 Protocol value for IPv4, normally 4 (= reset value). Used when the extracted IP header
version matches for IPv4, for comparing against extracted NH header version if the 'Invalid
NH' error check InvNHErrEn is enabled.
[15:8] ProtoIPv6 Protocol value for IPv6, normally 41 (= reset value). Used when the extracted IP header
version matches for IPv6, for comparing against extracted NH header version if the 'Invalid
NH' error check InvNHErrEn is enabled.
[20:16] InvalidIPCLE CLE value to write to the CLE field of the result token if InvIPErrEn is 1, and an extracted IP
header version does not match 4 (IPv4 detection) or 6 (IPv6 detection).
[22:21] Reserved Write with zeroes, ignore on read.
[23] InvIPErrEn Enable Invalid IP header version error generation. When 1, an extracted IP header version
that is not either 4 or 6 will result in the CLE error code from InvalidIPCLE.
[28:24] InvalidNHCLE CLE value to write to the CLE field of the result token if InvNHErrEn is 1 and an NH value
extracted from the IPsec padding does not match the corresponding ProtoIPv4 or ProtoIPv6
value.
[30:29] Reserved Write with zeroes, ignore on read.
[31] InvNHErrEn Enable Invalid NH value error generation. When 1, an NH value extracted from the IPsec
padding that does not match the ProtoIPvx value for the extracted IP header version (i.e.
ProtoIPv4 if 4 was extracted, ProtoIPv6 if 6 was extracted) will result in the CLE error code
from InvalidNHCLE.
C.5 Global Type and Version Registers

These registers are used to determine the available protocols and algorithms. The first register is the Type
register that defines the configuration; the second register reflects the current EIP-96 revision.
C.5.1 Type and Configuration Register

The settings in the diagram below are the settings of the standard configuration for the current hardware
revision.
EIP96_OPTIONS, Read Only, 32-bit address offset 0x03F8
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
External block cipher BC0
CBC-MAC key-lengths
CBC-MAC Speed
SHA2-384/512
SHA2-224/256
1024-bit mask
SHA-1-Speed
ARC4-Speed
384-bit mask
256-bit mask
XCBC-MAC
DES-Speed
AES-Speed
ChaCha20
AES-XTS
Poly1305
Wireless
DES-FB
AES-FB
GHASH
SHA-3
SHA-1
ARC4
MD5
SM3
SM4
DES
AES
reserved
- 1 0 1 1 - 1 1 1 1 1 1 - - 0 1 1 1 1 1 1 1 - - - - - - 0 0 0 0

007-096460-207
Bits Name Function

[3:0] Reserved
[4] 1024-bit If set to ‘1’ 1024-bit masking of the sequence number window is supported.
mask
[5] Ext. Block If set to ‘1’ External Block Cipher BC0 is available.
Cipher BC0
[6] SM4 If set to ‘1’ SM4 is available.
[7] SM3 If set to ‘1’ SM3 is available.
[8] ChaCha20 If set to ‘1’ ChaCha20 is available.
[9] Poly1305 If set to ‘1’ Poly1305 is available.
[10] 256-bit mask If set to ‘1’ 256-bit masking of the sequence number window is supported.
[11] 384-bit mask If set to ‘1’ 384-bit masking of the sequence number window is supported.
[12] AES If set to ‘1’ AES is available.
[13] AES-FB If set to ‘1’ AES-CFB-128 and AES-OFB-128 are available.
[14] AES-Speed This bit indicates which speed version of the AES core is integrated:
0: A Medium-Speed AES core is integrated (4.2 bits/cycle).
1: A Fast AES core is integrated (12.8 bits/cycle).
[15] DES If set to ‘1’ DES and 3DES are available.
[16] DES-FB If set to ‘1’ (3)DES-CFB-64 and (3)DES-OFB-64 are available.
[17] DES-Speed This bit indicates which speed version of the DES core is integrated:
0: A Medium-speed (3-round) DES core is integrated.
1: A Fast (4-round) DES core is integrated.
[19:18] ARC4 00: No ARC4 is available.
01: A Slow ARC4 core is integrated (3.5 bits/cycle); It requires two dual port memories.
10: A Medium-speed ARC4 core is integrated (6.4 bits/cycle); It requires four dual port
memories.
11: A fast ARC4 core is integrated (8.0 bits/cycle); It uses an internal register-based state
record instead of memories.
Note: These two bits are always 00 for the EIP-96i and EIP-96ie configurations and 11 for
the EIP-96is and EIP-96ies configurations.
[20] AES-XTS If set to ‘1’ AES-XTS is available.
[21] Wireless If set to ‘1’ wireless algorithms are available (ZUC, SNOW and Kasumi).
[22] MD5 If set to ‘1’ MD5 is available.
[23] SHA-1 If set to ‘1’ SHA-1 is available.
[24] SHA-1- This bit indicates which speed version of the SHA-1 core is integrated:
Speed 0: A Slow SHA-1 core is integrated (6.4 bits/cycle).
1: A Fast SHA-1 core is integrated (12.8 bits/cycle).
[25] SHA2- If set to ‘1’ SHA2-224/256 is available.
224/256
[26] SHA2- If set to ‘1’ SHA2-384/512 is available.
384/512 Note: This bit is ‘0’ for the EIP-96i and EIP-96is configurations and ‘1’ for the EIP-96ie and
EIP-96ies configurations.
[27] XCBC-MAC If set to ‘1’ AES-XCBC-MAC is available.
[28] CBC-MAC This bit indicates which speed version of the AES-CBC-MAC core is integrated:
Speed 0: A Slow AES-CBC-MAC core is integrated (4.2 bits/cycle).
1: A Fast AES-CBC-MAC core is integrated (12.8 bits/cycle).
[29] CBC-MAC 0: AES-CBC-MAC core accepts only key with a length of 128-bit.
key-lengths 1: AES-CBC-MAC core accepts all key lengths (128/192/256-bit).
[30] GHASH If set to ‘1’ GHASH core is available.
[31] SHA-3 If set to ‘1’ SHA-3 is available.

007-096460-207
C.5.2 Version Register
EIP96_VERSION, Read-only, 32-bit address offset 0x03FC

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
EIP_NUMBER_COMPL
MAJOR_VERSION
MINOR_VERSION
PATCH_LEVEL
EIP_NUMBER
Reserved
0 0 0 0 0 1 0 0 ? ? ? ? ? ? ? ? 1 0 0 1 1 1 1 1 0 1 1 0 0 0 0 0
Bits Name Function

[7:0] EIP_NUMBER These bits encode the Rambus EIP number for the EIP-96, so this field contains the
value 96 (decimal) or 0x60.
[15:8] EIP_NUMBER_COMPL These bits simply contain the complement of bits [7:0] (0x9F), used by a driver to
ascertain that the version register is indeed read.
[19:16] PATCH_LEVEL These bits encode the hardware patch level for this module. They start at value 0 on
the first release and are reset on each minor version change.
[23:20] MINOR_VERSION These bits encode the minor version number for this module. They start at value 0
on the first release and are reset on each major version change.
[27:24] MAJOR_VERSION These bits encode the major version number for this module.
[31:28] Reserved

007-096460-207
D Protocol Compliance
D.1 Introduction
This appendix lists the EIP-96 functionality used to perform packet processing for officially supported
protocols. For each function the mapping to RFC and other protocol specifications is given.
D.2 Disclaimer
Although the EIP-96 contains functional modules which can be used to perform different protocol
operations, this appendix lists the officially supported and verified set of protocols. The verification is
focused on the usage of provided token examples.
Functionality of the EIP-96 used to process protocols other than listed, is not fully verified.
D.3 IP header
The EIP-96 contains instructions to modify/update fields in IPv4 or IPv6 headers. The supported operations
are listed in Table 43 and Table 44.
Table 43 Supported IPv4 functionality
Functionality Document Outbound Inbound

Modification [RFC791] TTL decrement
Checksum modification
Next header replacement
Length modification
Post-process update [RFC791] Checksum modification
Length modification
Table 44 Supported IPv6 functionality

Extension headers [RFC8200] Forwarding, defined by the host
Modification Hop limit decrement
Length modification
Post-process update [RFC8200] Next header replacement
Length modification

007-096460-207
D.4 IPsec ESP

The EIP-96 provides hardware acceleration for IPsec ESP processing based on the supported functionality
listed in Table 45.
Table 45 Supported ESP functionality
Function Document Outbound Inbound

Header processing [RFC4303] SPI and sequence number Removal.
insertion SPI, sequence number check.
Sequence number Generation. Replay check
(normal) Overflow check. (32, 64, 128 wide window).
Sequence number Generation. Estimation.
(extended 64-bit) Overflow check. Replay check (32, 64, 128 wide
window)
Padding - TFC Addition supported. Can be removed when host knows
the length of padding
Padding – IPsec Addition up to 255 bytes (257 Removal.
in total). Length of padding is Next header check.
calculated by the host.
ECN tunneling [RFC3168] - ECN propagation, Checksum update.
[RFC3260] Next header check.
[RFC6040]
Confidentiality [RFC2451] DES(TDES)-CBC
[RFC2405]
[RFC3602] AES-CBC with 128, 192 and 256-bit keys
[RFC3686] AES-CTR with 128, 192 and 256-bit keys
[draft-ribose-cfrg- SM4-CBC with 128-bit keys
sm4-10] (only available in EIP-96*c configurations)
[sms4-diffie]
[GM/T 022-2014]
Integrity [RFC2403] HMAC-MD5
[RFC2404] HMAC-SHA1
[RFC6188] HMAC-SHA2-256/SHA2-224 – SHA2-512/SHA2-384
[RFC4868] (SHA2-512/384 are only available in EIP-96*e configurations)
[RFC3566] XCBC-MAC-96
[draft-sca-cfrg- HMAC-SM3
sm3-02] (only available in EIP-96*c configurations)
[GM/T 022-2014]
Combined modes [RFC4106] AES-GCM
[RFC6379]
[RFC4543] AES-GMAC
[RFC6379]
[RFC4309] AES-CCM with A0 and B0 vectors calculated externally.
EIP96 supports L value of 4 octets and key length of 128, 192, 256-bit.
[RFC7539] ChaCha20-Poly1305
[RFC7634] (ChaCha20 and Poly1305 are only available in EIP-96*b configurations)
ICV [RFC4303] Appending of any length Checking any length
Note: All applicable documents are part of [RFC7321]

007-096460-207
D.5 AH
The EIP-96 provides hardware acceleration for AH processing based on the supported functionality in Table
46.
Table 46 Supported AH functionality

IPv4 header [RFC4302] See Table 43
processing
IPV6 header See Table 44
processing
Header SPI and sequence number Removal.
processing insertion SPI, sequence number check.
Sequence Generation. Replay check
number Overflow check. (32, 64, 128 wide window).
(normal)
Sequence Generation. Estimation.
number Overflow check.. Replay check (32, 64, 128 wide
(extended 64- window)
bit)
Padding Addition supported. Can be removed if host knows the
length of the padding
Integrity [RFC2403] HMAC-MD5
[RFC2404] HMAC-SHA1
[RFC6188] HMAC-SHA2-256/SHA2-224 – SHA2-512/SHA2-384
[RFC4868] (SHA2-512/384 are only available in EIP-96ie and EIP-96ies)
[RFC3566] XCBC-MAC-96
Combined [RFC4543] AES-GMAC
modes [RFC6379]
ICV [RFC4302] Appending of any length Checking any length
Note: All applicable documents are part of [RFC7321]

007-096460-207
D.6 SSL
The EIP-96 provides hardware acceleration for SSL processing based on supported functionality in Table 47.
Attention: SSL is by default available in all configurations; The cipher suites with ARC4 are only available
in the EIP-96*s configurations that include the ARC4 algorithm.
Table 47 Supported SSL functionality

Header processing [RFC6101] Insertion type, version Removal,
checking type, version
Sequence number Generation. 64-bit overflow check
Fragment Null Null
compression/decompres
sion
Length field processing Fragment length is For stream ciphers, the
calculated by the host payload length is calculated
processor by the host processor.
For block ciphers, the EIP-96
autonomously calculates the
payload length based on
initial decryption of the pad
length.
Implicit IV From the context
Padding Insertion of SSL padding Removal (and verification if
from 0 to 255 (256 in the padding is constant) of
total). Length of padding is SSL padding. Pad length is
calculated by the host. determined by the EIP-96
autonomously.
Cipher Null-crypto
ARC4
(T)DES-CBC
AES-CBC with 128, 192 and 256-bit keys
Hash SSL-MAC-MD5
SSL-MAC-SHA1
ICV Insertion Verification

007-096460-207
D.7 TLS
The EIP-96 provides hardware acceleration for TLS processing (versions 1.0, 1.1, 1.2 and 1.3) based on
supported functionality Table 48.
Attention: TLS is by default available in all configurations; The cipher suites with ARC4 are only available
in the EIP-96*s configurations that include the ARC4 algorithm. Likewise, cipher suites with
Poly1305 and ChaCha20 are only available in EIP-96*b configurations.
Table 48 Supported TLS functionality

Header processing [RFC4346] Insertion type, version Removal.
[RFC5116] Checking type, version
[RFC5246]
Sequence number Generation. 64-bit overflow check
[RFC5288]
Fragment Null Null
[RFC5289]
compression/decompres
sion [RFC6655]
[RFC2246]
Length field processing Fragment length is For stream ciphers, the payload
[RFC7905]
calculated by the host length is calculated by the host
[RFC8446] processor processor.
For block ciphers, the EIP-96
autonomously calculates the payload
length based on initial decryption of
the pad length.
Explicit IV processing for Insertion of explicit IV from Retrieving explicit IV from input
TLS 1.1 and 1.2 (except context
for ChaCha20-Poly1305)
Implicit IV processing for Generate IV from generated sequence number XORed with the IV
TLS 1.3 and TLS1.2 from the transform record.
(ChaCha20-Poly1305
only)
Padding Insertion of TLS padding TLS padding detection and removal
from 0 to 255 (256 in (detection up to 16384 and removal
total). Length of padding is up to 256 bytes for TLS1.3)
calculated by the host. Pad length is determined by the EIP-
Up to 16384 bytes for TLS 96 autonomously.
1.3. Length of padding is
calculated by the host.
Cipher Null-crypto
ARC4 (only available in EIP-96*s configurations)
(T)DES-CBC
SM4-CBC (only available in EIP-96*c configurations)
BC0-CBC (only available in EIP-96*c configurations)
Hash HMAC-MD5
HMAC-SHA-1
HMAC-SHA2-256 (TLS 1.2 only)
HMAC-SHA2-384/512 (TLS 1.2 only)
HMAC-SM3 (only available in EIP-96*c configurations)
Combined modes AES-GCM
AES-CCM with A0 and B0 vectors calculated externally. EIP96
supports L value of 3 octets and key length of 128, 256-bit.
ChaCha20-Poly1305 (TLS1.2 and TLS1.3 only, only available in EIP-
96*b configurations)

007-096460-207
D.8 DTLS
The EIP-96 provides hardware acceleration for DTLS processing based on supported functionality in Table
49.
Attention: DTLS is by default available in all configurations but cipher suites with Poly1305 and ChaCha20
are only available in EIP-96*b configurations.

007-096460-207
Table 49 Supported DTLS functionality

Header processing [RFC4347] Insertion: type, Removal.
[RFC6347] version, epoch, Checking: type, version, epoch,
[RFC7905] generated sequence sequence number
number
Explicit Sequence Generation. IPsec type of replay check of 48-
numbering Overflow check of 48- sequence number with 64 or 128 bit
bit. mask. Compliant to chapter 3.4.3 of
[RFC2402]
Epoch Insertion Check
Fragment Null Null
compression/deco
mpression
Length field Fragment length is For stream ciphers, the payload length
processing calculated by the host is calculated by the host processor.
processor. For block ciphers, the EIP-96
autonomously calculates the payload
length based on initial decryption of
the pad length.
IV processing Insertion of explicit IV Taking explicit IV from the input
from the context
DTLS1.2 for ChaCha20- DTLS1.2 for ChaCha20-Poly1305:
Poly1305: Insertion of implicit IV, generated from
Insertion of implicit IV, sequence number XORed with the IV
generated from from the transform record
sequence number
(extracted from
packet) XORed with the
IV from the transform
record
Padding The same as in TLS 1.1, TLS1.2
Cipher Null-crypto
(T)DES-CBC
SM4-CBC (only available in EIP-96*c configurations)
BC0-CBC (only available in EIP-96*c configurations)
Hash The same as in TLS1.1 HMAC-MD5
and TLS1.2 HMAC-SHA1
HMAC-SHA2-256 (DTLS 1.2 only)
HMAC-SHA2-384/512 (DTLS 1.2 only)
HMAC-SM3 (only available in EIP-96*c configurations)
Combined modes AES-GCM
ChaCha20-Poly1305 (DTLS 1.2 only, only available in EIP-96*b
configurations)

007-096460-207
D.9 SRTP/SRTCP
The EIP-96 provides basic hardware acceleration for SRTP/SRTCP processing based on the supported
functionality in Table 50.
Table 50 Supported SRTP/SRTCP functionality

UDP header [RFC3711] Bypass Bypass
SRTP/SRTCP Bypass Bypass
header
MKI field Insertion from context Removal, Verification
(optional)
SRTP ROC Used from token (calculated by the host)
SRTCP E+Index Insertion (from token) Removal
IV processing From context (IV is calculated by the host)
(defined
externally)
Cipher - Null-crypto
- AES-ICM (overflow of the 16-bit counter should be checked
by the host)
Hash HMAC SHA1
TAG (variable Insertion Verification
length)
D.10 MACsec
The EIP-96 provides hardware acceleration for MACsec processing based on the supported functionality in
Table 51.
Table 51 Supported MACsec functionality

Header processing IEEE Std Insertion: Removal
802.1AE-2006 STI from token,
PN and SCI from context
IV processing From context - From input header (with SCI)
- From input header and context
(without SCI)
Packet number Generation. Verification.
Overflow check. 32-bit integer, in-window check
ICV (16-byte) Insertion Verification
Confidentiality offset Supported Supported
Cipher suites AES-GCM
AES-GMAC

007-096460-207
E Optional Context FIFO Interface

E.1 Introduction
The EIP-96-f configuration is optionally available with a FIFO interface for the context and is then referred to
the EIP-96-cf.
This section describes that optional interface. If this FIFO interface option is selected, the DMA/TCM
interface (see Sections 4.3.7, 4.4.4 and 4.4.5) is not available.
Note: This FIFO interface increases system complexity since context updates that are performed
automatically with the default EIP-96-f configuration have to be managed externally in case of a
FIFO interface. This may include updates in contexts that are prefetched in the input FIFO (outside
the EIP-96-f).
E.2 Context FIFO Interface Signals

This table lists the context FIFO interface signals.
Table 52 Context FIFO Interface Signal Descriptions

Context FIFO Interface signals
ctx_in[31:0] IN Input context data bus. Sending FIFO should provide valid context data
on this bus when ctx_fifo_empty is cleared to zero.
ctx_in_fifo_empty IN If zero, indicates that the sending FIFO has an input context data word
available. If this is signal is set to zero the context data on the ctx_in bus
is valid.
If one the sending FIFO has no context data available.
ctx_in_done IN If one, indicates that the context data on the ctx_in bus is the last
context data word of the Context Record. This signal is valid if
ctx_in_write is active (set to one).
If zero, the data word provided on the ctx_in bus is not the last context
data word of the Context Record.
ctx_in_read OUT If one, indicates that the EIP-96-cf is able to receive a new context data.
If zero, the EIP-96-cf is not ready to receive new context data.
ctx_out_fifo_full IN If zero, indicates the receiving FIFO is ready to accept context (update)
data.
If one, indicates that the receiving FIFO is full and cannot accept a new
context (update) data word.
ctx_out[31:0] OUT Result context bus. Context update data is valid when ctx_out_write is
active (set to one).
ctx_out_write OUT If one, indicates that the context update data on the ctx_out bus and
ctx_out_done signal are valid and can be read.
If zero, the EIP-96-cf has no data available.
ctx_out_done OUT If one, indicates that the context update data on the ctx_out bus is the
last context update data word of this context update data
block/sequence. This signal is valid if ctx_out_write is active (set to
one).
If zero, the context update data word provided on the ctx_outbus is not
the last context update data word of the packet.

007-096460-207
E.3 Context FIFO Interface Timing

Figure 67 below shows an example timing diagram of the Context FIFO Interface. Note that the context
output FIFO interface will never start writing context update data if the context input FIFO is reading
context data and vice versa, the context FIFO interface will never start reading context data if the context
output FIFO interface is writing context update data.
The figure shows a context fetch of four words and a context update of two context words (preceded by a
single address word). The context update is automatically preceded by a single address word indicating
where the update should be done. The address is derived by the base address from the token incremented
with the offset from the update instruction.
Figure 67 EIP-96-cf Context FIFO interface timing diagram

The Input format for the context data stream is the same as the standard EIP-96, i.e. the context data is
streamed-in using a DMA transfer; the exact data format depends on context transfer mode selected.
Context update data however needs to include the address information to which the context update
applies. The EIP-96-cf provides the address as the first data word in the context update stream (as shown in
Figure 67 above). This address is the context address provided to the EIP-96-cf by the token, to which the
field offset into the context structure, for the field that needs to be updated, is added.
If the context update spans multiple, sequential words in the context structure, these words are provided by
the EIP-96-cf as part of a single update stream (address of first word, followed by multiple words of data
with no additional address information). In certain (non-general use) corner cases, it may be required to
update individual context words that are not located adjacently in the context structure; the EIP-96-cf
provides more context update 'blobs', each time using the same 'address + data' format. Normally however,
this situation only occurs in certain 'debug type' scenarios.
Note also that a context update may occur after the context for the next packet has already been read from
the context input FIFO interface.

007-096460-207
E.3.1 Reuse Context

If two subsequent packets use the same context data, the external system must make sure to set the 'reuse
context’ (RC) bit in the input token (for the next packet) or select ‘automatic context reuse’ when the
context pointer can be used for that.
However if the EIP-96-cf detects reuses, it skips fetching of the context for the packet, and performs any
context update to the internal copy of the reused context, as well as to perform the regular context update
to the external system.
Therefore, for this configuration where the external system must be aware of the reuse, it is suggested not
to use automatic reuse detection, but use the ‘reuse context’ selection when needed.
When the external system sets the RC bit in the token (or -when selected- reuse is detected automatically),
it should also make sure to NOT provide context data for this packet in the context input FIFO interface.

007-096460-207
F References
F.1 Conventions Used in this Manual
F.1.1 Acronyms
AAD Additional Authenticated Data
AES Advanced Encryption Standard
AH Authentication Header, an IPsec mode that authenticates the entire IP packet
ARC4 “Alleged RC4”, compatible with RC4
anti-replay An IPsec security feature that prevents a third party from eavesdropping on an IPsec
conversation.
BIST Built-In Self Test
black data Data that is present on the public domain, it is typically encrypted data
CBC Cipher Block Chaining
CFB Cipher Feed Back
Context Record Data structure used by EIP-96 containing all parameters required by the EIP-96 for performing a
data plane packet transformation.
CTR Counter mode of operation for block cipher algorithms (as in AES-CTR)
DES Data Encryption Standard
DF Don’t Fragment, this is a bit in the IPv4 header
DMA Direct Memory Access
DRBG Deterministic Random Bit Generator
DST Destination
dword A 32-bit data word
ECB Electronic Code Book
ECC Elliptic Curve Cryptography
ECN Explicit Congestion Notification. Notification of congestion on the route in one or more nodes
when a packet travels on a network from host A to host B.
EIP EmbeddedIPTM
ESP Encapsulated Security Payload, an IPsec mode that crypts the data after the IPsec header.
HMAC Hash Message Authentication Code. A special kind of keyed hash. See [RFC2104].
HOP A node in an IPv6 network
HSM Hardware Security Module
IANA Internet Assigned Number Authority
ICM Integer counter mode (as in AES-ICM)
ICMP Internet Control Message Protocol
ICV Integrity Check Value
IHL Internet Header Length
IKE Internet Key Exchange
inbound data Packet data (typically encrypted) entering the EIP-96 from the public domain. This data is
typically decrypted by the EIP-96.
IP Internet Protocol
IPv4 Internet Protocol version 4
IPv6 Internet Protocol version 6
IPsec IP Security Protocol, supports two modes ESP and AH
LSb/LSbs Least Significant Bit (plural: LSbs)
LSB/LSBs Least Significant Byte (plural: LSBs)
ITCM Instruction Tightly Coupled Memory
IV Initialization Vector
LNME Long Number Multiplier / Exponentiator
MSb/MSbs Most Significant Bit (plural: MSbs)

007-096460-207
MSB/MSBs Most Significant Byte (plural: MSBs)

MTU Maximum Transfer Unit
n/a Used to indicate that a table cell does not apply.
NAT Network Address Translation
NAT-T NAT-Traversal
NH Next Header
OFB Output Feed Back
outbound data Packet data (plaintext) entering the EIP-96 for the private domain. This data is typically
encrypted by the EIP-96.
OTK One Time (authenticator) Key
OTP One Time Programmable
PD Pull-Down (internal resistor on input pads forcing logic ‘0’ input when not connected)
PKA Public Key Accelerator
PKCP Public Key Co-processor
PKE Public Key Exchange
plaintext Data in the clear, easily readable, not encrypted.
PRNG Pseudo Random Number Generator
RAM Random Access Memory
red data Data that is present on the private domain, this is typically plaintext.
ROM Read Only Memory
RNG Random Number Generator
RSA Rivest-Shamir-Adleman (cryptographic algorithm)

RTP Real-time Transport Protocol
SA Security Association. Used in IPsec context. Refers to the data structure describing the IPsec
tunnel parameters (encryption/hash keys, transform choice, sequence numbers etc.)
SHA Secure Hash Algorithm
SM3 / SM4 Security Module 3 / 4 (Chinese Standard)
SPI Security Parameter Index
SRC Source
SRTP Secure RTP
SOC System On (a) Chip
TCM Tightly Coupled Memory (simplified bus for direct connection to synchronous RAM’s)
TCP Transmission Control Protocol
TFC Traffic Flow Confidentiality
token Packet specific data structure containing the information that the EIP-96 needs to process a
packet.
TOS Type Of Service
TTL Time To Live
TRNG True Random Number Generator (based on a physical noise source)
UDP User Datagram Protocol

007-096460-207
F.1.2 Typographical conventions

Table 53 Typographical Styles and Use
Character Style Use

Signal Highlights peripheral signal names, and interface elements such as menu names.
Also used for terms in descriptive lists, where appropriate.
Emphasis Highlights module (or sub-module) names.
Emphasis Bold Highlights special terminology, cross references and citations.
Register Name Highlights register and token names.
Bit field Highlights bit fields in registers
Courier New Denotes texts that can be entered at the keyboard, such as commands, file
names and program names, and source code.
Courier Underline Denotes a permitted abbreviation for a command or option. The underlined text
can be entered instead of the full command or option name.
Courier Italic Denotes arguments to commands or functions where the argument is to be
replaced by a specific value.
Courier Bold Denotes language keywords when used outside example code.
PIN Highlights pin names in text when caps are used.
This document may contain timing diagrams. Figure 68 shows the key to the components used in these
diagrams. Any variations are clearly labeled and specifically stated when they occur.
Clock
HIGH to LOW
HIGH/LOW to HIGH
Bus stable
Bus unstable
Bus to high impedance
Bus change
High impedance to stable bus
Figure 68 Key to timing diagrams

Shaded bus and signal areas are undefined, the bus or signal can have any value within the shaded area. The
actual value is unimportant and does not affect normal operation.

007-096460-207
F.2 References
[IPsec Securing VPNs]
“IPsec Securing VPNs”, Carlton R. Davis, 2001,
https://www.iana.org/assignments/protocol-numbers/protocol-numbers.txt
[RFC791]
“Internet Protocol”, Internet architects, September 1981,
https://www.ietf.org/rfc/rfc791.txt
[RFC1321]
“MD5 Digest Algorithm”, R. Rivest, April 1992,
[RFC1828]
“IP Authentication using Keyed MD5”, P. Metzger, W. Simpson, August 1995,
[RFC1829]
“The ESP DES-CBC Transform”, P. Karn, P. Metzger, W. Simpson, August 1995,
[RFC2104]
“HMAC: Keyed-Hashing for Message Authentication”,
H. Krawczyk, M. Bellare and R. Canetti, February 1997,
[RFC2246]
“The TLS Protocol Version 1.0”, January 1999,
[RFC2401]
“Security Architecture for the Internet Protocol”, November 1998,
[RFC2402]
“IP Authentication Header”, November 1998,
[RFC2403]
“The Use of HMAC-MD5-96 within ESP and AH” C. Madson and R. Glenn, November 1998,
[RFC2404]
“The Use of HMAC-SHA-1-96 within ESP and AH”,
C. Madson and R. Glenn, November 1998,
[RFC2405]
“The ESP DES-CBC Cipher Algorithm With Explicit IV”,
C. Madson and N. Doraswamy, November 1998,
[RFC2406]
“IP Encapsulating Security Payload (ESP)”, November 1998,
[RFC2410]
“The NULL Encryption Algorithm and Its Use With IPsec” R. Glenn and S. Kent, November 1998,
[RFC2411]
“IP Security, Document Roadmap”, November 1998,
[RFC2451]
“The ESP CBC-Mode Cipher Algorithms”, R. Pereira and R. Adams, November 1998,

007-096460-207
[RFC2460]
“Internet Protocol, Version 6 (IPv6) Specification", December 1998
[RFC3168]
“The Addition of Explicit Congestion Notification (ECN) to IP”, September 2001,
[RFC3174]
“US Secure Hash Algorithm 1 (SHA1)”, September 2001,
[RFC3260]
“New Terminology and Clarifications for Diffserv”, April 2002,
[RFC3546]
“Transport Layer Security (TLS) Extensions”,
S. Blake-Wilson, M. Nystrom, D. Hopwood, J. Mikkelsen and T. Wright, June 2003,
[RFC3566]
“The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec”, S. Frankel, H. Herbert, September 2003,
[RFC3602]
“The AES-CBC Cipher Algorithm and Its Use with IPsec”,
S. Frankel, R. Glenn, S. Kelly, September 2003,
[RFC3610]
“Counter with CBC-MAC (CCM)”, September 2003,
[RFC3686]
“Using Advanced Encryption Standard (AES) Counter Mode With IPsec
Encapsulating Security Payload (ESP)”, R. Housley, January 2004,
[RFC3711]
"The Secure Real-time Transport Protocol (SRTP)", M. Baugher et al. March 2004,
[RFC4106]
“The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)”, J. Viega June 2005,
[RFC4301]
“Security Architecture for the Internet Protocol”, S. Kent, K. Seo, December 2005,
[RFC4302]
“IP Authentication Header”, December 2005
[RFC4303]
“IP Encapsulating Security Payload (ESP)”, (Obsoletes RFC2406), S. Kent, December 2005,
[RFC4304]
“Extended Sequence Number (ESN) - Addendum to IPsec Domain of Interpretation (DOI) for Internet Security
Association and Key Management Protocol (ISAKMP), S. Kent, December 2005,
[RFC4305]
“Cryptographic Algorithm Implementation Requirements for EncapsulatingSecurity Payload (ESP) and
Authentication Header (AH)”, D. Eastlake, December 2005, (Obsoletes RFC2402, RFC2406 Errata, obsoleted by
RFC4835),

007-096460-207
[RFC4308]
“Cryptographic Suites for IPsec”, P. Hoffman, December 2005,
[RFC4309]
“Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP)”, R.
Housley D. McGrew, J. Viega, May 2006,
[RFC4346]
“The Transport Layer Security (TLS) Protocol, Version 1.1”, T. Dierks, E. Rescorla, April 2006, (Obsoletes RFC2246,
Updated by RFC4366, RFC4680, RFC4681)
[RFC4347]
“Datagram Transport Layer Security (DTLS)”, E. Rescorla, N. Modadugu, April 2006,
[RFC4494]
“The AES-CMAC-96 Algorithm and Its Use with IPsec”, June 2006,
[RFC4543]
“The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH”, D. McGreq, May 2006,
[RFC4634]
“US Secure Hash Algorithms (SHA and HMAC-SHA)”, D. Eastlake 3rd, T Hansen, July 2006
[RFC4835]
“Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and
Authentication Header (AH)”, V. Manral, April 2007, (Obsoletes RFC4305),
[RFC4868]
“HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec”, S. Kelly, Aruba Networks, S. Frankel, May 2007
[RFC4869]
“Suite B Cryptographic Suites for IPsec”, L. Law, J. Solinas, May 2007
[RFC5116]
“An Interface and Algorithms for Authenticated Encryption”, January 2008
[RFC5246]
“The Transport Layer Security (TLS) Protocol Version 1.2”, August 2008
[RFC5288]
“AES Galois Counter Mode (GCM) Cipher Suites for TLS", August 2008
[RFC5289]
“TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter Mode (GCM)", August 2008
[RFC6040]
“Tunnelling of Explicit Congestion Notification”, November 2010,
[RFC6071]
“IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap”, Februari 2011
[RFC6101]
“The Secure Sockets Layer (SSL) Protocol Version 3.0”, August 2011

007-096460-207
[RFC6188]
“The Use of AES-192 and AES-256 in Secure RTP”, March 2011
[RFC6234]
“US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)”, August 2011
[RFC6347]
“Datagram Transport Layer Security Version 1.2", January 2012
[RFC6379]
“Suite B Cryptographic Suites for IPsec", October 2011
[RFC6655]
“AES-CCM Cipher Suites for Transport Layer Security (TLS)", July 2012
[RFC7321]
“Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload
(ESP) and Authentication Header (AH)”, August 2014, (Obsoletes RFC4835),
[RFC7539]
“ChaCha20 and Poly1305 for IETF Protocols", May 2015
[RFC7568]
“Deprecating Secure Sockets Layer Version 3.0", June 2015
[RFC7634]
“ChaCha20, Poly1305, and Their Use in the Internet Key Exchange Protocol (IKE) and IPsec", August 2015
[RFC7714]
“AES-GCM Authenticated Encryption in the Secure Real-time Transport Protocol (SRTP)", December 2015
[RFC7905]
“ChaCha20-Poly1305 Cipher Suites for Transport Layer Security (TLS)", June 2016
[RFC8200]
“Internet Protocol, Version 6 (IPv6) Specification", July 2017
[RFC8221]
“Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload
(ESP) and Authentication Header (AH)", October 2017
[RFC8439]
“ChaCha20 and Poly1305 for IETF Protocols", June 2018
[RFC8446]
“The Transport Layer Security (TLS) Protocol Version 1.3”, August 2018
[SM3]
Original Chinese version of the SM3 specification.
“SM3 Cryptographic Hash Algorithm”, Chinese Commercial Cryptography Administration Office, December 2010
http://www.sca.gov.cn/sca/xwdt/2010-12/17/1002389/files/302a3ada057c4a73830536d03e683110.pdf
[GM/T-0004-2012]
Translated version of Chinese specification.
“SM3 Cryptographic Hash Algorithm”, Chinese Commercial Cryptography Administration Office, July 2018
http://www.gmbz.org.cn/upload/2018-07-24/1532401392982079739.pdf

007-096460-207
[draft-sca-cfrg-sm3-02]
“The SM3 Cryptographic Hash Function”, January 2018
https://tools.ietf.org/html/draft-sca-cfrg-sm3-02
[SM4]
Original Chinese version of the SM4 specification.
http://www.gmbz.org.cn/main/viewfile/20180108015408199368.html
[SM4-eng]
Translated version of Chinese specification.
“SMS4 Encryption Algorithm for Wireless Networks“, Cryptology ePrint Archive, May 2008
https://eprint.iacr.org/2008/329.pdf
[draft-ribose-cfrg-sm4-10]
“The SM4 Blockcipher Algorithm and Its Modes of Operation”, April 2018
https://tools.ietf.org/html/draft-ribose-cfrg-sm4-10
[sms4-diffie]
“SM4 Encryption Algorithm for Wireless Networks”, May 2008
https://eprint.iacr.org/2008/329.pdf
[GM/T 022-2014]
IPSec VPN specification, China State Cryptography Administration, Februari 2014
[draft-sca-curdle-tls-sm34-00]
“SM3 and SM4 Cipher Suites for TLS”, April 2018
https://tools.ietf.org/html/draft-sca-curdle-tls-sm34-00
[FIPS Pub. 46-3]
“Data Encryption Standard”, NIST, October 1999, Withdrawn on May 19, 2005
http://csrc.nist.gov/publications/fips/fips46-3/fips46-3.pdf
[FIPS Pub. 81]
“DES Modes of Operation”, NIST, December 1980,
http://csrc.nist.gov/publications/fips/fips81/fips81.htm
[FIPS Pub. 180-2]
“Secure Hash Standard”, NIST, Per October 2008 superseded by: FIPS Pub. 180-3
http://csrc.nist.gov/publications/fips/fips180-2/fips180-2withchangenotice.pdf
[FIPS Pub. 180-3]
“Secure Hash Standard”, NIST,
http://csrc.nist.gov/publications/fips/fips180-3/fips180-3_final.pdf
[FIPS Pub. 180-4]
“Secure Hash Standard”, NIST,
http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf
[FIPS Pub. 140-2]
“Security Requirements for Cryptographic Modules”, NIST,
http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf
[FIPS Pub. 197]
“Announcing the ADVANCED ENCRYPTION STANDARD (AES) “, NIST, November 2001
http://csrc.nist.gov/publications/fips/fips-197/fips-197.pdf
[FIPS Pub. 202]
“SHA-3 standard: Permutation-Based Hash and Extendable-Output Functions”, NIST, August 2015
http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.202.pdf
[Netscape draft302]
“The SSL Protocol Version 3.0”, A. Freier, P. Karlton, P. Kocher, Nov 1998,
http://wp.netscape.com/eng/ssl3/draft302.txt
[Internet Draft IETF]
“Integer Counter Mode”, D. McGrew. October, 2002,
www.mindspring.com/~dmcgrew/draft-mcgrew-saag-icm-01.txt
[ARC4]
"A Stream Cipher Encryption Algorithm arcfour", K. Kaukonen, R. Thayer, 14 July 1999,
draft-kaukonen-cipher-arcfour-03.txt

007-096460-207
[GCM]
“The Galois/Counter Mode of Operation (GCM)”, May 31, 2005
http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/proposedmodes/gcm/gcm-revised-spec.pdf
[NIST Special Publication 800-67 Version 1.1]
“Recommendation for the Triple Data Encryption Algorithm (TDEA) Block Cipher”,
http://csrc.nist.gov/publications/PubsSPs.html#800-67
[IEEE Std 1619™-2007]
The XTS-AES Tweakable Block Cipher, IEEE Standard for Cryptographic Protection of Data on Block-Oriented
Storage Devices
[SNOW-3G]
“Specification of the 3GPP Confidentiality and Integrity Algorithms UEA2 and UIA2. Document 2: SNOW 3G
Specification” 6th September 2006, Version 1.1, ETSI/SAGE
[EEA3-EIA3]
“Specification of the 3GPP Confidentiality and Integrity Algorithms 128-EEA3 and 128-EIA3.
Document 1: 128-EEA3 and 128-EIA3 Specification”, 1st July 2011, Version 1.6, ETSI/SAGE
http://www.gsmworld.com/documents/EEA3_EIA3_specification_v1_6.pdf

007-096460-207
G Deliverables
The EIP-96 is shipped in a package that contains the following:
• Verilog HDL,
• Fast Verilog test bench including testvector set with (human) readable test data,
• Test scripts, including tests for all supported algorithms and protocols, also based on FIPS and NIST
example vectors,
• Verification check list, a comprehensive report of all tests executed by Rambus,
• Compile and simulation scripts,
• Sample synthesis scripts, including interface and clocking constraints,
• Full programming and user support documentation.
(End of Document)

Security IP 96 - HW4.6 - Hardware Reference and Programmer Manual - RevB

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Security IP 96 - HW4.6 - Hardware Reference and Programmer Manual - RevB

Uploaded by

Copyright:

Available Formats

Security IP

Multi-Protocol Transform Engine

Hardware Reference and Programmer Manual

© Rambus Inc. • rambus.com CONFIDENTIAL

Rambus Inc. Corporate Headquarters

Rambus ROTW Holding B.V.

© Rambus Inc. • rambus.com CONFIDENTIAL 2

Product Summary Synthesized at 400 MHz in a typical CMOS 28 nm LvT

FEATURES SSL v3.0 / TLS v1.0-1.3 / DTLS v1.0/v1.2:

© Rambus Inc. • rambus.com CONFIDENTIAL 3

CRYPTO ENGINE EIP-96-f SPECIFIC PROPERTIES

INTERFACE (standard EIP-96)

© Rambus Inc. • rambus.com CONFIDENTIAL 4

Product Summary ................................................................................... 3

© Rambus Inc. • rambus.com CONFIDENTIAL 5

3.2.1 Duplicate context handling ..................................................................................... 37

© Rambus Inc. • rambus.com CONFIDENTIAL 6

6 Pseudo Random Number Generator............................................. 75

8 Processing Instructions ................................................................. 98

© Rambus Inc. • rambus.com CONFIDENTIAL 7

8.4.2 PRE_CHECKSUM Instruction ................................................................................. 102

© Rambus Inc. • rambus.com CONFIDENTIAL 8

A.2 Postprocessing ...................................................................................... 162

B Context Record Fields ................................................................. 167

© Rambus Inc. • rambus.com CONFIDENTIAL 9

B.7.3 Combined basic encrypt hash operations............................................................. 186

© Rambus Inc. • rambus.com CONFIDENTIAL 10

C.3.7 Enable Clear Registers ........................................................................................... 213

© Rambus Inc. • rambus.com CONFIDENTIAL 11

© Rambus Inc. • rambus.com CONFIDENTIAL 12

Table 46 Supported AH functionality ................................................................................................................ 221

© Rambus Inc. • rambus.com CONFIDENTIAL 13

© Rambus Inc. • rambus.com CONFIDENTIAL 14

Document Revision History

© Rambus Inc. • rambus.com CONFIDENTIAL 15

1.2.1 General References

1.2.2 Explicit References

1.3 Applicable Rambus Documents

© Rambus Inc. • rambus.com CONFIDENTIAL 16

1.4 Target Audience

1.5 Part Numbers for Standard Configurations

© Rambus Inc. • rambus.com CONFIDENTIAL 17

913-096006-460 EIP-96iew-f EIP-96 Multi-Protocol Transform Engine

© Rambus Inc. • rambus.com CONFIDENTIAL 18

2 Features and Characteristics

© Rambus Inc. • rambus.com CONFIDENTIAL 19

Optional PRNG for IV generation

2.2 Datastream Naming Convention

Private EIP-96 Public

Figure 1 Data stream naming convention

© Rambus Inc. • rambus.com CONFIDENTIAL 20

2.3 Standard EIP-96 Interfaces

2.4 EIP-96-f Interfaces

© Rambus Inc. • rambus.com CONFIDENTIAL 21

2.5 System Integration Examples

INPUT Data In OUTPUT

M S INPUT Token Token OUTPUT S M

S INPUT Token Token

© Rambus Inc. • rambus.com CONFIDENTIAL 22

2.6 Modes of operation

2.6.2 Algorithm combinations

Crypto Algorithm Crypt Feedback Hash Algorithm Hash Mode

© Rambus Inc. • rambus.com CONFIDENTIAL 23