Hi, Sorry for the late reply. Your email was archived in a label and I didn’t see it till today.
Thanks for getting back to us. It will be great to work on this together. I’ve submitted a PR here with our changes so far: https://github.com/plctlab/plct-gem5/pull/6 Jerin On Sep 2, 2022 at 19:14:41, ksco <[email protected]> wrote: > Hi Jerin, > > Thanks for the amazing work! Do you mind submitting a PR? Then we can > discuss the implementation details in the PR. We’ve also added a bunch of > instructions in our private Gitlab repo, so there may be some conflicts > that needs to handle. But I think that can be done after merging your PR. > > Also, we will migrate to GitHub for development considering it’s easier > for us to work together. > > On Sat, Sep 3, 2022 at 6:01 AM Jerin Joy <[email protected]> wrote: > >> Hi, >> >> We want to restart this conversation about working on a single RVV >> implementation to be merged into upstream Gem5. >> >> We also think adding microcode support for the RVV instructions is the >> right way to go. >> >> To get started, we created a fork of PLCT lab’s Gem5 repo and have >> started commiting fixes and additions to the code. The branch with the >> changes so far is here: >> >> https://github.com/rivosinc/plct-gem5/commits/dev/joy/fixes_and_additions_aug31 >> >> These changes can be merged into the plct-gem5 repo after review. We plan >> to add more instructions going forward. >> >> Jerin >> >> On May 25, 2022 at 16:41:43, Jason Lowe-Power <[email protected]> >> wrote: >> >>> Hi Yang, >>> >>> On Sun, May 22, 2022 at 11:59 PM ksco <[email protected]> wrote: >>> >>>> Hi Jason and others, >>>> >>>> We (the PLCT Lab) are delighted to receive the rapid feedback from the >>>> community! And we are glad to see that there are so many contributors in >>>> the open source community participating in the RVV support on gem5. We want >>>> to give thanks and respectation to other contributors. We also hope to work >>>> together with the community to advance the development of RVV support >>>> faster and better. >>>> >>>> I think Zoom meetings are helpful for collaborative development, but >>>> our English (especially speaking) is not so good, so there may be some >>>> communication difficulties in the voice meeting. Maybe we can maintain >>>> long-term communication over some IM? I think Slack is a good option, but >>>> if you guys have any other preferred chat software, we'd love to use it >>>> too. >>>> >>> >>> Great idea. We've been talking about using a platform like this. I'll >>> try to set something up this weekend. >>> >>> >>>> >>>> We are honored that Jason believes collaboration should be based on our >>>> implementation posted on Gerrit. We are currently developing on GitHub ( >>>> github.com/plctlab/plct-gem5), PRs are very welcome! >>>> >>>> As for the instruction support, it is true that the implementation of >>>> RIVOS is more complete than our current implementation. We are very willing >>>> to cooperate with RIVOS to complete the follow-up instruction >>>> implementation. >>>> >>>> And as for the configuration support of VLEN, We hope to have some >>>> discussion. We believe that it is necessary to make VLEN configurable. We >>>> found that RIVOS has added support for it in the compilation phase. But we >>>> think it might be better to support this configuration at runtime (via >>>> python) as in Spike/QEMU. But we haven't yet found a way to do it. Is this >>>> possible in gem5? >>>> >>> >>> See >>> https://github.com/darchr/gem5/commit/8e5ff326d9c6dca4320fb231e335c5f8dbcf1e93. >>> It's not *quite* right, but the idea is there. >>> >>> >>>> >>>> And passing vtype/vl via PCState is indeed a better solution if it can >>>> implement support for the Timing model without hacking the CPU code. We are >>>> looking forward to further progress with this solution! >>>> >>> >>> Great :). Please let me know if you run into any major hurdles. We're >>> still working on a proof of concept to ensure the PCState solution works as >>> well. >>> >>> >>>> >>>> We're honored that the test repo ( >>>> https://github.com/huxuan0307/riscv-vector-tests) has your praise. >>>> More peer approval is required before integrating it in gem5-resources, we >>>> think. At present, this repository is experimental and unsteady. And there >>>> are still bugs to fix. We're glad if this repo is helpful for your >>>> development. >>>> >>>> In the next steps, we intend to focus on the development and >>>> improvement of the unit tests repository ( >>>> https://github.com/huxuan0307/riscv-vector-tests) and continue to >>>> explore the implementation of some new instruction formats under >>>> microinstructions (such as Widening and Narrowing instructions). In the >>>> future, we could have more discussions on division of cooperation. We hope >>>> we don't have duplicate work in cooperative development. >>>> >>> >>> A couple of quick and easy things to do here: >>> - Create a dockerfile to compile the workloads (Hoa at UC Davis may have >>> already done this, but I'm not sure). >>> - Write up enough documentation in the README so that anyone can easily >>> build these binaries (I think this is very close already). >>> - Document which binaries work and which don't in gem5 >>> >>> After those small things, I think we should go ahead and integrate these >>> tests here: >>> https://gem5.googlesource.com/public/gem5-resources/+/refs/heads/stable. >>> We can iterate on improving the tests and adding more there as well. We >>> (here at UC Davis) can also help by creating the gem5 scripts necessary to >>> run the tests. >>> >>> Cheers, >>> Jason >>> >>> >>>> >>>> Thanks again to all the contributors! >>>> >>>> Regards, >>>> >>>> Yang Liu >>>> >>>> Jason Lowe-Power <[email protected]> 于2022年5月21日周六 02:32写道： >>>> >>>>> Hi everyone, >>>>> >>>>> I'm super excited to see all of the activity around RISC-V vector >>>>> instructions right now. However, it looks like there are a few different >>>>> implementations being worked on, and it's a good idea to try to unify >>>>> around a single implementation and work together to get to a point where >>>>> everyone in the gem5 community can benefit from this support. >>>>> >>>>> Before going any further, I want to give a huge thanks to everyone >>>>> that has been working on this and has made contributions to varying >>>>> different implementations. I'm not going to try to name people (I'm >>>>> certain >>>>> I missed some in the cc line!), but I hope everyone knows that we >>>>> appreciate their contributions to the project! >>>>> >>>>> Before diving into details of the code, if there's interest from the >>>>> community I can set up a meeting time for us all to get together on zoom >>>>> to >>>>> chat about details and the best way to work together. >>>>> >>>>> Looking at the code ( >>>>> https://gem5-review.googlesource.com/c/public/gem5/+/59789) and the >>>>> documentation ( >>>>> https://docs.google.com/document/d/1yUDPU9NvpKo1WM1WYfdx20_aXLnlHssUUsDYR4lu95Q/edit) >>>>> recently submitted, I think there are many great things about this >>>>> approach, and a couple of places that we should discuss potential ways to >>>>> improve it. >>>>> >>>>> First, I think that using microcode is definitely the right way to >>>>> enable configurable VLEN and to get timing memory accesses to work. >>>>> Because >>>>> of this, I believe that the code posted to gerrit is probably the best >>>>> starting point for collaboration. Happy to hear other opinions, though. >>>>> >>>>> Note that the Rivos implementation on github ( >>>>> https://github.com/rivosinc/gem5/tree/rivos/dev/joy/initial_RVV_support) >>>>> does not use microcoded instructions, so it only works in atomic mode. >>>>> However, I believe this implementation may have more instructions >>>>> implemented than the one on gerrit. Also, in this implementation the VLEN >>>>> is a parameter of the ISA which allows users to configure the system >>>>> dynamically (which is great!). We should try to find a way to merge these >>>>> two implementations. >>>>> >>>>> Second, we should integrate the tests ( >>>>> https://github.com/huxuan0307/riscv-vector-tests) into gem5-resources >>>>> ASAP. This is a fabulous contribution! Having tests for vector insts will >>>>> enable much faster development. >>>>> >>>>> I would like to discuss one design decision in the gerrit code: >>>>> Specifically how the vtype/vl is set in the decoder. Stalling the decoder >>>>> to get the correct vtype/vl when vset*vl* is executed doesn't fit well >>>>> with >>>>> gem5's execution model, and it feels like a bit of a hack. >>>>> >>>>> I have an alternative proposal that I would like to hear your thoughts >>>>> on. >>>>> Instead of storing vtype/vl in the decoder, we could store it in the >>>>> PCState. Then, the vset*vl* instruction would look a lot like a control >>>>> instruction. At decode time, the next PC state could be set with some >>>>> values (maybe wrong values, just like the next pc after a branch may be >>>>> wrong) or if it is a vsetivli, then the next PC state would have the >>>>> correct values. Then, the subsequent instructions could access the PC >>>>> state >>>>> to get the current vtype/vl. >>>>> >>>>> In the execute stage of the vset*vl*, it would set the next pc state >>>>> correctly. The CPU models already check to see if the next PC is the same >>>>> in execute as it was "predicted" in the decode stage (i.e., was the branch >>>>> predicted correctly). We can leverage this to check to see if vtype/vl are >>>>> correct. If not, the CPU models will simply squash and re-execute starting >>>>> at the correct next pc (i.e., the next vector instruction will execute the >>>>> correct vtype/vl after vset*vl* is executed). If we extend the branch >>>>> predictor to predict the vtype/vl and use the "last" values, this should >>>>> be >>>>> correct a huge percentage of the time. Smarter methods could also be >>>>> employed. >>>>> >>>>> While this may not be a particularly realistic way to implement a >>>>> hardware version of RVV and vset*vl*, I think that it's probably the best >>>>> way to model it in gem5 without creating a separate vector engine object >>>>> which is decoupled from the CPU model. >>>>> >>>>> We have been working on a proof-of-concept for this here at UC Davis >>>>> (see https://github.com/darchr/gem5/tree/hn/rvv-uop, though this is >>>>> untested in timing mode right now). Do you all think this is a good way >>>>> forward? Or, is there something that I'm missing about the decoder >>>>> stalling? >>>>> >>>>> Cheers, >>>>> Jason >>>>> >>>>
_______________________________________________ gem5-dev mailing list -- [email protected] To unsubscribe send an email to [email protected]
