Re: on chip RAM
- To: misc
- Subject: Re: on chip RAM
- From: Wayne Steven MORELLINI - Wayne <WAYNEM@xxxxxxxxxxxxxxxxxxxxxxx>
- Date: Fri, 21 Mar 1997 02:21:21 +0000
- Organization: Halls of Residence, Monash U.
- Priority: normal
------- 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.