Deploy Your First FPGA Accelerator

Build and deploy a custom FPGA accelerator on AWS EC2 F2 instances.

Introduction

30 Second Summary

Every time you tap a button on your phone and get an instant response, there is specialized hardware working behind the scenes to make that speed possible. FPGAs are chips that you can reprogram to run custom hardware logic, and cloud providers now let you access them on demand.

In this project, you will deploy a working FPGA accelerator on an AWS EC2 F2 instance. You will build a hardware adder that performs addition directly on the FPGA fabric, write values to it from the host CPU, and read results back.

What You'll Build

You will go through the full FPGA-in-the-cloud development lifecycle: setting up a development environment with Vivado, simulating an RTL design, building a Design Checkpoint (DCP), creating an Amazon FPGA Image (AFI), loading it onto a live FPGA, and testing host-to-FPGA communication.

By the end of this project, you'll have:

  • A development EC2 instance running the FPGA Developer AMI with Vivado pre-installed, and a verified RTL design using the HDK simulation flow.
  • A compiled Design Checkpoint submitted to AWS and converted into an Amazon FPGA Image ready for deployment.
  • A live F2 instance with your custom AFI loaded, running software that writes operands, triggers FPGA computation, and reads results back over the AXI-Lite interface.
  • A custom subtraction operation added to the FPGA design and verified end-to-end (Secret Mission).

Are there any prerequisites?

You need an AWS account with the ability to launch F2 instances. Your quota for "Running On-Demand F instances" must be at least 24 vCPUs. You should also have basic familiarity with SSH, the Linux command line, and some prior exposure to HDL concepts like Verilog or VHDL.

Verify Your AWS Account and Launch the Development Instance

Before you can develop FPGA logic in the cloud, your AWS account needs the right permissions and quotas to launch the specialized instances this project requires. F2 instances are not enabled by default. The default quota for F-type instances is 0 vCPUs, which means you cannot launch one until you request an increase. In this step, you will get your account ready and launch a development instance with Vivado pre-installed.

In This Step, Get Ready To:
  • Verify your AWS account has enough vCPU quota for both F-type and standard instances.
  • Subscribe to the FPGA Developer AMI in the AWS Marketplace.
  • Launch a c5.4xlarge development instance with Vivado and the HDK tools ready to use.
Verify Your F-Instance Quota

AWS limits how many vCPUs you can run for each instance family. The default quota for F-type instances is 0 vCPUs, which means you cannot launch an F2 instance until you request an increase. You also need quota for the standard C-type instance you will use for development.

  • Open the Service Quotas console.
  • Make sure the region is set to US East (N. Virginia) (us-east-1) in the top-right corner of the console.
  • Type Running On-Demand F instances in the filter field.
  • Check the Applied quota value column. You need at least 24 vCPUs to launch an f2.6xlarge instance.
  • If the value is 0 or less than 24, click the quota name, then click Request quota increase. Enter 24 as the new value and submit.

Quota increases can take time

Quota increases for F instances may take a few hours to a few days to be approved. If you do not already have F-instance quota, request it now and continue with the rest of this step while you wait.

You also need quota for the development instance. This is a standard C-type instance.

  • Clear the filter and type Running On-Demand Standard (A, C, D, H, I, M, R, T, Z) instances.
  • Verify the Applied quota value is at least 16 vCPUs. This covers the c5.4xlarge development instance.
  • If the value is too low, request an increase to at least 16.

Why us-east-1?

F2 instances are currently available in three regions: us-east-1 (N. Virginia), eu-west-2 (London), and us-west-2 (Oregon). This project uses us-east-1 because it was the first region to support F2 and has the broadest availability.

Subscribe to the FPGA Developer AMI

The FPGA Developer AMI is a pre-built Amazon Machine Image that comes with AMD Vivado and the AWS FPGA development tools already installed. You need to subscribe to it in the AWS Marketplace before you can use it to launch instances.

  • Open the FPGA Developer AMI (Ubuntu) listing in the AWS Marketplace.
  • Click Continue to Subscribe.
  • Click Accept Terms.
  • Wait for the subscription to become active. This is usually immediate.

Pro tip: the AMI is free

There is no software charge for the FPGA Developer AMI. You only pay for the EC2 instance it runs on.

Launch the Development Instance

