KiviPQC-DSA Tiny vs Fast: Area or performance for hardware ML-DSA
Implementing ML-DSA is not only a question of supporting the correct NIST algorithm and parameter set. How much logic you spend, and how fast KeyGen, Sign and Verify complete, depends on which KiviPQC-DSA variant you integrate. KiviPQC-DSA is KiviCore’s hardware IP core for implementing the NIST-standardized ML-DSA post-quantum digital signature algorithm in FPGA and ASIC SoC designs. It is available in two variants, Tiny and Fast.
KiviPQC-DSA-Tiny is optimized for minimum resource utilization. It keeps logic available for the application. KiviPQC-DSA-Fast is optimized for cryptographic performance of signing and verification. It uses more logic in exchange for higher throughput. Both implement NIST FIPS 204 ML-DSA with ML-DSA-44, ML-DSA-65 and ML-DSA-87, including KeyGen, Sign and Verify. Both use an AMBA AXI4-Lite host interface and offload ML-DSA from the host. The C-based HAL, driver, and API support bare-metal, RTOS and Linux.
The algorithm and integration model are the same. The area/performance trade-off is not.

1. Same ML-DSA, two optimization goals
KiviPQC-DSA-Tiny and KiviPQC-DSA-Fast solve the same cryptographic problem at two different points in the design space.
- KiviPQC-DSA-Tiny is the area-first choice. The AMD (Xilinx) Kintex-7 results show 3,755 LUTs at 128.6 MHz. It is designed for systems where logic needs to remain available for other application functions while ML-DSA is still offloaded from the host.
- KiviPQC-DSA-Fast is the performance-first choice. On the same FPGA family, published results show 12,184 LUTs at 127.1 MHz. Fast therefore uses about three times the logic of Tiny while reaching a comparable maximum clock frequency.
This distinction is important: Fast is not simply Tiny clocked higher. It spends more resources on ML-DSA processing to achieve higher cryptographic throughput. Tiny uses sequential, software-controlled execution plus hardware acceleration for computationally intensive ML-DSA operations.
From the host perspective, both remain encapsulated cryptographic engines. The host supplies input, starts KeyGen, Sign or Verify and retrieves the result through the common integration model.
Neither variant is universally better. They address different constraints: available area versus required cryptographic performance.
2. Tiny vs Fast at a glance
The implementation results make the trade-off visible: Fmax is similar, while Fast uses substantially more logic. The additional resources are therefore spent on cryptographic performance rather than simply achieving a higher clock frequency.
|
KiviPQC-DSA-Tiny |
KiviPQC-DSA-Fast |
|
|---|---|---|
|
Binding constraint |
FPGA resources |
Crypto latency/throughput |
|
FPGA logic (Kintex-7) |
3,755 LUTs |
12,184 LUTs |
|
Published Fmax (Kintex-7) |
128.6 MHz |
127.1 MHz |
|
Optimization |
Area-first |
Performance-first |
|
Host interface |
AMBA AXI4-Lite |
AMBA AXI4-Lite |
|
Software integration |
C-based HAL, driver and API |
C-based HAL, driver and API |
|
OS support |
Bare-metal, RTOS, Linux |
Bare-metal, RTOS, Linux |
|
Host CPU offload |
Yes |
Yes |
|
ML-DSA-44 / -65 / -87 |
Yes |
Yes |
|
KeyGen / Sign / Verify |
Yes |
Yes |
|
Verify-only option |
Yes |
Yes |
|
Typical design goal |
Keep logic for the application |
Meet a signature-time or throughput budget |
3. Full ML-DSA or Verify-only?
Area versus performance is not the only decision. A second, independent question is whether the embedded device needs the complete ML-DSA functionality.
Many embedded products never generate signatures on the device. Secure boot and authenticated firmware update typically verify signatures generated in a trusted development or release environment. In this case, the embedded device needs the trusted public key and the Verify function, but does not necessarily need KeyGen and Sign.
KiviPQC-DSA therefore provides Verify-only as an option for both Tiny and Fast. It is not a third architecture. The two decisions remain independent: choose full ML-DSA or Verify-only based on the required functionality, and choose Tiny or Fast based on the area/performance requirements.
Typical Verify-only applications include secure boot, secure firmware updates, data and message authentication, and verification of signed control commands or configuration data.
Explore KiviCore IP:
4. Why KiviPQC-DSA-Tiny is smaller
KiviPQC-DSA-Tiny is designed for applications where most of the logic must remain available for application-specific functions. From the host’s perspective, Tiny operates as a self-contained engine: the host selects the ML-DSA parameter set, provides the input data, initiates KeyGen, Sign or Verify via AXI4-Lite, waits for completion and retrieves the result. Integration is based on the same platform-independent C-based HAL, driver and API model as KiviPQC-DSA-Fast, supporting Linux, RTOS and bare-metal environments. Execution is managed by a controller within the IP core, independently of the host processor. Tiny combines sequential processing with dedicated hardware acceleration for the most compute-intensive ML-DSA operations, concentrating resources where they deliver the greatest benefit. Published implementation results show that Tiny requires approximately one-third of the logic resources of Fast on the same FPGA families while achieving a comparable maximum clock frequency.
5. Why KiviPQC-DSA-Fast is faster
KiviPQC-DSA-Fast dedicates more logic to ML-DSA processing, enabling higher throughput for KeyGen, Sign and Verify. On the same FPGA devices, its published maximum clock frequency is comparable to that of Tiny. The performance gain is achieved through a larger datapath rather than a higher clock rate. Host integration remains identical across both variants, using AXI4-Lite together with the platform-independent HAL, driver and API model for bare-metal, RTOS and Linux environments. Published Fast performance figures represent the number of operations per second executed within the IP core. Signing throughput is reported as an average because ML-DSA uses rejection sampling, resulting in a variable number of attempts per signature.
|
Clock |
Operation |
ML-DSA-44 |
ML-DSA-65 |
ML-DSA-87 |
|---|---|---|---|---|
|
100 MHz |
Key generation |
2,700 op/s |
1,790 op/s |
1,180 op/s |
|
Signing (average) |
320 op/s |
196 op/s |
182 op/s |
|
|
Verifying |
2,130 op/s |
1,450 op/s |
980 op/s |
|
|
200 MHz |
Key generation |
5400 op/s |
3580 op/s |
2360 op/s |
|
Signing (average) |
640 op/s |
392 op/s |
364 op/s |
|
|
Verifying |
4,260 op/s |
2,900 op/s |
1,960 op/s |
These figures describe processing inside the cryptographic core. They are not equivalent to complete secure-boot or firmware-update times. Memory access, data movement, software control and other system functions also contribute to end-to-end latency.
Whether a particular clock frequency can be achieved also depends on the target FPGA. The published Fmax values should therefore be considered when translating the operations-per-second figures to a specific device.
6. Which variant fits?
Choose KiviPQC-DSA-Tiny when resources are the primary constraint and the device needs to retain logic for other application functions. Tiny still offloads ML-DSA from the host while prioritizing a small logic footprint.
Choose KiviPQC-DSA-Fast when cryptographic latency or throughput justifies allocating more logic to ML-DSA-Fast is intended for systems where substantially higher cryptographic processing performance is more important than minimizing the footprint.
If the device only authenticates externally signed firmware, software, FPGA bitstreams or other data, add the Verify-only option on top of that area/performance decision.
The highest-throughput core is not automatically the best system fit. Resources, host CPU load, data movement and required end-to-end latency should be evaluated together.
Not sure which constraint dominates?
KiviCore also supports the integration of ML-DSA into FPGA and ASIC SoC security architectures.
Related Semiconductor IP
- Post-Quantum Digital Signature IP Core
- Secure Boot Loader
- AES-GCM - Authenticated Encryption and Decryption
- AES-GCM Authenticated Encryption and Decryption
- AES-GCM - Authenticated Encryption and Decryption
Related Blogs
- ARM vs Intel...Performance? Power? OS support? Or ubiquity?
- Performance in Hardware Emulators
- Performance in Hardware Emulators: System Architecture
- Decisions, decisions: Hardware accelerator or DSP?