Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!ames!sun-barr!newstop!pitstop!jwest From: jwest@pitstop.West.Sun.COM (Jeremy West) Newsgroups: comp.arch Subject: Re: Criteria ... [really: are N designs better than 1?] Message-ID: <686@pitstop.West.Sun.COM> Date: 30 May 89 21:39:06 GMT References: <2368@ogccse.ogc.edu> <1464@cfa.cfa.harvard.EDU> <141@dg.dg.com> Organization: Sun Microsystems, Mt. View, CA Lines: 74 In article , mcg@mipon2.intel.com writes: > In article <674@pitstop.West.Sun.COM> jwest@pitstop.West.Sun.COM (Adrian Cockcroft) writes: > > > >A large number of comp.arch readers are interested in embedded > >realtime and a large number of SPARC designs are in this category. > >For them an integer unit is all you need. > > In this late response I wish to avoid the protracted debate (name-calling?) > currently happening between SPARC and MIPS advocates. Let me say simply > that, as a contended in the embedded processor market (with the Intel 960), > I do not believe that many people are taking SPARC seriously as an embedded > controller. The chips require too much board space and support logic, they > require a cache (almost always out of the question for embedded designs), You do not need a cache if you make your RAM out of SRAMS, you also avoid having to worry about refresh on DRAM's. Note that the 4/110 uses static column or fast page mode DRAM's without a cache also. If you want deterministic response times then caches are also a pain. Cypress publish an evaluation board circuit that uses SRAMs only. > have unpleasant code expansion characteristics, are too expensive, and have > too little development support (e.g. no In-Circuit Emulators) for most > embedded applications. There is a class of realtime applications where you need the fastest thing you can get for a reasonable price. SPARC has a place here. One of the reasons that SPARC is being used is *precisely* that it has a lot of development support in the shape of the Sun4/SPARCstation machines and the development tools that run on them. e.g. dbxtool. In-Circuit Emulators for SPARC are coming. It also has Wind River Systems real-time OS running now and VRTX being ported. > > I suspect that Sun is beginning to attempt to position SPARC in > realtime and embedded markets: a) as a fallback position in case they > don't succeed as thoroughly as they hope in the workstation market; and > b) because the volume of design wins and chip sales in 32-bit embedded > control is (conservatively) 10x the workstation market. > This is the wrong way round, Sun was surprised by the level of interest from realtime embedded systems people and has belatedly made some attempts to service an apparent demand. e.g. making SPARCsim generally available. Most of the push has come from the semiconductor vendors rather than Sun since they have most to gain from selling chips. One thing that has happened is that Sun has trained a group of pre-sales technical support engineers to be SPARC specialists, one for each sales region around the world and we (I am one) can spend some of our time helping people who want to build SPARC systems. Since the engineering people at mountainview are too busy designing to post to comp.arch I'm trying to keep the record straight myself. It is worthwile in that I can try out the things we have been told and get corrections on MIPS from John Mashey etc. BTW do people know about SPARCsim, the SPARC architectural simulator? It lets you simulate a IU/FPU/MMU/IO/Cache/Memory system and run unmodified SPARC binaries on it to see how it performs or to debug device drivers or kernels. The sun4 kernel was up and running on SPARCsim on a Sun3 before any Sun4 hardware existed. All the local SPARC specialists have a copy for demo's. I don't know of any design wins that I can name but one that I know of is doing a high speed signal processing system and has taken advantage of LSI logic's capability to use a SPARC IU as one corner of an ASIC with all the other stuff they want round the edge. The SPARC IU takes about 12000 gates out of a 50000 gate ASIC. This is a neat way to customise the interfaces to remove glue logic. > S. McGeady > Intel Corp. Adrian Cockcroft Sun Cambridge UK TSE sun!sunuk!acockcroft (Borrowing Jerry West's account at Mountain View to get at USENET)