Browse Prior Art Database

Reducing Cache Bus Contention

IP.com Disclosure Number: IPCOM000105138D
Original Publication Date: 1993-Jun-01
Included in the Prior Art Database: 2005-Mar-19
Document File: 2 page(s) / 99K

Publishing Venue

IBM

Related People

Rechtschaffen, R: AUTHOR

Abstract

Within processor design there is much information available that would improve performance but the design does not take advantage of the information. In the case of a common cache bus used for both I-FETCH and Operand access the information available at any given time could reduce the effects of I-FETCH/STORE interaction and reduce the effects of I-FETCH/STORE interaction and reduce the cycles lost because of this contention. Both a next sequential I-FETCH access, and a STORE PUTAWAY access usually do not require a DLAT/DIRECTORY access unless they leave the cache line.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 49% of the total text.

Reducing Cache Bus Contention

      Within processor design there is much information available
that would improve performance but the design does not take advantage
of the information.  In the case of a common cache bus used for both
I-FETCH and Operand access the information available at any given
time could reduce the effects of I-FETCH/STORE interaction and reduce
the effects of I-FETCH/STORE interaction and reduce the cycles lost
because of this contention.  Both a next sequential I-FETCH access,
and a STORE PUTAWAY access usually do not require a DLAT/DIRECTORY
access unless they leave the cache line.  As such the scenario of the
impact of this contention during the interval taken when the
processor performs three I-FETCH for a guessed taken branch
(unconditional/Decode History Table(DHT)directed) can easily be
manipulated to reduce its impact on performance.

      Consider a processor design that does not have a Branch History
Table, BHT, and has a common bus that is used for both I-FETCH ACCESS
and OPERAND ACCESS.  The ability to perform the requisite I-Fetching
for a Branch Taken Group, BTG, is limited to the interval between
taken branches.  The occurrence of Instruction Buffer Empty, IBE is
therefore truly a quality of the BTG.  That is, the state of the
processor before and after the BTG does not materially affect the
occurrence of the IBE with the sole exception of a store activity
from the previous group as preventing the 3 initial I-Fetches for the
BTG.  A taken branch whose target has not been prefetched, in
conjunction with a cache that returns the access with a delay of two
cycles, performs three I-FETCH ACCESSES on behalf of the new stream.
With the exception of the dynamics introduced by cache misses, that
allow additional sequential I-FETCHING, and the action and target
changes of branches, the inevitability of the I-Fetch - Store
interaction is clearly manifest, as cycles lost in the overall
performance, when a STORE TYPE INSTRUCTION is proximate to the end of
a BTG.  Not only will the store interfere with the I-Fetching but, in
a recurrent manner, continue to interfere with I-Fetching precisely
in the same way.

      On certain machines, the interaction between fetching and
stores is exacerbated by the property that a store can hold off a
concurrent fetch for two cycles.  The first cycle involves a
contention for the cache bus wherein the store is given a priority
and in the second cycle the data arrays are unavailable due to the
required separation of lookup and putaway with respect to stores.
For fetches concurrency of access and lookup is permitted by the
expedient of a parallel access to all candidates and a late
selection.  To  partially alleviate this problem the cache arrays can
be interleaved on a QUADWORD basis which would allow those fetches
directed to the alternate bank to processed concurrently with the
other array's putaway action.  Thus the manner of interaction is
worthy of det...