mash@mips.COM (John Mashey) (05/23/89)
In article <674@pitstop.West.Sun.COM> (Adrian Cockroft) writes: >A large number of comp.arch readers are interested in embedded >realtime and a large number of SPARC designs are in this category. Can you list for us the realtime designs that are public? (I just haven't kept track). >For them an integer unit is all you need. I take the points about >availability of full chipsets at hign clock rates. Any sensible high-performance SPARC design will use a cache, and so you still need cache control. Some embedded designs seriously want floating-point. Note that getting rid of an MMU will help the parts count, I don't know if it saves much on the cycle time (if the MMU is the critical path, it will; if the cache is on the critical path, it won't.) >John's questions about clones exceeding Sun in SPARC production rates >were interesting, how long did it take for IBM to drop below 50% >of the PC market? What happened to the (uncloned) DEC Rainbow in the meantime? >(The above is not architecture but it is short - don's asbestos Y-fronts.. :-) I don't know the answer to this. However, I observe that this particular analogy must be treated with caution. Note that IBM and Sun have traditionally pursued rather different pricing policies. What certainly makes sense in one case (clone something that is "IBM-priced", and whose software comes almost entirely from 3rd-parties, so you get it when IBM does), does not necessarily make sense when dealing with somebody who tends to price very aggressively, and which controls for much of the key software (regardless of who licensed from). This doesn't say Suns won't be cloned (I suspect they will), but that one cannot take as a given: IBM did PCs, and people cloned them massively. (X) implies Sun does SPARCstations, and people will clone them massively. (Y) (Note: logically, I'm asserting ! (X ==> Y), I'm not asserting !Y.) >On architecture, my OPINION is that there are a lot of good design tems >around and that anyone who wants to build their own processor can >have a lot of implementation freedom while still being SPARC binary >compatible and getting the software base without having to >start from scratch. This is clearly sensible, for example, for somebody like PRISMA, who is doing something usefully different. The point is that different implementations had better have different reasons for existence, not just because anyone "wants to build their own processor". There may be "a lot of good design teams around", but there are NOT a lot of first-class, leading-edge-of-performance, VLSI microprocessor design teams around: as far as I can tell, even huge companies usually don't have more than a couple apiece of such things. >On cost issues, John says: >> Both SPARC and MIPS > need the same speed vanilla SRAMs at the same clock rate, I think, > >I disagree and so do Cypress (who sell SRAMs to MIPS?) MIPS need much >faster SRAMS because of their two phase memory bus at a given clock >rate. We could try to compare the 25MHz 4/330 CPU to a >MIPS based CPU board to settle this. 1) (FACT) We don't use Cypress SRAMs for our caches. 2) (FACT) Here is some data, as you asked; somebody please post a definitive number for the SPARCsystem300: I did a quick ask around, bit none of my usual sources knew. In any case, here are some straight current comparisons: Machine CPU Cycle SRAM Acc.T. M/2000-6 R3000 50ns 25ns SPARCStation1 LSIL 50ns 25ns [I looked at a picture; both cache tags and cache data marked -25s] M/2000-8 R3000 40ns 20ns SPARCsystem300 Cypress 40ns ?? [I couldn't find one to look at] (Note: everyone will benefit from the forthcoming latched SRAMs). 3) (OPINION) One must be careful not to take on faith what ANY competitor says about another, unless they have an exceptional record for care and straightness (and one must still watch them). Alternatively, one needs enough knowledge to know whether something said: a) is plausible. b) is actually true. c) is false. d) is FACTOID, made-up-on-purpose, then propagated as though FACT, in some cases despite the ready availability of correct data. In this case, the assertion sounds plausible (a), and is a clear statement of fact, and hence has a chance of being verified. Whether it is true (b), is yet to be determined. Certainly, the only directly comparble pair (50ns) argues the other direction. I'm not sure whether one would count the difference between 20 and 25ns as "much faster". -- -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