Increasing Cache BandWidth

About this offer

1. Pipelined caches A processor's clock cycle can be no shorter than its slowest single step (the critical path). A cache access is one of the slowest steps: decode the index, read the arrays, compare tags, select the data. If the whole access has to fit in one cycle, it limits the clock speed of the entire CPU. The idea: split the cache access into stages Pipelining the cache works like an assembly line. The access is cut into stages, for example index → read → tag compare → data out, with latches between them. Each stage is short, so the clock can be faster. A new access can enter the cache every cycle, while earlier ones are still in later stages. Two things change, and it's important to keep them apart: Bandwidth goes up: more accesses finish per nanosecond, one per (shorter) cycle. Latency does not improve: each access still takes about the same real time, a little more because of latch overhead. Measured in cycles, a hit now takes k cycles instead of 1. 1stage 2stages 3stages 4stages What to notice as you go from 1 to 4 stages: The clock cycle shrinks, from about 2.1 ns to 0.6 ns, so the whole CPU can run faster. Bandwidth more than triples, because a new load starts every cycle. Hit latency in real time rises slightly, from 2.1 ns to 2.4 ns, because each latch adds overhead. Pipelining never makes a single access faster. Hit latency in cycles grows from 1 to 4, which is where the costs come from. 2. Multibanked caches 3. Nonblocking caches

Offer details

Provider

velog

Source

velog-rss

Score

54.38

Confidence

49%