Packaging options for RapidWright

[litghost]

As part of the FPGA interchange work, RapidWright needs to be packaged for use. RapidWright has two parts, a closed portion and an open portion. The closed portion is not a permissible library, and cannot be repackaged for distribution. The open portion is permissibly licensed (Apache 2.0) and can be packaged for distribution.

This issue is for tracking creating a conda package that packages the open portion of RapidWright for distribution, and provides a way to invoke entry points from the open portion. The closed portion of RapidWright needs to be installed by the end user somehow. It is unclear best to provide an "installable" conda package for the closed portion of RapidWright.

Ideas:

• Create a script that the user must invoke to accept the closed RapidWright license etc. Effectively invokes http://www.rapidwright.io/docs/_downloads/rapidwright-installer.jar , which downloads the closed portion to a known location. Wrapper scripts could be created to add both the repackaged open portions and user installed closed portions.

Manually installing RapidWright today:

1. git clone https://github.com/Xilinx/RapidWright.git
2. cd RapidWright
3. git checkout interchange
4. make update_jars

Entry points to support:

• bash -c "source bin/rapidwright_classpath.sh && java com.xilinx.rapidwright.interchange.PhysicalNetlistToDcp $1 $2 $3 $4"
• bash -c "source bin/rapidwright_classpath.sh && java com.xilinx.rapidwright.interchange.PhysicalNetlistExample $1 $2"

Additional notes:

• The open portion of RapidWright needs the closed portion of RapidWright added to the java class path. rapidwright_classpath.sh is currently created by the RapidWright Makefile to do this, by setting the CLASSPATH environment variable.
• RapidWright needs to know where the closed RapidWright data files are located. This is done via the environment variable RAPIDWRIGHT_PATH.

[mithro]

@PiotrZierhoffer -- What is your opinion here?

[PiotrZierhoffer]

I believe the first approach should require the user to provide the closed part. The way we approach it with Vivado is via a pre-link.sh script: https://github.com/litex-hub/litex-conda-eda/blob/master/xilinx/vivado/pre-link.sh

This allows us to verify if Vivado is there and in a correct version. If RapidWritght requires setting the RAPIDWRIGHT_DIR anyway, this could be a requirement for the pre-link script as well.

Entrypoints could be added simply as separate scripts. Is this an option, or do we need to be able to run these exact commands in the conda env (e.g. because some software runs it and cannot be adjusted easily)?

One question is "which java to use". I am not sure if it would be easy to force the closed part to use the one from conda. But we could start with using the system one, not adding java to conda package deps.

GitHub

litex-hub/litex-conda-eda

Conda recipes for FPGA EDA tools for simulation, synthesis, place and route and bitstream generation. - litex-hub/litex-conda-eda

[litghost]

That all sounds reasonable. I did make a typo in my first message. The environment variable needed is RAPIDWRIGHT_PATH, not RAPIDWRIGHT_DIR. I've updated my comment.

Yesterday I added https://github.com/Xilinx/RapidWright/blob/interchange/scripts/invoke_rapidwright.sh to make it easier to invoke RapidWright entry points.

With the new script the examples from above become:

RAPIDWRIGHT_PATH=<...> JAVA=<...> ${RAPIDWRIGHT_PATH}/scripts/invoke_rapidwright.sh com.xilinx.rapidwright.interchange.PhysicalNetlistToDcp $1 $2 $3 $4
RAPIDWRIGHT_PATH=<...> JAVA=<...> ${RAPIDWRIGHT_PATH}/scripts/invoke_rapidwright.sh com.xilinx.rapidwright.interchange.PhysicalNetlistExample $1 $2

If the current answer is going to be "the user has to supply a copy of RapidWright", then we could also just say that the user has to provide a Java runtime too. Not a great story for a packaging perspective, but consistent with the Vivado story.

GitHub

Xilinx/RapidWright

Build Customized FPGA Implementations for Vivado. Contribute to Xilinx/RapidWright development by creating an account on GitHub.