Using fusesoc for dependency management only

[benreynwar]

I'm looking into using fusesoc for dependency management without taking advantage of the simulation or image generation features yet.

I didn't see an easy to way to get fusesoc just to spit out a summary of all the files that a given core depended on, that I could then use with different tools outside of fusesoc.

I had a quick crack at implementing this myself, adding an 'elab' command which just spits out a new core file with no dependencies and with all the required files explicitly listed. I can then parse this with other tools. https://github.com/benreynwar/fusesoc/commit/6b5594ee0f97a4b800224edddbf1acca69575827 Is this a sensible way to go about things, or did I miss a more straightforward way of doing this?

[olofk]

Cool. My intention is to make it modular enough for it be useful only as a dependency manager for those who wish, so I'm happy to help out. I actually wrote a blog post about that a while ago. Not sure if the code need some updates though, as it relies on internal API that has moved around a bit, but you can probably get the idea at least There's also a related article about how to combine FuseSoC and VUnit

[benreynwar]

Thanks, I'll check that blog post out. I was mostly just checking you weren't in principle opposed to this before I put too much time into it :).

[evancox10]

+1 I'm interested in this usage too.

[olofk]

Well then, let's make this happen :)

I think there are several ways to do this. First of all, FuseSoC was always meant to be usable as a library in other applications in addition to being a command-line tool. Both the blog posts mentioned above makes use of this. The unit tests can also be useful as examples on how to do this

For non-python users, I think it would be best to either implenent a dummy backend that dumps all the data that would normally be exposed to the simulator/synthesis backends. Probably in a json/yaml format.

Both methods require that the internal APIs are made stable and cleaned up a bit. It's an area where I'm currently working quite a lot, especially in preparation for CAPI2, which is supposed to replace the existing .core files in time. This unfortunately means that there are some non-compatible changes lined up right now to better separate the tools from the core descriptions, but I hope the end result will be better.

[benreynwar]

Is there a public branch where you're working on the internal API changes?

I think separating the tools from each other, from the core descriptions, and from the main command line utility will make things much nicer for people using fusesoc as a python module, rather than as a command line utility.

For example, I was having a crack at using the ghdl wrapper that came with fusesoc. But I was constrained by the fact that I had to use the global config object, and I had to use the command line utility logging functions.

I'm still pottering away experimenting with fusesoc as time and enthusiasm allow, and if you do have a refactoring branch, I'm happy to jump in and try to help.

[olofk]

No public branch yet. I've been spending time on preliminary code cleanup to make the transition easier. I'll push when I got something.

And please report or fix any such problems (as the global config object) that you find. I'm happy to fix such things

[olofk]

I'm making some progress on this now. There's a branch called eda_api where I work on an API between the frontend and backend. Please be aware that this branch will be subject to force pushes and rebasing, but you can at least get an idea of what will come.

Slightly related to this is the work on CAPI2 that is now based on the eda_api branch

[olofk]

This is mostly done now. The core manager and tool backends only communicate through the EDA API structure. The only common part is that the tool backends and core manager share utils.py for logging and launching processes

[benreynwar]

I think you can pretty safely close this issue now. I'm happily using fusesoc for dependency management only! The new 'get_files' method on the core object that you created has helped with this.