--db-root parameter makes it hard to use custom target

[gergoerdi]

xcfasm takes a single --db-rootparameter and seems to use it for two purposes:

• Target-specific files such as package_pins.csv
• 400-odd .json and .db files which are individual FPGA components? sub-parts?

I'd like to distribute my target-specific flies together with my project. So for example if I am targeting a Nexys A7 50T development board, then I'd include the artix7/xc7a50t and artix7/xc7a50tcsg324-1 directories, together with an appropriately filled artix7/mapping directory. However, it would make no sense to include 56M of component description files that are not specific to any single A7 model.

The --db-root flag is a problem for this setup because I can either pass in the directory in my project, where it will not find the component .db/.json files, or I can let the user use their SymbiFlow installation, in which case it will not find my target part's description files.

[gergoerdi]

Thinking about this more, I think the real problem is the fact that symbiflow-xc-fasm tries to come up with the filenames for package_pins.csv and part.json. That sounds to me like a policy decision that shouldn't be handled by the actual tool. In other words, it's not very "GCC of FPGAs" of SymbiFlow ;)

I'll prepare a PR that instead takes the filenames for the pins and the part files as command-line arguments. Then it is up to automation tools to decide the policy of where to store these files.

[mithro]

@gergoerdi - I'm a bit confused, if there is a missing part in the prjxray-db then it should be added to the prjxray-db.

The three files inside a part directory are connected and should not be separated. Users are not expected to be creating their own package_pins.csv nor should they be required too.

What you are describing would be kind of like shipping stdio.h but not malloc.h from libc inside an end-users C project.

[gergoerdi]

The point about the three files not being separable is a very good one -- so maybe we could pass the target directory instead of the target json/yaml/csv files directly, and look up all three in that?

But it sounds like my approach is fundamentally wrong, so let me explain the situation I've found myself in, and then you can tell me how it should be handled.

I checked out symbiflow-examples and wanted to try it with my Nexys A7-50T dev board. As part of the installation process, I ended up with ~20G of data files for various Xilinx 7-series models, 99% of which I will never use. However, the one model that IS on the A7-50T, namely, xc7a50tcsg324-1, isn't supported out of the box. And I thought that's fine, can't please everyone. I went hunting for the missing files, found most of them except pinmap.csv, but a super helpful user on the SymbifFow Slack helped me out and recommended just using the existing pinmap.csv for xc7a35tcsg324-1. And now I'm all set.

So at the end, I had all these custom CSV and JSON and YAML files that I copied from various sources, and I wanted to put them somewhere that is not polluting the main SymbiFlow directories, because then I won't know what files I need to include with my project so that users who start with a stock SymbiFlow installation won't have to do the same hunting.

Let me know how this situation should be handled.

[mithro]

The only real reason that the part on the Nexys A7-50T isn't currently supported is nobody had a board with it to test things actually worked. Can you log a bug about the part being missing and what you have confirmed as working or not?

[gergoerdi]

Sure! Which repo should I file that bug for? Also, how extensive testing do you require?

[gergoerdi]

I've got Pong from https://github.com/SymbiFlow/vtr-verilog-to-routing/issues/570 working so that includes a simple but non-trivial circuit and an MMCM, driving a VGA output. Does that suffice for enough testing to add the part as working?

[unbtorsten]

This issue looks superseded and can likely be closed. The missing part has been added to prjxray-db meanwhile.