Bender integration, sram update

[micprog]

Added Bender.yml file and bump dependencies for compatibility to bender. Updated tech_cells_generic, changed deprecated generic_memory to tc_sram.

@bluewww @meggiman Please let me know if any other changes are required Replaces https://github.com/pulp-platform/pulp_soc/pull/33

[micprog]

Small update: in my most recent tests building pulpissimo with this pulp_soc, I encountered an issue with two different definitions of FLL_BUS due to updating apb_fll_if, now fixed with the latest commit.

[micprog]

Hi @meggiman @bluewww, With the most recent changes, hwpe-mac-engine and riscv should no longer point to my personal repository. I had some challenges with cv32e40p, as the repository is now named differently this may cause confusion, but this only refers to the directory name with IPApproX, and the repository link. Please let me know if any further changes are needed. I have not yet tested the bender build, as I am currently working with pulp, not pulpissimo, and I believe the integration there is not yet complete, but can look into it if desired.

[meggiman]

The commit id of Ibex in this PR seems to be invalid or the commit doesn't exist anymore. Could you please update this?

[meggiman]

Also I just noticed that there are many version conflicts when trying a bender checkout. If possible we should have the master branch in a state, where version conflicts do not have to be resolved manually or with an override file. This will probably require a lot of version bumping to align the repositories version requirements...

[micprog]

The commit id of Ibex in this PR seems to be invalid or the commit doesn't exist anymore. Could you please update this?

The pulpissimo branch in ibex has been moved to a newer version of ibex, referenced in #47. There are a few options to fix this, depends on what you would prefer.

1. I can reference my personal repo for this commit until #47 is merged, which still has the commit (I could add a pulpissimo-v6.0.1 tag).
2. Alternatively, ips_list.yml could reference the pulpissimo-v6.0.0, which is the version previously used, however does not include updates for bender and minor bugfixes.
3. If the older version referenced here should originate from the lowRISC repository, the appropriate commits would need to be re-introduced, with tags (@vogelpi's help here would be needed).
4. I could re-arrange the update to ibex in #47 such that it can be merged first, and an available version of ibex referenced in this PR.

[meggiman]

I personally would prefer option 4. Merging this PR should yield a working Bender flow which would not work with option 2.

[micprog]

Also I just noticed that there are many version conflicts when trying a bender checkout. If possible we should have the master branch in a state, where version conflicts do not have to be resolved manually or with an override file. This will probably require a lot of version bumping to align the repositories version requirements...

While behavior would definitely be improved, these updates are not always that easy. For specifics:

• [ ] tech_cells_generic: requires update of udma_sdio, udma_i2c, udma_camera, udma_qspi, cv32e40p, common_cells, apb_adv_timer (if identical versions between ips_list.yml and bender.yml are desired, a new tag would also be needed)
• [x] common_verification: requires update of common_cells, axi
• [ ] axi: requires update of register_interface, and likely the removal of axi_slice_dc

I will start with these updates, but strongly suggest the use of a Bender.local file for overrides in the main pulpissimo and pulp repositories, as certain mismatches seem to be prevalent in pulp.

[micprog]

I personally would prefer option 4. Merging this PR should yield a working Bender flow which would not work with option 2.

Done, I will update the dependencies in this PR once #47 is merged

[vogelpi]

Thanks for reworking #47 @micprog this is the cleanest solution.

[bluewww]

47 is merged

[bluewww]

Can you also add the override file to this pr you use to the bender checkout? This would allow users to get a working state of this project withouth having to tell bender which ip version to use. I believe this is a good short term solution.

[meggiman]

@micprog Regarding the version alignment issues of all the dependencies I can see the dificulty, although using an override file kind of defeats the purpose of Benders semantic versioning resolution. In order to finally bring bender support to pulp_soc without further delays I would thus suggest that we temporarily add a bender.local file with the necessary overrides and later on remove it step by step once the other IPs become aligned. Otherwise requiring less experienced pulp user to decide which version to check out is a fool proof way to completely overwhelm ourselves with support requests once we point to the newest pulp_soc version in PULPissimo and pulp-open. What do you think?

[micprog]

@bluewww @meggiman Based on some quick tests, the bender config file used for overrides can currently only be placed in the top-level repository, i.e. the PULPissimo or pulp-open repositories, not this repo. This would also make sense to keep all overrides in one central location. I agree that users should not be required to choose dependency versions, unless they are working on dependency updates, so integrating Bender to the top repositories will require adding a config file to those PRs, but unfortunately adding one here will not make a difference. Is this an acceptable approach?

[bluewww]

Ok thats fine by me.

Do you want me to put a rev tag onto the cv32e40p branch?

[micprog]

Do you want me to put a rev tag onto the cv32e40p branch?

Would probably be cleanest, just know that dependency resolution will not work the same as with version tags. The benefits are limited to persistence within the repository, and legibility, which I think both is worth it.

[bluewww]

Ok I created a tag.