Should core-v-verif integrate Bender for filelist generation dependency tracing?

[MikeOpenHWGroup]

A recent pull-request (#2643) suggested integrating Bender, a "dependency management tool for hardware design projects" for the cv_dv_utils. This could be a good idea. FWIW, here are my thoughts:

PROs:

• Bender is an active project hosted by PULP-Platform. This gives me confidence that the tool is well supported.
• OpenHW currently has no standardized methodology for managing dependencies.

CONs:

• Bender is not currently used by any other OpenHW repositories or their associated scriptware.
• It is not clear that we need Bender as most of our projects have deliberately avoided having multiple dependencies on other repositories.

[khandelwaltanuj]

Hi @MikeOpenHWGroup

I think to me it would be great to try. It seems to work pretty well and it can be a great update to the scripts.

Regards
Tanuj

[micprog]

I believe some other projects support Bender in part (e.g., CVA6). Bender is well-suited to allow projects to re-use dependencies (such as common cells), helping to resolve conflicts when requesting the same dependency. From what I understand, these dependencies are currently vendored into the project (e.g., CVA6 and CV32E40P, both requiring cvfpu, common_cells), which can result in duplicate code when including two separate cores in a single project, where the dependency vendored in might slightly differ.

I think Bender can be used here as an additional feature, supporting the existing frameworks by generating file lists, assisting with vendoring if needed, and allowing for more flexible use of the IPs in other projects. Versioning IPs according to Semantic Versioning helps a lot here.

Of course, as the maintainer of Bender, my opinion here might be biased.

[fischeti]

I can maybe comment more from a user perspective, since I am not an active developer of bender (yet). For us in the PULP platform, Bender has become an indispensable tool, especially for larger projects or systems where the number of dependency can reach 50 by now. This is where Bender helps a lot since it can automatically resolve dependencies, but still gives the user the last word for dependencies where it cannot find a solution. As Michael already said, this works a lot better if Semantic Versioning is used consistently.

I am not very familiar with all the IPs that OpenHW manages, but I assume the number of dependencies are probably a bit lower, since you are managing single IPs instead of larger systems. Even then, Bender is very helpful to collect the files from dependencies and generate scripts for different EDA tools. I think by now, every PULP repository uses a Bender.yml to easily generate those scripts, regardless of whether it relies on dependencies or not.

The concept of Bender is also very sound and it follows the same approach that modern package managers of other languages have had for a while (e.g. Cargo, npm, uv, poetry), where dependencies are specified with loose constraints (i.e. Bender.yml) and then resolved and locked in another file (i.e. Bender.lock) for consistent behaviour. Also the implementation of Bender is very good and I cannot recall any buggy behaviour at all (also props to @micprog!). From time to time we have discovered some limitations (e.g. resolving dependencies from different remotes), but they have all been addressed along with new features to speed up the workflow.

All in all, Bender is a very solid tool (some of the best thing that came out of the PULP platform in my opinion), and it would also make our lives a bit easier in the PULP team if OpenHW would adopt Bender :-)

[khandelwaltanuj]

Hi,

I will be very interested in trying bender. I have used it a bit with IDMA of pulp but I still do not have the proper understading of this.
I believe integrating bender within the python scripts (generic) of compilation/run and regression developed by CEA and improved by this PR (#2643) could be really great.

I shall give it a try in one of our project but may not be possible beore January.

Thanks

[khandelwaltanuj]

Just to clarify the PR request :

It proposes a bender based compile flow that uses the scripts from cv_dv_utils. And the combination of 2 can be a developped as a generic compile flow not only for cv_dv_utils but for any IP. In the example stated in the pull request, this combined flow is used for cvfpu-uvm.

[MikeOpenHWGroup]

OK, its official, as of #2643, Bender has been merged into this repo. Of course, it is only for a few components of the cv_dv_utils, but its a start. I'd still like to hear opinions and experiences of others in the community.