Hi, 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. >>> >> Yes, we at Rivos are also be interested in attending. It would be good if we can unify towards a single RVV implementation for Gem5.
Jerin On May 25, 2022 at 16:41:43, Jason Lowe-Power <ja...@lowepower.com> wrote: > Hi Yang, > > On Sun, May 22, 2022 at 11:59 PM ksco <numbk...@gmail.com> 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 <ja...@lowepower.com> 于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 -- gem5-dev@gem5.org To unsubscribe send an email to gem5-dev-le...@gem5.org
