andy@pcsbst.UUCP (Andre Wolper) (04/11/88)
In article <3347@omepd> mcg@iwarpo3.UUCP (Steve McGeady) writes: > >Three weeks ago I posted an article with the above title, asking, among >other things, that we discuss in this group a broader range of issues >[stuff deleted] > Alright then, since I've spent the last few months thinking about MIPSco, here an attempt at a set of comprehensive info in response to Steve's questions: (I'm just learning my way around the net, so please endure with me if I screwed up somewhere) > 1) Who manufactures MIPSco's silicon?, with details. Until now and for the near future, Sierra Semiconductor & Toshiba were/are the foundry producing the R2000. MIPSco has their silicon manufactured there and resells it to their customers. IDT, Performace Semi., and LSI have signed on to 'volume' produce the R2000 & support chips in the future. Part of the agreement stipulates that MIPSco will leave the Component OEM business as soon as volume capacity is in place at the partners. It appears, though, that due to the the new R3000, these Partners are now more interested in starting their production with the R3000 (which, with different bonding and package, will continue to drop into R2000 sockets), and will never manufacture the R2000. IDT is so far the first and only company that has actually approached me about selling chips to us; I'm still waiting to hear from Performance & LSI personally. > 2) How does MIPSco keep apace of silicon technology? The above three manufacturers are more than a silicon foundry, and have decent process technologies. They are eager to expand their product spectrum, and this desire mates well with MIPSco's desires. As a side note, and from what I can tell, MIPSco is primarily interested in selling systems. You only sell systems when you have application software, and you only have lots of application software for a given architecture when lots of people use that architecture. Since architecture is nowadays defined at the chip level, it seems pretty logical what MIPSco has done. The big semi-houses (intel, mot, etc), from my point of view, are too strapped into their existing architectures to make the most performance of today's technology (no stab intented, just the way I see it), as they are very afraid to threaten their own, well selling stuff with a new, incompatible architecture. > 3) What is the availability of compilers, assemblers, debuggers) > on VAXen, SUN's, and PC's? From the performance analysis I've done, I can only agree with John Mashey's statement: 'After all, RISC is half software'. System design is the art of carefully balancing a large number of tradeoffs, and in a system utilizing RISC ideas a *lot* of work goes into the compilers. It's only natural that the company that designs a RISC Processor also furnishes a good compiler to go with it, and that this compiler runs on their own machine. To me, there seems nothing captive about this, as I'd imagine that no-one is barred from producing a cross-compiler for the MIPS family of processors (I don't know this for *sure*, though, someone from MIPSco correct me if I'm wrong). My impression is that MIPSco welcomes anything that helps broaden the acceptance of their products, just as any computer manufacturer does. As an example, a large number of compilers for Intel processors are not furnished by Intel, but by independent 3rd parties. Generally, if there is a big enough market, there will be 3rd party suppliers. > 4) What is the complexity of integrating a MIPSCo chip set > into a system? What amount and kind of support HW is needed? > (E.g. memory bus i'face: how wide, deep, long, strong?; cache: how fast, > expensive, hard, necessary?) Our experience has not been accompanied by any extreme pains, so far. We have our own R2000 based System running, and are working with the R3000. The amount of hardware needed is less than with our 68020 (25MHz) design for the equivalent function, as the Cache Control Logic and the MMU are already on the R2000. This is not the case with the SPARC stuff, a big disadvantage in my opinion, especially as the SPARC MMU is not even a standard, off the shelf part, but a discrete implementation in the SUN-4 (and different MMU's mean different System Software). Furthermore, all of the floating point is done in the R2010, again one VLSI chip (vs. 3 in the case of the SUN-4). The Cache interface is similarly not too hardware intensive to implement, as the entire Cache control logic is on-chip. This restricts the options that the System designer has available, of course, but given that one can deal with that it's a snap. For a 16.67 MHz R2000, we use 25nS SRAMs. For comparison, I've used a combination of 25 and 35 nS SRAMS on my last design (20Mhz 80386 based). The memory bus interface consists of a seperate 32bit Address and a 32bit Data Bus. The Addresses for the Instruction and Data Caches, as well as the data of these caches are time multiplexed. The Machine needs a seperate Data and Instruction Cache. Both i-cycles and d-cycles are started one per CLK, out of phase with each other by half a clock, since a RISC processor with a 1 CLK per Instruction cycle time goal needs potentially two words per CLK (one the Instruction, the other an eventual Data access that is caused by an instruction). Data writes go into a four deep FIFO write buffer. If a Cache miss (or write buffer full) occurs, then the processor will stall and present the Main Memory address on the second clock, waiting for the access to complete. If both an i-cycle and a d-cycle miss simultaneouly, the processor will serialize the two 'parallel' accesses to the single main (DRAM) memory (with corresponding performance degradation, of course). With this architecture, and assuming that the throughput rate of 1 CLK per Instruction isn't inhibited by processor internals, and ignoring MMU TLB misses, as well as write buffer overflows, my formula for CLKs Per Instruction has become: CPI = 1+(BCPI*(1-HR)*ML), where BCPI is the average number of Bus Cycles per Instruction (somewhere between 1.0 and 2.0, example 1.4), HR is the Hitrate of an application (example 0.9), and ML is the main memory latency in CPU clocks. This formula estimates the performance degradation that the *memory subsystem* can cause a R2000. (I don't warrant it, of course %-) Divide the MHz rate of the processor by CPI, and you'll arrive at the native MIPS for an application, whatever good that will do you. I hope that this is some useful info in response to the question. > 5) What does it take to make an architecture successful? Oh boy... I don't know. Assuming that successful in this context means 'sell a lot', I'll say this much: the longer I'm around, the more I realize that sexy, well performing technology is only a *small* part of the equation. Good support, a well known name, and *lots* of Application Software are certainly equally or even more important. Hence see side note of Question 2. ****************************** A. Wolper... usual disclaimers PCS GmbH, Munich, West Germany ...!unido!pcsbst!andy ****************************** P.S. Steve, based on your uucp address, you must work close to Dick Hofsheier. Greetings to him!
uday@mips.COM (Robert Redford) (04/14/88)
In article <199@pcsbst.UUCP>, andy@pcsbst.UUCP (Andre Wolper) writes: > From the performance analysis I've done, I can only agree with John Mashey's statement: > > 'After all, RISC is half software'. > RISC is many things to many people. For sales and marketing people, it stands for Revolutionary Improved Speed Computer. The definition, I like the most, stands for- Relegates Important Stuff to Compilers. I forgot the other insightful definitions that the speaker at Stanford gave. ..Uday