I will review the guidelines and then send out a diff for review in the next few days. You can then give some feedback.
Best, -Rick Ali Saidi wrote: > Assuming that it meets the M5 style guidelines I think that it sounds > very useful to me. > > Thanks, > Ali > > On May 1, 2009, at 6:49 PM, Rick Strong wrote: > > >> Hi all, >> >> I created this tool that extended MemTest to work with L1 caches in >> a fullsystem model. The idea is that you keep devices that forward >> requests to and from the L1 cpu-side cache and it keeps track of all >> memory accesses with a funcmem blog that has zero latency. It also >> schedules a timeout for each memory accesses to detect deadlocks. I >> found it useful in debugging my directory coherence. The great thing >> is >> that it makes no assumption of the memory coherency model and it can >> be >> plugged into either fullsys or syscall mode. I have the features >> below. >> If there is interest in this tool, please let me know and I can get it >> into m5dev. >> >> Thanks, >> -Rick >> >> Features or insane rambling: >> >> * MemDebugger creation >> o Device inserts on cpu-side of L1 cache. >> + Supports cpu and bus on other side >> # Use for CPUS and IOBUS >> o Forwards all requests between L1cache and CPU and visa- >> versa >> o funcmem >> + Use one shared funcmemory between all funcPorts of >> all >> memtesters to verify reads and writes >> o Verify all reads >> + Uncacheable not tracked, but forwarded >> + StoreConditional only updates blog if extraData is 1 >> + Writes update blob >> + Reads are verified against blob >> # Including functional >> # Did not do atomic >> + CondCompSwap asserts(false) >> # Easy to implement if we need >> o Periodic Updates >> + Perodically warns that a number of successful reads >> have completed >> o Timeout event on all memory accesses >> + 0ns specifies that the timeout should not be used >> + Schedule a timeout event on each memory access unless >> another device unschedules it >> # Provide sentTime, req, and address >> o TODO: >> + You can verify that LLSC don't stomp on each other >> + Do this with a map or LLSC that makes sure only one >> SC >> succeeds at a time >> >> >> _______________________________________________ >> m5-dev mailing list >> [email protected] >> http://m5sim.org/mailman/listinfo/m5-dev >> >> > > _______________________________________________ > m5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/m5-dev > > _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
