two way set associative cache referencing using lru - caching

I am trying to understand how caching works. I am working on a problem to better understand this concept:
Given a 2 way set associative cache with blocks 1 word in length, with the total size being 16 words of length 32-bits, is initially empty, and uses the least recently used replacement strategy. Show whether the following addresses hit or miss and list the final contents of the cache.
Addresses:
00010001
01101011
00111111
01001000
00011001
01000010
10001001
00000000
01001000
00011100
00110000
11111100
00111010
First off, with the given information, it seems to me that there will be 2 offset bits, 3 set bits, and 3 tag bits in the following order (T=tag,S=set,O=offset): TTTSSSOO
Example (address 1):
Tag=000 (0), Set = 100 (4), Offset = 01 (1)
Now, assuming this is correct, the following should happen when the above addresses are looked up:
Miss, stored in set 4, block 0
Miss, stored in set 2, block 0
Miss, stored in set 7, block 0
Miss, stored in set 2, block 1
Miss, stored in set 6, block 0
Miss, stored in set 0, block 0
Miss, stored in set 2, block 0 (block 0 was LRU, now block 1 becomes LRU)
Miss, stored in set 0, block 1
Hits on set 2, block 1
Miss, stored in set 7, block 1
Miss, stored in set 6, block 1
Miss, stored in set 7, block 0 (block 0 was LRU, now block 1 becomes LRU)
Miss, stored in set 6, block 0 (block 0 was LRU, now block 1 becomes LRU)
And the final contents of the cache should look like the following:
Set 0: 01000010, 00000000
Set 1: empty, empty
Set 2: 10001001, 01001000
Set 3: empty, empty
Set 4: 00010001, empty
Set 5: empty, empty
Set 6: 00111010, 00110000
Set 7: 11111100, 00011100
I am having a very difficult time with this so hopefully someone can let me know if I am on the right track or not. If these look ok, I want to try the same exercise but with different addresses for further practice, to make sure that I've got it.
EDIT1: New addresses.
000_100_01
000_010_01
000_001_10
000_001_01
001_010_11
000_001_00
000_010_11
000_010_01
001_110_00
000_100_11
000_000_01
000_101_11
011_010_11
Which should like:
Miss, stored in set 4 block 0
Miss, stored in set 2 block 0
Miss, stored in set 1 block 0
Miss, stored in set 1 block 1, block 0 becomes LRU
Miss, stored in set 2 block 1, block 0 becomes LRU
Miss, stored in set 1 block 0, block 1 becomes LRU
Miss, stored in set 2 block 0, block 1 becomes LRU
Hit, set 2 block 0 becomes LRU
Miss, stored in set 6 block 0
Miss, stored in set 4 block 1
Miss, stored in set 0 block 0
Miss, stored in set 5 block 0
Miss, stored in set 2 block 0, block 1 becomes LRU

Related

Direct mapped cache example

i am really confused on the topic Direct Mapped Cache i've been looking around for an example with a good explanation and it's making me more confused then ever.
For example: I have
2048 byte memory
64 byte big cache
8 byte cache lines
with direct mapped cache how do i determine the 'LINE' 'TAG' and "Byte offset'?
i believe that the total number of addressing bits is 11 bits because 2048 = 2^11
2048/64 = 2^5 = 32 blocks (0 to 31) (5bits needed) (tag)
64/8 = 8 = 2^3 = 3 bits for the index
8 byte cache lines = 2^3 which means i need 3 bits for the byte offset
so the addres would be like this: 5 for the tag, 3 for the index and 3 for the byte offset
Do i have this figured out correctly?
Do i figured out correctly? YES
Explanation
1) Main memmory size is 2048 bytes = 211. So you need 11 bits to address a byte (If your word size is 1 byte) [word = smallest individual unit that will be accessed with the address]
2) You can calculating tag bits in direct mapping by doing (main memmory size / cash size). But i will explain a little more about tag bits.
Here the size of a cashe line( which is always same as size of a main memmory block) is 8 bytes. which is 23 bytes. So you need 3 bits to represent a byte within a cashe line. Now you have 8 bits (11 - 3) are remaining in the address.
Now the total number of lines present in the cache is (cashe size / line size) = 26 / 23 = 23
So, you have 3 bits to represent the line in which the your required byte is present.
The number of remaining bits now are 5 (8 - 3).
These 5 bits can be used to represent a tag. :)
3) 3 bit for index. If you were trying to label the number of bits needed to represent a line as index. Yes you are right.
4) 3 bits will be used to access a byte withing a cache line. (8 = 23)
So,
11 bits total address length = 5 tag bits + 3 bits to represent a line + 3 bits to represent a byte(word) withing a line
Hope there is no confusion now.

Can a 2-way set associative mapping have just one set?

Though unintuitive, can a 2-way set associative mapping have only one set.
For e.g., Cache size 8 bytes, block size 4 bytes and main memory size as 16 bytes. Here the number of cache lines are 2 and given 2 way set associative the set count is only 1. Can I map the 4 blocks (0,1,2 and 3) in the main memory to a 2-way set associative mapping?
If I can, what would be the set index? Since the set size is 1 = 20. is set index always 0. [in CPU OS simulator, it is not throwing any error when I try to set the cache and block size and mapping as 2-way]
Set index will be 0 or no set index. Set associative mapping has set identification algorithm the same as direct mapping which is j mod m, where j is the main memory line and m is the total set count. Here in this case, main memory has 4 main memory lines ( 0, 1, 2 and 3 with each having 4 bytes). Now set count is 1, hence 0 mod 1, 2 mod 1, 3 mod 1 and 4 mod 1 are all 0 which means all blocks will get mapped to Set 0 and within the set 0, the mapping is fully associative. The behaviour and mapping is more like fully associative mapping. hence for a set-associative mapping, a 2-way set associative mapping with 2 cache lines or a 4-way set associative mapping with 4 cache lines etc., behaves like fully associative and set index width is 0.
Generalizing, a K-way set associative mapping with K cache lines only will behave like a fully associative mapping.