Your development instance is where you will clone the FPGA development kit, run simulations, and build the design checkpoint. Vivado requires at least 4 vCPUs and 32 GiB of memory, so you will use a c5.4xlarge instance (16 vCPUs, 32 GiB RAM) at approximately $0.68/hour.

  • Open the EC2 Console.
  • Confirm you are in the us-east-1 region.
  • Click Launch instances.
  • Enter fpga-dev in the Name field.

Now select the FPGA Developer AMI you subscribed to.

  • Under Application and OS Images (Amazon Machine Image), click Browse more AMIs.
  • Go to the AWS Marketplace AMIs tab.
  • Search for FPGA Developer AMI (Ubuntu).
  • Select the latest version (1.19.1 with Vivado 2025.2).

Configure the instance type and key pair.

  • Set Instance type to c5.4xlarge.
  • Under Key pair (login), select an existing key pair or create a new one. If you create a new key pair, download the .pem file and save it somewhere safe.
  • Under Network settings, leave the defaults. Make sure SSH is allowed from your IP.

The Vivado tools and build artifacts need significant disk space. You need to increase the default storage.

  • Under Configure storage, increase the root volume to at least 100 GiB. Set the volume type to gp3.
  • Click Launch instance.

Why c5.4xlarge and not a smaller instance?

AMD Vivado requires at least 4 vCPUs and 32 GiB of memory to run synthesis and place-and-route. The c5.4xlarge meets these requirements and is the minimum recommended instance type for FPGA development. It must also be an x86-based instance. Graviton (ARM) instances are not supported.

Wait for the instance to reach the Running state, then connect to it.

  • Select your fpga-dev instance in the EC2 Console.
  • Click Connect.
  • Use EC2 Instance Connect from the browser, or connect via your preferred SSH client. The username is ubuntu.

macOS

If you are using SSH from a terminal, run the following command.

ssh -i [[PEMPATH="path to your .pem file"]] ubuntu@[[EC2DNS="your instance's public IPv4 DNS"]]

Windows

If you are using PowerShell, run the following command.

ssh -i [[PEMPATH="path to your .pem file"]] ubuntu@[[EC2DNS="your instance's public IPv4 DNS"]]

Linux

If you are using SSH from a terminal, run the following command.

ssh -i [[PEMPATH="path to your .pem file"]] ubuntu@[[EC2DNS="your instance's public IPv4 DNS"]]

I'm connected

You should see a terminal prompt showing ubuntu@ followed by your instance's hostname. You are now on your FPGA development instance.

I see an error

Having trouble connecting?

If you see Permission denied (publickey), make sure you are using the correct .pem file and that the username is ubuntu (not ec2-user).

On macOS or Linux, you may also need to set permissions on your key file with chmod 400 your-key.pem. If you see a timeout error, check that your security group allows SSH from your IP address.

Help me troubleshoot my SSH connection.

Your development environment is up and running. Next up, you will clone the AWS FPGA development kit and explore the example design you are going to build and deploy.

Set Up the HDK Environment and Explore the Example Design

Your development instance is running, but it doesn't know anything about FPGA development yet. The AWS FPGA Development Kit (HDK) provides the shell definitions, build scripts, and example designs you need to create custom FPGA logic. In this step, you'll set up the HDK environment and explore the example design that implements a hardware adder on the FPGA.

In This Step, Get Ready To:
  • Clone the aws-fpga repository and initialize the HDK environment with Vivado.
  • Explore the cl_axil_reg_access example design and understand its register map.
  • Run an RTL simulation to verify the adder logic before building.
Clone the aws-fpga Repository and Set Up the HDK

The HDK lives in the aws-fpga GitHub repository. You need to clone it and run a setup script that configures environment variables, verifies your Vivado installation, generates IP simulation models, and downloads shell files from S3.

  • SSH into your fpga-dev instance. The username is ubuntu.
  • Clone the repository and check out the f2 branch:
git clone https://github.com/aws/aws-fpga.git
cd aws-fpga
git checkout f2

Why the f2 branch?

The f2 branch contains the development kit for EC2 F2 instances specifically. The older F1 instances were retired in December 2025, so f2 is the only branch you need for new FPGA development on AWS.

  • Run the HDK setup script:
source hdk_setup.sh

What does this command do?

