Unexplained behavior with DDR2 controller on Xilinx V5

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
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


Re: Unexplained behavior with DDR2 controller on Xilinx V5
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?

"Sylvain Munaut  wrote in message
Quoted text here. Click to load it



Re: Unexplained behavior with DDR2 controller on Xilinx V5
Quoted text here. Click to load it

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


Re: Unexplained behavior with DDR2 controller on Xilinx V5
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:
http://www.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&getPagePath25%040

I hope this helps.
Jaco




Re: Unexplained behavior with DDR2 controller on Xilinx V5
Quoted text here. Click to load it
bit:http://www.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountry ...
Quoted text here. Click to load it

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


Site Timeline