Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use ipgen to generate rv_plic #8431

Merged
merged 4 commits into from
Oct 7, 2021
Merged

Use ipgen to generate rv_plic #8431

merged 4 commits into from
Oct 7, 2021

Conversation

imphil
Copy link
Contributor

@imphil imphil commented Sep 29, 2021

This PR converts rv_plic to an IP template, and instantiates it through ipgen. Since rv_plic is the first IP block to be converted, the PR also contains some preparatory commits. Only the last commit ([rv_plic] Produce top_earlgrey instance of rv_plic with ipgen) is the actual conversion. Reviewers are encouraged to look at this commit especially.

Since most of the conversion job is renaming files, and all files in hw/top_earlgrey/ip_autogen are auto-generated, the diff isn't as beautiful as it could be -- but the manual work is still rather limited.

This conversion is effectively a clean-up, no functional change on OpenTitan is expected.

[rv_plic] Produce top_earlgrey instance of rv_plic with ipgen

This rather large commit makes rv_plic an IP template, and then uses
ipgen to instantiate the block with the right parametrization for
top_earlgrey.

In contrast to the previous approach, `hw/top_earlgrey/ip_autogen`
now contains a full copy of rv_plic under a unique FuseSoC core
name, `lowrisc:opentitan:top_earlgrey_rv_plic`.

Unfortunately, doing so requires a fair amount of reshuffling, which
cannot be easily split into individual commits while keeping the whole
tree building. Here's what was done:

* Move `ip/rv_plic` to `ip_templates/rv_plic`.
* Remove the `reg_rv_plic.py` tooling, which is now replaced by ipgen.
* Change `topgen.py` to generate the toplevel-specific instance of
  `rv_plic` through ipgen.
* Adjust references in the documentation as necessary.
* Adjust the software build as necessary.
* The FPV testbench is now only run for the Earl Grey-instantiated IP
  block, there is no more "generic" testbench. Update all references
  pointing to the testbench.

@imphil imphil force-pushed the ipgen-plic branch 3 times, most recently from a79b699 to bf6b8e1 Compare October 1, 2021 16:17
@imphil
Copy link
Contributor Author

imphil commented Oct 1, 2021

@cindychip This PR reshuffles the FPV testbench a bit, and I can't really test the result. Would you mind checking out this PR and run FPV on it?

The relevant part from the commit message:

  • The FPV testbench is now only run for the Earl Grey-instantiated IP
    block, there is no more "generic" testbench. Update all references
    pointing to the testbench.

The FPV FuseSoC core is now named lowrisc:opentitan:top_earlgrey_rv_plic_fpv.

@imphil imphil force-pushed the ipgen-plic branch 3 times, most recently from e2d1d28 to 5e0bdac Compare October 4, 2021 12:00
"Falling back to template %s for initial validation." %
str(hjson_file))
# validation, use the Hjson file with default values.
# TODO: All of this is a rather ugly hack that we need to get rid
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@imphil sorry i'm a bit late to the party.
Does this comment mean hjson's won't be templated in the future? or that they will be templated in a specific way?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

First of all: in this PR and the first stage of ipgen work, nothing changes here from how we did it before: we use the default template in the first run, and then the real template in the second run of topgen.

In the medium-term future, I'd hope that we can avoid string-templating Hjson files. Instead, it would be great if we can use what are template variables now as proper variables in Hjson files. But all of this is for another day.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah yeah i think the main thing we run into there is when we using a templating variable to create different versions of a register.. we don't really support the idea of nested multi-reg right now.

name: rv_plic_fpv
fusesoc_core: lowrisc:fpv:rv_plic_fpv
name: top_earlgrey_rv_plic_fpv
fusesoc_core: lowrisc:opentitan:top_earlgrey_rv_plic_fpv
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the middle portion here "opentitan" seems a bit different from before.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, it's different, but intentional: these IP blocks are specific to OpenTitan, they are not generic lowRISC IP. I therefore put them into the "opentitan" library (that's what the second part of the Vendor-Library-Name-Version (VLNV) string stands for).

Copy link

@tjaychen tjaychen Oct 4, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i guess the part where this is confusing to me is because all the stuff under hw/ip and hw/ip_autogen are all under the opentitan repo. So in a way it feels like they are all specific to opentitan.

I actually thought you would want something like lowrisc:top_earlgrey:rv_plic_fpv to show their specificity to the top level while maintaining a more generic function. What do you think?

I know we also talked about the oddball dependencies we have now between certain modules..that probably plays a factor as well.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The "lowrisc" namespace is actually for all things lowRISC produces, which is more than OpenTitan. We for example share IP blocks with Ibex and other things we're (now or in the future are/might be) working on.

We had for a long time plans to split out the "common" lowRISC IP into a separate repository (e.g. in discussions with Scott and Mark ages ago). We never followed through with that due to the churn it would create for the OpenTitan project. Instead, we went for using the opentitan repository as "source", and vendor the IP blocks into other repositories, e.g. Ibex (here).

So while it is the most ergonomic choice right now to keep all IP in the opentitan repository, I'd like to use the opportunity to get the naming and namespacing more aligned with this vision and avoid a potential massive renaming down the line.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah okay that's a fair point. The common modules being inside the opentitan repo is a bit odd and i imagine will cause issues elsewhere as well.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

