🚀 go-pugleaf

In article <m0fRxlf-0001fDC@mipon2.intel.com>, 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)