mash@mips.UUCP (John Mashey) (07/25/86)
In article <166@ima.UUCP> johnl@ima.UUCP (John R. Levine) writes: >I'd be interested in hearing from the RISC crowd -- how much to they tune >their designs to the precise technology available today, and how much do >they expect to carry over into their next generation? 1) The carry-over effect has been a major concern of the HP Spectrum folks, in their case, under the term "scalabile architecture", and they are implementing their architecture in at least 3 announced technologies [TTL, NMOS, CMOS]. RIDGEs and Pyramids use TTL, I think. 2) RISCs share a lot of design ideas with Seymour Cray's machines, which have been implemented in various technologies; the GaAs people have a lot of interest in RISC designs [since GaAs chips don't have as many gates available as many less aggressive technologies.] 3) I can't speak for anyone else, but we certainly did a lot of thinking about plausible VLSI technology trends, to make sure that likely changes wouldn't zap us. For example, our chips are designed at 2micron CMOS, but with mask layouts geared for shrink to 1.5 and 1.2microns. 4) As has been observed elsewhere, there have been some recent trends that make VLSI RISC designs intersting. IF these trends turn around and go back, it might not be so interesting; fortunately, I'm not worried: a) Fast, dense, cheap SRAMs ==> cached designs, typical of the higher-performance RISCs. b) Higher pin count packinging ==> needed because RISCs often like higher instruction bandwidth [given the less dense encoding]. In general, a carefully done RISC design should be reasonable to implement in other technologies. It might or might not save effort versus more CISCy designs, but probably won't make it any worse. 5) There are certainly some lessons available: over time, techniques are introduced at the high end, and migrate downward. Thus, if you're building a current microprocessor, you probably look at previous generation minis, and generation-before-that mainframes. If you're thinking ahead, you look at current mainframes for where you might get. (I apologize for any inaccuracies in the dates below; also, don't send me mail complaining that somebody else did it earlier: I just picked especially well-known examples). For example, consider caches: 1968? IBM 360/85: big deal, design not quite optimal, but good stuff 1976 DEC PDP-11/70: big deal to have a minicomputer with a cache, [although I think DG Eclipse had one a year or two earlier], but routine on mainframes by then. 1981-? A few cached micro board designs [like CRDS or MASSCOMP 68K designs]; a few micros with on-chip caches [68020]; routine on minicomputers. 1986- Many cached micro board designs; more micros with substantial dedication of silicon to cache or cache control [Fairchild Clipper, MIPS R2000] TLB-based MMUs follow almost the same trend, with almost the same years for [IBM 360/67; DEC VAX; {80386, Clipper, R2000}]. In any case, it's hard to invent fundamentally new things. What's different now is that heavy use of VLSI sometimes makes for different tradeoffs than for TTL and ECL designs. Fundamentals of memory system design and system partitioning don't really seem to change much, even if the details and design points are different. Anyway, we've certainly worked very hard at near-term and long-term CPU family planning, and I suspect other people have done so also. A good thing about RISC designs is this tendency to leave things out: you get once chance to start from scratch, and then you'd better be upward-compatible. As usual, entropy will always occur, so it helps to start small; that way, you only end up big, not gigantic. -- -john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc> UUCP: {decvax,ucbvax,ihnp4}!decwrl!mips!mash, DDD: 408-720-1700, x253 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086