School of computer science

Georgia Institute of Technology

CS6290HPCA Fall 2009

Overview
This assignment is composed of three parts: Part 1: Complete the memory system. Part 2: Add SMT feature, Part 3(extra credit): Simulation. (part 1 and part 2: 100 points)
Part 1: Complete the memory system

Step 1:
You need to fill the dcache_access function in this assignment. I-cache is still a perfect cache for this assignment

To activate your dcache structure, you must turn off KNOB_PERFECT_DCACHE.
e.g.) ../../../pin -t obj-intel64/sim.so -perfect_dcache 0 -readtrace 1 -- /bin/ls
Note that KNOB_PERFECT_DCACHE should work even after you implement a data cache. Hence, when KNOB_PERFECT_DCACHE value is 1, regardless of data cache size, all the cache access should be cache hit.

The cache has a 64B block size, true LRU and write-through policy. D-cache access latency is set by KNOB_DCACHE_LATENCY. Note that, a load execution cycle is determined by the cache access time not the load operation latency itself. Hence, if there is a cache miss, the processor needs to wait KNOB_MEM_LATENCY cycles. We assume that the cache and the memory have enough read/write ports so all the memory requests can be handled simultaneously. You do not need to differentiate between store and load. Even store miss, the processor cannot retire the store instruction waits until the store miss is completed.

KNOB_DCACHE_SIZE, and KNOB_DCACHE_WAY set the cache configurations. Cache size should use a K-Byte unit

e.g) ../../../pin -t obj-intel64/sim.so -perfect_dcache 0 -dcache_size 1 -dcache_way 4 -readtrace 1 -- /bin/ls
cache size = 1KB, 1024/4/64=4 sets



To provide hints for building a cache, a stand alone cache simulator, cache.cc (inside lab3.tar.gz) is provided. You can design your own cache structure.
Step 2:
You need to implement a MSHR to handle memory latency correctly.
The size of MSHR is determined by KNOB_ROB_SIZE to simplify the problem. (In actual hardware, there will be fewer number of MSHR entries than ROB size.


Summary of how to handle memory instructions

• Step 1: A memory instruction is fetched, decoded, and executed. In the execution stage, it does not do any useful work for memory instructions.
  
• Step 2: In MEM_stage, the instruction checks dcache. (If you already have removed the mem stage, you perform this step 2 in the EX stage.)
• Step 3(cache hit): If a cache hit, the instruction will be moved to the WB stage after KNOB_DCACHE_LATENCY.
• Step 3(cache miss): If a cache miss,
  
• Step 4: the instruction searches MSHR using memory address. If there is a match (i.e., the memory address is the same), the processor records the instruction id into the MSHR entry. The instruction's ready cycle is the same as the ready cycle in the MSHR. (the simulator stores op pointer inside the MSHR entry.)
  When the simulator checks MSHR, it checks cache block address not the actual memory address. Because we always brining the entire cache block.
  
• Step 5: If there is no match in MSHR, the processor creates an entry in the MSHR and sends the memory request into the memory. To simplify the memory system modeling, we assume that the memory request will be serviced KNOB_MEM_LATENCY cycle later. Since we always set the size of MSHR as the size of ROB, there is always a free entry to insert a new request.
  
• Step 6: Every cycle, the simulator checks MSHR and see whether there are ready requests. (i.e. MSHR->ready_cycle > cycle_count). If yes, then all ops in the MSHR entry should broad cast tags. We insert the block into the cache at that moment. After we insert the block into the cache, we free the MSHR entry. The ops in the ready MSHR entry are ready to retire.
  
  
  

Req ID: op->inst_id should be OK to fill out this field.
V: Valid bit of this entry. Valid(true) does not mean the corresponding memory instruction is ready.
MEM addr: memory addresses
Waiting insts IDs: link list or arrays. This should have (op *)
Ready_cycle: the ready cycle when memory request is completed.
Ld or St: indication of load and store.

from op structure
op->ld_vaddr: load address
op->st_vaddr: store address
op->mem_read_size: load memory size
op->mem_write_size: store memory size

 

for (int ii = 0; ii < KNOB_MAX_THREAD_NUM.Value(); ii++) { 
thread_retire_stop[ii] = false; 
}
retired_thread_here = 0; 

for ( traverse rob structure using whatever data structure that you have) { 
 if (op->done  && !thread_retire_stop[op->thread_id] ) {
  // free rob 
  // free op 
  retire_count++; 
  if (retire_count ==KNOB_ISSUE_WIDTH.Value()) { 
    break; 
  }
 } else {
 if ((thread_retire_stop[op->thread_id]==false) {
  retired_thread_here; 
  thread_retire_stop[op->thread_id] = true; 
  }
  if (retired_thread_here > KNOB_MAX_THREAD_NUM.Value()) break; 
 }
}

}

 
if (bp_corr) { 
   bp_corr_predict++;
   bp_corr_predict_thread[op->thread_id] = bp_corr_predict_thread[op->thread_id]+1; 
}

gshare history length: 12
issue width: 4
out of order scheduler
ROB size: 64
scheduler size: 16
cache size, way: 512KB 4 way
Dcache latency: 5 cycles
mem latency: 100 cycles
Use 2 benchmarks: one is very memory intensive and the other is non-memory intensive. (a simple matrix multiplication would use lots of memory operations.)


• Vary the cache size ( 128KB, 512KB, 1MB, and 2MB) and measure the IPC and cache hit ratio. Discuss the performance improvements. Estimate a working set size based on the evaluated four points.
  Where you see a big cache hit ratio increment when you increase the cache size is the estimated working set size.
• Vary rob size from 32, 64, 128, 256, 512, and 1024 and vary the knob_mem_latency from 6, 50, 100 and enable perfect dcache (total 4 test cases). Discuss the rob size effect as we increase cache latency.
  
• Vary scheduler size when rob size is 128. scheduler size 8, 36, 64, 128.
  Discuss the effects of scheduler.
  (Hints, the size of scheduler shouldn't be that much sensitive. Why? )
  
  2-way SMT architecture.
  
  
• For SMT, create 2 benchmarks using 3 traces (trace1+trace2, trace1+trace3, trace2+trace3). Show weighted IPC results.
  weighted ipc = Sigma(i,n) (ipc_smt(i)/ipc_alone(i))/n
  
  
• Classify three traces as memory intensive or not. Discuss the performance impacts.
  
• Discuss branch prediction accuracy effect in SMT. Do you see degradation compared to a single thread running? why or why not?
  
• You could notice that one benchmark finishes much faster than others. Discuss how we should simulate benchmarks to reduce the simulation errors.