f4pga: no script to rerun the build

[tcal-x]

It is convenient to rerun the bitstream build flow (or just parts of it) using the build_<platform>.sh script that is usually left in the <build>/gateware/ directory.

I think it is not written when using F4PGA since it is not actually needed for the build (see here).

Could we still write out a (one-line?) shell script as a convenience for users who want to rerun the flow? Or can we record the top-level STDOUT to something like flow.log so that I can rerun specific commands?

@koluckirafal @robertszczepanski @umarcor

P.S. the updates to the flow (showing detailed progression & keeping the log files) are a huge improvement, thanks!

[umarcor]

@tcal-x, I think that the build_script function refers to the TCL scripts passed to Yosys. Those were included in arch-defs packages and are now included in f4pga (see https://github.com/chipsalliance/f4pga/tree/main/f4pga/wrappers/tcl). I guess that's different from the functionality requested in this issue.

[tcal-x]

@umarcor, thanks for following up. I had been thinking of the Vivado flow, which builds both a TCL script for Vivado (build_project()) and a top-level bash script (build_script()).

But formerly, the SymbiFlow flow also made it possible to rerun the implementation commands. It would generate a Makefile in the <build>/gateware/ directory. Now, I'm still stumped how to rerun some or all of the synth/pack/PnR/fasm flow.

[umarcor]

@tcal-x did that Makefile look similar to https://github.com/SymbiFlow/f4pga-arch-defs/blob/main/xilinx/xc7/tests/install_test/Makefile or https://github.com/chipsalliance/f4pga-examples/blob/main/common/common.mk? That corresponds to the deprecated SymbiFlow, which allowed and required to execute up to six steps. Now, all of them are included in f4pga build and it does have an internal cache to decide when to rerun/update the intermediate/final results (see https://f4pga.readthedocs.io/en/latest/f4pga/Usage.html#f4cache and https://f4pga.readthedocs.io/en/latest/f4pga/Usage.html#dependency-resolution-display). Hence, my guess is that it is expected to run f4pga build (in this case run Litex) again in order to rerun whichever stages need to be executed again (due to source changes). In order to execute some stages, but not all of them, requesting one intermediate result should suffice. In other words, f4pga build is expected to work as a call to make. Litex just needs to generate HDL sources, constraints, etc. and provide a JSON file declaring them, so that users can call f4pga build afterwards.

There is a functionality which is not supported by make and neither by f4pga build: to execute some intermediate stages only, despite previous ones being out of date. E.g., in a flow composed of A -> B -> C -> D. It's possible to execute the following:

• A
• A -> B
• A -> B -> C
• A -> B -> C -> D

But it is not possible to do:

• B
• B -> C
• B -> C -> D
• C -> D
• D

However, since flows are DAGs, and because the currently supported f4pga build flow is a linear sequence (without branches), induction/reduction operations allow to extract those intermediate chains. Should such functionality be useful, we might want to implement a task filtering syntax such as https://github.com/dbhi/run#list.

/cc @tmichalak @kboronski-ant