-
Notifications
You must be signed in to change notification settings - Fork 668
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
Documentation: Heterogeneous SoCs #786
Comments
I suspect these issues are copy-paste errors when updating the documentation reference guards in the source code ( |
Alright, I've taken care of the first two issues in #796, but I'm still unclear on number 3. How does core config fragment ordering affect hart numbering for those cores? Is there an easy way I can inspect that after building a config? |
All questions answered in #796, this issue can safely be closed once that PR is merged. |
Merged in #796 . Thank you! |
Impact: documentation
Tell us about your environment:
Chipyard Version: 1.4.0
In the Heterogenous SoCs documentation page, I ran into a few confusing points.
Issue 1
In the "Creating a Rocket and BOOM System" section, the docs say:
And then it includes the
DualBoomAndRocket
fragment from HeteroConfigs.scala, which looks like this:That looks as expected (although the config has 2 rocket cores, rather than the expected single core), but when I look at that example in the ReadTheDocs page, I see the
LargeBoomAndHwachaRocketConfig
config rather thanDualLargeBoomAndDualRocketConfig
. Not entirely sure what's wrong there. Do you see the same issue?Issue 2
In the "Assigning Accelerators to Specific Tiles with MultiRoCC" section, the docs say:
And then it includes the
DualBoomAndRocketOneHwacha
fragment, but that config doesn't actually describe 2 BOOM cores and a Rocket core, it looks like this:So it just has 1 BOOM core and 1 Rocket core. Since people might be using this config, should we just create a new
DualLargeBoomAndHwachaRocketConfig
config, and point this doc fragment to that new config?Issue 3
Related to the previous issue, the docs say:
However, the
WithMultiRoCCHwacha
fragment uses a hart ID of 1. So, that should be fixed when Issue 2 is resolved. Still, that brings up a general point of confusion: in a heterogeneous config like this, how to I map hart IDs to the different cores? I don't think that mapping is explained. Presumably the ordering of the core config fragments affects this mapping, so that should probably be documented.Once these questions are sorted out, I'm happy to submit a PR to resolve this.
The text was updated successfully, but these errors were encountered: