F4PGA Flow: Use openFPGALoader instead of openOCD

[Pocketkid2]

This PR includes and thus requires #322, #325, and #326. It simply replaces the openOCD code with openFPGALoader code, which is simpler but does require an extra board specifier

[mithro]

I would like us to support both OpenOCD and OpenFPGALoader.

[mithro]

(I think OpenFPGALoader is probably a better default option however.)

[Pocketkid2]

I would like us to support both OpenOCD and OpenFPGALoader.

I'll add it to the list

[trabucayre]

It's maybe too late to add a comment here. I assume board property was mainly introduce to provides informations for openFPGALoader but I have small remarks.

This property is not limited to programming step: it's a mandatory information used to extract FPGA's parameters from a json according to the board name. This means:

• all compatibles boards must have an entry into this file. Without that edalize will fails
• flow_options properties provided by users become useless: it's conflictual with tools using edalize (fusesoc for instance)

Another issue with board, for openFPGALoader point of view: this information may, or not, be enough. For targets with onboard JTAG interface it's okay, but in other case cable must be provided too.

[Pocketkid2]

@trabucayre The goal is actually to have the entire flow configure based on a single option (board) and then all the other values (including the openFPGAloader 'board' specifier) load from an internal database. You can see an example here of how it would map a single identifier into the various configuration values needed by the f4pga toolchain.

Using an internal database like this has other advantages, such as being able to possibly ship or retrieve default NextPNR chipDB files or xilinx design constraints (.xdc files)

[trabucayre]

Ok. I have to read more carefully all f4pga related PR. Reducing properties set looks good but this mean user has to PR all board not already listed instead of just providing part and device_type. I have tested edalize's f4pga backend as build backend for @enjoy-digital LiteX successfully but I have commented everything about board to have just to provides properties set.

[trabucayre]

Avoiding to the user the needs to provides too many informations is a great idea: chipdb extraction for example is a task, currently must be done for all tools using f4pga (I have done that for my PoC) so it make sense to refactorize that. But one thing is not really clear to me: why a db by board instead of by devices (with vendor, chipdb, ..)? If you have more than one board with a xc7a35ticsg324-1L you only needs one db's entry instead more than one. With a devices db users with projects using edalize and vivado have only to replace vivado by f4pga to switch between backend instead of adding a new edam. But maybe I've lost something.

[olofk]

I'm also sceptical towards using board here. It's helpful with the most popular boards but in reality only a small subset of users use these boards. And many times I want to do test synthesis for certain devices without knowing what board it lives on. I would say the best solution would be if you could optionally supply a board which contains some info like device, perhaps how to program it and some other things.

Also, I totally missed the OpenOCD/OpenFPGALoader discussion. I think the big problem is that I assumed there would be a single progrmamign tool per backend when I started on this ten years ago. That was very wrong. Ideally I would like to see a separate library abstracting programmers (e.g. quartus_pgm, vivado, openocd, openfpgaloader, urjtag, iceprog...etc) which can be used by Litex, Edalize and all other frameworks (I have written about that e.g. here https://github.com/olofk/fusesoc/issues/319). For that reason I'm always a bit sceptical towards adding support for more programming tools within Edalize because I'm worried it will end up a maintenance nightmare.

So if anyone knows someone who would be interested in creating such a library, please let me know :)

[Pocketkid2]

By the time we are ready to take another look at the f4pga run stage (after the main flow is working and merged in) we may have to redo this PR, but it looks like there's some great discussion here. I think if the user triggers the run stage then we probably have to assume they want to download to a board, and thus they would have to supply some kind of board identifier. If the user just wants to compile then all they would trigger is the configure and build stage.

[trabucayre]

I'm agree with @olofk : board is a good idea for user having one of listed boards may don't want to worry about exact device code, but for most people device code is be more useful (even more if the board is not listed). And again with LiteX (and amaranth) at toolchain level notion of board is lost: the only information available is the model of the targeted FPGA. If board is required big modifications will be required to propagate board name with a cross dependency between platform and toolchain with, as result, the risk to limits edalize adoption as build backend.

Maybe something like:

if "board" in flow_options:
    [retrieve part from json]
elif "part" in flow_options:
    [do something]
else:
   raise RuntimeError("xxx")

For programmer tools: it's true too. An independent class/tool may be required to focus on this aspect: openFPGALoader has different requirements than openocd, which has different requirements as xc3sprog... And since some of these tools are not limited to one backend/device model/vendor it make more sense to have something backend independent.

[Pocketkid2]

Closing this PR as its parent PRs have been superseded