am i doing this right for direct mapping cache - caching

I wanted your guys opinion on if I'm doing this the right way.
"how much memory is needed for a 128kb (data) cache with 8 byte blocks and 64 bit address line."
Firstly I would put the data cache in power of 2 so that would be 2^17
Then the same with the 8 byte block which would be 2^3
So number of blocks would be 2^17 / 2^3 = 2^14.
Byte offset is always 2 bits.
Index is 14 bits as we got that earlier.
Would the tag be 32-14-2? =>16bits
so cache size is 2^14(64+16+1) = 1296KB?
(1 was gained because of valid bit field)

Related

How to calculate cache block size from its overhead?

I've being looking for this for a lot of time now (over 3 days) without luck. Maybe one of you guys can tell me how can I solve it.
Consider you have a computer with a 16-bit size address and a byte addressable memory. The cache is 2-way set-associative mapped, write-back policy and a perfect LRU replacement strategy. Cache has an overhead of 4352 bits. What's the size of the block?
Very few resources talk about overhead and the ones I've found only relate it to total cache size. The problem is I only know how to calculate cache size with #blocks or at least with the fields of the address properly defined (which I have not being able to do for this problem since I can't calculate the size of the tag.).
Any help would be appreciated.
So, here's how I read this question:
Overhead bits are the bits that don't count toward the actual data that is being cached.  They are bits that track maintenance state of the cache, and help the cache implement hits, write back, and eviction policy.  To some way of looking at it, if one byte is being cached (8 bits) how many non-data bits are in the cache to help manage that (or at least for all the actual data bits how many non-data/overhead bits are there).
This is mathematical, so I hope I haven't made an error, but even if I have maybe you can see your way through the reasoning.
Let's derive some additional information:
A write-back policy means the cache needs to store "dirty" information for each data block: dirty is 1-bit: yes, dirty -or- no, clean.
For 2-way set associative cache, a "perfect" LRU algorithm is also 1 bit (yes: first block -or- no: second block) but this 1 bit costs per index position (i.e. per line) — not per block as there are two blocks per index.
What we don't know is if there is a valid bit, which would also be per data block, but most caches I see in coursework have the valid bits, so we might assume they have it.
And lastly, there's the tag bits where tag bits are: however many bits are leftover in the address space bits after accounting for index bits and block offset bits.
So, a formula for overhead might be:
overhead in bits = index positions * (1 x LRU bit + block overhead bits)
where block overhead bits = 2 [ways] * (1 x Dirty bit + 1 x Valid bit + tag bits)
We also know that tag bits = address space bits - index bits - block bits
So, we have:
4352 [overhead in bits] = index positions * (1 + 2 * (2 + tag bits))
-and-
tag bits = address space bits - index bits - block offset bits
-and-
index positions = 2index bits
-and-
We also know that the number of tag, index, and block offset bits has to be an integer (no fractions of bits).
So, we can begin to reduce those two formulas by substituting:
4352 = index positions * (1 + 2 * (2 + address space bits - index bits - block bits)
by reduction also then:
4352 = 2index bits * (1 + 2 * (2 + 16 - index bits - block bits)
Solving for block bits we have:
-((4352/2index bits - 1)/2 - 18 + index bits) = block bits
I don't know how to solve this directly mathematically, given the constraint that the variables must be integers, so, instead of solving directly, simply try/search different values:
If index bits is 7 then by this formula, block bits is fractional, so that doesn't work.
If index bits is 9 then by this formula, block bits is fractional, so that doesn't work.
No other values between 0 and 16 result in an integer number of bits, except:
If index bits is 8 then by this formula, block bits is 2, so:
16 = tag bits + 8 + 2, meaning tag bits is 6, index bits is 8, and block offset is 2.
Since block offset is 2 then block size is 22.

Mapping 512KB main memory into 1KB cache homework question

I'm sorry if I made an error in posting this. Please let me know if I need to change anything.
I've received my computer architecture homework back and I missed this question. My professor's explanation didn't make sense to me, and I disagree with what he told me, so I am here asking what you guys think.
Here is the question:
A computer uses 16-bit memory addresses. Main memory is 512KB, and the cache is 1KB with 32B per block. Given each of the following mapping functions, calculate the number of bits in each field of the memory address.
Here is how I worked through the direct mapping part of the problem:
Cache memory: 1KB (2^10), 16-bit memory addresses (1 word = 2B) -> 1024B/2B = 512 words, 16 words per block (32B) -> 512/16 = 32 cache memory blocks.
Main memory: 512 KB (2^19), 16-bit memory addresses (1 word = 2B) -> 524288B/2B = 256K words, 16 words per block (32B) -> 256K/16 = 16384 or 16K main memory blocks.
I understand the word tag as such: 32B per block allows for 16 16-bit memory addresses per block. This (I believe) supports that: 1 word = 16 bits = 2 B -> 32B/2B = 16 words in each block. This equates to 2^4 = 4 bits for determining which word in the block, leaving 12 bits for tag and block bits in the memory address.
Now, in order to map 16K main memory blocks directly into 32 cache memory blocks, there will have to be 512 main memory blocks mapped to each cache memory block. So 512/16K blocks per 1/32 blocks.
Here is where I am confused. Doesn't this require 9 tag bits, as 2^9 = 512 (main memory blocks possibly mapped into one cache memory block)?
For the block bits, which point to a particular block in the cache, this requires 5 bits. 2^5 = 32, blocks in cache memory.
This would require 18 bits in the memory address.
Here is my professor's answer for this question:
2^5 = 32 -> 5 Word bits
(1KB)/(32B) = 32 blocks -> 5 Block bits
16 – 5 – 5 = 6 Tag bits
I did not realize I could simply subtract the required block and word bits to get the tag bits. But it still doesn't make sense to me. 2^6 = 64 blocks per cache block. 64*32 gives 2048. I can't wrap my head around this. Can someone please help?
Okay, the terminology that i learnt is slightly different but the principal should be the same for this explanation.
So cache will have multiple sets (sort of like a cell). And each set will have 1 cache line (containing 1 block of data) or multiple cache lines (each contain 1 block of data) (direct mapping or n-associativity mapping).
In mapping the main memory blocks to the cache, the main memory address (16 bit) is divided into 3 fields: tag, index bits and offset bits. A memory cell is 1 byte and a block is made up of a few cells
Offset bits are used to access the individual bytes of a memory block. Think of it as the offset on top of the block base address to get the byte you want (i assume your memory should be byte-addressable rather than word-addressable as it doesn't make sense to access 2B word as this would be inflexible) And here your prof/textbook call it as word bit. Hence if a block has 32 Bytes, there would be log2(block size) = 5 bits needed to access the individuals cells in the mapped block.
Index bits (in direct mapped cache is called block bits too as the number of set is the same as the number of blocks in the cache) is used to identify which set/cache line/ cache block that the main memory block is mapped to the cache. There are 1KB/32B = 32 cache blocks in the cache. As direct mapping is used, each set contain only 1 cache block and therefore there will be 32 set in this cache. Thus to access the correct set in cache, 5 bits is needed and therefore index bits = 5 bits
Tag is a name to determine if the data block in cache is the correct one we are looking one from the main memory. As the address of main memory is 16 bit and we already know index and offset fields, it is easy to deduce that tag will need 16 - 5 - 5 6 bits. How we determine the tag is not really a concern as the block size and cache size (and hence no. of sets in cache is given here).

Direct Mapped Cache Bits

So Im having trouble understanding some parts to direct mapped caching. I have a byte addressed memory system that has 64KB memory with a 2KB direct-mapped cache. Cache blocks are 32 bytes.
From what I understand and please correct me if i'm wrong, I have 2048B/32B = 64 cache blocks. I need to figure out how many total bits are needed for each cache entry (tag, "dirty" bit, etc).
I believe i'll need 6 index bits (2^6 = 64 (# of blocks))
and 5 offset bits (2^5 = 32 (size of cache block))
Im just having trouble figuring out the rest that are needed.
The bits of a physical address can be split into 3 groups - the least significant group of bits that determine "offset of byte within cache block" and doesn't need to be stored in the tag, the middle group of bits that determine "index of cache block within the cache" and doesn't need to be stored in the tag, and the most significant group of bits that is used to check if the data in the cache is the data you want which must be stored in the tag.
With 64 KiB of physical address space a physical address would have 16 bits; and if your cache is 2048 bytes then (for "direct mapped") the least significant group of bits and the middle group of bits combined must add up to a total of 11 bits. That means the most significant group of bits (which must be stored in the tag) needs to be 5 bits (because 16 bits - 11 bits = 5 bits).
For other bits; you always need something to indicate if the entry is used or empty; if the cache is "write-back" you need a dirty bit but if the cache is "write-through" you don't; if there are multiple CPUs and cache coherency you need more bits for that (e.g. exclusive/shared); and if there's any kind of error detection or correction you need more bits for that (e.g. a "parity bit"). This means the total tag size is at least 6 bits (but may be more).

Find Associativity of this Cache?

Given a Cache with the following characteristics:
Main Memory: 16 bit Address
Cache Size: 256 Bytes
Cache Block Size: 8 Bytes
Cache Tag Size: 11 bits
What is the associativity of this Cache? Is it n-way Associative? If so what is n? Can someone please explain this so I can understand it?
Have a look at this nice illustration.
Here is how it works: Your address size is 16 bits, so you have 16 bits for the tag plus the index plus the offset within a cache block. If we assume that we want to address single bytes in the cache (which is usually the case), we need 3 bits to address 1 byte within a block (since each cache block is 8 = 2^3 bytes). That leaves 16 - 3 - 11 = 2 bytes for the index. With two bytes, we can address 2^2 = 4 different sets. We have 256 / 8 = 32 blocks in the cache (size of the cache / size of one block). Those 32 blocks are split into 4 sets, so each set holds 8 cache blocks. Your cache is thus 8-way associative.

About cache memory size - Getting the number of blocks out of the size and number words per block

This is an example from the book Computer Organization and Architecture by Stallings
The cache can hold 64 Kbytes
Data are transfered between main memory and the cache in blocks of 4 bytes each. This means that the cache is organized as 16K = 2^14 lines of 4 bytes each *.
The main memory has 16M. That is 2^24 words. So 4M blocks of 4 bytes.
My confusion is in the second point. It is said that each block is of 4 bytes that is 4 words of 8 bits so one block is 32 bits = 2^5. Now I want to get the number of blocks in the cache. For that I divide the size of the cache with the size of one block, that is 2^16(64K)/2^5(4bytes) = 2^11 lines of 4 bytes each but the answer is 2^14. What am I doing wrong? Thanks!
Its 64K Bytes so it will be 2^16 Bytes.
You will have to make it to bits so it will be (2^16 * 2^3 bits) / 2^5 bits = 2^14

Resources