pyfpga / symbiflow_cli

A possible replacement for openflow, which would be ideally contributed to the SymbiFlow project

SymbiFlow Command-line Interface (CLI)

A CLI utility which solves HDL-to-bitstream based on FOSS.

Disclaimer: this repository is a proposal for a SymbiFlow CLI, but is not directly related, neither endorsed, by the project.

Note: this project uses hdl/containers.

Installation

NOTE: this repo is in a very early stage.

pip3 install -e .

NOTE: instructions to test in hardware (IceStick) here.

symbiflow_cli's Issues

Data driven execution

The current approach of symbiflow_cli is to select which tools will be used in the backend based on the part name:

• if --part hx1k-tq144, nextpnr-ice40 and tools from the icestorm project are employed.
• if --part 25k-CSFBGA285, nextpnr-ecp5 and tools from the prjtrellis are employed.

In f4pga/f4pga-arch-defs#2225, another approach is suggested, based on specifying a board name and provide a JSON file whit needed options.

My thoughts:

• Specify the board name can be an option, but the decision must be made based on the FPGA part because we will support more boards with less code (or there is something related to the board per se?)
• For devices from Xilinx and VPR, probably we will need more info than for ice40 and nextpnr, but it must be internally used, not to be mandatorily provided by the user (it can be an advanced feature for developers).

Currently, for ice40 and ecp5 devices and nextpnr, which are probably easier than Xilinx devices and VPR, the "magic" is programmatically performed at https://github.com/PyFPGA/symbiflow_cli/blob/main/symbiflow/fpgadb.py I chose this approach because I consider that it provides support for more devices by default. It doesn't depend on options for a particular device, instead, it supports the whole family.

@mithro @mkurc-ant can we work together on it? Feel free to add others.

Command-line interface definition

In this issue, I will summarize the currently supported sub-commands and their arguments. @mithro @kgugala @acomodi could you provide me feedback?

• What about sub-commands and arguments names?
• Need I split commands (imp) to have a more granular control?
• Missing arguments that I haven't into account?

Please, add other users to the talk if needed, and feel free to ask any doubt.

For more details, the following is defined here.

Sub-commands

• syn: Performs synthesis
• pnr: Performs Place and Route
• bit: Performs bitstream generation
• all: Performs from synthesis to bitstream generation (runs together syn, imp and bit in one step)
• pgm: Performs programming (when available).

Command-line arguments

Shared by all the sub-commands:

• --project: basename for generated files.
• -p, --part: name of the target FPGA part (something like 'hx8k-ct256)
• -o, --outdir: location for generated files
• --oci-engine: OCI engine internally employed (docker, podman)
• --oci-volumes: volumes for the OCI engine. Can be specified multiple times.
• --oci-work: working directory for the OCI engine

For syn (and all)

• -t, --top: specify a top-level name
• --param: specify top-level Generics/Parameters (as NAME VALUE). Can be specified multiple times.
• --arch: specify a VHDL top-level Architecture
• --define: specify [System] Verilog Defines (as DEFINE VALUE). Can be specified multiple times.
• --include : specify [System] Verilog Include Paths. Can be specified multiple times.
• --scf: a Synthesis Constraint Files (not yet implemented). Can be specified multiple times.
• hdl: (positional, mandatory) a list of HDL files (which can be specified as FILE[,LIBRARY] in case of VHDL)

For imp (and all)

• --pcf: a Physical Constraint Files (IO place). Can be specified multiple times.