Add Bender support

[micprog]

Add Bender.yml for bender support, add Bender.local for overrides, add Makefile compatibility with bender (set envvar BENDER to use checkout, build, clean)

[bluewww]

You don't need to change this file. The ${BASH_SOURCE[0]:-$0} with the : makes it so that it works under zsh already.

[micprog]

@bluewww @meggiman Thanks for merging pulp_soc! This PR should implement bender within pulpissimo, adding overrides for axi and tech_cells_generic as discussed in pulp-platform/pulp_soc#45. There are two points I know of that could cause issues currently:

• It would be great if pulp_soc could have a proper version tag, such that future updates could easily be included
• FPGA deployment currently is not set up with bender script generation. I am not very familiar with this, and have no means to properly test it, but I believe generating scripts using bender script vivado, with some flags etc. similar to the bender script for vsim in the Makefile, could work, although the Makefiles in the fpga directory may need to be adjusted accordingly.

Let me know if you would like me to modify anything, I also updated the readme slightly to inform a bit about bender integration.

[bluewww]

I made a new pulp_soc release, so you can point to it in this PR: https://github.com/pulp-platform/pulp_soc/releases/tag/v2.1.0

As for the FPGA + bender thing, we can address this in another PR.

[bluewww]

Only one small issue.

CI passes so I can merge it right afterwards.

[bluewww]

If you change this to all, then you should also remove clean from the all target it sim/. Anyway, it is a mistake from me to put clean into the all target.

[meggiman]

I added a couple of comments in my review. On a side-note: I already have the necessary changes for the benderization of the FPGA port. I will add them in a separate PR once this one is merged. All in all the PR looks very nice. Thanks a lot @micprog, there are only a couple of consideration about make target interdependencies I want to raise:
I think having the bender download target as a dependency of all other bender using targets is a must. What could be considered on top of that is to add dependencies to the build and scripts target as well to force a bender update or bender scripts when necessary. For these two cases I would be interested in you opinion if there are corner cases where such a behavior is nuisance during usual workflow.

[meggiman]

Would it maybe make sense to add the default deps checkout folder used by the bender clone command here as well?

[micprog]

We can of course add this, here are some considerations why I haven't yet.
First, the ips directory used for IPApproX is not added, so it would be conflicting behavior (this could be added of course).
Second, one use-case for bender clone would be to temporarily check in edits to one IP, along with the corresponding Bender.local edits, to share with a collaborator. Although, for this use-case, I think trickier behavior could be considered OK, as this is non-standard, so adding working_dir to the .gitignore would be acceptable.
Finally, I would consider keeping this directory outside of the .gitignore as a check before merging, to see if all changes to dependencies have been added before committing the parent repo, in an effort to avoid conflicts when sharing.

Please let me know your thoughts on this, I will gladly update as needed.

[meggiman]

I think it would make sense to have the bender target as a dependency of the script target. Like this, bender would be automatically downloaded upon first use of the bender-script. What do you think?

[micprog]

This makes sense. I didn't add it, as the checkout command would call it, with bender-script serving as a support target, and for the logical flow I decided to separate dependency download and script generation, but bender will fetch the dependencies if they're not there, so ensuring bender is present for this command is reasonable, will add.

[meggiman]

We should ideally have a single set of commands, that only discriminates between the usage of the BENDER env variable. I.e. we should have a checkout scripts build target that does the job for both tools. Right now, generate scripts is done with a make target for bender but with a Python script for IPApprox. That's a bit inconsistent.

[micprog]

This makes sense, I have updated it, although this is likely to cause confusion for IPApproX users, as the behavior of ./update-ips is now different from before, requiring an additional step.

[micprog]

I think having the bender download target as a dependency of all other bender using targets is a must. What could be considered on top of that is to add dependencies to the build and scripts target as well to force a bender update or bender scripts when necessary. For these two cases I would be interested in you opinion if there are corner cases where such a behavior is nuisance during usual workflow.

I agree on the bender download as a target for the other bender commands. Regarding the calling of bender update and bender scripts when necessary (I assume before a build), the only nuisance I can think of right now is that the update command takes a while, and may require you to always re-select the dependencies you're using (pending https://github.com/fabianschuiki/bender/issues/48). I would also avoid this to ensure a similar workflow to IPApproX, as updating IPs may checkout older commits when working on IPs. A reasonable alternative would be to introduce an all target, calling checkout scripts build.

[bluewww]

lgtm from my side

When @meggiman approves we can merge this.

[meggiman]

Lgtm! Thanks for the changes.