The hdk_setup.sh script performs four things: it verifies that Vivado is installed and accessible, sets environment variables like $AWS_FPGA_REPO_DIR, generates IP simulation models for the design tools, and downloads the F2 shell files from S3. This takes about 2 minutes the first time you run it.

  • Wait for the message: AWS HDK setup PASSED.

I see AWS HDK setup PASSED

Your HDK environment is ready. The script confirmed that Vivado 2025.2 is installed and all shell files are downloaded.

I see an error

Having trouble with HDK setup?

If you see a Vivado-related error, make sure you launched the correct AMI (FPGA Developer AMI with Ubuntu). Vivado comes pre-installed on this AMI. If you see S3 download errors, check that your instance has internet access. Help me troubleshoot my HDK setup error.

Explore the cl_axil_reg_access Example Design

The HDK includes several example designs. You'll work with cl_axil_reg_access, a beginner-friendly design introduced in DevKit v2.3.2. It implements a 32-bit hardware adder that communicates with the host CPU through the AXI-Lite interface.

  • Navigate to the example design directory and set the CL_DIR environment variable:
cd hdk/cl/examples/cl_demo/cl_axil_reg_access
export CL_DIR=$(pwd)

What is CL_DIR?

CL_DIR stands for Custom Logic Directory. The HDK build scripts use this environment variable to locate your design source files, verification tests, and build configurations. Every HDK project requires it to be set before building or simulating.

  • Open the design source file to see what the accelerator does:
cat design/cl_axil_reg_access.sv

This is the SystemVerilog file that defines the entire accelerator. Take a few minutes to read through it. Here are the key things to notice.

The design uses the OCL AXI-Lite interface. This is a 32-bit wide communication channel between the host CPU and the FPGA, mapped to PCIe Application PF0 BAR0 with a 32 MiB register space.

The design implements five registers at specific memory addresses:

  • Operand_A at address 0x0000 (read/write, 32-bit unsigned).
  • Operand_B at address 0x0004 (read/write, 32-bit unsigned).
  • Sum at address 0x0008 (read-only, 32-bit unsigned).
  • Carry at address 0x000C (read-only, bit[0] is the carry output).
  • Control_Status at address 0x0010 (read/write, bit[0] is start, bit[1] is ready).

The workflow is straightforward: the host writes two operands, triggers the addition by writing 1 to the start bit, then reads back the Sum and Carry registers. If the host reads from an invalid address, the design returns 0xDEADBEEF. The entire design runs on clk_main_a0 at 250MHz.

What is AXI-Lite?

AXI-Lite is a lightweight bus protocol for reading and writing individual registers. Think of it as a simple address-and-data interface. The host CPU says "write this value to this address" or "read the value at this address," and the FPGA responds. It's the simplest way for software to talk to custom hardware logic.

Why cl_axil_reg_access instead of a more complex example?

The HDK includes more advanced examples like cl_mem_perf (HBM bandwidth optimization) and cl_sde (streaming data engine). Those require understanding DMA engines and complex memory hierarchies. The cl_axil_reg_access design uses only 0.26% of the FPGA's CLB LUTs, which means fast builds and a focused learning experience on the most fundamental pattern: host-to-FPGA register communication.

Run RTL Simulation to Verify the Design

Before spending 30-90 minutes building a Design Checkpoint (DCP), you should verify the design works correctly in simulation. RTL simulation compiles the design and runs a testbench against it using XSIM, the Xilinx Simulator included with Vivado.

  • Navigate to the verification scripts directory:
cd $CL_DIR/verif/scripts
  • Run the simulation test:
make TEST=test_sum

What does this command do?

This compiles the SystemVerilog design files and the test_sum testbench, then runs the simulation using XSIM. The testbench writes operand values to the FPGA registers, triggers the addition, and checks that the Sum and Carry outputs match the expected results. This is the same workflow you'll eventually run on real hardware, but entirely in software.

The simulation takes a minute or two to compile and run. When it finishes, look for TEST PASSED in the output.

I see TEST PASSED

The adder logic is verified. The testbench confirmed that the design correctly computes sums and carries for the test inputs. You're ready to build the design for real hardware.

I see an error or TEST FAILED

Simulation not passing?

Make sure you set the CL_DIR environment variable before navigating to the verification directory. Also confirm that hdk_setup.sh completed successfully (it generates the IP simulation models that the testbench depends on). If you're still stuck, help me debug my simulation error.

Pro tip: explore other tests

You can browse additional test files in the $CL_DIR/verif/tests/ directory. Each test exercises different aspects of the design. Reading testbench code is one of the best ways to understand how hardware designs are verified.

Your design is simulated and verified. Next up, you'll build a Design Checkpoint from this design and submit it to AWS for AFI creation. This is where your design goes from simulation to real FPGA hardware.

Build the Design Checkpoint and Create the AFI

Your simulation confirmed the adder logic works correctly. Now it is time to turn that verified design into real hardware. In this step, you will compile the design into a Design Checkpoint (DCP) using Vivado, upload it to S3, and submit it to AWS for Amazon FPGA Image (AFI) creation.

The DCP build runs Vivado synthesis, placement, and routing. This process takes 30-90 minutes depending on design complexity. Since the cl_axil_reg_access example uses only 0.26% of CLB LUTs, your build should be on the shorter end.

In This Step, Get Ready To:
  • Build a Design Checkpoint (DCP) from the cl_axil_reg_access design using Vivado.
  • Upload the DCP tarball to an S3 bucket.
  • Submit the DCP to AWS and receive your AFI and AGFI IDs.
Start the DCP Build

A Design Checkpoint is a compiled snapshot of your FPGA design after Vivado has synthesized, placed, and routed all the logic. Think of it as the "binary" equivalent for hardware. AWS needs this file to create an FPGA image that can be loaded onto real hardware.

  • Navigate to the build scripts directory:
cd $CL_DIR/build/scripts
  • Start the build:
./aws_build_dcp_from_cl.py -c cl_axil_reg_access

What does this command do?

This Python script launches Vivado to synthesize your SystemVerilog design into FPGA primitives, then place and route those primitives onto the physical FPGA fabric. The -c cl_axil_reg_access flag tells it which custom logic design to build.

A log file is created in the current directory with a timestamp (e.g., 2026_01_15-143022.vivado.log). You can monitor progress in a separate terminal:

tail -f *.vivado.log

How long does this take?

The build takes approximately 30-90 minutes for the included examples. The cl_axil_reg_access example is very small (0.26% of CLB LUTs), so expect it to finish on the shorter end. You can work on the next substep (creating your S3 bucket) while the build runs.

When the build completes, you will see: Finished building design checkpoints for customer design cl_axil_reg_access.

The DCP tarball is saved to $CL_DIR/build/checkpoints/ as a .Developer_CL.tar file.

DCP filename says VIOLATED?

If the DCP filename contains .VIOLATED, it means timing closure failed. The design did not meet the 250MHz clock requirement. For the small cl_axil_reg_access example, this is unlikely. If it happens, try running the build again. Help me debug a timing violation in my DCP build.

Create an S3 Bucket and Upload the DCP

AWS needs your DCP file stored in S3 before it can create an AFI from it. You can create the bucket while the build is still running.

  • Open the S3 Console at https://console.aws.amazon.com/s3/.
  • Click **Create bucket**.
  • Enter a globally unique bucket name, e.g., my-fpga-dcp- followed by your AWS account ID.
  • Set the region to **US East (N. Virginia) us-east-1**.
  • Leave all other settings as defaults and click **Create bucket**.

Before you can upload from your dev instance, it needs permission to access S3. You will attach an IAM role to the instance.

  • Go to the EC2 Console and select your fpga-dev instance.
  • Click **Actions**, then **Security**, then **Modify IAM role**.
  • Attach a role with AmazonS3FullAccess and AmazonEC2FullAccess policies. If you do not have an existing role, create one in the IAM Console first.

Pro tip: minimum IAM permissions

For production use, avoid full-access policies. AWS provides a guide on the minimum required permissions at Setting Up IAM Roles for DevKit Use. For this project, full access keeps things simple.

After the DCP build completes, upload the tarball from your dev instance.

  • Run the following command in your SSH session, replacing the bucket name with yours:
aws s3 cp $CL_DIR/build/checkpoints/*.Developer_CL.tar s3://[[BUCKET="your-fpga-dcp-bucket-name"]]/dcp/

What does this command do?

The AWS CLI copies the DCP tarball from your local build output directory to the dcp/ prefix in your S3 bucket. AWS will read from this location when creating the AFI.

Submit the DCP for AFI Creation

With the DCP in S3, you can now ask AWS to create an Amazon FPGA Image (AFI). This is an asynchronous process where AWS takes your compiled design and packages it into a loadable image for the F2 FPGA hardware.

You have two options for submitting the DCP. You can use the provided Python helper script, or run the AWS CLI command directly.

AWS CLI (recommended)

  • Run the following command, replacing the bucket name and DCP filename with your values:
aws ec2 create-fpga-image \
  --name "cl-axil-reg-access" \
  --description "CL AXIL Register Access Example" \
  --input-storage-location Bucket=[[BUCKET="your-fpga-dcp-bucket-name"]],Key=dcp/[[DCPFILE="your-dcp-filename.Developer_CL.tar"]] \
  --logs-storage-location Bucket=[[BUCKET="your-fpga-dcp-bucket-name"]],Key=logs

What does this command do?

The create-fpga-image command tells AWS to read your DCP from S3, validate it, and create a loadable FPGA image. The --logs-storage-location flag specifies where AWS should write build logs, which is useful for debugging if the AFI creation fails.

Python helper script

  • Activate the HDK Python virtual environment and run the helper script:
source $AWS_FPGA_REPO_DIR/hdk/scripts/start_venv.sh
$AWS_FPGA_REPO_DIR/hdk/scripts/create_afi.py

The script prompts you for the S3 bucket and key information interactively.

Note on this script

The exact prompt flow of create_afi.py may vary by HDK version. If the prompts are unclear, use the AWS CLI method in the other tab instead.

The command returns two critical IDs. Save both of them.

  • FpgaImageId (AFI ID): looks like afi-0d123e123bfc85abc. Used for checking AFI status.
  • FpgaImageGlobalId (AGFI ID): looks like agfi-123cb27b5e84a0abc. Used for loading the AFI onto the FPGA.

Why are there two IDs?

The AFI ID is region-specific and used for management operations like checking build status or deleting the image. The AGFI ID is globally unique and is what the FPGA management tools use to load the image onto hardware. You will need the AGFI ID in the next step.

AFI creation is asynchronous. It typically takes 20-40 minutes. Check the status with:

aws ec2 describe-fpga-images --fpga-image-ids [[AFIID="your-afi-id"]]
  • Wait until the State field shows available. Re-run the command every few minutes to check.

Pro tip: save money while waiting

You can stop your c5.4xlarge development instance while the AFI is being created. The AFI creation happens on AWS infrastructure, not on your instance. Stopping it saves you ~$0.68/hour. Just remember to re-run the describe-fpga-images command from your local machine or AWS CloudShell instead.

Your custom hardware design is now packaged as an Amazon FPGA Image, ready to be loaded onto real FPGA hardware. Next up, you will launch an F2 instance and see your accelerator run on actual silicon.

Load and Test Your Accelerator on an F2 Instance

Your AFI is built, submitted, and available. Now it is time to load your custom hardware onto an actual FPGA and prove it works. In this step, you will launch an F2 instance, load your AFI onto the FPGA, and run the runtime software to perform a hardware-accelerated addition from the host CPU.

In This Step, Get Ready To:
  • Launch an f2.6xlarge instance with the FPGA Developer AMI.
  • Load your custom AFI onto the FPGA using the FPGA management tools.
  • Run the runtime test to verify host-to-FPGA register communication.
Launch an F2 Instance

The f2.6xlarge is the smallest F2 instance size, with 1 FPGA, 24 vCPUs, and 256 GiB of RAM. It costs $1.98/hour, so you want to keep it running only as long as needed for testing.

  • Go to the EC2 Console and click Launch instances.
  • Set the Name to fpga-test.
  • For the AMI, select the same FPGA Developer AMI (Ubuntu) you used for your development instance.
  • Set the Instance type to f2.6xlarge.
  • Select the same Key pair you used for your development instance.
  • Under Network settings, allow SSH from your IP.
  • Set Storage to 50 GiB gp3.
  • Click Launch instance.
  • Wait for the instance to reach the Running state, then SSH in using the username ubuntu.

Cost reminder

The f2.6xlarge costs $1.98/hour. Complete the testing in this step and then stop or terminate the instance as soon as you are finished.

Load Your AFI Onto the FPGA

Before you can interact with your accelerator, you need to set up the SDK tools on the F2 instance and load your AFI into the FPGA slot. The SDK includes the FPGA management commands that communicate with the FPGA hardware over PCIe.

  • Navigate to the aws-fpga repository and source the SDK setup script.
cd ~/aws-fpga
git checkout f2
source sdk_setup.sh

What does this script do?

The sdk_setup.sh script installs the FPGA management tools (fpga-load-local-image, fpga-clear-local-image, etc.) that let you manage the FPGA hardware from the command line. The aws-fpga repo may already be cloned on the FPGA Developer AMI. If not, clone it the same way you did in Step 2.

  • Clear any existing AFI from FPGA slot 0.
sudo fpga-clear-local-image -S 0
  • Verify the slot is cleared.
sudo fpga-describe-local-image -S 0 -H

You should see StatusName: cleared in the output. This confirms the FPGA slot is empty and ready for your AFI.

  • Load your AFI using the AGFI ID (not the AFI ID) that you saved from Step 3.
sudo fpga-load-local-image -S 0 -I [[AGFI_ID="your AGFI ID, e.g. agfi-123cb27b5e84a0abc"]]

Why the AGFI ID and not the AFI ID?

AWS provides two IDs when you create an FPGA image. The AFI ID (e.g. afi-0d123e123bfc85abc) is used for API operations like checking status. The AGFI ID (e.g. agfi-123cb27b5e84a0abc) is the global identifier used by the FPGA management tools to load the image onto hardware.

  • Verify the AFI loaded successfully.
sudo fpga-describe-local-image -S 0 -R -H

What does the -R flag do?

The -R flag performs a PCI device remove and rescan. This exposes the AFI's vendor and device IDs to the host operating system so the runtime software can communicate with the FPGA over PCIe.

You should see StatusName: loaded in the output. Your custom hardware accelerator is now live on the FPGA.

I see StatusName: loaded

Your AFI is loaded and ready for testing. Move on to the next substep.

I see an error or a different status

If you see StatusName: not-programmed or an error, try these steps:

  • Confirm your AFI status is available by running aws ec2 describe-fpga-images --fpga-image-ids afi-YOUR-AFI-ID from a machine with the AWS CLI configured.
  • Double-check that you are using the AGFI ID (starts with agfi-), not the AFI ID (starts with afi-).
  • Try clearing and reloading the image.

If you are still stuck, help me troubleshoot my AFI loading issue.

Run the Runtime Software to Test the Accelerator

The FPGA is loaded with your adder design. Now you need to run a C program on the host CPU that communicates with the FPGA over the AXI-Lite interface. This program writes two operand values to FPGA registers, triggers the addition, and reads back the result.

  • Navigate to the software runtime directory and build the test program.
cd ~/aws-fpga/hdk/cl/examples/cl_demo/cl_axil_reg_access/software/runtime
make all

What does this command do?

The make all command compiles the C runtime test program. This program uses the FPGA PCIe library functions (fpga_pci_poke and fpga_pci_peek) to write to and read from FPGA registers over PCIe.

  • Run the test with sudo (required for PCIe access).
sudo ./test_sum

You should see output confirming the test passed, with the correct sum values printed to the terminal.

What just happened?

Your host CPU wrote operand values over PCIe to registers inside the FPGA fabric via the OCL AXI-Lite interface. The FPGA performed the addition in hardware at 250MHz and returned the result. The host then read the sum and carry values back from the FPGA registers.

This is the fundamental pattern for all FPGA-accelerated applications on AWS. The host CPU offloads computation to the FPGA by writing inputs to registers, triggering an operation, and reading outputs back.

How does the register map work?

The test program interacts with five registers mapped to specific addresses on the FPGA:

  • 0x0000 - Operand_A (read/write, 32-bit unsigned).
  • 0x0004 - Operand_B (read/write, 32-bit unsigned).
  • 0x0008 - Sum (read-only, the addition result).
  • 0x000C - Carry (read-only, bit 0 is the carry output).
  • 0x0010 - Control_Status (read/write, bit 0 is start, bit 1 is ready).

The host writes operands to the first two registers, sets the start bit in Control_Status, waits for the ready bit, then reads Sum and Carry. Reading an invalid address returns 0xDEADBEEF.

I see TEST PASSED

Your FPGA accelerator is working. You have successfully completed the full FPGA-in-the-cloud development lifecycle.

I see an error

If the test fails or you see a segmentation fault, try these steps:

  • Confirm the AFI is still loaded by running sudo fpga-describe-local-image -S 0 -H.
  • Make sure you ran the test with sudo. PCIe access requires root privileges.
  • Verify you ran source sdk_setup.sh before building the runtime software.
  • Try clearing and reloading the AFI, then run the test again.

If you are still stuck, help me troubleshoot my test_sum failure.

You have completed the full FPGA development lifecycle: develop, simulate, build, create AFI, load, and test. Your custom hardware accelerator is running on a live FPGA in the cloud. Next up, check out the Secret Mission to extend your design with a subtraction operation, or head to Before You Go to clean up your resources.

Secret mission

Add a Subtraction Operation to Your FPGA Accelerator

Your FPGA adder works. But real accelerators do more than one thing. Can you modify the RTL to add a subtraction register, rebuild the design, and verify both operations end-to-end on the F2 instance?

Before you go

Clean Up Your Resources

This project uses cloud resources that cost money while running. The F2 instance alone costs $1.98/hour, and the development instance costs ~$0.68/hour. Decide whether to keep your resources running, pause them to come back later, or delete them entirely.

Cost warning

Your f2.6xlarge instance costs $1.98/hour and your c5.4xlarge instance costs ~$0.68/hour. If you leave both running overnight (8 hours), that is over $21 in charges. Stop or terminate these instances as soon as you are done testing.

Resources you used:

  • EC2 instance fpga-dev (c5.4xlarge) for development and DCP builds (~$0.68/hour).
  • EC2 instance fpga-test (f2.6xlarge) for FPGA testing ($1.98/hour).
  • S3 bucket containing your DCP tarball and AFI creation logs (minimal cost, pennies per month).
  • Amazon FPGA Image (AFI) stored in your account (no ongoing cost).
  • IAM role attached to your development instance.
  • EC2 key pair (if you created one for this project).
  • FPGA Developer AMI subscription in AWS Marketplace (free, no charges).

Keep everything running

No action needed. Choose this if you are still actively experimenting with your FPGA design or plan to continue the Secret Mission right away. Be aware that the F2 instance costs $1.98/hour, so keep an eye on your bill.

Pause - I'll come back to this later

Stop your EC2 instances to eliminate compute charges while keeping your files and configuration intact. You will still pay for EBS storage (~$0.08/GB/month), but this is a fraction of the running cost.

  • Go to the EC2 Console.
  • Select the fpga-test instance, then go to Instance state and click Stop instance.
  • Repeat for the fpga-dev instance.
  • Your S3 bucket, AFI, and IAM role can remain as they are. They incur negligible or zero cost.
  • When you are ready to resume, start the instances from the EC2 Console and SSH back in.

Delete - I don't want to use this again

Remove all project resources and start fresh. This is irreversible.

  • Go to the EC2 Console. Select the fpga-test instance, then go to Instance state and click Terminate instance.
  • Repeat for the fpga-dev instance.
  • Go to the S3 Console. Open your DCP bucket, select all objects, and click Delete. Then delete the bucket itself.
  • Delete the AFI by running the following command from any machine with the AWS CLI configured:
aws ec2 delete-fpga-image --fpga-image-id afi-YOUR-AFI-ID
  • If you created a key pair specifically for this project, go to EC2 Console, select Key Pairs in the left sidebar, and delete it.
  • If you created an IAM role specifically for this project, go to the IAM Console and delete it.
  • Your FPGA Developer AMI subscription can remain active. It is free and does not incur any charges.

Mission accomplished

That's a Wrap!

You just programmed an FPGA in the cloud! You went from a blank development instance to a live hardware accelerator running on an AWS EC2 F2 instance, performing computation on real FPGA fabric at 250MHz.

Here's what you learned:

  • Set up the full FPGA development lifecycle on AWS, from cloning the HDK and running RTL simulation to building a Design Checkpoint with Vivado and creating an Amazon FPGA Image.
  • Deployed a custom hardware accelerator to a live F2 instance and verified end-to-end host-to-FPGA register communication over the AXI-Lite (OCL) interface.
  • Used the FPGA management tools to clear, load, and verify AFIs on FPGA slots, and ran runtime software that writes operands, triggers hardware computation, and reads results back from the FPGA.
  • Modified the cl_axil_reg_access design to add a custom subtraction operation, rebuilt the DCP, and verified your own custom logic running on the FPGA.

Ready to quiz yourself?