FAT filesystem: calculate the size and search a byte

I have this question in an Operating System test:
Given a disk of 1GB with 16KB blocks:
(1) Calculate the size of the File Allocation Table:
My Answer: since there are 2^16 blocks in the disk, we have a table with 2^16 entry, and every entry needs to store 16 bit (since there are 2^16 different blocks, we need 16 bit to identify each of them). So the size is 2^16 times 16 bit = 2^16 x 2^4 = 2^20 bit = 2^17 byte = 128Kb.
(2) Given the following table, indicate in which block are stored the following byte:
-byte 131080 of FileA starting at block 4.
-byte 62230 of FileB starting at block 3.
Entry Content
0 10
1 2
2 0
3 6
4 1
5 8
6 7
7 11
8 12
So FileA is (4) -> (1) -> (2) but the problem is: since every block is 16Kb = 2^4 x 2^10 byte = 2^14 byte = 16384 byte, block 4 contains from 1 to 16384, block 1 contains from 16385 to 32768, and block 2 from 32769 to 49152, where am I supposed to find the byte 131080???
Where is this wrong??

Direct-Mapped Cache Hit & Miss

4-bit address
tag 1-bit
index 2-bit
offset 1-bit
2 bytes per block
4 sets (1 block per set)
I am trying to determine if the following addresses are hits or misses. I am presenting the information I have acquired thus far.
(all credit will be given to stack overflow)
Addresses
14
set 3
v = 0
tag = 1
offset = 0
9
set 0
v = 0
tag = 1
offset = 1
2
set 1
v = 0
tag = 0
offset = 0
6
set 3
v = 1
tag = 0
offset = 0
3
set 1
v = 1
tag = 0
offset = 1
As it's a direct mapped cache, and it has 4 sets, this means that it has a capacity for 4 blocks.
1) Address 14 which in binary is: 1110
Assuming that in the beginning the cache is empty, we got a miss and we store this word on the cache. Tag 1, at set #3.
2) Address 9 which in binary is: 1001
Tag 1 , Set #0, we got a miss. Therefore we store it on set 0.
3) Address 2 in binary; 0010
this block goes on set 1 and it's empty. We got a miss and store it. With the tag 0
4) Address 6 in binary: 0110
As we already have stored a block in set 3, we compare it. As their tags are different Tag 0 != Tag 1 we evict the previous one and we store the new one. Miss
5)Address 3 in binary: 0011
this block goes in set 1 and as we already had a block in set 1 we compare it.
As their tags are equal 0 = 0, we got a HIT.

Cache tag value

In reference to the cache question at the following link :
link
Question is : Using the the series of addresses below, show the hits and misses and final cache contents for a two-way set-associative cache with one-word blocks, 4-byte words, and a total size of 16 words. Assume FIFO replacement.
0, 4, 64, 0, 128, 32, 12, 96, 128, 64
My question is : Why is the tag value set to word address / 8 ?
Thanks.
Short explanation - If the cache holds 16 words total ( = 64 bytes cache, pretty small :), and it's 2-way set associative, then you have 8 sets that are directly mapped by the address. You don't need the set bits to be part of the tag because you've already used them to map to the correct set.
Assuming the access granularity is 1 byte, than you address has 2 LSB bits that map you inside a block (4 bytes), you need to ignore these when accessing the cache since you're reading the full block (the memory unit would then use these 2 bits to give you the exact bytes within the block according to the read size and alignment). So word address = real_address / 4
Now, since you have 8 sets, you use the next 3 bits to map to the correct set.
+--------------------------------------+----------------------+-------------------+
| Tag (bits 5 and above) | Set (bits 2,3,4) | Offset (bits 0,1) |
+--------------------------------------+----------------------+-------------------+
That is, addr 0x0 would map to set 0, addr 0x4 (word addr 0x1) would always sit at set no. 1, no matter what. set 2 would have addr 0x8 (word addr 0x2), set 3 would have addr 0xC (word addr 0x3), ... and so on , until set 7 would be used for addr 0x1C (word addr 0x7).
The next address would simply wrap - addr 0x20 (word addr 0x8) would check bits 2..4 and see they're zeroed, so would map again to set 0, and so on. At this point comes the tag to distinguish between address 0x0, addr 0x20, addr 0x10000, or any other address that maps there (addr % 0x20 == 0, or word_addr % 8 == 0). Since you don't care about the offset inside the line here, and the set bits are already known when you decide to access a given set, the only thing missing that requires storage (aside from the data of course), are the bits above the set bits - this is required (and enough) to determines the line identity in a given set, and to know if a lookup hits or misses. These bits are addr / 0x20 (or addr >> 5), or word_addr / 8 ( = word_addr >> 3)
Note that this means that a tag alone is not enough to identify the line addr, you need tag and set bits to reconstruct that.

Resources