Unexplained behavior with DDR2 controller on Xilinx V5

Hi,

I'm working on a custom DDR2 controller on Virtex 5 and I have a very weird behavior that I can't explain. I'm doing my tests on a SO-DIMM of which I only use 8 bits and running it at 200 MHz. My controller uses the ISERDES / OSERDES so that it only runs at 100 MHz and expose a 32 bits data interface to the user.

The problem is that the first word of a write burst is corrupted.

The weird part is that depending on the reset/power-up, either it works fine, or it fails. That is, I reset the board, then either the controller works OK and it will stay OK indefinitly. Or it exhibit the problem and it will continue to show the same problem until reset.

So for example the test I'm running in loop is :

- Write 0x01234567 to 0x0000

- Write 0x89abcdef to 0x0004

- Write 0x02468ace to 0x0008

- Write 0x13579bdf to 0x000c

- Write 0x600dbabe to 0x0010

- Pause

- Write 0xf05a3c7d to 0x0008

- Pause

- Read 0x0000

- Read 0x0000

- Read 0x0004

- Read 0x0008

- Read 0x000c

- Read 0x0010

- Read 0x0010

So I write some known words in burst, then overwrite the middle word with another in a single write, then reread the whole burst (but reading the first and last word twice).

The results are : - Either every thing is fine - or, at 0x0000 I read 0x3c7d4567 (instead of 0x01234567) during both reads and at 0x0008 I read 0xf05af05a (instead of 0xf05a3c7d)

My problem is that I don't see what in my code could cause that kind of problems because I have nothing clocked at clk_2x ... I just provide 4 bits in // to the serdes and let it do the job.

Sylvain

Reply to
Sylvain Munaut
Loading thread data ...

Maybe it's a phase issue between your 200 and 100 MHz clocks, and you come in on different phases during your reset. What's your dcm/clocking scheme?

Reply to
Brad Smallridge

All the clocks comes from a V5 PLL.

I found the issue yesterday. I plugged in a scope and watched DQS and DQS_n and it turned out that when the design was failing, DQS and DQS_n were somehow not in phase, one of them being 1 clock cycle late ... Which is _very_ weird given that in my design I had :

OSERDES -> IOBUFDS

with the iobuf ds being a differential output buffer connected to dqs and dqs_n with the same OSERDES as source ...

I replaced that with two independant output buffer OBUFT and two OSERDES (one of them having inverted data input), and now it works fine ...

Sylvain

Reply to
Sylvain Munaut

Hi

I've seen this before. The reason what that the current V5 controllers do not support SODIMMs. This feature is going to be added in one of the upcoming releases of MIG.

For now the controller needs to be changed a little bit:

formatting link

I hope this helps. Jaco

Reply to
naude.jaco

bit:

formatting link

Actually I don't think it's the issue described here.

I think the problem is in the tools. When putting an oserdes followed by a differential output buffer, the tool duplicate itself the oserdes so that you have two serdes and two output buffer. But it somehow does it wrong and the duplicated oserdes is not always in sync ... When you manually do the duplication, it works fine.

Sylvain

Reply to
Sylvain Munaut

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.