Making this so someone else could reproduce this would be a bit hard, this is ~20 minutes into a 700MB checkpoint with a modified prefetcher. The benchmark is a simpoint from Spec2006's 433.milc.
The general status of the benchmark at the time is the write queue is full and the read queue is relatively empty. I've attached two traces (one with just DRAM flag, one longer with the DRAM + DRAMWR flags). Last 5 activates: 5351655344750: system.physmem: Activate at tick 5351656006000 5351655344750: system.physmem: Activate at tick 5351656024750 5351655344750: system.physmem: Activate at tick 5351656043500 5351655344750: system.physmem: Activate at tick 5351656062250 5351655344750: system.physmem: Activate at tick 5351656042250 // Read activate is actually prior to write's activates The final activate that violated timing came from a read access @ simple_dram.cc:885. For this final access @ 5351655344750, the parameters in the doDRAMAccess() function were.... #4 0x0000000000eb4edc in SimpleDRAM::doDRAMAccess (this=0x3a4a560, dram_pkt=0x2afff940) at build/ARM/mem/simple_dram.cc:885 885 recordActivate(bank.freeAt - tCL - tRCD); //since this is open page, (gdb) print bank.freeAt $22 = 5351656069750 // after being updated on line 879 (gdb) print tCL $23 = 13750 (gdb) print tRCD $24 = 13750 (gdb) print addDelay $25 = 208750 (gdb) print accessLat $26 = 516250 (gdb) print busBusyUntil $27 = 5351656069750 My brain is a bit fried now (witnessed a long and painful prelim), so I'll come back to this tomorrow. I'm guessing its some timing assumption because the final read request packet arrived on the same cycle, just after the stream of write activates were scheduled. On Tue, Apr 23, 2013 at 2:35 AM, Andreas Hansson <[email protected]>wrote: > Hi Mitch, > > Thanks for reporting. Is there an easy way to reproduce this? > > Andreas > > From: Mitch Hayenga <[email protected]> > Reply-To: gem5 users mailing list <[email protected]> > Date: Tuesday, 23 April 2013 01:17 > To: gem5 users mailing list <[email protected]> > Subject: [gem5-users] SimpleDDR3 failing on an assertion with default > parameters > > Hi all, > > I'm running the SimpleDDR3 memory with default parameters and one of my > benchmarks is failing on a panic/sanity check. I was wondering if any knew > of any issues with the default DDR3 parameters or if this sanity check > might be overzealous? > > Here's how I've configured the memory: > physmem = SimpleDDR3(range = AddrRange('1GB'), zero = True) > > Here's the error: > panic: Got 4 activates in window 36250 (5351656042250 - 5351656006000) > which is smaller than 40000 > @ cycle 5351655344750 > [recordActivate:build/ARM/mem/simple_dram.cc, line 830] > Memory Usage: 1796052 KBytes > Program aborted at cycle 5351655344750 > > > I'm generating a trace now to try to diagnose why the number > of activates were not properly limited, but I'm rusty on reading DDR timing > info. > > Thanks for any help. > > -- IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. > > _______________________________________________ > gem5-users mailing list > [email protected] > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >
dram.out
Description: Binary data
dram.out.rw
Description: Binary data
_______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
