This is to mimic systemc's protocol extension mechanism, where you can add side channel info to a transaction. Sender state is more for keeping track of information the sender needs related to a particular packet, rather than to send additional state down the line to other consumers. For instance, there is no identifier in a SenderState, since it is assumed when you get a response back, your SenderState is at the top of the stack. There would be no real way to determine which SenderState matched a particular extension except dynamic casting everything to search for a particular type, and even then you could have false hits from extension subclasses.
Gabe On Mon, Apr 18, 2022 at 4:49 PM Jason Lowe-Power <ja...@lowepower.com> wrote: > Hi Yan, > > Can you use the Packet::pushSenderState(), popSenderState(), etc > functions? This is a stack instead of a linked-list, but it may work for > your use case. See > https://gem5.googlesource.com/public/gem5/+/refs/heads/stable/src/mem/packet.hh#440 > for more information. > > The idea with that interface is that an object can push "sender state" > into the packet, send the packet on to some other receiver, and then when > you get a response you can pop the sender state back off. You can also > use findNextSenderState to get any sender state from the stack. > > To use it, you can extend the class SenderState to hold any state that > you'd like. > > Let me know if this isn't what you're looking for. It sounds quite similar > to what you're proposing. If we can extend that interface, it would > probably be better than adding something totally new. > > Cheers, > Jason > > On Thu, Apr 14, 2022 at 1:08 AM Yan Lee via gem5-dev <gem5-dev@gem5.org> > wrote: > >> Hi Gabe and everyone, >> >> Thanks Gabe for bringing this up. Currently I am making a model in AXI >> protocol and this model will need the AxUser and AxProt fields in the AXI >> protocol. The packet in gem5 cannot carry additional information except the >> actual read/write data. I think we can have the extension mechanism in our >> gem5 packet just like the way in SystemC. Therefore, we can simulate some >> protocol-related behavior with this extension in each gem5 packet. >> >> I think we can have an array-based or linked-list-based extension >> mechanism in gem5 packet. That is, we can have multiple extensions in one >> packet and may be increased during the transaction. But we can discuss the >> way of searching for one extension. In systemc, it uses linear search to >> find if one extension exists or not. >> >> Look forward to any feedback or ideas, and thanks for your sharing. >> >> Yan >> >> On Thu, Apr 14, 2022 at 3:37 PM Gabe Black <gabe.bl...@gmail.com> wrote: >> >>> Hi folks. Yan Lee, a Google colleague of mine, is interested in adding >>> one or more extension objects to gem5 Packet. Systemc has a mechanism like >>> this already, and it's come up a few times where we've wanted to have >>> something like this on the gem5 side as well. >>> >>> Yan, can you please talk about the problem you're trying to solve, and >>> the mechanism you want to add to handle it? >>> >>> Gabe >>> >> _______________________________________________ >> gem5-dev mailing list -- gem5-dev@gem5.org >> To unsubscribe send an email to gem5-dev-le...@gem5.org >> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s > >
_______________________________________________ gem5-dev mailing list -- gem5-dev@gem5.org To unsubscribe send an email to gem5-dev-le...@gem5.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
