CAPI2-BSP (CAPI version 2.0 board support)
What is CAPI 2.0?
The majority of computational accelerator systems use PCI Express (PCIe) to connect to the main processor units via the I/O subsystem. The IBM Coherent Accelerator Processor Interface (CAPI) provides an alternative that removes the complexity and overhead of the I/O subsystem to enable higher system performance.
While the first version of CAPI was designed for acceleration in a POWER8 system, its successor CAPI 2.0 is the CAPI version for acceleration through the PCIe link on POWER9 systems.
For more information about CAPI, see https://developer.ibm.com/linuxonpower/capi
Board support and PSL
The Power Service Layer (PSL) is the component for FPGAs that provides access to CAPI.
This repository contains the necessary resources for creating a Xilinx Vivado IP container that integrates the PSL component into an FPGA card specific infrastructure for CAPI 2.0.
Currently, support for the following cards is implemented:
- AD9V3 (AlphaData 9V3)
- N250SP (Nallatech 250S+)
- RCXVUP (ReflexCES XpressVUP-LP9PT)
- FX609 (Flyslice FX609QL)
- S241 (Semptian NSA241)
The build process for the CAPI 2.0 board support depends on POWER9 PSL (PSL9) sources that can be obtained as zip archive from the IBM Portal for OpenPOWER
From the menu, select "CAPI"->"Coherent Accelerator Processor Interface (CAPI)" or directly click the "CAPI" icon to go to the CAPI section
and download the required zip archive contained in "PSL IP Source Files for POWER9 CAPI".
Alternatively, the following link will provide direct access:
Please copy the downloaded zip file to the subdirectory psl.
Creating container via make process
With the archived PSL9 IP core available in the subdirectory psl the CAPI board support IP container for a supported card with name
<CARD NAME> can simply be generated by calling
make <CARD NAME>
This will automatically create the required PSL9 IP for the card's FPGA chip which will be included in the resulting CAPI board support IP container
Adding new cards
In order to add a new card
<NEW CARD> a new subdirectory has to be created that contains
Makefilefor setting up the card specific environment variables (see AD9V3/Makefile for an example)
- a subdirectory
srckeeping the capi board support sources
- a subdirectory
tclcontaining at least the following files
add_ip.tclto add card specific IP to the
add_src.tclto add card specific files not contained in
create_ip.tclto create the required card specific IP
- optionally a script
patch_ip.tclto apply additional patches
- a subdirectory
xdccontaining card specific constraint files
After creation of the directories and files as described above,
the new card can be enabled by just adding the card to the variable
in the top level Makefile.
When creating a CAPI 2.0 board support IP container, the required PSL9 IP will be generated
automatically from the archived PSL9 IP core (see Board support and PSL
for information on how to obtain that archived IP core).
It is not even necessary to take care of that in the card specific
The build scripts for PSL9 IP generation are contained in the subdirectory psl. In that directory the build process also expects to find the archived PSL9 IP core
PSL_VERSION is an environment variable used by the build process to identify the PSL version.
If that variable is not defined, the default value
2.00 will be assumed, currently.
While it is not necessary to explicitly build the PSL9 IP for a card, calling
make -C <CARD_NAME> psl
will build the PSL9 IP for the FPGA part that belongs to the card with name
This is an open-source project. We greatly appreciate your contributions and collaboration. Before contributing to this project, please read and agree to the rules in
To simplify the sign-off, you may want to create a ".gitconfig" file in you home by executing:
$ git config --global user.name "John Doe" $ git config --global user.email firstname.lastname@example.org
Then, for every commit, use
git commit -s to add the "Signed-off by ..." message.
By default the git repository is read-only. Users can fork the snap repository, make the changes there and issue a pull request. Even members with write access to this repository can't commit directly into the protected master branch. To contribute changes, please create a branch, make the changes there and issue a pull request.
Pull requests to merge into the master branch must be reviewed before they will be merged.