baum@Apple.COM (Allen J. Baum) (01/23/91)
[] >In article <PCG.91Jan22172644@odin.cs.aber.ac.uk> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: >On 21 Jan 91 03:46:27 GMT, I said >baum> I couldn't let this pass by. Doubling a register file size slows >baum> down register access a few percent. It may or may not slow down >baum> cycle time-- when register access is in the critical path. > >Conceded, yet maybe you could have let it pass; how useful is it to >consider the case where the register file *isn't* in the critical path? Very. >I mean, register files are typically multiported on *the* critical >internal buses of the machine. The critical buses are not the internal ones, generally, and when they are, they are not the register access ports. >I can only say that it is hard for me to imagine, not being an hardware >designer, relevant cases where the register file is not in the critical >path or does not influence it. I'd like the opinion of someone who has >dealt firsthand with this kind of issue. I think that if there are >relevant cases, they could teach us something. All the information that I have is that this is exactly the case. I have talked to people involved with rather hairy designs, and never has register access been on the critical path. In one of the recent SPARC designs reported at last year's ISSCC, they even did a reg-read/add in a single pipe stage, and if anyone was going to be hurt by register access, it would be a register window machine like SPARC. I have specific examples, but I'll let MIPS & SPARC & AMD designers speak for themselves- they're probably reading this. -- baum@apple.com (408)974-3385 {decwrl,hplabs}!amdahl!apple!baum
mash@mips.COM (John Mashey) (01/24/91)
In article <48369@apple.Apple.COM> baum@apple.UUCP (Allen Baum) writes: >[] >>In article <PCG.91Jan22172644@odin.cs.aber.ac.uk> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: >>On 21 Jan 91 03:46:27 GMT, I said > >>baum> I couldn't let this pass by. Doubling a register file size slows >>baum> down register access a few percent. It may or may not slow down >>baum> cycle time-- when register access is in the critical path. >> >>Conceded, yet maybe you could have let it pass; how useful is it to >>consider the case where the register file *isn't* in the critical path? > >Very. > >>I mean, register files are typically multiported on *the* critical >>internal buses of the machine. > >The critical buses are not the internal ones, generally, and when they >are, they are not the register access ports. > >>I can only say that it is hard for me to imagine, not being an hardware >>designer, relevant cases where the register file is not in the critical >>path or does not influence it. I'd like the opinion of someone who has >>dealt firsthand with this kind of issue. I think that if there are >>relevant cases, they could teach us something. > >All the information that I have is that this is exactly the case. >I have talked to people involved with rather hairy designs, and never >has register access been on the critical path. In one of the recent >SPARC designs reported at last year's ISSCC, they even did a reg-read/add >in a single pipe stage, and if anyone was going to be hurt by register >access, it would be a register window machine like SPARC. According to folks who here who know such things, register access was NOT in the critical path on R3000 or R6000 (or on the ECL SPARC, which had the same register circuit designs). In multiple-chip designs, the critical paths are likely to be things like cache-access times, interaction with separate FPU, doing 2-cycle adds in the FPU, and (always) exception/stall control. In single chip designs, about all that changes are the places where you used to have chip crossings, but don't any more. Of course, this is all relative, i.e., in any ofthe current chips, people try hard to push everywhere. There might be some one thing that is "the" critical path .... but then there are probably many more that are only one gate delay away from it, so you can't be sloppy anywhere. -- -john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc> UUCP: mash@mips.com OR {ames,decwrl,prls,pyramid}!mips!mash DDD: 408-524-7015, 524-8253 or (main number) 408-720-1700 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086
qzhe1@cs.aukuni.ac.nz (Qun Zheng ) (02/05/91)
If register access not in the critical path, cache access must be in. I have never read any detail material about a cache design at functional-unit/near- gate-level detail. I think lots of netters here are specialists on this. Can you give me some clue or information sources? Thanks in advance. I'm currently designing a Mem-Mem architectre as my MSc thesis. It uses cache instead of registers. I doubt that cache may not be able to support 2 reads and 1 write in a single pipeline stage. Any trick to play here? Chuck Q ZHENG Dept CompSci Auckland University New Zealand