btw @imphil , let's say in the long term world we split hw/ip into its own common repository, would the hw/ip_template stuff also go there? Technically it feels like it should right? Those are not necessarily specific to opentitan.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, that would be my current take on it.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah that sounds good and very consistent.
thanks!

@tjaychen
Copy link

tjaychen commented Oct 4, 2021

this looks pretty good to me overall, although i think things are big enough that I wouldn't be able to tell if something would get majorly broken until we merged.

I've left a comment above since i'm a bit confused about the opentitan naming.

Copy link
Contributor

@rswarbrick rswarbrick left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks like a great improvement: nice!

Copy link
Contributor

@msfschaffner msfschaffner left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @imphil and sorry for being late to the party here.

LGTM in general - however I found a couple of issues when piping this through the FPV flow, see comments (@cindychip is out on vacation at the moment).

hw/top_earlgrey/formal/top_earlgrey_fpv_cfgs.hjson Outdated Show resolved Hide resolved
srcs = [
"rv_plic.hjson",
],
)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it looks like this removes bazel build rules... we probably have to leave these in place (or generate them) since this may otherwise break the new bazel-based SW build flow (CC @drewmacrae to confirm that this is the case).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All Bazel-related things are unsupported and experimental for as long as we don't even have agreement on using Bazel going forward; I cannot even test it. This will need to be sorted out up by the people experimenting with Bazel currently after the fact, unfortunately.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for flagging this, I have a PR to fix it, if you have bazel installed and you're interested you can test the bazel rules with bazel test //...

I still need to write a getting started doc for it. If you don't have it installed I can point to instructions here: https://docs.bazel.build/versions/main/install-ubuntu.html

hw/ip/rv_plic/fpv/rv_plic_component_fpv.core Show resolved Hide resolved
// Licensed under the Apache License, Version 2.0, see LICENSE for details.
// SPDX-License-Identifier: Apache-2.0
//
// ------------------- W A R N I N G: A U T O - G E N E R A T E D C O D E !! -------------------//
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

could this potentially use the autogen header library that @sriyerg has added recently?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

None of the files in the ip_autogen folder have autogen headers:

  • All files in ip_autogen are auto-generated, I don't want to give the impression that only some of them are.
  • Adding headers to all files is tricky: ipgen doesn't know and care about file types; adding generated headers would require per-extension logic to e.g. use the right types of comments.
  • We were talking about symlinking some files in ip_autogen to ip_templates, which would prevent added headers.

I'd therefore much prefer developers getting used to the fact that all in ip_autogen (as in other autogen folders) is autogenerated and shouldn't be manually edited. (And ultimately, maybe we can get rid of the autogenerated checked-in files completely, but that's a separate discussion.)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fair enough, let's leave this as is then.

Add the ability to produce IP blocks through ipgen instead of having
custom logic within topgen. In this commit this logic isn't use yet.

A difference between topgen-generated IP blocks and ipgen-generated
ones is the slightly different directory structure: ipgen does produce a
full IP block directory, matching a "regular" IP block, and does not
include "autogen" subdirectories.

Signed-off-by: Philipp Wagner <[email protected]>
The hw/ip_templates directory is meant to host IP templates, which can
be used after they have been rendered through ipgen. Since those
templates may contain partial FuseSoC core files, but are not meant to
be used as template, we add a FUSESOC_IGNORE file, excluding the
directory from the core search path.

Signed-off-by: Philipp Wagner <[email protected]>
This rather large commit makes rv_plic an IP template, and then uses
ipgen to instantiate the block with the right parametrization for
top_earlgrey.

In contrast to the previous approach, `hw/top_earlgrey/ip_autogen`
now contains a full copy of rv_plic under a unique FuseSoC core
name, `lowrisc:opentitan:top_earlgrey_rv_plic`.

Unfortunately, doing so requires a fair amount of reshuffling, which
cannot be easily split into individual commits while keeping the whole
tree building. Here's what was done:

* Move `ip/rv_plic` to `ip_templates/rv_plic`.
* Remove the `reg_rv_plic.py` tooling, which is now replaced by ipgen.
* Change `topgen.py` to generate the toplevel-specific instance of
  `rv_plic` through ipgen.
* Adjust references in the documentation as necessary.
* Adjust the software build as necessary.
* The FPV testbench is now only run for the Earl Grey-instantiated IP
  block, there is no more "generic" testbench. Update all references
  pointing to the testbench.

Signed-off-by: Philipp Wagner <[email protected]>
@imphil
Copy link
Contributor Author

imphil commented Oct 6, 2021

Thanks for trying the FPV stuff, @msfschaffner. Would you mind giving it another try to see if the latest push fixed things?

@msfschaffner msfschaffner self-requested a review October 7, 2021 00:21
Copy link
Contributor

@msfschaffner msfschaffner left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok it looks like the FPV setup works again now.

There are some failing assertions - but they seem to have been failing before as well so this is unrelated.

@imphil imphil merged commit c720ac8 into lowRISC:master Oct 7, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants