Generating Traces and API calls for cache and branch

[amithgopi]

• [x] How the APIs are called and what parameters are used for cache replacement and branch prediction algorithms?
• [ ] Figure out where to get the trace from - tracereader.cc or from respective predictor/cache files. (ooo_model_instr - instruction.h)
• [ ] Find which information to log to CSV file and info is being transformed - Amith.

[amithgopi]

Cache API Call Format

• find: cpu, instr_id, set, current_set, ip, full_addr, type
• update: cpu, set, way, full_addr, ip, victim_addr, type, hit

[amithgopi]

Cache - API calls and Where Info is populated

cache.cc, contains calls to the cache replacement APIs in the form of impl_replacement_update_state(..) (update) and impl_replacement_find_victim(..) (find) which are mapped to the corresponding replacement algorithm when Champsim is configured. This is done via the python script which creates certain .inc files (cache_modules.inc for cache) that map the function to the API call in the algorithms.

In cache.cc, main call to operate() function:

• operate -> operate_writes -> handle_fill, handle_writeback
• operate -> operate_reads -> readlike_hit, readlike_miss (this one does not call any replacement APIs)

Cache APIs are then called from these as follows:

• handle_fill - find
• handle_writeback - update, find
• readlike_hit - update
• filllike_miss - update

The API arguments are populated as:

• cpu, instr_id, ip, full_addr, type directly from PACKET
• cpu is set to NUM_CPUS in block.h declaration of the PACKET class
• victim_addr = 0 and hit = 1 for hits, hit = 0 for miss
• set from get_set(full_addr) function -> shift address and mask -> (address >> OFFSET_BITS) & bitmask(lg2(NUM_SET))
• current_set -> from block variable (vector of BLOCKs) -> get data pointer and index it with set*NUM_WAYS to get eh current set data and then take the address of this
• way from get_way(address, set)
• for update full_addr from BLOCK given by block vector indexed using as block[set * NUM_WAY + way] -> take the address attribute from this BLOCK

NOTES: miss status holding registers (MSHR) - MSHR of type list of PACKET PACKET in block.h - message packet

[amithgopi]

Thoughts on generating Trace for cache

Most of the cache-based info comes as part of the runtime. Hence this most probably cannot be generated directly from the trace. It's better to get this info from one of the cache implementations or use a new implementation to capture the details.

For cache, it's better to map the info of arguments in each of the API calls to separate trace files (one for each call, or with some indicator to which call created which trace). The same process can be repeated for branch predictors. The parameters available as arguments to the API calls to cache or brach impls are limited and changing these would require extensive changes to many of the Champsim internal classes. I would be easier to just go with the ones currently available in the APIs. Although, things that are present in the last call to the API impls can be added easily. (I have not tested this, but this seems easy enough).

Notes on Champsim dynamic config changes

Champsim uses the config file passed by the user to configure the different algorithms used. Using this file the config.sh script creates a file in the inc folder which maps generic function calls in the main code to the correct ones in the user-defined files. The initial script run generates mappings to functions whose implementations are lined when the Makefile (which is also created by the config.sh script) is run. This is where the function declarations created in the .inc files are finally mapped to the ones in the user algorithms.

[amithgopi]

Branch Prediction

Branch prediction APIs are mapped similar to cache to the algorithm implementations in the ooo_cpu_module.inc file generated at config time. Branch prediction APIs are called from the ooo_cpu.cc file which implements the ooo_cpu (O3_CPU) class. There are two general calls to the APIs:

• impl_predict_branch(ip, predicted_target, always_taken, branch_type) in init_instruction
• impl_last_branch_result(ip, target, taken, branch_type) : in init_instruction

In these,

• IP and type come from arch_instr (instance of ooo_model_instr)
• For the last_branch_result API call the branch target and branch taken also come from the arch_instr variable
• For predict_branch the predicted target and always_taken come from a BTB prediction (implemented in btb/basic_btb/basic_btb.cc). These are not used in most branch prediction APIs, at least not in the ones that are present in the Champsim source.