The following table summarizes the DRAM capacity and bandwidth impact of enabling Inline ECC
and Inline Encryption features. Use this table for system planning to select the
appropriate mode for your application.
Table 1. DRAM Capacity and Bandwidth Impact of Inline ECC and Encryption
-1/8 of the protected region size (≈ -1/9 of total DRAM at
maximum ECC coverage)
Example: (4 GB DRAM): -455 MB reserved for ECC, ≈3.56 GB
available for user data.
Added overhead because every ninth cycle is occupied by ECC. Bandwidth
impact is worse with partial writes due to RMW operation.
XTS-AES-256
None — no DRAM metadata required
XTS metadata stored on-chip
Maximum bandwidth capped at 27 GB/s.
AES-GCM-256
(Single-Level Authentication DRAM metadata)
−1/4 of GCM-protected data (≈ −1/5 of total DRAM at maximum
coverage).
Example: (4 GB DRAM at maximum coverage): ≈ −820 MB.
Maximum throughput of 2 GB/s for protected region.
AES-GCM-256
(Dual-level auth, 64 MB protected data)
First-level MACs remain in DRAM; second-level MACs in on-chip
SRAM.
Reduced DRAM metadata per message (32-bit vs. 96-bit primary MAC).
Cache-miss scenarios require more DRAM accesses than single-level
auth (2R+3W vs. 1R+2W for a write miss+evict). Primary benefit is
DRAM replay-attack prevention, not bandwidth improvement.
ILECC + XTS
ECC storage only (−1/9)
No XTS metadata overhead
Combination of ILECC + XTS impacts; see individual rows
ILECC + GCM
ECC: −1/8 of ECC-protected data; GCM metadata: −1/4 of
GCM-protected data; metadata ECC: −1/8 of GCM metadata. Each
term scales with its respective protected region size.
Example (4 GB DRAM at maximum coverage): ≈ −364 − 728 − 91
MB.
Useful data throughput capped at 2 GB/s by the AES-GCM encryption engine
— the same limit as AES-GCM alone. ILECC adds DRAM
read-modify-write overhead but does not reduce this ceiling
further.
Bandwidth impact varies with traffic pattern and design
configuration. You can configure the size of the protected
region, limiting the bandwidth impact to accesses within the
protected region.