mcg@omepd (Steven McGeady) (05/05/88)
In article <833@imagine.PAWL.RPI.EDU> jesup@pawl18.pawl.rpi.edu (Randell E. Jesup) writes: >In article <476@pcrat.UUCP> rick@pcrat.UUCP (Rick Richardson) writes: >>I'm still looking for the RISC that does ~4K (C language) Dhrystones, >>has no cache, clocks around 4 Mhz, has a 16 bit bus, can address maybe 1MB, >>is a power miser, can't do floating point, and costs no more than $15. > > Yeah, and what technology is this wonder-chip implemented in??? >Whatever it is, I can think of dozens of Si companies that would give away >all their current facilites for that process. Oh, and I'm not even worrying >about cost. > > Back to reality, it just can't be done, except MAYBE with a state of >the art chip optimized to NOTHING but fast dhrystones (which, by the way, >are a pretty poor predicter for most applications, due to string handling.) >4 Mhz is REAL slow. A 4Mhz rpm-40 would be equivalent to maybe a 14Mhz >68000 (note: not '020). At such slow speeds, CISC chips may well show >superiority due to wanting to maximize the usefulness of every bus cycle. > Mr. Jesup is unnecessarily negative about the prospects of such a machine. With the introduction of the 80960, Intel has made a commitment to building a range of price/performance solutions for real-time and embedded computing systems. The current implementation, the 80960KA, runs at 7-10 MIPS (12-15 Kdhry) at 20 MHz, addresses 2^26 bits of physical memory, has no floating-point, has a 32-bit multiplexed bus, and costs (at introduction, in quantity 100) $174. Now, this is three times the performance and 10x the cost of Mr. Richardson's request, but look more closely. One could: a) run the chip at 16Mhz (or 10, for that matter); b) put 1Mb of relatively inexpensive 2 or 3 wait-state memory on the bus; c) buy the chips in lots of, say, 1,000,000, and expect a healthy discount (I believe this was stated in Mr. Richardson's original article); This would reduce the cost (and performance) of the overall system to the area that Mr. Richardson is investigating. If one was really going to buy chips in large lots. You still have slightly higher support costs because of a 32-bit bus, rather than 16, but that's not such a big deal. As with any piece of silicon, one can expect the price to drop as the part matures, and as quantities rise. Chip price has almost *nothing* directly to do with architecture complexity. It has everything to do with die size, wafer yield, and marketing. Once a particular implementation is released, the die size does not change except by shrinks (which have a desirable side-effect of making the chip run faster, thus drawing a higher price), and then only by 10-20% at a time. Yield is affected by experience with a process and by volume, also not by chip complexity (except as reflect in size). Marketing is marketing. The rate at which recently announced parts will become "commoditized" is left as an exercise to the reader. I suggest looking at the price curves for the 8086 and 68000 as examples, taking into account single- versus multi-source issues. S. McGeady Intel Corp
rick@pcrat.UUCP (Rick Richardson) (05/06/88)
In article <3444@omepd> mcg@iwarpo3.UUCP (Steve McGeady) writes: >Now, this is three times the performance and 10x the cost of Mr. Richardson's >request, but look more closely. One could: > a) run the chip at 16Mhz (or 10, for that matter); > b) put 1Mb of relatively inexpensive 2 or 3 wait-state memory on > the bus; > c) buy the chips in lots of, say, 1,000,000, and expect a healthy > discount (I believe this was stated in Mr. Richardson's original > article); >This would reduce the cost (and performance) of the overall system to the >area that Mr. Richardson is investigating. > >If one was really going to buy chips in large lots. You still have slightly >higher support costs because of a 32-bit bus, rather than 16, but that's >not such a big deal. But: Widgets in plastic boxes don't pass FCC at high clock rates without a lot of layout headaches and extraneous R's and C's. Keep the clock down around 4 Mhz! The bus width is a big deal. We're talking parts count here. Ideally: 1 CPU, 1 RAM, 1 ROM, 1 Glue, and peripheral chips. The 16 bit bus gets the nod only because RAM/ROM requirements exceed current state of the art in RAM/ROM chips. Go beyond 128K ROM and you're talking two chips. Go beyond 32K (static) RAM and you're also talking two chips. I'm looking at a bunch of consumer type applications that have outgrown the 8088 level of CPU performance, and are moving into the 64K to 128K bytes range of RAM, and the 256K to 512K bytes range of ROM. -- Rick Richardson, President, PC Research, Inc. (201) 542-3734 (voice, nights) OR (201) 834-1378 (voice, days) uunet!pcrat!rick (UUCP) rick%pcrat.uucp@uunet.uu.net (INTERNET)