LLM4PQC - Accurate and Efficient Synthesis of PQC Cores by Feedback-Driven LLMs

LLM4PQC is a feedback-driven, agentic framework that leverages large language models to automate the refactoring of complex post-quantum cryptography reference codes into synthesizable HLS specifications and RTL, significantly reducing manual effort and accelerating design-space exploration through a hierarchical verification process.

The Gist

Imagine you are a master architect trying to build a super-fast, quantum-proof bank vault (this is Post-Quantum Cryptography, or PQC). You have the blueprints, but they are written in a language meant for a human reader, not for a robot builder.

The paper you're asking about, LLM4PQC, is essentially a "Smart Translator and Construction Manager" that helps turn those human-readable blueprints into instructions a robot factory can actually build.

Here is the story of how it works, broken down into simple concepts:

1. The Problem: The "Human vs. Robot" Language Gap

Currently, when cryptographers design these new security algorithms, they write code in C (a programming language). This code is great for computers to run as software, but it's terrible for building hardware (like chips).

Think of it like this:

• The C Code is a recipe written for a chef who has a full kitchen, a fridge, and a pantry. It says things like, "Go grab a bag of flour from the pantry," or "Mix this while the oven heats up."
• The Hardware (HLS) is a robot arm on an assembly line. It doesn't have a pantry, and it can't "go grab" things. It needs everything pre-measured, sitting right in front of it, in a specific order.

If you try to feed the chef's recipe directly to the robot, the robot crashes. It doesn't know how to handle "dynamic memory" (grabbing things on the fly) or "math functions" (like calculating square roots on the spot).

2. The Solution: LLM4PQC (The Smart Translator)

The authors created a system called LLM4PQC. It uses a Large Language Model (LLM)—basically a super-smart AI that knows how to write code—to act as the translator.

But here's the catch: If you just ask the AI, "Translate this recipe," it often makes mistakes because it doesn't know the robot's limitations. So, the authors built a Feedback Loop.

The Four-Step Assembly Line:

Step 1: The Scavenger Hunt (Extraction)
The PQC algorithms are huge, like a 1,000-page novel. But the robot only needs to build the "engine" (the parts that do the heavy math), not the whole book.

• Analogy: The AI reads the novel, finds the specific chapter about the engine, and copies just that page. It also sets up a "test drive" to make sure the engine still works before we start building.

Step 2: The Kitchen Renovation (Preprocessing)
The AI looks at the copied page and sees things the robot can't handle, like "Go to the pantry" (dynamic memory) or "Calculate the square root of 5" (floating-point math).

• Analogy: The AI rewrites the recipe. Instead of "Go to the pantry," it says, "Here is a cup of flour sitting on the counter." Instead of "Calculate the square root," it says, "Here is the answer: 2.23." It turns a messy, flexible kitchen into a rigid, pre-stocked assembly line.

Step 3: The Translation & Trial Run (HLS Generation)
Now the AI translates this cleaned-up recipe into HLS-C (High-Level Synthesis). This is a language that hardware tools understand.

• The Magic: The system doesn't just translate once. It tries to build the robot arm. If the robot arm breaks (the code fails), the system reads the error message, feeds it back to the AI, and says, "Hey, you told the robot to grab a cup that doesn't exist. Fix it."
• The AI rewrites the code, tries again, and keeps doing this until the robot arm works perfectly.

Step 4: The Final Build (Synthesis & Verification)
Once the code passes all the tests, the system turns it into the final hardware design (RTL). It checks to make sure the new robot arm does exactly what the original chef's recipe said it should do.

3. Why is this a Big Deal?

Building hardware for these new security systems is usually slow, expensive, and requires a team of experts who speak "Robot" (hardware engineers).

• Before LLM4PQC: It was like trying to build a car by hand, hammering every single bolt. It took months.
• With LLM4PQC: It's like having a 3D printer that can read a sketch and print the car, fixing its own mistakes as it goes.

4. The Results: Fast, but maybe a bit "Compact"

The paper tested this on real-world security algorithms (Kyber, Dilithium, Falcon).

• Success: The AI successfully built hardware for very complex parts, like the "Falcon Sampler" (which is notoriously difficult, like trying to build a Swiss watch out of LEGOs).
• The Trade-off: The hardware built by the AI was incredibly small and efficient (it used fewer materials than human experts usually do). However, because the AI tended to be very careful and sequential, it was sometimes a little slower (higher latency) than a human expert who might have built a bigger, faster, but more expensive machine.

The Bottom Line

LLM4PQC is a new way to automate the creation of secure hardware. It uses an AI that learns from its own mistakes to turn messy, human-friendly code into clean, robot-friendly hardware instructions.

It's not perfect yet (it's still a bit slow compared to the best human designs), but it proves that we can use AI to build the "quantum-proof" hardware of the future, saving us years of manual labor. It's the difference between hand-crafting a watch and having a smart factory print one.

Technical Summary

1. Problem Statement

The transition to Post-Quantum Cryptography (PQC) requires efficient hardware implementations to protect critical infrastructure against quantum attacks. However, designing PQC hardware is hindered by two primary bottlenecks:

• Manual Refactoring: PQC reference implementations are provided as portable, high-level C code prioritizing correctness over hardware synthesizability. Converting these to High-Level Synthesis (HLS) specifications requires extensive manual refactoring to remove non-synthesizable constructs (e.g., dynamic memory, math.h calls, floating-point arithmetic, and runtime constant table initialization).
• Scalability and Complexity: Complex PQC primitives, such as Number Theoretic Transform (NTT) accelerators and Gaussian samplers (e.g., in the Falcon algorithm), involve intricate data structures and irregular memory access patterns that are difficult to optimize manually.
• Limitations of Current LLMs: While Large Language Models (LLMs) excel at general coding, they struggle with hardware design due to a lack of domain-specific feedback loops. Direct translation often results in code that compiles in C but fails during HLS synthesis.

