I think this may not be quite right, or I'm misunderstanding what Jason is saying. The Tick number returned in atomic mode is supposed to approximate how long the access took, and it's up to the caller to do something with that. Often the caller does throw away the number, but that's what it's supposed to mean.
In timing mode, there is no returned Tick value, and it's up to the device servicing the access (the thing *implementing* the read or write) to delay the response to the access by whatever length of time it would take. This is also done by all the steps along the way as the access is propagated, so the interconnect, caches, etc. Cumulatively those all add up to how long the access takes, which is what the atomic mode return value is supposed to approximate. When using atomic mode, performance is very loosely modeled. When using timing mode, your device should implement delays by scheduling events for in the future which actually send a response to a given access. Gabe On Mon, Dec 27, 2021 at 3:59 PM Jason Lowe-Power via gem5-users < gem5-users@gem5.org> wrote: > Hello, > > If you are using *atomic* memory mode, then the tick number is mostly > ignored. If you're using *timing* mode, then the tick number should be used > by whatever object calls the read/write function and the delay is inserted > there. Also, if your program doesn't have a direct dependence on the I/O > device, the latency may be hidden. Enabling various debug flags should help > you track this down. > > Cheers, > Jason > > On Thu, Dec 23, 2021 at 8:58 AM lin via gem5-users <gem5-users@gem5.org> > wrote: > >> Hi >> >> I make an IO device link to the membus and complete the Tick >> read(PacketPtr pkt) and the write() function .But I find that no matter how >> many ticks ( the funciton return n*tick) I set,the simSeconds no change.If >> it normal?If not , what can I do to set the return ticks of the read() or >> write() function? >> >> Thanks everyone! >> >> >> >> _______________________________________________ >> gem5-users mailing list -- gem5-users@gem5.org >> To unsubscribe send an email to gem5-users-le...@gem5.org >> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s > > _______________________________________________ > gem5-users mailing list -- gem5-users@gem5.org > To unsubscribe send an email to gem5-users-le...@gem5.org > %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
_______________________________________________ gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email to gem5-users-le...@gem5.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
