Blog
 / 
Engineering
TFHE-rs
Announcements

Announcing HPU on FPGA: The First Open-source Hardware Accelerator for FHE

May 21, 2025
  -  
Pierre Gardrat

This month, Zama’s hardware team released the first fully open-source hardware accelerator for FHE, along with TFHE-rs v1.2, which includes a new backend to support this Homomorphic Processing Units (HPU) running on an Field-Programmable Gate Array (FPGA).

After more than two years of development, our team at Zama is excited to share this milestone and to gather feedback from both application developers and FHE hardware acceleration community.

The complete systemVerilog implementation of HPU is available in this repository. 

What is HPU?

HPU is a processor designed to compute directly on encrypted data. Unlike hardware that simply accelerates cryptographic primitives like bootstrapping or re-linearization, the HPU is a complete on-chip processor. It includes a register file, control logic, and an arithmetic unit that executes a stream of instructions over encrypted operands.

Running today on an FPGA, the FHE hardware accelerator HPU contains all the logic needed to execute boolean and integer operations on encrypted operands of various sizes.

‍

The HPU is driven via the new tfhe-hpu-backend, available in TFHE-rs v1.2. This new TFHE-rs backend initializes HPU’s keys, LUT and Digit Operations (DOp) firmware — the micro-code associated with each of the input instructions named Integer Operations (IOp). 

For example, when an application needs to do an encrypted addition [.c-inline-code]a + b[.c-inline-code], where [.c-inline-code]a[.c-inline-code] and [.c-inline-code]b[.c-inline-code] are [.c-inline-code]FheUint[.c-inline-code], [.c-inline-code]a[.c-inline-code] and [.c-inline-code]b[.c-inline-code] are sent to the large memory of the HPU, along with the command [.c-inline-code]ADD IOp[.c-inline-code]. The [.c-inline-code]ADD IOp[.c-inline-code] is then translated into a series of DOp instructions by the embedded controller. Each DOp is handled by one of the processing elements of the HPU. 

HPU is not limited to run addition & multiplication. It has been designed to be a versatile FHE processor, so the HPU IOp instruction set is fully customizable. Developers can not only modify existing operations, but also create new IOps and write their own corresponding DOps firmware to execute on chip.

HPU includes all the processing elements necessary to run all your TFHE operations on chip. It interacts with the host memory & CPU only when required by the running application. For those familiar with TFHE cryptographic scheme, it includes a module implementing complete Programmable BootStrapping (PBS) — a core requirement for fast and scalable FHE execution. To learn more about the TFHE scheme, check out our blog post series TFHE deep dive to understand why PBS module is a must-have for this accelerator.

How to use HPU?

Zama's HPU is integrated into the TFHE-rs library. When the HPU backend is enabled, it receives its encrypted operands and instructions from TFHE-rs.

Using the HPU is easy — it works with the same high-level API TFHE-rs used to run encrypted operations on CPU or GPU. Simply select an HPU device, and all operations on your ciphertexts will be executed on the HPU.

A comprehensive documentation is available here.

 // Instantiate HpuDevice --------------------------------------------------
    let hpu_device = HpuDevice::from_config(&args.config.expand());

    // Generate keys ----------------------------------------------------------
    let config = Config::from_hpu_device(&hpu_device);

    let client_secret_key = ClientKey::generate(config);
    let server_key = CompressedServerKey::new(&client_secret_key);

    set_server_key((hpu_device, server_key));
    
    // Product ---------------------------------------------------------
    // Generate random inputs value and compute expected result
    let in_a = rng.gen_range(0..u64::max_value());
    let in_b = rng.gen_range(0..u64::max_value());

    let clear_mul_ab = in_a.wrapping_mul(in_b);

    // Encrypt input value
    let fhe_a = FheUint64::encrypt(in_a, &client_secret_key);
    let fhe_b = FheUint64::encrypt(in_b, &client_secret_key);

    // Triggered operation on HPU through hl_api			
    let fhe_mul_ab = fhe_a * fhe_b;

    // Decrypt values
    let dec_mul_ab: u64 = fhe_mul_ab.decrypt(&client_secret_key);

    // Display result and check
    println!(" {} *  {} = fhe({}), clear({})", in_a, in_b, dec_mul_ab, clear_mul_ab);
    assert_eq!(dec_mul_ab, clear_mul_ab,
         "Error with * operation get {}, expect {}",dec_mul_ab, clear_mul_ab);

Let’s talk about performance 

How fast is HPU? Well, it’s pretty fast! Today, it is running at 350Mhz on the 7nm FPGA of the AMD/Xilinx V80 board equipped with x2 HBM2e. It can process around 13k PBS/s consuming around 200W. Some FHE operations are still being optimized, but you can already find the first benchmark results that we published in the documentation.

Why use HPU? And when?

The HPU is a specific machine designed for FHE. It is faster and more power-efficient than CPU or GPU for the same task. HPU also has lower cost per unit thanks to the affordability and energy efficiency of FPGAs compared to both CPUs and GPUs.

