DDR Controller problems

running on a Memec V2MB1000 dev board but not having much luck so far.

signals to the RAM when I checked with a scope, but DQS was not being strobed during the read cycle and the controller was reading back the last value written

- presumably because of the bus capacitance. After reading a few discussions I got the idea that my external clock might be skewed, but I was unsure of how to calculate the necessary phase shift as I have no idea how long the feedback trace is (the feedback and clock pins are right next to each other on the package however so I would imagine it would be pretty short). I tried various speculatory values for the phase shift to no avail.

downloaded the XBD files for the board from Avnet and set up a simple memory test project using the OPB DDR controller. The test passes for the flash memory and then freezes when it gets to the DDR and returns neither a pass or a fail. I'm kinda stuck here and unsure what to try next - is it possible that there's a problem with the board? Any help you guys could give me would be much appreciated.

If DQS is not being strobed during the read cycle, then a number of things may be wrong:

1. Clocks completely wrong relative to command. If this were the case, the initial setup of the mode and extended mode registers in the DDR would fail.
2. Address/data/command/clock skew. You already alluded to this and it would easily cause even the setup to fail.

Something that is unknown is whether your writes are succeeding - and that's not possible to know if you don't get a read strobe.

I would suggest, however, that if you don't even get a read strobe, the DDR is either :

a. Not properly connected (check your UCF pin locations) b. Defective. c. Not being given a proper read cycle command d. Not being properly initialised. e. Not getting precharged (some DDR won't respond with read strobes unless precharge has been done in the last n cycles). See a typical DDR datasheet (micron does the best ones) for details.

For d, make sure you are actually initialising the device Others could implicate clock/data/address/command skew.

I do not know your level of knowledge with DDR itself, but I can assure you (having laid down DDR on my own boards, using chips as well as using sticks) that the slightest thing wrong in connectivity will render it useless.

Cheers

PeteS

running on a Memec V2MB1000 dev board but not having much luck so far.

signals to the RAM when I checked with a scope, but DQS was not being strobed during the read cycle and the controller was reading back the last value written

- presumably because of the bus capacitance. After reading a few discussions I got the idea that my external clock might be skewed, but I was unsure of how to calculate the necessary phase shift as I have no idea how long the feedback trace is (the feedback and clock pins are right next to each other on the package however so I would imagine it would be pretty short). I tried various speculatory values for the phase shift to no avail.

downloaded the XBD files for the board from Avnet and set up a simple memory test project using the OPB DDR controller. The test passes for the flash memory and then freezes when it gets to the DDR and returns neither a pass or a fail. I'm kinda stuck here and unsure what to try next - is it possible that there's a problem with the board? Any help you guys could give me would be much appreciated.

What kind of memory speed are you trying to achieve? Maybe you should try to use 100MHz first. Anyway, if the DDR memory is not responding, you should look into the initialisation and alignment of the clock and control signals. A logic analyzer (16 channels at 400MHz is enough) will help a lot.

--
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl

In addition to the above replies, you can have a look at the following points.

1) When you say that you are using Memec board, then I assume that the board is already tested for the required frequency. So as such there might be no problem with resepct to the Board routing, SI and all.

2) As you are using OPB DDR Controller (which is a proven core), there is no issues from the controller side, unless we are giving wrong parameters to it.

but as you are using the xbd file, that means we can rule out any issues in the ucf file, mhs file,.... .

3) Under this circumstances, the first opton I will try is to run the DDR controller at a low frequency. By low frequency I mean Actual Frequency /4 or /8. For this you have to change the parameters accordingly.

If it still does not work, then see if there is dry soldering in the components (mostly Pull up/ Pull down registers and capacitors) in the DDR SDRAM path.

Wish you all the best.

Saumyajit

Nico Coesel wrote:

running on a Memec V2MB1000 dev board but not having much luck so far.

correct signals to the RAM when I checked with a scope, but DQS was not being strobed during the read cycle and the controller was reading back the last value written - presumably because of the bus capacitance. After reading a few discussions I got the idea that my external clock might be skewed, but I was unsure of how to calculate the necessary phase shift as I have no idea how long the feedback trace is (the feedback and clock pins are right next to each other on the package however so I would imagine it would be pretty short). I tried various speculatory values for the phase shift to no avail.

