MISC-d Digest V97 #9
- To: misc
- Subject: MISC-d Digest V97 #9
- From: Wayne Steven MORELLINI - Wayne <WAYNEM@xxxxxxxxxxxxxxxxxxxxxxx>
- Date: Fri, 21 Mar 1997 13:11:07 +0000
- Organization: Halls of Residence, Monash U.
- Priority: normal
From: jfox@dnai.com (Jeff Fox)
Dear MISC readers:
[snip]
Sorry I missed one of the questions...
>From: houghtoa@oclc.org (Houghton,Andrew)
>Has Chuck given any thought to providing a RAMBUS interface to memory
>on his chips?
Yes he has considered this and other memory options. He has been pretty
conservative in his concern about which memories will be avialable and
at what price when the chips he designs will be in production. He had
some concern about designing for designs that get hype if he is not
convinced that they will actually be available and cheap when a cpu
design is finished. These things are hard to predict.
One memory option I beleive is very good is the NeoMagic concept.
***********************************
They produce a SVGA chip with 1mb internal memory on a seperate die
going out to a PCI bus. I have asked them for information (they were
reluctant to say anything) and asked if the design was available for
another design to be inserted (P32 being my intention) of course the
reaction was no. Mitishbitu (whatever) has a Risc design with 1 mb
memory onboard, the chip is going Java and will include multimedia
functions. These two designs offer possibilities. I have also found
out the internal bandwidth of the Neomagic chip (it came up in an
article) 400Mb/s at a 128-bit bus width, oh well 100mhz op anyway at
32-bits (hey thats not to bad).
Wayne.
************************************
From: lowry@htc.honeywell.com (Dave Lowry)
I think Jeff Fox deserves some public thanks for the *free* P21 support
he's giving on this mailing list.
As far as I know he doesn't make a nickel from P21 sales, and has only
the satisfaction of paying for F21 fab runs out-of-pocket as renumeration.
:-)
***********************************
Yes, thanks Jeff, you have been doing a marvelous job.
I wish we heard more from Mr Ting.
***********************************
-Dave
Date: Fri, 21 Mar 1997 02:21:21 +0000
From: Wayne Steven MORELLINI - Wayne <WAYNEM@halls1.cc.monash.edu.au>
To: misc
Subject: Re: on chip RAM
Message-id: <340D1E55FF7@halls1.cc.monash.edu.au>
------- Forwarded Message Follows -------
From: Self <HALLS1/WAYNEM>
To: Christophe Lavarenne <Christophe.Lavarenne@inria.fr>
Subject: Re: on chip RAM
Date sent: Tue, 18 Mar 1997 21:59:55 AEST-1000
Sorry this was meant for the list but I replied instead of
forwarding.
From the discussion so far, that because of random defects adding on
chip ram will greatly increase the developement cost of a chip, ram
is waiting in the wind.
A suggestion could be that when Chuck submits designs to the foundry
that he could include experimental memory on chip as a seperate
module (being agreed to by the contractor so they don't have any
legal claim to the memory design, of course). This would be a sort
of parrallel developement stratergy. To stop the interruption of
random defects to the main (paid for) design the memory could be
implemented in a seperate (buffered) region possibly with its own
pins to cut interference between the two seperate designs.
Example sectioned off region:
D = Paid Design.
M = Experimental Memory.
In reality the D bit would be semmetrical so the final design can
easily be chopped into chips and shipped.
____________
IDDDDI IMMMI
IDDDDI ----I
IDDDDI------I
IDDDDDDDDDDDI
-------------
> Date sent: Mon, 17 Mar 1997 18:22:35 +0100 (MET)
> From: Christophe Lavarenne <Christophe.Lavarenne@inria.fr>
> To: misc
> Subject: on chip RAM
[snip]
> These figures are very pessimistic, because RAM memory cells will not use as
> much area as the stack memory cells.
>
> Each stack memory cells is composed of 8 transistors:
> - two complementary transistors for each of the two inverters
> - two complementary pass transistors for each of the two bus connections
> (one "write=push" bus is driven by the S -resp. R- register to write it into
> the cell pointed to by the data -resp. return- stack pointer, and one
> "read=pop" bus is driven by the neighbour cell, also currently pointed to by
> the stack pointer, to read it into S -resp. R-)
> These transistors, sized for fast register transfers, are bigger than the
> smallest transistor allowed by the process.
>
> The pitch of stack memory cells is fixed by the surrounding circuits:
> - horizontally, the pitch is mainly determined by the ALU bit slice width
> - vertically, the pitch is mainly determined by the drivers of the lines
> controlling the 4 pass transistors of the push/pop bus connections.
>
> These pitch constraints do not need to be propagated to a RAM array.
>
> The third metal layer, presently unused by Chuck, may lead to a denser layout.
> Stackable vias, unavailable in the current .8 micron process, but available in
> most smaller .5 and .35 processes, will save a lot of silicon area.
> Denser layouts imply shorter wires, smaller impedances, and faster switching.
>
> The transistors may be of minimal size, leading to slower access than with the
> stacks, but much faster than with external memory, which must be routed through
> the pads and the inter-chip wires, which altogether have an impedance orders of
> magnitudes higher than the on-chip buses.
Yes the Memory on chip would only have to be 4* slower than the
processor in the Mup21 and 8 times times slower in the P32 to
archieve the full Mips of the processor. (4 or 8 instructions per
memory location). So there is a bit of room here.
>
> SRAM cells may be made even smaller, although slower, with fewer transistors
> (6 or even 5) and only one read/write bus.
> DRAM cells require a minimum of one transistor, but must be refreshed.
>
> In both cases, memory cells may be organized in larger rows (4 or 8 words wide)
> to factor the address decoder and drivers, and reduce the silicon area needed
> for them, again at the price of slower access due to an added pass transistor.
>
> Altogether, Chuck estimated that he should be able to add around 20 Kbits of
> DRAM on-chip. Even half of that would be great. It still has to be done.
Well that would be enough for a self contained application like a
vector graphics driver.
I am going on a hunch here, but Chuck mentioned using capacitance of
the lines for his designs, might there be some way to use
that as memory Chuck ? Random access memory 4 times slower will do
the job.
Does Chuck keep a record of his work and techniques in case anything
goes wrong Jeff?
Wayne.
------------------------------
Date: Thu, 20 Mar 1997 13:56:45 -0500 (EST)
From: Penio Penev <penev@venezia>
To: MISC
cc: misc
Subject: Re: on chip RAM
Message-ID: <Pine.SGI.3.96.970320135313.12608A-100000@venezia.rockefeller.edu>
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Fri, 21 Mar 1997, Wayne Steven MORELLINI - Wayne wrote:
> Yes the Memory on chip would only have to be 4* slower than the
> processor in the Mup21 and 8 times times slower in the P32 to
> archieve the full Mips of the processor. (4 or 8 instructions per
> memory location). So there is a bit of room here.
4x5=20 6x5=30.
*********************************
hmm, your right I'm being two byte oriented :)
*********************************
> Does Chuck keep a record of his work and techniques in case anything
> goes wrong Jeff?
You mean, does iTV hold insurance policies for a couple of $M angainst
something going wrong with Chuck? That would be investors money well
spent :-)
*********************************
Well I meant do he have records of how things work etc, so that
somebody else can fill in for him (I don't think any of us would like
anything to happen to Chuck).
Wayne.
*********************************
- - Penio Penev
<Penev@pisa.Rockefeller.edu> 1- 212- 327- 7423
--------------------------------
End of MISC-d Digest V97 Issue #9
*********************************
