"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
Reply by Mayank Kaushik●January 26, 20052005-01-26
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
Reply by Richard H.●January 26, 20052005-01-26
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?)
Reply by Mayank Kaushik●January 26, 20052005-01-26
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
Reply by CBFalconer●January 25, 20052005-01-25
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
Reply by Steve at fivetrees●January 25, 20052005-01-25
"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
Reply by Tim Wescott●January 25, 20052005-01-25
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
Reply by Gene S. Berkowitz●January 25, 20052005-01-25
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
Reply by Mayank Kaushik●January 25, 20052005-01-25
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
Reply by Tim Wescott●January 24, 20052005-01-24
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