Program FPGA recommended flow

[towoe]

In lowRISC/opentitan#1006 @olofk changed pgm to run --run to start the program of the FPGA board.

For the OpenTitan project the following worked for me:

fusesoc --cores-root . run --target=synth --run lowrisc:systems:top_earlgrey_nexysvideo

(I guess the target was necessary as there is no default specified.)

Is this the preferred way to start the programming instead of?

fusesoc --cores-root . pgm lowrisc:systems:top_earlgrey_nexysvideo

[olofk]

Short answer : Yes, even though it's a bit less convenient for users

Longer answer: I realized some time after creating FuseSoC that there isn't a 1 to 1 mapping between backends and programming tools. Personally I have moved to using openocd for programming Xilinx devices as it is a bit more convenient when you also to debugging with OpenOCD (an example here )

At some point I also thought it would be a good idea to define programming as the run phase in Edalize (similarly to how the run phase runs a simulation in the simulator flows). In hindsight I'm not sure it was the best idea. With that move, I pretty much deprecated the build, sim and pgm commands, although they are still available but not really maintained.

Ideally I would like to break out all the programming stuff to a separate library that can be shared among e.g. apio, migen, litex, edalize and other tools as all of them already implement different subsets of FPGA programming options.

I also just had a PR for Edalize that makes it possible to define what you want to build in the build phase. Maybe it would be best to use that to optionally program the device during the build phase by defining a new makefile target. Alternatively, we could define new backend options (e.g. a --pgm option) that tells the run phase to program the device and how (e.g. --pgm=vivado or --pgm=openocd).

[towoe]

Thanks Olof for the short and long answer!

Short answer : Yes, even though it's a bit less convenient for users

Longer answer: I realized some time after creating FuseSoC that there isn't a 1 to 1 mapping between backends and programming tools. Personally I have moved to using openocd for programming Xilinx devices as it is a bit more convenient when you also to debugging with OpenOCD (an example here )

Certainly a good idea. But I also like the convenience of using FuseSoC for building and programming, especially for instructions for inexperienced users.

At some point I also thought it would be a good idea to define programming as the run phase in Edalize (similarly to how the run phase runs a simulation in the simulator flows). In hindsight I'm not sure it was the best idea. With that move, I pretty much deprecated the build, sim and pgm commands, although they are still available but not really maintained.

I saw the warning for build and sim in b838e89, but there is no warning for pgm. Should this be added?

Ideally I would like to break out all the programming stuff to a separate library that can be shared among e.g. apio, migen, litex, edalize and other tools as all of them already implement different subsets of FPGA programming options.

I also just had a PR for Edalize that makes it possible to define what you want to build in the build phase. Maybe it would be best to use that to optionally program the device during the build phase by defining a new makefile target. Alternatively, we could define new backend options (e.g. a --pgm option) that tells the run phase to program the device and how (e.g. --pgm=vivado or --pgm=openocd).

If using run I like the idea of using --pgm. Adding --run seems a little strange. For a simulation this makes more sense, though.
Using only run, will this make it easier to track dependencies between different stages, like --setup, --build, --pgm?

[olofk]

Thanks Olof for the short and long answer!

Short answer : Yes, even though it's a bit less convenient for users
Longer answer: I realized some time after creating FuseSoC that there isn't a 1 to 1 mapping between backends and programming tools. Personally I have moved to using openocd for programming Xilinx devices as it is a bit more convenient when you also to debugging with OpenOCD (an example here )

Certainly a good idea. But I also like the convenience of using FuseSoC for building and programming, especially for instructions for inexperienced users.

I agree. It's quite convenient. But it needs to be expanded a bit since it currently only works with the quartus, ise and vivado backends using the vendor-supplied programmer. There are plenty of cases where this isn't enough to program the boards. Could still have the current programming method as default.

At some point I also thought it would be a good idea to define programming as the run phase in Edalize (similarly to how the run phase runs a simulation in the simulator flows). In hindsight I'm not sure it was the best idea. With that move, I pretty much deprecated the build, sim and pgm commands, although they are still available but not really maintained.

I saw the warning for build and sim in b838e89, but there is no warning for pgm. Should this be added?

Yes, you're right. I probably just forgot, or potentially had some idea here that I have forgotten about since then :)

Ideally I would like to break out all the programming stuff to a separate library that can be shared among e.g. apio, migen, litex, edalize and other tools as all of them already implement different subsets of FPGA programming options.
I also just had a PR for Edalize that makes it possible to define what you want to build in the build phase. Maybe it would be best to use that to optionally program the device during the build phase by defining a new makefile target. Alternatively, we could define new backend options (e.g. a --pgm option) that tells the run phase to program the device and how (e.g. --pgm=vivado or --pgm=openocd).

If using run I like the idea of using --pgm. Adding --run seems a little strange. For a simulation this makes more sense, though.
Using only run, will this make it easier to track dependencies between different stages, like --setup, --build, --pgm?

I haven't thought this through to be honest. There needs to be improvements regarding dependencies between stages in any case. Realized as I write this that doing programming during the run phase and just adding a --pgm backend option won't improve things with the current code, as it would require fusesoc run --run $core --pgm to program without rebuilding which just makes it even less convenient. Oh...unless of course the backend itself skips the setup and build phases when --pgm is applied. Might be overthinking the whole thing :)

Edit: No, that won't work since the work root is cleaned out by FuseSoC unless the --run flag is passed to the run command. Better depedency checking between the stages is probably the first thing that needs to get worked out

[imphil]

"fusesoc pgm" is now deprecated (#431), running a stage on its own without the previous stage (e.g. only "--run" without "--build") isn't supported and will need major improvements to dependency tracking (i.e. rebuild only on demand). I think all questions in this issue have been addressed, please re-open if I got it wrong.