Closed tymcauley closed 3 years ago
I suspect these issues are copy-paste errors when updating the documentation reference guards in the source code (DOC include start
and DOC include end
).
The names in the guards should match the config names they are guarding
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.