aws-fpga: the accelerator build kit tied to EC2 F2 and one Vivado version list

A kit scoped to one instance family, not to FPGAs in general

The scope is stated in the first line of the repository description: this is the official repository of the AWS EC2 FPGA Hardware and Software Development Kit. The unit of work is an accelerator for the high-performance accelerator cards that appear on EC2 F2 instances. That is a narrower target than the name suggests. A design written here is built around a specific card, a specific host instance family and the software that AWS expects to find alongside it, and none of that transfers to a board you buy yourself or to another cloud's FPGA offering.

Within that scope the stated workflow is the ordinary FPGA loop: architect, simulate, optimize and test. Nothing in the documentation claims to shorten that loop. The value being offered is the card-level plumbing, not a new methodology.

The primary language GitHub reports is SystemVerilog, which is what tells you the HDL side is the substance here and that the repository is not a wrapper around someone else's design. The default branch is `f2`, which is also a useful signal: the repository has carried branch-per-hardware-generation naming, so older generations of this kit are not necessarily in the branch you are about to clone.

The README notes that FPGA and cloud development demands distinct domain knowledge.

Three setup scripts, three distinct halves of the stack

The repository layout is the clearest statement of what the kit actually contains. The top level holds an `hdk/` directory, an `sdk/` directory, a `vitis/` directory and a `shared/` directory, alongside an ERRATA.md, a RELEASE_NOTES.md, a `release_version.txt`, a `supported_vivado_versions.txt`, a `.gitmodules` file and the main `User_Guide_AWS_EC2_FPGA_Development_Kit.md`.

Each of the three halves has its own setup script: `hdk_setup.sh`, `sdk_setup.sh` and `vitis_setup.sh`. That split is the mechanism to understand. The hardware development kit side is what turns your RTL into something the F2 card can load. The SDK side is the host-side software that talks to it. The repository provides a separate `vitis/` directory and setup script. The source does not explain how these components are consumed.

A `.gitmodules` file is present at the root, but its contents are not shown here. The README gives no shell commands for any of the setup scripts, so how they are invoked and what they require is documented elsewhere rather than in the repository front page. Expect to follow the ReadTheDocs user guide rather than guessing at arguments.

The `developer_resources/` and `docs-rtd/` directories, together with the `.readthedocs.yaml` at the root, show that the documentation is a first-class build output checked into the same tree as the code, not a set of loose markdown files.

supported_vivado_versions.txt and ERRATA.md are the two files to open first

Two filenames in the root carry more adoption information than any amount of description. `supported_vivado_versions.txt` is the set of tool versions the kit is known to work with, which means the toolchain is pinned and your local Vivado version is a hard constraint rather than a preference. If the version you have is not in that list, nothing else in the kit will help you, and finding that out after a multi-hour build is expensive. Check it first.

ERRATA.md is the other one. A project that keeps an errata at the repository root is telling you that known defects are published there, ahead of the documentation rather than behind it. For an FPGA flow, errata tend to be the kind of thing that produces a confusing bitstream or a driver that returns nonsense at full speed, so this file is worth reading end to end before you trust a result.

`release_version.txt` and `RELEASE_NOTES.md` complete the versioning picture. Recent tags are v2.3.2 on 2026-04-15, v2.3.3 on 2026-06-22 and v2.3.4 on 2026-08-06, so the line moves in roughly two month increments. The repository is not archived and the last push was on 2026-10-07, which is a healthier cadence than a hardware kit from a vendor would normally have.

The practical consequence is that you should pin a release tag rather than tracking the branch if you need reproducibility, and read the release notes for the tag you pin.

The tutorial path runs through AWS, not through the repository

The README contains no install commands and no getting-started code, and it says so by pointing elsewhere. The User Guide, tutorials and code snippets live on a ReadTheDocs site hosted at readthedocs-hosted.com, and the interactive path is the AWS F2 FPGA Workshop in the AWS workshop catalog, which the README describes as an interactive quick-start for engineers of all backgrounds that covers F2's architecture and walks a participant through loading a design and using it.

That split has a consequence. The README provides no install commands or getting-started code and points users to the ReadTheDocs documentation and AWS F2 FPGA Workshop.

Support follows the same split. Code and documentation problems go to GitHub issues with reproduction steps. Questions that are not defects go to re:Post under the 'FPGA Development' tag. There is no community forum or mailing list mentioned, so support is asynchronous and vendor-routed, which is worth knowing before you commit a deadline to it.

The licensing answer is equally routed. GitHub cannot classify the licence and reports it as a custom one; the actual terms live in `LICENSE.txt`. So this is not an MIT or Apache-2.0 dependency you can drop into a product stack on the usual assumptions. Reading `LICENSE.txt` before you build on it is not optional for a commercial team, and the repository gives you no summary of what the custom terms permit.

What to compare it against before you commit

There are two reasonable alternatives, and they fail in opposite directions.

The first is a generic open FPGA tool flow, where you install your own vendor toolchain, target a board definition you maintain, and write the host interface yourself. The difference is ownership: with aws-fpga, the card support, the host interface and the expected software layout come from AWS and are consistent with what an F2 instance boots; with a generic flow, every one of those is a file you own and must keep in step with your instance image. Choose the generic route if your accelerator will eventually run somewhere other than F2, or if the custom licence is a problem for your distribution.

The second alternative is not technical at all: the AWS F2 FPGA Workshop on its own. The README says it provides an architecture overview and guides participants through loading and using a design. It may offer a shorter introductory path than building a full accelerator.

The honest summary is that aws-fpga is a vendor-supplied hardware enablement package for one cloud instance family. Inside that boundary it saves real work. Outside it, the pinning to F2, the pinned Vivado versions and the unclassified licence are all reasons to look elsewhere.

Editorial conclusion

Adopt this kit if your work is an accelerator targeting EC2 F2 and you want AWS's own card support rather than a generic FPGA flow, and read ERRATA.md and supported_vivado_versions.txt before your first build. Do not adopt it as a general purpose FPGA toolchain, as a learning platform for FPGAs in general, or as a permissive open source dependency, because the repository is pinned to one instance family, ships a custom licence rather than a standard identifier, and documents its setup steps on ReadTheDocs rather than in the README. Verify first that your account can attach an F2 instance at all, that the Vivado version named in supported_vivado_versions.txt matches the tool you have, and that the release you clone matches the instance image you intend to run on.

Frequently asked questions

Official sources

1. aws/aws-fpga on GitHub
2. Issues
3. README
4. Releases