Re: on chip RAM

[Wayne Steven MORELLINI - Wayne <WAYNEM@xxxxxxxxxxxxxxxxxxxxxxx>]

------- 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.