The OR1000 specification doesn't explicitly state that implementations using hardware page walking do not have to implement the TLB match\translate registers. I assume this is just an oversight though, correct?

I guess so.

Any chance you might want to note this as something which should be fixed up in the spec, under the 'Typos/Clarifications' section here: http://opencores.org/or1k/Architecture_Specification

Thanks

By hardware page walking you mean hardware re/loading of the TLB when a TLB miss occurs? How does hardware processing of TLB misses impact the need for match and translate registers?

The TLB match/translate registers provide a means for software to simulate address translations. That being the case, I think they are correctly labeled as mandatory.

Sorry, ignore this question. I still think is is important to have a guaranteed mechanism for software to simulate TLB. In some of the firmware work I've done, the ability to inspect the TLB entries was essential.

The most glaring oversight is the fact that they are not big enough to translate a 50-bit EA for a 64-bit implementation. Forcing an implementation to implement them would also make a CAM based TLB with more than 4 entries impossible to implement properly.

Another thing I noticed is that they cache the user\supervisor executable bits, rather than the PPI bits. This means that any change to the IMMUPR register requires software or hardware to invalidate all TLB entries because it's not possible to determine which entire's permissions have been changed as a result of the write to IMMUPR. This seems to completely ruin any advantage the permission index feature had to begin with.


Overall, I think Chapter 8 is horribly anemic as far as a specification goes. I think this is probably in part due to some of the rather bizarre design decisions made (I'm still looking for an advantage to separate instruction\data page tables). I've thoroughly read the x86\x64 MMU specs and skimmed through the ARM\SPARC MMU specs, and they're much better. I understand all the work on OpenRISC is donated, but I'm pretty disappointed in how many questions I have after reading the chapter.

I am guessing that for 64-bits, you would use the Area Translate Buffer (ATB). The problem is that ATB[VPN] holds 22-bits, but you would only store the most significant 11-bits of the effective address, leaving 11-bits to always be 0---note that I find it confusing that the VPN is used differently in the spec, sometimes it is 19-bits and sometimes it is 23-bits.



You mean more than 4 ways? I agree. The specification also limits the size of each TLB way to 128 entries. These seem like OR1000 design decisions. Before worrying about fully associative TLBs, it would be nice to have an implementation with that wasn't direct mapped.

Maybe there are changes you could propose for the OR2000 to make sure it can work with fully associative, 64-bits TLBs.



Interesting. I guess you could brute force search through all the valid TLB entries and only invalidate entries that match the old protection settings. You could use a CAM on the entry protection bits to do the same in hardware. Would this work?



I would add that Section 8 is also confusing...at least to me. It sounds like with all that experience you would provide some great input to the team working on OR2000.

Many of those sections were written a long time ago and certainly could have used some brushing up over the years.Last time I heard volunteers are still welcome!! :) Then again I haven't done more than lurk around here in a long while.