First off, I'll point out that functional accesses are useful for debugging as well as syscall emulation and pseudo-ops. Another place you might run into functional accesses (besides m5readfile) would be calls like vtophys that allow you to walk the page tables to do a virtual address translation inside the simulator in FS mode. So from a long-term maintainability and generality perspective, I would urge you to consider just biting the bullet and figuring out how to do functional accesses in the SST memory system. We've already established that it's not going to be high performance or realistic, so something like syncing all the threads, doing the functional access, then restarting the timing simulation might be a reasonable approach.
That said, one of the main reasons for using functional accesses is because the simulator itself can't tolerate the split transaction model that timing mode provides. Another solution would be to add a threading capability within the simulator to enable that. Thus, for example, you could dedicate an internal thread to an operation like m5readfile, then at each simulator memory access, issue the request into the memory system and suspend the thread, then resume it when the response comes back. Neither of these are small tasks. If you're just trying to get some specific limited number of things to work in the short term, Ali's advice is probably better than mine. However, I wanted to point out what I think the "right answers" are from a longer term perspective. Steve On Mon, Oct 14, 2013 at 9:34 AM, Ali Saidi <[email protected]> wrote: > Hi Branden, > > I've been giving thin some thought. If it's just the readfile, one way to > implement this would be to create a new pseduo-op that is more like read > word. and it returns a word in a GP register. It would take longer, but in > this way the application could read 8-bytes from the simulator and write it > with timing accesses. > > The other way I can think of would be to have a op that indicates if the > currently requested operation is complete. While it's not complete it can > poll and that gives the simulator time to do a set of timing accesses. > > Anyone else? > > Thanks, > Ali > > > On Oct 9, 2013, at 10:56 AM, "Moore, Branden James" <[email protected]> > wrote: > > > Hi folks, > > > > I've been working on re-doing the integration between Gem5 and SST. > > > > The basic idea is to have SST provide the memory hierarchy (caches, main > > memory, etc) to processor cores that are provided by Gem5. I've created > > an "External Connector" MemObject that provides a mechanism for SST to > > connect into Gem5, and translate Gem5 Memory Packets to and from SST's > > MemEvent. > > > > Through this mechanism, I've been able to successfully boot Linux on an > > x86 Full-System configuration with SST-provided memory hierarchy. > > > > However, I'm currently running into an issue with the Full-System Pseudo > > Instructions for m5readfile, in that it causes Functional accesses to the > > memory hierarchy, both through the TLB Walker cache, as well as the the > > data cache. Functional accesses don't integrate well with SST, as it is > a > > pure timing based simulation environment. > > > > If I set the system's MemoryMode to Timing (or, alternatively, a new > > mode "External"), then we should avoid Functional accesses all together. > > > > I had previously solved this in our old port with Gem5 for SE mode's > > system call emulation, by causing the instruction pointer not to advance > > until the system call had completed. This was fairly easy in the context > > of system call emulation, but I'm not sure that the same technique would > > work well in the general Pseudo-instruction context. > > > > Does anybody have advice on how we can cleanly get these > > Pseudo-Instruction's functional accesses to switch to Timing-based > > Accesses? > > > > Thanks much, > > > > - Branden > > > > -- > > Branden J. Moore > > > > Sandia National Labs > > (505) 844-0989 > > [email protected] > > > > > > _______________________________________________ > > gem5-dev mailing list > > [email protected] > > http://m5sim.org/mailman/listinfo/gem5-dev > > > > _______________________________________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
