WTD: WISHBONE SDRAM interface or some Vlog HDL synthesizing...

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=A0am, 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:
> =A0 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?
>
> =A0 2) Duff SDRAM chip or bad connections/soldering. It's a BGA, BGAs
> always make me suspicious... :-/
>
> =A0 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 yea=
r

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?

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@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=A0am, 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 0x80=
0
> > 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 RAM=
s
> 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:
> =A0 =A0 =A0 =A0 // columns: 9 bits
> =A0 =A0 =A0 =A0 assign col_adr =3D linear_adr[8:0];
> =A0 =A0 =A0 =A0 // rows: 12 bits, with A10 unused
> =A0 =A0 =A0 =A0 assign row_adr =3D { linear_adr[20:19], 1'b0, linear_adr[=
18:9]};
> =A0 =A0 =A0 =A0 assign bank =3D linear_adr[22:21];
>
> gets me:
> =A0 ADR0 Read Failure after writing to linear address 0x207
> =A0 Expected 0x9BAB55AA, got 0xFF75EF7F.
> =A0 Write to 0x207 went OK, but the value at 0x000 was found to have chan=
ged
> =A0 ---
> =A0 ADR+N Readback Failure at linear address 0x240
> =A0 Expected 0x6454AA55, got 0x00000000.
> =A0 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:
> =A0 =A0 =A0 =A0 // rows: 12 bits, with A10 unused
> =A0 =A0 =A0 =A0 assign row_adr =3D { linear_adr[11:10], 1'b0, linear_adr[=
9:0]};
> =A0 =A0 =A0 =A0 // columns: 9 bits
> =A0 =A0 =A0 =A0 assign col_adr =3D linear_adr[20:12];
> =A0 =A0 =A0 =A0 assign bank =3D 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:
> =A0 ADR+N Readback Failure at linear address 0x100
> =A0 Expected 0x6454AA55, got 0x00000000.
> =A0 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? =A0The 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 A0-A8 =A0=3D Column Address, with A10 as precharge
> =A0 A0-A11 =3D 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 yea=
r

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.

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