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

Reply via email to