Cache block tag size | 易学教程

问题

I'm writing a cache simulation program in C on linux using gcc as the compiler and I'm done for the most part. Only a few test cases go wrong (a few things out of the thousands of fed addresses that should be hitting are missing). I specify the cache properties on the command line. I suspect the error within my code has to do with the tag (if things aren't hitting then their tags aren't matching up when they should be). So my question is: Am I calculating the tag right?

//setting sizes of bits
int offsetSize = log2(lineSize);
int indexSize = 0;
if (strcmp(associativity,"direct") == 0){//direct associativity
  indexSize = log2(numLines);
}else if (assocNum == numLines){//fully associative
  indexSize = 0;
}else{//set associative
  indexSize = log2(assocNum);
}

address = (int) strtol(readAddress,&eptr,16);
unsigned long long int mask = 0;

//get the offset Bits
mask = (1 << offsetSize) - 1;
offsetBits = address & mask;

//get the index bits
mask = (1 << (indexSize)) - 1;
mask = mask << offsetSize;
indexBits = (address & mask) >> offsetSize;

//get tag bits
tagBits = address >> (offsetSize+indexSize);

The addresses that are being fed are usually 48 bits, so the variables address and mask is of type unsigned long long int. I think the problem I'm having is that I'm taking all the upper bits of the address, when I should only be taking a small set of bits from the large address.

For example: I have 32 cache lines in a 4-way set associative cache with a block size of 4.

offsetSize = log2(4) = 2

indexSize = log2(4) = 2

My code currently takes the upper bits of the address no matter the address size, minus the last 4 bits. Should I be taking only the upper 28 bits instead? (tagSize = (8*4)-3-2)

回答1:

My code currently takes the upper bits of the address no matter the address size, minus the last 4 bits. Should I be taking only the upper 28 bits instead?

The tag has to contain all upper bits so that the tag can be used to determine if it is or isn't a cache hit.

If addresses are 48-bits and are split into 3 fields, you'd have a 2-bit "offset in cache line" field, a 2-bit "index in cache" field and a 44-bit "upper bits that have to be stored in the tag" field. If you only store 28 bits in the tag then you get cache hits when you should get cache misses (because the entry in the cache happens to contain data for a different address where the 28 bits happened to match).

Note that you can/should think of "associativity" as the number of sets of cache lines that happen to operate in parallel (where direct mapped is just "associativity = 1", and where fully associative is just "associativity = total_cache_size / cache_line_size"). The associativity has no direct effect on the index size (only the size of the sets of cache lines matters for index size), and the problem you're having is probably related to indexSize = log2(assocNum); (which doesn't make sense).

In other words:

    if( direct_mapped ) {
        associativity = 1;
    } else {
        max_associativity = total_cache_size / cache_line_size;
        if( fully_associative || (associativity > max_associativity) ) {
            associativity = max_associativity;
        }
    }

    set_size = total_cache_size / associativity;
    number_of_lines_in_set = set_size / cache_line_size;

    offset_size = log2(cache_line_size);
    index_size = log2(number_of_lines_in_set);
    tag_size = address_size - index_size - offsetSize;

来源：https://stackoverflow.com/questions/53620806/cache-block-tag-size

标签

caching

bit-manipulation