SDRAM data garbled due to seperate PCB for SDRAM ???

RusH wrote:

> "Mayank Kaushik" <prehistorictoad2k@yahoo.com> wrote :
> 
> 
>>Hi!
>>
>>
>>>Is the cable wired like this:
>>>pin1 - signal1
>>>pin2 - signal2
>>>pin3 - signal3
>>>pin4 - signal4
>>>(...)
>>
>>Thats the way its wired..bad, huh?
> 
> 
> nice VHF Transmitter you got there :)
> start with replacing this cable with UDMA60/100/133 HDD IDE cable 
> wiring as larwe suggested
> 
> 
>>Er..Nahin,Nope respectively :-( I did inspect the pins on the
>>SDRAM that are fed Vdd and Vss with a multimeter, the level was
>>correct..do u mean the measurement of the capacitance between
>>them..i dont have any experience with these things, some
>>enlightenment would be welcome, im still an undergrad.
> 
> 
> solder decoupling capacitors directly to ram pins
> 
> Pozdrawiam.

And you may still have issues if the ARM part isn't designed to drive 
that long of a line -- the MPC860, for one, gave you a choice between 
drivers or putting the SDRAM right next to the chip -- a driverless 
schematic with long traces or a cable was definitely not in the cards.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Hi everyone,

If the SDRAM chips are on the same board as the CPU, will there still
be a need for decoupling caps on the SDRAM`s power supplies?
Regards
Mayank

In article <1106628696.643138.23700@f14g2000cwb.googlegroups.com>, 
prehistorictoad2k@yahoo.com says...
> Hi everyone,
> 
> If the SDRAM chips are on the same board as the CPU, will there still
> be a need for decoupling caps on the SDRAM`s power supplies?
> Regards
> Mayank


Yes.

--Gene

Mayank Kaushik wrote:

> Hi everyone,
> 
> If the SDRAM chips are on the same board as the CPU, will there still
> be a need for decoupling caps on the SDRAM`s power supplies?
> Regards
> Mayank
> 
Now _this_ calls for a story:

In my misspent youth I worked my way to an MS degree as a teaching 
assistant.  One semester I was in charge of the lab for 4th-year analog 
circuit design (i.e. how to make an op-amp out of two sets of matched 
transistors, some resistors and a capacitor).

As we came to the point where everyone's circuit was going together I 
had occasion to go around the lab making people put in decoupling caps. 
  One intrepid pair insisted that there was no reason for them, their 
use was black magic, and would I please tell them why their circuit was 
oscillating?  I told them that it was good to humor crazy people, and I 
wouldn't help them until I saw the caps.  I came back later to find the 
caps in place, and their circuit happily working.

_Always_ put in decoupling caps.  Every IC on the board should have at 
least one decoupling cap.  Multiple power pins are the IC designer's way 
of telling you the chip needs multiple decoupling caps.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

"Mayank Kaushik" <prehistorictoad2k@yahoo.com> wrote in message
news:1106581955.292822.256260@f14g2000cwb.googlegroups.com...
> Hi,
>
> Im trying to interface two 128Mbit SDRAMs (MT48LC8M16A2) to the
> AT91RM9200, but it doesnt seem to be going right. I have a custom board
> for the AT91, and a seperate board for the SDRAM, the two are connected
> through an ordinary ribbon cable.

Looks like you've had some good replies so far. It also looks like you have
quite a bit to learn about high-speed logic design.

Briefly: look into "transmission lines". A track (or cable) acts as a
transmission line at high frequencies (it has series inductance and parallel
capacitance). If you don't terminate the track correctly at either end,
you'll get reflections - meaning that your nice square edges end up looking
very messy. It's quite common to need to take this into account when bus
signals are on the same board, let alone on different boards connected by
ribbon cables.

Re decoupling: this is fairly fundamental stuff ;). Again, consider that the
power tracks/cables are not perfect. On a change of output, there is a brief
spike of current - needed to inject charge into the track. Decoupling
capacitors ensure this current is delivered locally, rather than via the
inductance of the power track - which would cause a brief dip in the applied
power, probably also affecting plenty of other devices in the neighbourhood.

As I said, this was brief ;).

HTH,

Steve
http://www.fivetrees.com

Steve at fivetrees wrote:
> "Mayank Kaushik" <prehistorictoad2k@yahoo.com> wrote in message
>>
>> Im trying to interface two 128Mbit SDRAMs (MT48LC8M16A2) to the
>> AT91RM9200, but it doesnt seem to be going right. I have a custom
>> board for the AT91, and a seperate board for the SDRAM, the two
>> are connected through an ordinary ribbon cable.
> 
> Looks like you've had some good replies so far. It also looks like
> you have quite a bit to learn about high-speed logic design.
> 
> Briefly: look into "transmission lines". A track (or cable) acts
> as a transmission line at high frequencies (it has series
> inductance and parallel capacitance). If you don't terminate the
> track correctly at either end, you'll get reflections - meaning
> that your nice square edges end up looking very messy. It's quite
> common to need to take this into account when bus signals are on
> the same board, let alone on different boards connected by
> ribbon cables.

Also those signals take perceptible time to travel down those
lines.  You can normally make a guesstimate of 1 nS per foot (3 nS
per meter) for one way travel, and be reasonably close.  So you can
see that even if you have infinitely fast memory at the other end
of a meter of cable, you can't expect to get an answer back in less
than 6 nS.  That has already put a cycling repetition limit of
about 160 Mhz on the system.  In practice the transaction time will
be much greater, and cycling repetition rate much slower.

-- 
"If you want to post a followup via groups.google.com, don't use
 the broken "Reply" link at the bottom of the article.  Click on 
 "show options" at the top of the article, then click on the 
 "Reply" at the bottom of the article headers." - Keith Thompson

Hello everyone,

Thanx for all your replies.

CBFalconer wrote:
>Also those signals take perceptible time to travel down those lines

In accordance with that, i had pared the cable down from 35-45cms
initially to about 15cms, yet i saw no change in the garbled data.
Maybe other factors are having a greater effect.

The decoupling issue is yet to be taken care of, i will look into it
next. I must consult the SDRAM datasheet on this.

Steve wrote:
>If you don't terminate the track correctly at either end,
>you'll get reflections - meaning that your nice square edges end up
looking
>very messy.

Lending credence to the impedence mismatch theory at the cable ends is
the fact that when i try to read the same data a number of times, i get
different values sometimes..perfectly correct sometimes, semi-garbled
sometimes..Would it help to solder the cable ends to the board pins
(not the ram pins)?

>Briefly: look into "transmission lines". A track (or cable) acts as a
>transmission line at high frequencies (it has series inductance and
parallel
>capacitance).
took a course in transmission lines last semester...until now, never
thought it would ever come in handy ;-)

Best regards
Mayank

Mayank Kaushik wrote:
> The master clock of the uC is running at 60Mhz.

A few random thoughts...

Have you tried a *much* slower cycle on your signals, plus adding delays 
between each step (command + clock strobe + MCU input) to let the line 
stabilize?  This SDR chip should tolerate a very slow clock cycle 
(although "stable" is a requirement).

Have you checked with a scope to see if the input rise times are within 
spec at the SDRAM?

Are you certain you've got the CS lines right so only one chip is 
selected during an operation, so they don't conflict?

Once you get past the signal and power issues, try posting code snippets 
for the init, I/O, and refresh (you are refreshing, right?)

Hi Richard,
Richard H. wrote:
> Have you tried a *much* slower cycle on your signals, plus adding
delays
> between each step (command + clock strobe + MCU input) to let the
line
> stabilize?  This SDR chip should tolerate a very slow clock cycle
> (although "stable" is a requirement).
I thought of that. I need the 60Mhz cycle, coz im using the DBGU (debug
unit) on the chip as my sole debugging aid. It needs a bit-rate of
115200bps, for which i need the 60Mhz master clock. I could bring it
down to 1Mhz, i think...il try that. In the USART, each bit would be
sent out at at least one clock edge, and for receiving, the rate should
be double the bit rate..so that puts a cap on the lowest i can go...but
i wonder..hmmm.il check that.

> Have you checked with a scope to see if the input rise times are
within
> spec at the SDRAM?
To Do.

> Are you certain you've got the CS lines right so only one chip is
> selected during an operation, so they don't conflict?
Actually both chips are supposed to be selected at a time, the CS lines
are tied. Each byte is taken care of by masking lines on the chip. Yes,
i have checked them.

> Once you get past the signal and power issues, try posting code
snippets
> for the init, I/O, and refresh (you are refreshing, right?)
Yes, of course :-). This AT91RM9200 has an SDRAM controller that takes
care of all the refreshes after you feed in the proper refresh times.
==============================
Heres the code for that:
(im using Atmel`s libraries)