While Zama’s HPU on FPGA is not fully production-ready yet, Zama’s teams are actively working on improving it. We aim to  integrate it in the Zama product line before the end of 2025. In the meantime, we are working on multi-HPU servers that will further reduce the latency of FHE operations and increase the number of operations per dollar and per hour. 

The cool part is that the entire HPU stack is fully open source — from the systemVerilog hardware design and firmware to the TFHE-rs integration backend. Developers and researchers can not only use the HPU accelerator, but also audit, extend, and repurpose it for their own prototypes. If you’re eager to test it out now, it’s simple:

  • Get your hands on an V80 board
  • Load the provided HPU bitstream
  • Or compile your own version from: zama-ai/hpu_fpga

We’re excited to see what the community builds with it.

Additional links

‍

Read more related posts

No items found.
Libraries
Concrete ↗ Concrete ML ↗FHEVM ↗TFHE-rs ↗
Products & Services
Privacy-preserving Machine learningConfidential blockchainThreshold key management SYSTEM
Developers
BlogDOCUMENTATION ↗‍GITHUB ↗ FHE resources ↗ Research papers ↗Bounty Program ↗FHE STATE OS
Company
Aboutintroduction to fheEventsMediaCareers ↗Legal
Contact
Talk to an expertCONTACT USXDiscordTelegramALL community channels
Privacy is necessary for an open society in the electronic age. Privacy is not secrecy. A private matter is something one doesn't want the whole world to know, but a secret matter is something one doesn't want anybody to know. Privacy is the power to selectively reveal oneself to the world.If two parties have some sort of dealings, then each has a memory of their interaction. Each party can speak about their own memory of this; how could anyone prevent it? One could pass laws against it, but the freedom of speech, even more than privacy, is fundamental to an open society; we seek not to restrict any speech at all. If many parties speak together in the same forum, each can speak to all the others and aggregate together knowledge about individuals and other parties. The power of electronic communications has enabled such group speech, and it will not go away merely because we might want it to.Since we desire privacy, we must ensure that each party to a transaction have knowledge only of that which is directly necessary for that transaction. Since any information can be spoken of, we must ensure that we reveal as little as possible. In most cases personal identity is not salient. When I purchase a magazine at a store and hand cash to the clerk, there is no need to know who I am. When I ask my electronic mail provider to send and receive messages, my provider need not know to whom I am speaking or what I am saying or what others are saying to me; my provider only need know how to get the message there and how much I owe them in fees. When my identity is revealed by the underlying mechanism of the transaction, I have no privacy. I cannot here selectively reveal myself; I must always reveal myself.Therefore, privacy in an open society requires anonymous transaction systems. Until now, cash has been the primary such system. An anonymous transaction system is not a secret transaction system. An anonymous system empowers individuals to reveal their identity when desired and only when desired; this is the essence of privacy.Privacy in an open society also requires cryptography. If I say something, I want it heard only by those for whom I intend it. If the content of my speech is available to the world, I have no privacy. To encrypt is to indicate the desire for privacy, and to encrypt with weak cryptography is to indicate not too much desire for privacy. Furthermore, to reveal one's identity with assurance when the default is anonymity requires the cryptographic signature.We cannot expect governments, corporations, or other large, faceless organizations to grant us privacy out of their beneficence. It is to their advantage to speak of us, and we should expect that they will speak. To try to prevent their speech is to fight against the realities of information. Information does not just want to be free, it longs to be free. Information expands to fill the available storage space. Information is Rumor's younger, stronger cousin; Information is fleeter of foot, has more eyes, knows more, and understands less than Rumor.We must defend our own privacy if we expect to have any. We must come together and create systems which allow anonymous transactions to take place. People have been defending their own privacy for centuries with whispers, darkness, envelopes, closed doors, secret handshakes, and couriers. The technologies of the past did not allow for strong privacy, but electronic technologies do.We the Cypherpunks are dedicated to building anonymous systems. We are defending our privacy with cryptography, with anonymous mail forwarding systems, with digital signatures, and with electronic money.Cypherpunks write code. We know that someone has to write software to defend privacy, and since we can't get privacy unless we all do, we're going to write it. We publish our code so that our fellow Cypherpunks may practice and play with it. Our code is free for all to use, worldwide. We don't much care if you don't approve of the software we write. We know that software can't be destroyed and that a widely dispersed system can't be shut down.Cypherpunks deplore regulations on cryptography, for encryption is fundamentally a private act. The act of encryption, in fact, removes information from the public realm. Even laws against cryptography reach only so far as a nation's border and the arm of its violence. Cryptography will ineluctably spread over the whole globe, and with it the anonymous transactions systems that it makes possible.For privacy to be widespread it must be part of a social contract. People must come and together deploy these systems for the common good. Privacy only extends so far as the cooperation of one's fellows in society. We the Cypherpunks seek your questions and your concerns and hope we may engage you so that we do not deceive ourselves. We will not, however, be moved out of our course because some may disagree with our goals.The Cypherpunks are actively engaged in making the networks safer for privacy. Let us proceed together apace.Onward. By Eric Hughes. 9 March 1993.