downloaded the XBD files for the board from Avnet and set up a simple memory test project using the OPB DDR controller. The test passes for the flash memory and then freezes when it gets to the DDR and returns neither a pass or a fail. I'm kinda stuck here and unsure what to try next - is it possible that there's a problem with the board? Any help you guys could give me would be much appreciated.

Hi Peter, Nico, Saumyajit,

Thanks for your replies. I was initially trying to use 100 MHz and I've tried slowing the OPB bus down to 66MHz - which EDK says is as slow as the Micron chip will go - but it still freezes on the memory test. The solder joints look fine to me but I'm just a Masters student - not exactly an expert!

I checked the initialisation and found that it wasn't waiting 200 cycles after setting the mode register the second time so I fixed that but it had no effect. I checked the precharge - the period met the specifications - 7.8us. I haven't been able to check the clock relative to the commands as I only have a 100MHz scope - I can see that the signals are going up and down in roughly the right places but the time resolution is pretty lousy - I'm working on getting access to a better logic analyser.

While I was checking the UCF for the pin configurations I noticed that in the mapper report I was getting this:

| data | IOB | BIDIR | SSTL2_I | | | OUTDDR | | | | | | | | ENFF2 |

when according to the readme I should be getting this:

| data | IOB | BIDIR | SSTL2_I | | | INFF1 | | | | | | | INFF2 | | | | | | | OUTDDR | | | | | | | ENFF2 What do I need to set to get it to use the INFFs? (They aren't being used on the input pins either)

Thanks again,

David

Hi Peter, Nico, Saumyajit,

Thanks for your replies. I was initially trying to use 100 MHz and I've tried slowing the OPB bus down to 66MHz - which EDK says is as slow as the Micron chip will go - but it still freezes on the memory test. The solder joints look fine to me but I'm just a Masters student - not exactly an expert!

I checked the initialisation and found that it wasn't waiting 200 cycles after setting the mode register the second time so I fixed that but it had no effect. I checked the precharge - the period met the specifications - 7.8us. I haven't been able to check the clock relative to the commands as I only have a 100MHz scope - I can see that the signals are going up and down in roughly the right places but the time resolution is pretty lousy - I'm working on getting access to a better logic analyser.

While I was checking the UCF for the pin configurations I noticed in the mapper report that the data line IOBs were only using the OUTDDR and ENFF2 registers, when according to the Readme they should also be using INFF1 and INFF2. None of the input IOBs were using any registers either. I'm pretty sure that I checked the map report back when I was using ISE 7.1 and the input registers were being used - has anything changed in 8.1? Is there a constraint I can set to force it to use the INFFs?

Thanks again,

David

slowing the OPB bus down to 66MHz - which EDK says is as slow as the Micron chip will go - but it still freezes on the memory test. The solder joints look fine to me but I'm just a Masters student - not exactly an expert!

setting the mode register the second time so I fixed that but it had no effect. I checked the precharge - the period met the specifications - 7.8us. I haven't been able to check the clock relative to the commands as I only have a 100MHz scope - I can see that the signals are going up and down in roughly the right places but the time resolution is pretty lousy - I'm working on getting access to a better logic analyser.

mapper report I was getting this:

| OUTDDR | | | | | | | ENFF2 What do I need to set to get it to use the INFFs? (They aren't being used on the input pins either)

In your mapper report, you are missing the IN FF [x] reports. This might mean (I am no expert on these tools, although I use them... ;) ] that the read functtionality is not being generated and has been optimised out. That would certainly explain what you are seeing.

Did the compiler (synthesiser) report have any such warnings? (Note they may be buried in the noise on such a compile)

Cheers

PeteS

tried slowing the OPB bus down to 66MHz - which EDK says is as slow as the Micron chip will go - but it still freezes on the memory test. The solder joints look fine to me but I'm just a Masters student - not exactly an expert!

after setting the mode register the second time so I fixed that but it had no effect. I checked the precharge - the period met the specifications - 7.8us. I haven't been able to check the clock relative to the commands as I only have a

100MHz scope - I can see that the signals are going up and down in roughly the right places but the time resolution is pretty lousy - I'm working on getting access to a better logic analyser.

the mapper report I was getting this:

| | OUTDDR | | | | | | | ENFF2 What do I need to set to get it to use the INFFs? (They aren't being used on the input pins either)

Hi Pete,

I can't see any warnings to that effect - here are the warnings that I can't account for, sorry there's so many:

WARNING:Xst:37 - Unknown property "buffer_sig". WARNING:Xst:37 - Unknown property "buffer_sig". WARNING:Xst:37 - Unknown property "buffer_sig". WARNING:Xst:37 - Unknown property "buffer_sig".

This is generated by this bit of code:

attribute buffer_sig : string; attribute buffer_sig of clk : signal is "IBUFG"; attribute buffer_sig of clk_fb : signal is "IBUFG";

WARNING:Xst:37 - Unknown property "preserve_signal". WARNING:Xst:37 - Unknown property "preserve_signal". WARNING:Xst:37 - Unknown property "preserve_signal". WARNING:Xst:37 - Unknown property "preserve_signal".

attribute preserve_signal : boolean; attribute preserve_signal of dqsz_q : signal is true; attribute preserve_signal of tristate_q : signal is true; attribute preserve_signal of z_q : signal is true; attribute preserve_signal of rst_qn : signal is true;

WARNING:Xst:1748 - "C:/Memec/memtest/ddr_sdr.vhd" line 494: VHDL Assertion Statement with non constant condition is ignored. WARNING:Xst:37 - Unknown property "preserve_signal". WARNING:Xst:37 - Unknown property "clock_feedback". WARNING:Xst:37 - Unknown property "clock_feedback". WARNING:Xst:1748 - "C:/Memec/memtest/user_if.vhd" line 244: VHDL Assertion Statement with non constant condition is ignored.

WARNING:Xst:2404 - FFs/Latches (without init value) have a constant value of 0 in block .

WARNING:Xst:1895 - Due to other FF/Latch trimming, FF/Latch (without init value) has a constant value of 0 in block . WARNING:Xst:1895 - Due to other FF/Latch trimming, FF/Latch (without init value) has a constant value of 0 in block . WARNING:Xst:1895 - Due to other FF/Latch trimming, FF/Latch (without init value) has a constant value of 0 in block .

WARNING:Xst:1710 - FF/Latch (without init value) has a constant value of 0 in block . WARNING:Xst:1710 - FF/Latch (without init value) has a constant value of 0 in block . WARNING:Xst:1291 - FF/Latch is unconnected in block . x16

WARNING:Xst:1988 - Unit : instances , of unit and unit are dual, second instance is removed WARNING:Xst:1710 - FF/Latch (without init value) has a constant value of 0 in block . WARNING:Xst:1895 - Due to other FF/Latch trimming, FF/Latch (without init value) has a constant value of 0 in block .

WARNING:Xst:1291 - FF/Latch is unconnected in block . WARNING:Xst:1710 - FF/Latch (without init value) has a constant value of 0 in block . WARNING:Xst:1710 - FF/Latch (without init value) has a constant value of 0 in block . WARNING:Xst:1710 - FF/Latch (without init value) has a constant value of 0 in block . WARNING:Xst:1710 - FF/Latch (without init value) has a constant value of 0 in block . WARNING:Xst:1710 - FF/Latch (without init value) has a constant value of 0 in block . WARNING:Xst:1895 - Due to other FF/Latch trimming, FF/Latch (without init value) has a constant value of 0 in block . WARNING:Xst:1895 - Due to other FF/Latch trimming, FF/Latch (without init value) has a constant value of 0 in block . WARNING:Xst:1895 - Due to other FF/Latch trimming, FF/Latch (without init value) has a constant value of 0 in block . WARNING:Xst:1895 - Due to other FF/Latch trimming, FF/Latch (without init value) has a constant value of 0 in block . WARNING:Xst:1895 - Due to other FF/Latch trimming, FF/Latch (without init value) has a constant value of 0 in block . WARNING:Xst:1291 - FF/Latch is unconnected in block . WARNING:Xst:1291 - FF/Latch is unconnected in block .

Cheers,

David