int i;
int *pSDRAM = (int *)BASE_EBI_CS1_ADDRESS;

//* Configure PIOC as peripheral (D16/D31)
AT91F_SDRC_CfgPIO();

//* Setup MEMC to support CS1=SDRAM
AT91C_BASE_EBI->EBI_CSA |= AT91C_EBI_CS1A;
AT91C_BASE_EBI->EBI_CFGR = 0;

//* Init SDRAM

AT91C_BASE_SDRC->SDRC_CR =
0x01 |//NC=9 columns
0x04 |//NR=12 rows
0x08 |//NB=4 banks
0x40 |//CAS=4
0x100 |//TWR=2
0x2800 |//TRC=5
0x10000 |//TRP=2
0x180000 |//TRCD=3
0x2800000 |//TRAS=5
0x28000000 //TXSR=5
;

//* 2. A Precharge All command is issued to the SDRAM
AT91C_BASE_SDRC->SDRC_MR = AT91C_SDRC_MODE_PRCGALL_CMD;
*pSDRAM = 0;

//* 3. Eight Auto-refresh are provided
AT91C_BASE_SDRC->SDRC_MR = AT91C_SDRC_MODE_RFSH_CMD;
for(i=0;i<7;i++)
*pSDRAM = 0;

//* 4. A mode register cycle is issued to program the SDRAM parameters
AT91C_BASE_SDRC->SDRC_MR = AT91C_SDRC_MODE_LMR_CMD;
*(pSDRAM+0x80) = 0;

