|
We are having quite a bit of trouble getting our SDRAM to work properly with the C6711. We are using Micron MT48LC8M16A2 chips, and none of our settings seems to help (CE2, SDRAM CTL, SDRAM EXT, SDRAM TIMER). Has anyone interfaced with these chips and care to share the values they are using as a starting point? Thanks. |
|
|
SDRAM EMIF settings
Started by ●September 3, 2003
Reply by ●September 4, 20032003-09-04
|
I haven't used the MT48LC8M16A2, but my 6711 DSK has
MT48LC4M16A2's on it [have a look at the dsk GEL file if you haven't -
it actually has promming for MT48LC8M16A2's]. You also have to be
careful - because of differences in TI's timing and that of PCs, you have
to have at least PC133 speed to get close to running with a 100Mhz EMIF
clock.
mikedunn
rworne <r...@hotmail.com> wrote: We are having quite a bit of trouble getting our SDRAM to work |
Reply by ●September 4, 20032003-09-04
|
R Worne- > We are having quite a bit of trouble getting our SDRAM to work > properly with the C6711. > > We are using Micron MT48LC8M16A2 chips, and none of our settings > seems to help (CE2, SDRAM CTL, SDRAM EXT, SDRAM TIMER). > > Has anyone interfaced with these chips and care to share the values > they are using as a starting point? The Micron devices should work well with C6x; you can find them on any number of C6xxx boards including the Texas Inst DSK and EVM boards. If it turns out to be more than a software/config problem, then typically two things can get you into trouble: a) trace lengths from C6xxx device to SDRAM are not matched and/or too long or noisy, and b) SDRAM clock rate relative to processor clock rate. What is your processor clock speed and what is the SDRAM clock speed (which C6711 pin is being used for SDRAM clock)? Jeff Brower system engineer Signalogic |
|
|
Reply by ●September 5, 20032003-09-05
|
The traces are going through an FPGA if I understood correctly in the lab. The processor clock speed (CLKIN) is 150MHz SDRAM Clock Speed is 100MHz The C6711 pin is ECLKOUT. Any help would be greatly appreciated. Robert W. --- In , Jeff Brower <jbrower@s...> wrote: > R Worne- > > > We are having quite a bit of trouble getting our SDRAM to work > > properly with the C6711. > > > > We are using Micron MT48LC8M16A2 chips, and none of our settings > > seems to help (CE2, SDRAM CTL, SDRAM EXT, SDRAM TIMER). > > > > Has anyone interfaced with these chips and care to share the values > > they are using as a starting point? > > The Micron devices should work well with C6x; you can find them on any number of > C6xxx boards including the Texas Inst DSK and EVM boards. > > If it turns out to be more than a software/config problem, then typically two things > can get you into trouble: a) trace lengths from C6xxx device to SDRAM are not > matched and/or too long or noisy, and b) SDRAM clock rate relative to processor clock > rate. What is your processor clock speed and what is the SDRAM clock speed (which > C6711 pin is being used for SDRAM clock)? > > Jeff Brower > system engineer > Signalogic |
|
|
Reply by ●September 5, 20032003-09-05
|
Robert,
Not really?? Through the FPGA?? Why??
Are you sure that there is not just an FPGA hanging on the bus with the
SDRAM??
What and how many devices are on the data and address bus?? Has
anyone looked at the signals with a scope??
mikedunn
rworne <r...@hotmail.com> wrote: The traces are going through an FPGA if I understood correctly in the |
|
|
Reply by ●September 5, 20032003-09-05
|
Let's just say it's for a proprietary reason. It goes through
the FPGA from what I'm told. If I am told different tomorrow, I'll let you know. The FPGA is actually doing lots of things. I'm a software weenie by trade, and this HW stuff mostly confuses me. I just happen to be the resident expert at getting Code Composer Studio working with our custom board. I've seen the scope and data from a logic probe, we can see the refreshes and all, we have SBSRAM and Flash running this way too with no problems. Our latest adventures actually have us reading and writing data, but the behavior is odd. We use 32-bit access, 9 x 12 (rows & columns), with 4 chips. Write to one address (say 0xA0000000) and the same data shows up on 0xA0000004,8,and C). The first memory location in the memory window always is corrupted (that is, the very first read). If we write datadress we get something like this: 0xA0000000 0xFFFFF7FF 0xA0000004 0xA0000180 0xA0000008 0xA0000180 0xA000000C 0xA0000180 0xA0000010 0xA0000180 0xA0000014 0xA0000181 0xA0000018 0xA0000181 If we do a fill, everything seems OK, except for the very first address appearing in the window. It's got us completely stumped. When I'm back in the lab tomorrow, I'll try to get the EMIF settings. Robert W. --- In , Mike Dunn <mike-dunn@s...> wrote: > Robert, > > Not really?? Through the FPGA?? Why?? > > Are you sure that there is not just an FPGA hanging on the bus with the SDRAM?? > > What and how many devices are on the data and address bus?? Has anyone looked at the signals with a scope?? > > mikedunn > > rworne <rworne@h...> wrote: > The traces are going through an FPGA if I understood correctly in the > lab. > > The processor clock speed (CLKIN) is 150MHz > SDRAM Clock Speed is 100MHz > The C6711 pin is ECLKOUT. > > Any help would be greatly appreciated. > > Robert W. > > --- In , Jeff Brower wrote: > > R Worne- > > > > > We are having quite a bit of trouble getting our SDRAM to work > > > properly with the C6711. > > > > > > We are using Micron MT48LC8M16A2 chips, and none of our settings > > > seems to help (CE2, SDRAM CTL, SDRAM EXT, SDRAM TIMER). > > > > > > Has anyone interfaced with these chips and care to share the > values > > > they are using as a starting point? > > > > The Micron devices should work well with C6x; you can find them on > any number of > > C6xxx boards including the Texas Inst DSK and EVM boards. > > > > If it turns out to be more than a software/config problem, then > typically two things > > can get you into trouble: a) trace lengths from C6xxx device to > SDRAM are not > > matched and/or too long or noisy, and b) SDRAM clock rate relative > to processor clock > > rate. What is your processor clock speed and what is the SDRAM > clock speed (which > > C6711 pin is being used for SDRAM clock)? > > > > Jeff Brower > > system engineer > > Signalogic > > _____________________________________ > Note: If you do a simple "reply" with your email client, only the author of this message will receive your answer. You need to do a "reply all" if you want your answer to be distributed to the entire group. > > _____________________________________ > About this discussion group: > > To Join: Send an email to > > To Post: Send an email to > > To Leave: Send an email to > > Archives: http://www.yahoogroups.com/group/c6x > > Other Groups: http://www.dsprelated.com |
Reply by ●September 5, 20032003-09-05
|
Robert- > Let's just say it's for a proprietary reason. It goes through the > FPGA from what I'm > told. If I am told different tomorrow, I'll let you know. The FPGA > is actually doing lots > of things. Just off the top of my head, I would say that running SDRAM data and/or address lines through an FPGA is a really bad idea. The problem you describe below makes me think the first access in any burst is at risk; once you start running C code it will be game over. SDRAM timing is synchronous and sensitive; you don't have an asynchronous ARDY signal to play with if it should turn out you need to fix this with extra "wait-states". Sensitivity to timing is one reason why people are so careful to match trace lengths between the DSP and the SDRAM device -- that means *physical* trace length, on the PCB board. Obviously that's not been done in your design. Did your hardware mates run both address and data through the FPGA? What about clock? Processor clock and SDRAM clock should be exactly synchronized. You might tell them to try this: use CLKOUT2 as SDRAM clock (i.e. run CLKOUT2 to ECLKIN), and then see what happens to the first access. That will decrease your SDRAM speed to 1/2 processor clock. If that does not work, try 1/4 speed (CLKOUT3). I'm not suggesting that you run SDRAM permanently that slow, this is just debug to verify what's wrong. Yeah, another idea is to ask your hardware mates to get on this group. If I were their manager I'd say they need to be dealing with this not you, and I'd give them about 5 min to register and start asking questions, or else they can spend the next 5 min packing. -Jeff > I'm a software weenie by trade, and this HW stuff mostly confuses me. > I just happen > to be the resident expert at getting Code Composer Studio working > with our custom > board. I've seen the scope and data from a logic probe, we can see > the refreshes and > all, we have SBSRAM and Flash running this way too with no problems. > > Our latest adventures actually have us reading and writing data, but > the behavior is > odd. We use 32-bit access, 9 x 12 (rows & columns), with 4 chips. > Write to one > address (say 0xA0000000) and the same data shows up on > 0xA0000004,8,and C). > The first memory location in the memory window always is corrupted > (that is, the very > first read). If we write datadress we get something like this: > > 0xA0000000 0xFFFFF7FF > 0xA0000004 0xA0000180 > 0xA0000008 0xA0000180 > 0xA000000C 0xA0000180 > 0xA0000010 0xA0000180 > 0xA0000014 0xA0000181 > 0xA0000018 0xA0000181 > > If we do a fill, everything seems OK, except for the very first > address appearing in the > window. It's got us completely stumped. > > When I'm back in the lab tomorrow, I'll try to get the EMIF settings. > > Robert W. > > --- In , Mike Dunn <mike-dunn@s...> wrote: > > Robert, > > > > Not really?? Through the FPGA?? Why?? > > > > Are you sure that there is not just an FPGA hanging on the bus with > the SDRAM?? > > > > What and how many devices are on the data and address bus?? Has > anyone looked > at the signals with a scope?? > > > > mikedunn > > > > rworne <rworne@h...> wrote: > > The traces are going through an FPGA if I understood correctly in > the > > lab. > > > > The processor clock speed (CLKIN) is 150MHz > > SDRAM Clock Speed is 100MHz > > The C6711 pin is ECLKOUT. > > > > Any help would be greatly appreciated. > > > > Robert W. > > > > --- In , Jeff Brower wrote: > > > R Worne- > > > > > > > We are having quite a bit of trouble getting our SDRAM to work > > > > properly with the C6711. > > > > > > > > We are using Micron MT48LC8M16A2 chips, and none of our settings > > > > seems to help (CE2, SDRAM CTL, SDRAM EXT, SDRAM TIMER). > > > > > > > > Has anyone interfaced with these chips and care to share the > > values > > > > they are using as a starting point? > > > > > > The Micron devices should work well with C6x; you can find them > on > > any number of > > > C6xxx boards including the Texas Inst DSK and EVM boards. > > > > > > If it turns out to be more than a software/config problem, then > > typically two things > > > can get you into trouble: a) trace lengths from C6xxx device to > > SDRAM are not > > > matched and/or too long or noisy, and b) SDRAM clock rate > relative > > to processor clock > > > rate. What is your processor clock speed and what is the SDRAM > > clock speed (which > > > C6711 pin is being used for SDRAM clock)? > > > > > > Jeff Brower > > > system engineer > > > Signalogic |
