Date: | Mon, 30 Jul 2007 17:53:40 -0400 |
---|---|
From: | "Juyoung Jung" <juyoung.jung@xxxxxxxxx> |
Subject: | [Gems-users] A series of a cache line hit |
Hi Mike, I would like to ask about seemingly weird situation with my modified MESI protocol. For stimulating my design, I authored a sequence of opertions like the below. File <little.trace>: 2 0x61c0 1 LD 2 0x61cc 2 ST 2 0x61c4 3 ST 2 0x61c8 4 ST 2 0x61cc 12 LD 2 0x61c4 13 LD 2 0x61c8 14 LD 2 0x61c0 15 ST 2 0x61cc 16 LD 2 0x61c4 17 LD 2 0x61c8 18 LD 2 0x61cc 19 ST 2 0x61c4 20 ST 2 0x61c8 21 ST As you can see it, I stimulated only processor #2 intending that all of other memory operations except for the first operation will be L1 cache hit. For your reference, I configured 4-way set associative cache, 256B line size, and 1KB L1 size. In addition, I also changed the parameter "g_SEQUENCER_OUTSTANDING_REQUESTS" to 1 instead of 16. Therefore, I think the above operations should be run on processor #2; I tested it with 4 core configuration. When I run it, I found out the unexpected result like the below. The below shows the protocol trace. Note the time 101. The first Load operation from 0x61c0 completes at time 88, and 2nd operation ST to 0x61cc start its execution at 101. As I expected, it makes "cache hit", and thus has 0 miss cycle. Yet, 3rd operation also finished its execution at time 101. I observed the same trace with MOSI_SMP_bcast protocol. Although this little trace is quite a simple, it made me confused. I am worrying if I missed something to set or not. Q: Could you explain why sequencer doesn't increase the simulation time on trace display? Does it mean the processor stuck to time 101? ================================================================ Testing clear stats...Done. Reading trace from file 'little4.trace'... 1 2 -1 Seq Begin > [0x61c0, line 0x61c0] 5 2 0 L1Cache Load NP>IC [0x61c0, line 0x61c0] 9 2 0 L2Cache L1_GETS_Own NP>IE [0x61c0, line 0x61c0] 16 2 0 L2Cache GETS_Own IE>IE [0x61c0, line 0x61c0] 16 0 0 L2Cache Ack_None NP>NP [0x61c0, line 0x61c0] 16 1 0 L2Cache Ack_None NP>NP [0x61c0, line 0x61c0] 16 3 0 L2Cache Ack_None NP>NP [0x61c0, line 0x61c0] 20 2 0 L2Cache Other_Ack IE>IE [0x61c0, line 0x61c0] 1 p: 2 20 2 0 L2Cache Other_Ack IE>IE [0x61c0, line 0x61c0] 1 p: 1 21 2 0 L2Cache Ack_all IE>IE_I [0x61c0, line 0x61c0] 1 p: 0 28 3 0 Directory Fetch I>I [0x61c0, line 0x61c0] 80 2 0 L2Cache Mem_Data IE_I>E [0x61c0, line 0x61c0] 88 2 -1 Seq Done > [0x61c0, line 0x61c0] 87 cycles L2Cache Yes 88 2 0 L1Cache Data IC>C [0x61c0, line 0x61c0] [0x61c0, line 0x61c0]0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ] 101 2 -1 Seq Done > [0x61cc, line 0x61c0] 0 cycles L1Cache Yes 101 2 -1 Seq Done > [0x61c4, line 0x61c0] 0 cycles L1Cache Yes 101 2 -1 Seq Done > [0x61c8, line 0x61c0] 0 cycles L1Cache Yes 101 2 -1 Seq Done > [0x61cc, line 0x61c0] 0 cycles L1Cache Yes 101 2 -1 Seq Done > [0x61c4, line 0x61c0] 0 cycles L1Cache Yes 101 2 -1 Seq Done > [0x61c8, line 0x61c0] 0 cycles L1Cache Yes 101 2 -1 Seq Done > [0x61c0, line 0x61c0] 0 cycles L1Cache Yes 101 2 -1 Seq Done > [0x61cc, line 0x61c0] 0 cycles L1Cache Yes 101 2 -1 Seq Done > [0x61c4, line 0x61c0] 0 cycles L1Cache Yes 101 2 -1 Seq Done > [0x61c8, line 0x61c0] 0 cycles L1Cache Yes 101 2 -1 Seq Done > [0x61cc, line 0x61c0] 0 cycles L1Cache Yes 101 2 -1 Seq Done > [0x61c4, line 0x61c0] 0 cycles L1Cache Yes 101 2 -1 Seq Done > [0x61c8, line 0x61c0] 0 cycles L1Cache Yes Thank you. - Young |
[← Prev in Thread] | Current Thread | [Next in Thread→] |
---|---|---|
|
Previous by Date: | Re: [Gems-users] profile misses in L1 cache controller, Mike Marty |
---|---|
Next by Date: | Re: [Gems-users] A series of a cache line hit, Mike Marty |
Previous by Thread: | Re: [Gems-users] A new Topology, Mike Marty |
Next by Thread: | Re: [Gems-users] A series of a cache line hit, Mike Marty |
Indexes: | [Date] [Thread] |