Closed
Conversation
Co-authored-by: Vincenzo Maisto <vincenzo.maisto2@unina.it> Co-authored-by: Matteo Perotti <mperotti@iis.ee.ethz.ch> Signed-off-by: Moritz Imfeld <moimfeld@student.ethz.ch>
This was referenced Oct 15, 2024
18cd941 to
ce46d3c
Compare
3 tasks
6d4a76f to
858569a
Compare
858569a to
dc2cbd1
Compare
6170122 to
dc79fa1
Compare
paulsc96
requested changes
Oct 22, 2024
Member
paulsc96
left a comment
There was a problem hiding this comment.
This is very clean as far as the diff in this repository.
The back-referencing setup however, while an intriguing construction, seems unnecessary. We can further discuss this offline, but:
- To avoid the hardware back-reference (Bender script inject):
- It is perfectly fine to unconditionally add Bender flags required by Ara to Cheshire; CVA6 does this too.
- If you need these flags to be configurable (
nr_lanes,vlen), it is best to introduce variables for them in the Cheshire make fragment (like those for the PLIC, CLINT etc.) and insert them in the build targets for the analyze scripts. This way, they can be overriden the same way as all other non-SV IP parameters. - If I missed something and you need to dynamically generate RTL (I don't think so), it would be great if you could follow the established method of creating an includable Make fragment in Ara to reconfigure its RTL from Cheshire as needed.
- For the device tree, each (FPGA) target may have multiple device trees; you can simply add one called
cheshire.vcu128_ara.dtsusingriscv,isa = "rv64imafdcv"instead of patchingcheshire.dtsi. - For Linux, I don't necessarily mind if an Ara-ready image cannot (yet) be built directly from Cheshire. How we build and manage Linux is about to fundamentally change anyways, so adding a back-reference for this now is perhaps untimely. We can address this in a cleaner way in a later PR.
| `endif | ||
| `ifdef ARA | ||
| ret.Ara = 1; | ||
| ret.AraVLEN = `ifdef VLEN `VLEN `else 0 `endif; |
Member
There was a problem hiding this comment.
Having these as defines is fine, but perhaps they should be prefixed to clarify they affect Ara
Author
|
PR moved to #231, to integrate CVA6 version |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This is the second PR for Ara's FPGA and OS support. See #112 for the bare-metal one.
Before merging, Ara and CVA6 should be referenced with TAGs laying on the
mainbranch.EDIT:
PR moved to #231, to integrate CVA6 version
pulp-v2.