Hi Vedika, That's bad luck and slightly surprising to me that functional reads are not implemented in Garnet. Because you use the SE mode, functional accesses are absolutely necessary for syscall emulation, both functional reads and writes.
Now, why do Garnet only support functional writes? According to this post (https://gem5.atlassian.net/browse/GEM5-604?focusedCommentId=11781), functional accesses are also used in FS mode but I believe only functional writes. That would explain why Garnet only supports them: it is a detailed network model so it does not make a lot of sense to use it in SE mode which is not as accurate as FS. That being said, I see no technical reason for not supporting functional reads in Garnet. If you want to try, you can get inspiration from GarnetNetwork::functionalWrite to implement GarnetNetwork::functionalRead. It will likely consist in walking your way down to each component in the network that might contain a chunk of data, i.e. a Ruby message. I believe that implementing and calling functionalRead wherever functionalWrite is currently called in Garnet will cut it. Finally, note that depending on whether you use CHI or another protocol, you will need two versions of functional read. With CHI, the default protocol, you must override Network::functionalRead(Packet *pkt, WriteMask& mask). With other protocols, you must override Network::functionalRead(Packet *pkt). Mostly copy pasting involved in both cases. You can also use fs.py and you should be fine ;) Also note that --caches and --l2caches are inhibited by --ruby as you cannot use the classic caches (--caches and --l2cache) and Ruby (--ruby) at the same time. Good luck with your experiments, Gabriel _______________________________________________ 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
