LM-AES-GCM is a cryptographic IP core for hardware offloading of authenticated encryption in FPGA and SoC designs.
The engine implements AES in Galois/Counter Mode according to NIST SP 800-38D, with the AES block cipher of FIPS 197 at 128-bit and 256-bit key sizes. It performs authenticated encryption, authenticated decryption with tag verification, GMAC authentication-only operation, counter mode and electronic codebook mode, with additional authenticated data of any length.
The cipher is fully unrolled: one 128-bit block enters and one leaves every clock cycle, with the GHASH authenticator keeping pace. The core is delivered as vendor-neutral SystemVerilog and builds from one source on AMD, Altera and Efinix devices. It includes AMBA AXI interfaces and a register map, and ANSI C drivers are provided for fast integration into the target platform.
Measured FPGA results
Product top, out of context, constrained at the target clock. AMD and Efinix report LUTs, Altera reports ALMs; the two are never combined.
| Device | Configuration | Logic | FF | Memory | DSP | Fmax |
|---|---|---|---|---|---|---|
| Altera Agilex 3A3CW135BM16AE6S · quartus-pro 26.1.1 | PIPES=1 | 9,927 ALM | 11,736 | 466 Kb M20K | 0 | 251.3 MHztarget 250 |
| AMD Kintex UltraScale+xcku3p-ffva676-1-e · vivado 2026.1 | PIPES=1 | 12,485 LUT | 7,142 | 114 BRAM | 0 | 273.6 MHztarget 250 |
| Efinix Titanium Ti375Ti375N1156 · efinity 2026.1 | PIPES=1 | 24,394 LUT | 14,915 | 228 RAM | 0 | 296.9 MHztarget 250 |
Features
Authenticated encryption
- AES-GCM authenticated encryption and authenticated decryption
- GMAC — authentication of additional data with no payload
- Tag lengths of 128, 120, 112, 104 and 96 bits
- Additional authenticated data of any length, forwarded or discarded
- Initialisation vectors of 96 bits and of arbitrary length
Block cipher modes
- CTR — counter mode
- ECB — electronic codebook, encryption
Key sizes
- 128-bit and 256-bit, with the key schedule expanded in hardware
Engine
- Fully unrolled cipher: one 128-bit block per clock, sustained
PIPES = 2configuration processes two blocks per clock- GHASH sustains the cipher's rate — the authenticator is not the bottleneck
- Tag comparison in hardware, with the verdict on dedicated output pins
Integration
- AMBA AXI4-Lite control and six AXI4-Stream data interfaces
- Key, initialisation vector, payload and tag each on their own port
- No key material at any register address
- Two delivery tops: complete AXI product, or bare engine for a custom fabric
- ANSI C driver, UVM RAL, IP-XACT, SystemRDL register description
Applications
- IPsec, MACsec and TLS record protection
- NVMe and storage self-encrypting drives
- High-throughput network encryption
- Secure firmware and configuration images
- Datacentre link encryption
Block diagram
Interfaces
Six AXI4-Stream ports carry data and an AXI4-Lite interface carries control. Key material, initialisation vector, payload and tag each have their own lifetime, so each has its own port.
| Interface | Type | Width | Carries |
|---|---|---|---|
s_axil | AXI4-Lite slave | 32-bit | configuration, command, status, counters, tag and IV lengths |
s_axis_key | AXI4-Stream sink | 32-bit | the key, most significant word first |
s_axis_iv | AXI4-Stream sink | 32-bit | the initialisation vector |
s_axis_din | AXI4-Stream sink | 128 × PIPES bits | payload in |
m_axis_dout | AXI4-Stream source | 128 × PIPES bits | payload out |
s_axis_tin | AXI4-Stream sink | 32-bit | the expected tag, on decrypt |
m_axis_tout | AXI4-Stream source | 32-bit | the computed tag, on encrypt |
enc_dec | input | 1-bit | direction, sampled at message start |
enable | input | 1-bit | payload gate |
tag_valid, tag_ok, tag_fail | output | 1-bit each | verification verdict, as pins |
irq | level | 1-bit | completion and error events |
The verdict is on pins as well as in a register, so a downstream sink can gate itself on tag verification without a bus access and without a race.
Throughput
Throughput follows directly from the architecture:
throughput = 128 x PIPES x f_clk bits per second
At 250 MHz, PIPES = 1 gives 32 Gbit/s and PIPES = 2 gives 64 Gbit/s.
There is no slow path and no key-dependent timing: the cipher is unrolled, so a block enters every clock regardless of key size, and GHASH sustains that rate rather than throttling it.
Security properties
Authenticated decryption returns nothing on failure. SP 800-38D clause 5.2.2 requires that a decryption failing verification returns FAIL and nothing else, and this core implements that literally: plaintext is not released to the output when the tag does not verify. Because the tag is a function of the whole ciphertext, an integrator needing plaintext before the verdict must buffer it outside this core, and is then accepting the risk the clause exists to prevent.
No key material is readable. Keys arrive on their own stream and appear at no register address. Zeroisation clears the key schedule and the hash subkey on demand.
Power analysis is not addressed. No masking, no randomised schedule, no constant-power substitution and no dummy rounds are implemented; the substitution memory is a block RAM whose access energy is data dependent. An application facing an attacker with physical access and trace-collection capability requires countermeasures above this core.
Configuration
| Parameter | Type | Effect |
|---|---|---|
PIPES | elaboration | 1 = one block per clock; 2 = two blocks per clock |
| key size | run time | 128 or 256 bits |
| mode | run time | GCM, CTR or ECB |
| tag length | run time | 128, 120, 112, 104 or 96 bits |
| AAD forwarding | run time | forward additional data to the output, or discard it |
| top choice | elaboration | full AXI product, or bare engine |
Resources and performance
Resource utilisation and maximum clock frequency for each target device are measured out of context and published per target in the measured results on this page. AMD and Efinix rows report LUTs; Altera rows report ALMs, and the two are never combined. End-to-end latency is published per key size with both endpoints named.
Deliverables
| Item | Contents |
|---|---|
| RTL | parameterised SystemVerilog, vendor-neutral |
| Model | bit-accurate C++ model |
| Registers | SystemRDL source plus six generated exports |
| Verification | UVM RAL, formal property wrappers, CAVP vector drivers |
| Software | ANSI C reference driver with generated header and JSON |
| Packaging | IP-XACT, IEEE 1685-2022 |
| Implementation | runnable flow script per FPGA vendor, file list, SDC |
| Documentation | integration guide |