Forums

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

Started by Mayank Kaushik January 24, 2005
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