WTD: WISHBONE SDRAM interface or some Vlog HDL synthesizing...
in [FPGA]
|
Prev: 2010 Fashion Shoes,top quality the lowest price here www.ecgo2buy.com
Next: Simple hack to get $500 to your home.
From: Philip Pemberton on 13 Jul 2010 08:28 Hi guys, I'm (still) trying to chase down an issue with the SDRAM on an Enterpoint Drigmorn2 development board. Basically, the SDRAM is acting like the mythical Write Only Memory -- I can write stuff to it, but as soon as the address goes over 0x800, the readback is stuffed. Does anyone have either a known-working SDRAM IP core (ideally with a WISHBONE interface), or an SDRAM tester, which I can borrow to do some testing? I just need it to work with a 2M*32bit*4bank (the ISSI part on the Drigmorn2) and a 1M*16bit*4bank (the Powerchip part on the Altera/ Terasic DE1) chip. If it works with one, the other or neither, I'm open to tweaking it to work (should be a simple enough case of modifying the addressing logic). At this point I've more or less ruled out SI issues (clock rate is only 25MHz, slew rate is set to SLOW, tracks are very short...), which just leaves: 1) XST/ISE isn't synthesizing my logic properly. Can't prove this without a different synthesizer -- if I put a zip file with the ISE project somewhere, could someone possibly synthesize it with a different tool for me and send the bit-file back? 2) Duff SDRAM chip or bad connections/soldering. It's a BGA, BGAs always make me suspicious... :-/ 3) My logic is doing something wrong which the ISSI chip doesn't like, but which doesn't cause problems with the Powerchip chip on the Altera DE1 board. The board is currently hooked up to a logic analyser (HP 16500B+16555D Deep Memory analyser blade), but I'm not seeing anything out-and-out wrong. Refresh timing is right on (15.625us between each AUTO REFRESH), read/write latency seems to be set right, init looks good and matches the datasheet... Thanks, -- Phil. usenet10(a)philpem.me.uk http://www.philpem.me.uk/ If mail bounces, replace "10" with the last two digits of the current year
From: Gabor on 13 Jul 2010 09:05 On Jul 13, 8:28 am, Philip Pemberton <usene...(a)philpem.me.uk> wrote: > Hi guys, > > I'm (still) trying to chase down an issue with the SDRAM on an Enterpoint > Drigmorn2 development board. Basically, the SDRAM is acting like the > mythical Write Only Memory -- I can write stuff to it, but as soon as the > address goes over 0x800, the readback is stuffed. > > Does anyone have either a known-working SDRAM IP core (ideally with a > WISHBONE interface), or an SDRAM tester, which I can borrow to do some > testing? I just need it to work with a 2M*32bit*4bank (the ISSI part on > the Drigmorn2) and a 1M*16bit*4bank (the Powerchip part on the Altera/ > Terasic DE1) chip. If it works with one, the other or neither, I'm open > to tweaking it to work (should be a simple enough case of modifying the > addressing logic). > > At this point I've more or less ruled out SI issues (clock rate is only > 25MHz, slew rate is set to SLOW, tracks are very short...), which just > leaves: > 1) XST/ISE isn't synthesizing my logic properly. Can't prove this > without a different synthesizer -- if I put a zip file with the ISE > project somewhere, could someone possibly synthesize it with a different > tool for me and send the bit-file back? > > 2) Duff SDRAM chip or bad connections/soldering. It's a BGA, BGAs > always make me suspicious... :-/ > > 3) My logic is doing something wrong which the ISSI chip doesn't like, > but which doesn't cause problems with the Powerchip chip on the Altera > DE1 board. > > The board is currently hooked up to a logic analyser (HP 16500B+16555D > Deep Memory analyser blade), but I'm not seeing anything out-and-out > wrong. Refresh timing is right on (15.625us between each AUTO REFRESH), > read/write latency seems to be set right, init looks good and matches the > datasheet... > > Thanks, > -- > Phil. > usene...(a)philpem.me.ukhttp://www.philpem.me.uk/ > If mail bounces, replace "10" with the last two digits of the current year Just a guess, but if you're address is mapped such that going over 0x800 activates column address 10, then maybe you're not handling the auto- precharge properly? SDRAM chips with more than 1K columns skip column address 10 and go to column address line 11 because the A10 pin doubles as the auto-precharge select during CAS cycles. I remember early Xilinx MIG versions wouldn't even allow the use of row address 10 because they didn't handle this correctly and just tied A10 low instead of fixing it. I have to admit I've only worked with Micron parts, but it's hard to imagine ISSI parts behaving much differently given they all presumably meet the same JEDEC specifications. Are these single-data rate parts? Can you cross it to a Micron part number and get the Verilog model from their website? The Micron models are pretty good at showing you what is going on. Regards, Gabor
From: Philip Pemberton on 13 Jul 2010 11:30 On Tue, 13 Jul 2010 06:05:49 -0700, Gabor wrote: > Just a guess, but if you're address is mapped such that going over 0x800 > activates column address 10, then maybe you're not handling the auto- > precharge properly? That might be a possibility... though an unlikely one. I'll look into it. The address generator is a little messy (out of necessity; it handles RAMs with between 8 and 16 column address bits, programmable at runtime believe it or not). The chip I'm using has 512 columns (9bit column address), 4096 rows (12bit row address) and four banks, so a column address should never overflow into bit 10. Hard coding the address decoder logic to this: // columns: 9 bits assign col_adr = linear_adr[8:0]; // rows: 12 bits, with A10 unused assign row_adr = { linear_adr[20:19], 1'b0, linear_adr[18:9]}; assign bank = linear_adr[22:21]; gets me: ADR0 Read Failure after writing to linear address 0x207 Expected 0x9BAB55AA, got 0xFF75EF7F. Write to 0x207 went OK, but the value at 0x000 was found to have changed --- ADR+N Readback Failure at linear address 0x240 Expected 0x6454AA55, got 0x00000000. Wrote to 0x240 OK, but value read back was different. It doesn't look like a CA / RA issue to me... Removing the "1'b0" from the row_adr concatenation gets me the same result. If I change it to this: // rows: 12 bits, with A10 unused assign row_adr = { linear_adr[11:10], 1'b0, linear_adr[9:0]}; // columns: 9 bits assign col_adr = linear_adr[20:12]; assign bank = linear_adr[22:21]; I get an "ADR+N" error ("I put a book in the box, looked again and it contained a fish!") at 0x100 instead: ADR+N Readback Failure at linear address 0x100 Expected 0x6454AA55, got 0x00000000. Wrote to 0x100 OK, but value read back was different. > I have to admit I've only worked with Micron parts, but it's hard to > imagine ISSI parts behaving much differently given they all presumably > meet the same JEDEC specifications. "Presumably" being the operative word here. While Micron seem to make a big deal about JEDEC standards compliance and testing, ISSI stay remarkably quiet about the subject. > Are these single-data rate parts? Yes. > Can you cross it to a Micron part number and get the Verilog model from > their website? The Micron models are pretty good at showing you what is > going on. The equivalent Micron part appears to be the MT48LC8M32B2 (which is obsolete; it seems Micron have canned all their 256Mb x32 SDRAM parts -- the largest current x32 part is 4Mbit although 256Mb and 128Mb parts are available in x16). This is a 2Meg, 32bit, 4bank part with the same 4096x512x32 bank size and addressing scheme: A0-A8 = Column Address, with A10 as precharge A0-A11 = Row Address I've already done that and run the Testbench over the driver core using Icarus Verilog. It works fine... :-/ -- Phil. usenet10(a)philpem.me.uk http://www.philpem.me.uk/ If mail bounces, replace "10" with the last two digits of the current year
From: Jon on 14 Jul 2010 11:37 On Jul 13, 8:30 am, Philip Pemberton <usene...(a)philpem.me.uk> wrote: > On Tue, 13 Jul 2010 06:05:49 -0700, Gabor wrote: > > Just a guess, but if you're address is mapped such that going over 0x800 > > activates column address 10, then maybe you're not handling the auto- > > precharge properly? > > That might be a possibility... though an unlikely one. I'll look into it. > The address generator is a little messy (out of necessity; it handles RAMs > with between 8 and 16 column address bits, programmable at runtime > believe it or not). > > The chip I'm using has 512 columns (9bit column address), 4096 rows > (12bit row address) and four banks, so a column address should never > overflow into bit 10. > > Hard coding the address decoder logic to this: > // columns: 9 bits > assign col_adr = linear_adr[8:0]; > // rows: 12 bits, with A10 unused > assign row_adr = { linear_adr[20:19], 1'b0, linear_adr[18:9]}; > assign bank = linear_adr[22:21]; > > gets me: > ADR0 Read Failure after writing to linear address 0x207 > Expected 0x9BAB55AA, got 0xFF75EF7F. > Write to 0x207 went OK, but the value at 0x000 was found to have changed > --- > ADR+N Readback Failure at linear address 0x240 > Expected 0x6454AA55, got 0x00000000. > Wrote to 0x240 OK, but value read back was different. > > It doesn't look like a CA / RA issue to me... Removing the "1'b0" from > the row_adr concatenation gets me the same result. > > If I change it to this: > // rows: 12 bits, with A10 unused > assign row_adr = { linear_adr[11:10], 1'b0, linear_adr[9:0]}; > // columns: 9 bits > assign col_adr = linear_adr[20:12]; > assign bank = linear_adr[22:21]; > > I get an "ADR+N" error ("I put a book in the box, looked again and it > contained a fish!") at 0x100 instead: > ADR+N Readback Failure at linear address 0x100 > Expected 0x6454AA55, got 0x00000000. > Wrote to 0x100 OK, but value read back was different. > > > I have to admit I've only worked with Micron parts, but it's hard to > > imagine ISSI parts behaving much differently given they all presumably > > meet the same JEDEC specifications. > > "Presumably" being the operative word here. While Micron seem to make a > big deal about JEDEC standards compliance and testing, ISSI stay > remarkably quiet about the subject. > > > Are these single-data rate parts? > > Yes. > > > Can you cross it to a Micron part number and get the Verilog model from > > their website? The Micron models are pretty good at showing you what is > > going on. > > The equivalent Micron part appears to be the MT48LC8M32B2 (which is > obsolete; it seems Micron have canned all their 256Mb x32 SDRAM parts -- > the largest current x32 part is 4Mbit although 256Mb and 128Mb parts are > available in x16). This is a 2Meg, 32bit, 4bank part with the same > 4096x512x32 bank size and addressing scheme: > A0-A8 = Column Address, with A10 as precharge > A0-A11 = Row Address > > I've already done that and run the Testbench over the driver core using > Icarus Verilog. It works fine... :-/ > > -- > Phil. > usene...(a)philpem.me.ukhttp://www.philpem.me.uk/ > If mail bounces, replace "10" with the last two digits of the current year I believe I can supply the Micron chip. If you are interested in crosses I will check it out and let you know. All parts are new in original factory packaging. Please let me know if you have an interest and how many you need. Thank you , Jon E. Hansen (949)864-7745
From: Philip Pemberton on 17 Jul 2010 06:24
On Wed, 14 Jul 2010 08:37:06 -0700, Jon wrote: > I believe I can supply the Micron chip. If you are interested in crosses > I will check it out and let you know. All parts are new in original > factory packaging. Please let me know if you have an interest and how > many you need. Unfortunately it's not really an option -- swapping the BGA RAM chip on all my DM2s is a bit beyond my capabilities (I've tried a few times with a hot-air soldering tool but never got a BGA off a board without ruining the board, the chip or both). At this point, I want to get the SDRAM controller working with this chip and this hardware... I'm starting to suspect an issue in my SDRAM controller's implementation of the WISHBONE bus WAIT state -- the read errors usually occur after the 9th address bit (A8) goes high. Strange. And I'm seeing the same issue on a second DM2 board -- so that pretty much rules out hardware, leaving HDL issues and timing issues. Process of elimination... fun. -- Phil. usenet10(a)philpem.me.uk http://www.philpem.me.uk/ If mail bounces, replace "10" with the last two digits of the current year |