In message <15865.60253.501351.350595@whitewater.local>, you write: 

-> >>>>> "Rafal" == Rafal Boni <rafal@attbi.com> writes:
-> 
-> Toru> Um, mystery insolved.  The IDT does not mention about the
-> Toru> secondary cache tag design and how addess coded performed.
-> Toru> RM5200 UM describes the 2ndary cache architecture in defnite
-> Toru> figures.  I can see R5000 SC controlling pin out is identical to
-> Toru> RM527x.  On the other hand, JP version of NEC Vr5000 provides
-> Toru> (very confusing) 2nd cache tag figure which does not match to
-> Toru> RM527x.
-> 
-> Rafal> Unfortunately, what you say about Vr5000 is true of not only
-> Rafal> the Japanese but the English version as well... At some point
-> Rafal> it will come down to just having to write the code and attempt
-> Rafal> to verify that behaviour is sane across both real R5000 and
-> Rafal> Rm527x.
-> 
-> I think you can guess the SC organisation from a couple of
-> things. Firstly, fig 8.5 of the IDT manual shows address bits 35-19
-> from the SysAD bus being stored in the tag RAM. Fig 12.5 of the NEC
-> manual shows bits 35-17 of the physical address in the tag.
-> 
-> In both cases, the tag arrangement would not be sufficient for a
-> virtually indexed cache, since it would allow two virtual addresses
-> that differ only in bits 31-21 mapping to two physical addresses that
-> differ only in bits 16-12, but both using the same cache line and
-> having the same tag value. Hence, a the tags would not uniquely
-> identify virtual addresses for a virtually indexed cache.
-> 
-> The arrangement does allow for a physically indexed cache. (the cache
-> line index guarantees uniqueness of bits 18-5 of the paddr, while the
-> tag would take care of bits 35-19).

Hmm, interesting.  When I went digging for this info originally, I had
almost convinced myself of the fact that it did indeed have to be indexed
physically, not virtually but I now forget on what basis... However, I
was not 100% sure of this.

Your explanation sounds like it nails this issue.. Thanks for the hints;
I'll now have to go find the manuals, and figure out what bits I missed
that you caught 8-)

--rafal

----
Rafal Boni                                              rafal.boni@eDial.com
 PGP key C7D3024C, print EA49 160D F5E4 C46A 9E91  524E 11E0 7133 C7D3 024C