Project F welcomes contributions from beginners and experts alike. We have a few simple policies to ensure new designs are compatible with the project goals. This document is a draft; we will expand it as needed.
Our designs are self-contained and simple to understand. Complex or overly clever designs are unlikely to be accepted.
Avoid vendor-specific IP. We want our designs to work on as many FPGAs as possible. See FPGA Architecture for examples of acceptable vendor-specific functionality.
Write your designs in SystemVerilog and follow the style of existing modules. Familiarise yourself with a few modules from the library before submitting a PR.
SystemVerilog has many valuable additions over older Verilog standards, but we restrict ourselves to simple, widely-supported SV features. See SystemVerilog Features for what's currently allowed.
While we love to see Project F designs ported to new dev boards, we only accept new ports into the repo if we can test them. Otherwise, we won't be able to maintain your code after it's merged. If you want us to mention a fork, talk to us on the Project F discussion forum, and we'll consider linking to it from the Project F blog and docs.
Designs must pass a Verilator lint with: verilator --lint-only -Wall
Use the Project F discussion forum to discuss significant changes before submitting a PR.
Please keep your PRs small. Submitting tens of new files or changes together makes testing and merging almost impossible.