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
