Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.carno.net.au!harbinger.cc.monash.edu.au!nntp.coast.net!news2.acs.oakland.edu!news.tacom.army.mil!news.webspan.net!www.nntp.primenet.com!nntp.primenet.com!cam-news-hub1.bbnplanet.com!news.mathworks.com!uunet!in1.uu.net!delphi.com!usenet From: Jim Nelson <smartsignal@delphi.com> Newsgroups: comp.unix.bsd.freebsd.misc Subject: Re: Why one should buy parity memory for reliability? Date: Mon, 30 Sep 96 09:48:35 -0500 Organization: Delphi (info@delphi.com email, 800-695-4005 voice) Lines: 28 Message-ID: <xlDxUb7.smartsignal@delphi.com> References: <32485B0D.41C6@austin.ibm.com> <52br3d$9s8@flash.noc.best.net> NNTP-Posting-Host: bos1d.delphi.com X-To: Matthew Dillon <dillon@best.com> Matthew Dillon <dillon@best.com> writes: >:>I was involve in designing one of the microcontroller for Motorola, >:>one of the things we left out for the future controller was not >:>I was involve in designing one of the microcontroller for Motorola, >:>one of the things we left out for the future controller was not >:>supporting parity (less pin count). The reasoning was, In the normal The big difference between controllers and larger systems is in the amount of RAM consumed. A typical microcontroller can do its job with a 64KB address space - and the RAM is normally static CMOS - which comprises 5 or 6 fets per bit vs the single fets/bit in DRAM. The difference in memory size - 64KB vs 64MB - i.e., 1000 to 1, is the really big factor. Even a vanishingly small probability of corruption is made probable when multiplied by the number of individual bits in a large array, say 64MB, or 2GB... > Having parity and the dram controller incorporated *into* the > microcontroller or cpu is the way to go, removing the requirement for > external buffers or muxes and reducing the pin count while at the same > time supporting page mode, burst read, and interleaved dram > subsystems... even wider data busses. Couple that with I/O, a *real* > cpu core, and at *least* an instruction cache, and you have a hot product. That's a different market from the microcontroller market. Sounds great, but microcontrollers aimed at low-power environments don't use DRAM because of the refresh requirement. Maybe what you need is a new name for the solution.