WTD: WISHBONE SDRAM interface or some Vlog HDL synthesizing.

P

Philip Pemberton

Guest
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@philpem.me.uk
http://www.philpem.me.uk/
If mail bounces, replace "10" with the last two digits of the current year
 
On Jul 13, 8:28 am, Philip Pemberton <usene...@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...@philpem.me.ukhttp://www.philpem.me.uk/
If mail bounces, replace "10" with the last two digits of the current year
Click to expand...
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
 
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?
Click to expand...
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.
Click to expand...
"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?
Click to expand...
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.
Click to expand...
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@philpem.me.uk
http://www.philpem.me.uk/
If mail bounces, replace "10" with the last two digits of the current year
 
On Jul 13, 8:30 am, Philip Pemberton <usene...@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...@philpem.me.ukhttp://www.philpem.me.uk/
If mail bounces, replace "10" with the last two digits of the current year
Click to expand...
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
 
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.
Click to expand...
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@philpem.me.uk
http://www.philpem.me.uk/
If mail bounces, replace "10" with the last two digits of the current year
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top