nagel@blanche.ics.uci.edu (Mark Nagel) (03/12/89)
Hi there. I'm in need of some answers to some questions I have about
the MIPS R2000 processor. Specifically, I'm implementing a simulation
of the MIPS for an academic project and I've run into the limitations
of using [Kane] as a reference for this simulation.
My questions pertain to the R2000 pipeline -- what happens to it in
the event of a cache miss? Among other things, how many cycles are
used in fetching a line into the cache in some typical machine X? How
does the delayed load work properly in the event of a cache miss?
From the information in the book and what little I can surmise from
life in general, if a cache miss occurred and it, say, doubled the
length of the MEM pipeline stage (is that what happens?) then the
loaded value can no longer be available to the ALU stage of the
instruction after the load delay slot. This must be incorrect since
there are real live machines out there that must have cache misses :-)
[Kane] implies that there is no fancy interlocking and delaying of the
pipeline, etc., but it also implies there will never be a cache miss
(or at least it never addresses the problem other than mentioning the
D-cache miss status bit).
Could someone please set me straight on this? I'd very much
appreciate it.
Mark Nagel @ UC Irvine, Department of Information and Computer Science
+----------------------------------------+
ARPA: nagel@ics.uci.edu | Six plus six equals fourteen for large |
UUCP: ucbvax!ucivax!nagel | values of six -- Dave Ackerman |mash@mips.COM (John Mashey) (03/13/89)
In article <9060@paris.ics.uci.edu> nagel@ics.uci.edu (Mark Nagel) writes: >My questions pertain to the R2000 pipeline -- what happens to it in >the event of a cache miss? Among other things, how many cycles are >used in fetching a line into the cache in some typical machine X? How >does the delayed load work properly in the event of a cache miss? It's real simple: if you have a cache miss, the main pipeline (but not, for example, the integer multiply/divide or FP units) freezes, while the cache refill is performed, then you have a retry cycle that retries the instruction and then goes on. Because of the freeze, there is no issue of some following instruction having to worry about the data not being there yet. I-cache misses are more complex. R2000s, and R3000s in R2000-mode refill 1 word per cache miss, so that's simple. R3000s may refill multiple words, and if I-streaming is turned on, they attempt to execute as many instructions as they can while doing the refill, in order to help cover the long latency of going across a bus and then refilling a large block. THus, suppose you jump to word W in an N-word block that is a miss: a) Freeze the pipeline. b) Fetch words 0..W-1, without executing anything c) Fetch words W...N-1, executing them until a stream break: stall due to unsatisfied memory request stalls due to pipeline interlocks branches/exceptions A moderately-detailed example (use of R3000 in M/2000 box) can be found in: PROC IEEE Compcon, March 1989, "System Design Using the MIPS R3000/3010 RISC Chipset"), 494-498. And it discusses teh above in some detail. Before you ask, we don't start fetching at W and doing wraparound, because it was more complex, and for these machines, simulation showed it didn't help. Maybe it does help on other designs. There are various other things you can do with multiple-outstanding reads, and for various reasons, we didn't think they really helped much either, at least at the design point where this was aimed. Reasonable designs would include a total latency to memory of 4-6 cycles, to the first word returned (in a tight-coupled design), like a single-board-computer, up to around 10-15 for large-machine designs. Also, if you're doing simulators, you need to think of things like: write-buffer behavior (read-around versus flush-writes and then do read), Page mode DRAMs and related designs, etc. -- -john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc> UUCP: {ames,decwrl,prls,pyramid}!mips!mash OR mash@mips.com DDD: 408-991-0253 or 408-720-1700, x253 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086