Re: Memory map with "holes"... (slightly off-topic)

3 messages, 3 authors, 2003-08-13 · open the first message on its own page

Re: Memory map with "holes"... (slightly off-topic)

From: David Jander <hidden>
Date: 2003-08-13 08:36:14

Hi Conn,

Thank you for the tip. AFAICS, you plan on using the only two 32-bit wide
chips available in the same package from Micron. Fortunately, these have the
same size of columns, and that makes things easy.
At first we thought this trick wouldn't work with our design, since we plan on
designing for 4 different 16-bit wide chips in TSOP-54 housing, using always
2 of them to get a 32-bit bus. The reason: TSOP-54, 16-bit wide chips seem to
be one of the most popular formats out there, used by most important SDRAM
manufacturers, and for us it is vital to ensure we always get second sources
for several years to come. The Micron types are MT48LC4M16A2 for the
smallest, and 8M16, 16M16 up to 32M16 types. The problem is, that for these 4
types you get 3 different column sizes and 2 different row sizes. Dealing
with 3 different column sizes makes things a little tricky, but it is
possible, and after playing around a little bit, we got to the following
solution:
SDRAM A[9:0] are connected straight to CPU A[20:29] and are muxed.
SDRAM A10 connected to GPL0 that will be programmed to work as either A11 (for
the 4M16 types), A10 (for the 8M16 and 16M16) or A5 (for the 32M16).
SDRAM A11 connected to either A10 (for 4M16) or A7 (for the rest) selectable
via two 0-Ohm resistors (place one or the other).
Finally SDRAM A12 connects to CPU A6 and the bank select lines BA0 and BA1 go
to CPU A9 and A8 respectively.
You'll get half crazy checking this, but I believe it must work, it uses only
one CS line (certainly not CS0, sorry for the mistake, Wolfgang ;-), and
makes linux happy with one contiguous block of RAM always.

Sincerely,

--
David Jander
Protonic Holland.
tel.: +31 (0) 229 212928
fax.: +31 (0) 229 210930
Factorij 36 / 1628 AL Zwaag

On Tuesday 12 August 2003 19:02, you wrote:
 It is possible to design a system to accomidate larger ram chips for
future expansion with out leaving holes in your memory map. We did
this on our ESTeem 192E. What you need to do is design your memory
system around the samllest chip in the memory family you intend
to use. connect the bank selects lines to the address immediately
following the highest address line used by the smallest memory part.
Then following the bank selects place the other address lines to the
larger memory parts

This is how we did ours ( and it works with the larger parts )

We designed our board using a Micron part MT48LC2M32B2. But we
decieded to include an extra clock cycle so we could use other
manufacturers parts, Such as Toshiba TC59S6432CFT and Samsung
K4S643232C(not tested)

Micron has said that they will make a bigger parts in the same foot
print.

This is how we hooked up our ram to make provisions for the larger
parts. (Note that the two additional address lines have an * next to
them)

MPC850                    SDRAM
=============================
A29                        A0
A28                        A1
A27                        A2
A26                        A3
A25                        A4
A24                        A5
A23                        A6
A22                        A7
A13                        A8
A12                        A9
GPL_A0                     A10
*A8                        A11 (pin 71)
*A7                        A12 (pin 69)
A10                        BA0
A9                         BA1
OE_GPL_A1                  RAS
GPL_A2                     CAS
GPL_A3                     WE

This design will probably work with little modification on all of the
MPC860 family.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Shall I use which IRQ as input parameter of this function?

From: John Zhou <hidden>
Date: 2002-02-15 07:31:53

Dear all,

I have a device with interrupt pin connecting to MPC8250's IRQ0( nonmaskable interrupter ),  when I use function " request_8xxirq( IRQx, tem_interrupt, 0, "temp", dev) " to register IRQ, but I only find SIU_INT_IRQ1-SIU_INT_IRQ7 in file <asm/irq.h> and can't find SIU_INT_IRQ0.  Shall I use which IRQ as input parameter of this function?

Thanks in advance!
John Zhou

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Memory map with "holes"... (slightly off-topic)

From: Conn Clark <hidden>
Date: 2003-08-13 17:01:27

Hi David,

	I'm glad to see you get the general principal behind the trick. I was
afraid I was going to get mailed data sheets and asked to design it for
you (Note: this has happened). I didn't know you pland on using chips
with differing column sizes, however you have seem to found a solution
to make it work. My hat off to you.

	Now the real challenge begins trying to program the UPM and figuring
out how to detect which memory config you have. I pretty sure that
variable columns will require different UPM programmings. Figguring out
the UPM was the toughest part of the design for us. A good BDM/JTAG
debugger is worth its weight in gold for this. A nice logic analyzer
wouldn't hurt either.

Good Luck,

	Conn
PS.

	Actauly in our design we planned on using different three chips sizes,
its just the largest isn't being built yet. We also found 4 other
manufacturers that made drop in replacements for the MT48LC2M32B2. The
only difference is they just had a higher CS latency and a slightly
diffent but compatible mode register programing sequence.

David Jander wrote:
Thank you for the tip. AFAICS, you plan on using the only two 32-bit
wide chips available in the same package from Micron. Fortunately,
these have the same size of columns, and that makes things easy. At
first we thought this trick wouldn't work with our design, since
we plan on designing for 4 different 16-bit wide chips in TSOP-54
housing, using always 2 of them to get a 32-bit bus. The reason:
TSOP-54, 16-bit wide chips seem to be one of the most popular formats
out there, used by most important SDRAM manufacturers, and for us it
is vital to ensure we always get second sources for several years
to come. The Micron types are MT48LC4M16A2 for the smallest, and
8M16, 16M16 up to 32M16 types. The problem is, that for these 4
types you get 3 different column sizes and 2 different row sizes.
Dealing with 3 different column sizes makes things a little tricky,
but it is possible, and after playing around a little bit, we got
to the following solution: SDRAM A[9:0] are connected straight to
CPU A[20:29] and are muxed. SDRAM A10 connected to GPL0 that will be
programmed to work as either A11 (for the 4M16 types), A10 (for the
8M16 and 16M16) or A5 (for the 32M16). SDRAM A11 connected to either
A10 (for 4M16) or A7 (for the rest) selectable via two 0-Ohm resistors
(place one or the other). Finally SDRAM A12 connects to CPU A6 and the
bank select lines BA0 and BA1 go to CPU A9 and A8 respectively. You'll
get half crazy checking this, but I believe it must work, it uses only
one CS line (certainly not CS0, sorry for the mistake, Wolfgang ;-),
and makes linux happy with one contiguous block of RAM always.
--

*****************************************************************
   If you live at home long enough, your parents will move out.
  (Warning they may try to sell their house out from under you.)
*****************************************************************

Conn Clark
Engineering Stooge				clark@esteem.com
Electronic Systems Technology Inc.		www.esteem.com

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help