//4.5 Three NOPs to take care of tMRD
AT91C_BASE_SDRC->SDRC_MR = AT91C_SDRC_MODE_NOP_CMD;
for(i=0; i<2; i++)
*pSDRAM = 0;


//* 6. A Normal Mode Command is provided, 3 clocks after tMRD is set
//Normal Mode, 32 bit word length
AT91C_BASE_SDRC->SDRC_MR = 0x0;
*pSDRAM = 0;

//* 5. Write refresh rate into SDRAMC refresh timer COUNT register
AT91C_BASE_SDRC->SDRC_TR = (AT91C_SDRC_COUNT & 0x2E0);//4096 refresh
cycles every 64ms
*pSDRAM = 0; 
======================================


Regards
Mayank

"Mayank Kaushik" <prehistorictoad2k@yahoo.com> schrieb im Newsbeitrag 
news:1106730223.825690.136270@z14g2000cwz.googlegroups.com...
> Hi Richard,
> Richard H. wrote:
>> Have you tried a *much* slower cycle on your signals, plus adding
> delays
>> between each step (command + clock strobe + MCU input) to let the
> line
>> stabilize?  This SDR chip should tolerate a very slow clock cycle
>> (although "stable" is a requirement).
> I thought of that. I need the 60Mhz cycle, coz im using the DBGU (debug
> unit) on the chip as my sole debugging aid. It needs a bit-rate of
> 115200bps, for which i need the 60Mhz master clock. I could bring it
> down to 1Mhz, i think...il try that. In the USART, each bit would be
> sent out at at least one clock edge, and for receiving, the rate should
> be double the bit rate..so that puts a cap on the lowest i can go...but
> i wonder..hmmm.il check that.
>
>> Have you checked with a scope to see if the input rise times are
> within
>> spec at the SDRAM?
> To Do.

Also check the clock signal for undershoot/overshoot or possible
double clocking (clock rising above halve value, then descending
due to reflection and rising again to full value).

You need a good (FET) probe and a high bandwidth scope to
see this effect in action.

- Rene