2. Methodology: The LLM4PQC Framework

The authors propose LLM4PQC, a feedback-driven, agentic workflow that automates the transformation of PQC reference C code into synthesizable HLS-C code. The framework operates in four distinct phases (illustrated in Fig. 1 of the paper):

Phase I: PQC Subroutine Extraction

• Goal: Isolate performance-critical kernels (e.g., NTT, Sampler, FFT) from the full reference implementation.
• Process: An LLM (GPT-5.2) analyzes the codebase to identify target functions, extracts them with minimal dependencies, and co-generates a verification infrastructure. This includes Known-Answer Tests (KATs) and test harnesses to ensure functional equivalence before HLS conversion begins.

Phase II: HLS Preprocessing

Before feeding code to the synthesis tool, an automated LLM pipeline refactors "HLS blockers":

1. Static Memory Mapping: Dynamic memory allocations (malloc, memcpy) are replaced with static arrays or stack allocations.
2. Initialization Removal: Runtime routines that compute constant tables (e.g., twiddle factors for FFT) are executed in a standalone runner. The resulting values are emitted as const arrays in C, allowing the HLS tool to infer ROMs rather than executing logic at runtime.
3. Data Structure Expansion: Complex struct/union definitions are unpacked into primitive data types to satisfy HLS tool constraints.

Phase III: HLS-C Generation and Design-Space Exploration (DSE)

• Core Engine: The preprocessed code is fed into C2HLSC, an LLM-driven framework integrated with the Catapult HLS tool.
• Iterative Refinement: The system employs a feedback loop:
  • The LLM generates HLS-C code.
  • Catapult attempts compilation and simulation.
  • If errors occur (e.g., unsupported library calls, structural issues), error messages are fed back to the LLM as corrective prompts.
  • DSE: Once functional correctness is verified via KATs, the LLM introduces HLS pragmas (loop unrolling, pipelining) based on quantitative feedback (Area, Latency, Power) to optimize for specific objectives.

Phase IV: Synthesis and Verification

• The final HLS-C code is synthesized into RTL for both ASIC (Nangate 45nm) and FPGA (Xilinx Artix-7, XCZU7EV) targets.
• Verification: Automated testbenches compare the RTL output against the original C reference model using 1,000 test cases to ensure end-to-end correctness.

3. Key Contributions

1. LLM-Driven Preprocessing: A novel automated pipeline that transforms non-synthesizable C constructs (dynamic memory, runtime initialization, complex structs) into HLS-compliant code.
2. Structured Feedback Workflow: A fully integrated loop connecting LLM code generation with tool-driven feedback (C2HLSC + Catapult). This allows the system to iteratively refine code based on compilation errors and PPA (Power, Performance, Area) metrics.
3. Empirical Validation: A comprehensive case study on NIST-standardized PQC algorithms (Kyber, Dilithium, Falcon), covering their core primitives (NTT, Sampler, FFT).

4. Experimental Results

The framework was evaluated on five benchmarks: Kyber-NTT, Dilithium-NTT, Falcon-NTT, Falcon-Sampler, and Falcon-FFT.

• Success Rates:
  • Kyber-NTT & Dilithium-NTT: 100% success rate.
  • Falcon-FFT: 100% success rate.
  • Falcon-NTT: 70% success rate (challenging due to hybrid FFT/NTT architecture).
  • Falcon-Sampler: 40% success rate (the most complex case due to Gaussian sampling logic and dynamic structures).
• Hardware Efficiency (ASIC - Nangate 45nm):
  • The framework generated highly compact designs. For example, Kyber-NTT achieved an average area of 2,957 µm², and Dilithium-NTT 6,506 µm².
  • Falcon primitives required larger areas (up to ~162k µm² for NTT) due to floating-point support and hybrid architectures.
• FPGA Comparison:
  • Compared to manual baselines and prior LLM work ([18]), LLM4PQC achieved lower resource utilization (LUTs and FFs) for Kyber, Dilithium, and Falcon NTT.
  • Latency Trade-off: The generated designs generally exhibited higher latency (more cycles) than hand-optimized RTL. This is attributed to the LLM favoring compact, sequential loop structures over aggressive parallelization unless explicitly guided.
  • Sampler Performance: The LLM4PQC Falcon Sampler achieved significantly lower latency (0.39 µs) compared to the prior LLM-based work [18] (0.73 µs).

5. Significance and Future Directions

• Productivity vs. Quality: LLM4PQC demonstrates that feedback-driven LLM workflows can significantly reduce manual effort in PQC hardware design while producing competitive, area-efficient hardware.
• Overcoming Domain Gaps: The study highlights that general-purpose LLMs lack specific HLS domain knowledge (e.g., handling floating-point to fixed-point conversion). The proposed preprocessing phase is critical to bridge this gap before LLM generation.
• Future Work: The authors suggest moving from basic synthesizability to performance tuning. Future directions include:
  • Fine-tuning LLMs on HLS-specific datasets.
  • Using Retrieval-Augmented Generation (RAG) to query verified HLS patterns.
  • Implementing pre-synthesis PPA prediction models to accelerate Design Space Exploration without full synthesis runs.

Conclusion: LLM4PQC provides a powerful, automated pathway for synthesizing complex PQC hardware accelerators, effectively navigating the trade-off between design productivity and hardware quality, and outperforming existing automated approaches in resource efficiency.