1/1

|
Two-way implementation idea
by Unknown on Sep 20, 2004 |
Not available! | ||
|
Not being well-educated in the specifics of hardware design I do
not know if the following is sensible/practical.
In implementing a 2-way set-associative cache and TLBs, might one
have the physical address of TLB way 0 be compared with the tag
of cache way 0 in parallel with the comparison of the TLB virtual
address and the virtual address of the access and likewise with
TLB way 1 and cache way 1? This would seem to allow an early
determination of which cache way _might_ be a hit. Only one
additional comparison might be necessary to determine a hit (when
one TLB hits but does not match the corresponding cache way tag).
(This obviously could be extended to N-way associative TLBs with
a linear increase in the number of comparisons needed for the
initial phase. A more associative cache could be implemented by
using a prediction mechanism to decrease the number of speculated
ways to two or by using allocation restrictions such that certain
TLB entries can only hold pages with data mappable into certain
cache ways.)
This scheme obviously trades power, area, and complexity for
speed (doing the virtual address comparison in parallel with the
physical address comparison). Only comparing some of the least
significant physical address bits initially to select the way
might reduce power and area costs at modest complexity and
performance cost (one could get some false intial-check hits when
the LSbs are the same in both ways).
Paul A. Clayton
just a technophile
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.opencores.org/forums/openrisc/attachments/20040920/43edf635/attachment.htm
|
|||
1/1

