OpenCores
no use no use 1/1 no use no use
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
no use no use 1/1 no use no use
© copyright 1999-2026 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.