jbush001 / NyuziProcessor

GPGPU microprocessor architecture

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Is there a problem with these lines of code in cache_lru.sv or is it just that I don't understand the algorithm?

wxmwy opened this issue · comments

commented

微信截图_20201010114314

Yeah, I think I see a problem, good catch! I made a little picture to walk through how the code should work: let me know if this makes sense.

image

The LRU flags correspond to branches in the tree structure, with a zero meaning 'go left' and a one meaning 'go right'.

  1. We start at bit 3 of the LRU flags, in the middle. It is one, so we take the right branch.
  2. We then evaluate bit 5. It is zero, so we take the left branch.
  3. Finally, we look at bit 4. It is one, so we take the right branch. This ends us at entry 5.

It appears decoding the LRU for 6 and 7 are also correct.

To move a slot to the MRU, we want to set all of the flags along the path the opposite way. The easiest rule to do this is that: any bits that are ? in the top casez should be passed through (lru_flags) unaltered to update_flags, and any bits that are 1 or 0 in the top should be set to the opposite in update_flags, so:

  • 5 = {lru_flags[6:4], 3'b001, lru_flags[0]}
  • 6 = {lru_flags[6:4], 1'b0, lru_flags[2], 2'b01}
  • 7 = {lru_flags[6:4], 1'b0, lru_flags[2], 2'b00}

In each case, it appears I mentally swapped bits 4 and 5 when updating the lru_flags, probably because I was visualizing walking the tree in my head and wrote the bits in traversal order rather than in strict horizontal order.

Thanks!

commented

Yes, I understand now. Thank you for your reply.