- #1
bremenfallturm
- 81
- 13
- TL;DR
- Something that I can't seem to find a good explanation of online is how the "byte offset" field in the cache address is used practically. In the examples I have seen, it seems to only give different outputs for some of the byte values (only returning a word at a time)
Hi!
Something that I can't seem to find a good explanation of online is how the "byte offset" field in the cache address is used practically.
For example, take this example from the course I am currently taking:
Assume that we have a 32-bit RISCV processor with a direct mapped instruction cache.
Assume further that the number of sets (also called rows) are 16, and the block size is 8
bytes.
Draw the hardware implementation for reading from the instruction cache.
In this example, we have a direct-mapped cache, and this cache has 8 bytes per block. So the number of bits in the byte offset field is ##\log_2(8)=3## bits.
The question asks for a hardware implementation of the cache. While there are 8 bytes stored per block and the byte offset field can take any value from 0 to 8, in the solution key, the byte offset field is wired to a MUX with only two inputs (0 and 1), and we only use bit 2 of the byte offset field in practise. See the screenshot of the solution key below and look at the MUX wired to byte offset, and you'll hopefully see what I mean!
If I read my course book, they have an example (Figure 8.7) where they instead of 8 bytes have a similar direct-mapped cache, but with 4 bytes (1 word in their context) in the data field. Since they have only one word in each block, they say: "the byte offset bits, are ignored for word accesses."
So, even though the byte offset field in theory for a cache storing ##m## bytes of data can take on values ##0,1,...m## caches will generally return the whole word that the passed byte offset is associated with? For example, returning to the question I mentioned in the quote above and the 8 bytes data per block, accessing addresses on byte offsets 0,1,2, and 3 would all return the same data from the cache, it would return the whole least signifcant word stored in the block.
I hope my question is understandable:)
Something that I can't seem to find a good explanation of online is how the "byte offset" field in the cache address is used practically.
For example, take this example from the course I am currently taking:
Assume that we have a 32-bit RISCV processor with a direct mapped instruction cache.
Assume further that the number of sets (also called rows) are 16, and the block size is 8
bytes.
Draw the hardware implementation for reading from the instruction cache.
In this example, we have a direct-mapped cache, and this cache has 8 bytes per block. So the number of bits in the byte offset field is ##\log_2(8)=3## bits.
The question asks for a hardware implementation of the cache. While there are 8 bytes stored per block and the byte offset field can take any value from 0 to 8, in the solution key, the byte offset field is wired to a MUX with only two inputs (0 and 1), and we only use bit 2 of the byte offset field in practise. See the screenshot of the solution key below and look at the MUX wired to byte offset, and you'll hopefully see what I mean!
If I read my course book, they have an example (Figure 8.7) where they instead of 8 bytes have a similar direct-mapped cache, but with 4 bytes (1 word in their context) in the data field. Since they have only one word in each block, they say: "the byte offset bits, are ignored for word accesses."
So, even though the byte offset field in theory for a cache storing ##m## bytes of data can take on values ##0,1,...m## caches will generally return the whole word that the passed byte offset is associated with? For example, returning to the question I mentioned in the quote above and the 8 bytes data per block, accessing addresses on byte offsets 0,1,2, and 3 would all return the same data from the cache, it would return the whole least signifcant word stored in the block.
I hope my question is understandable:)