This is a general collection of FPGA IP modules to make starting new designs easier. All modules come with formal specification and/or behavioural validation testbenches to ensure correct functionality. Designs are generally optimized for the hardware primitives found on modern Xilinx FPGAs (7 series and up), and use synthesis constructs that function well for the Vivado synthesizer.
Here is a summary of the default interfaces that are used in the IP modules. Consult individual IP documentation sheets for any deviations from these standards.
| Application | Interface | Notes |
|---|---|---|
Streamed data |
AXI-S |
AXI-Stream, or extended AXI-Stream with backpressure feedback is acceptable. |
Internal low-speed bus |
AXI-Lite |
Wishbone may also be used. |
Internal high-speed bus |
TBD |
No IPs require a HS bus yet. |
Audio |
I2S |
-
Synthesis suite for hardware implementations (e.g. Xilinx VDS).
-
Verilator for simulation testbenches and linting.
-
Timing testbenches have been tested in Vivado xsim.
-
Icarus should also work in theory.
-
-
SymbiYosys (SBY) and baseline Yosys install for formal property verification and model check.
-
CPP 20 compiler and CMake >= 2.20 for the ipcore generators.
Drop the entire hdl/ folder into the design project and add all files to the design. A
dependency resolution system and selective distribution builder will be created in the
future to allow usage with hardware toolchains that require manual elaboration order
specification.
Formal verification can be run by entering the tb/formal directory and "making" the
project using GNU make. It is heavily recommended to set the make -j jobs setting to the
number of CPU cores to allow different IP modules to be verified in parallel.
-
doc: Long-form test documentation. -
gen: IP module configurators and generators if needed by given module. -
rtl: Synthesizable RTL source files. -
tb: Testbench and validation files. -
tools: maintenance and utility tools for the repository.
Q: NAIL?
A: "commoN fpgA Ip Library" (yes, this is a gratuitously constructed acronym)
Q: So why does this exist? Don’t most vendor toolchains come with large amounts of included IP.
A: Good question! Firstly, writing blocks of reusable IP is quite educational. Secondly, vendor IP often is license encumbered, and somewhat difficult to integrate. Vendor IP also is usually encrypted, which makes debugging design issues very difficult, and greatly reduces the compatibility. Finally it is quite convenient to have a suite of IP with copyright fully owned by a single entity for commercial purposes.
|
Important
|
Synthesizable IP and testbench code in this repository is licensed under the CERN-OHL-S v2. This is the hardware equivalent to the GNU GPL license, with corresponding strongly reciprocal terms that bind derived and incorporating works under the same license. If these license terms are unacceptable for any reason, a commercial-use, non-reciprocal license may be negotiated for each closed-source derivative project by contracting 0-PID Technologies. |
We consider licensing to be an important part of establishing our rights to designs and documentation. To foster the open-hardware community while protecting our commercial interests, we have elected to make IP available under the strongly reciprocal CERN OHL-S V2 license by default. This should be sufficient to enable other open hardware and educational projects to incorporate these IPs.
Note that closed-source 3rd-party proprietary components, such as vendor provided encrypted IP, need only be made available in the format that is configurable and usable by the synthesis tools per section 1.8 of CERN-OHL-S. (e.g. if you wish to incorporate Xilinx IP in any derived works, you must distribute the xci, coe, and bd files needed to configure and synthesize said IP). However unencrypted and first/second party IP used in derived works must be delivered in RTL form.
Please note that Verilator generated C++ sources produced from IP in this repository are still bound by the original OHL-S-V2 license under the derived works clause.