Hi Fela, In short, gem5 atomic is like SystemC TLM Loosely Timed, and gem5 timing is a high-level implementation of SystemC TLM Approximately Timed.
The gem5 memory system is transaction based, so in timing mode, a request packet (as well as a response packet) corresponds to a single phase in the communication protocol. That is, the request, as well as its associated payload only corresponds to a single call to send/recvTiming. There is no fundamental reason why we cannot model individual beats in a burst, command vs data handshakes etc, but at the moment this is not something we do. More detail means slower simulation. You can of course implement an interconnect model that has more phases and more detail, but be mindful as there are assumptions in the coherency protocol. For example, at the moment we never buffer request packets in the crossbar, as that would involve a lot of tracking of coherency operations. Instead we instantaneously pass the request on to the downstream cache, and only later pay for the latency. Another issue to remember is that gem5’s event model is making modelling of arbitration challenging. By default we do not do a proper notify/update cycles in the event loop. Thus, in the case of you M1 and M2, we do not wait for both to “request” before deciding which one to serve. Instead, which ever calls sendTiming first will go ahead and block the other. As a result, the arbitration in the crossbar is only applied on retries, rather than calls to recvTiming. I hope this provides a bit more clarity. Andreas On 19/11/2015, 17:17, "gem5-users on behalf of fela" <[email protected] on behalf of [email protected]> wrote: >Hello users, > >I'm modeling a new interconnect model using classic memory system in gem5. > >My question is : when two masters M1 and M2 attempt to access a memory >line >simultaneously, is the coherent_xbar able to observe the M2 transaction >while handeling the M1 request? >After debbuging a small example of two memtest objects generating two >requests at the same time, I see that the second request is handled after >the recvTimingRequest functon (from the M1). >This is due to the sequential implementation. >Am I right? Is it the right behavior of the coherent_xbar? >If so, how we can observe an interrupt while handeling an access for some >master? > >Thanks, >Fela. > > > >_______________________________________________ >gem5-users mailing list >[email protected] >http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users ________________________________ -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
