01-18-2012 10:52 AM
We started using the MIGv3.61 generated DDR2 core with our custom V5 based boards (xcv5vlx110t-1ff1136 connected to an MT4HTF3264HY-667 SO-DIMM module), but there are some errors on some of the boards.
PCB wiring seems to meet timing and signal integrity requirements according to specs.
First we had to modify the reference core to meet our device:
- we use only one 200Mhz external clock source, so sys_clk_ibufg is wired to clk200_ibufg (thats ok, I think)
- because of the PCB pinout DQS signals are not routed to clock capable (CC) IOs, so I had to comment out the BUFIO components and use direct wiring for the code to compile:
dqs_bufio <= dqs_idelay;
(I'm not so confident about that, could this cause this kind of problems?)
Timing is met for the MIG and the whole core too.
Some of the boards seem to work flawlessly with the same core (calib_done is OK, and no error), some have error, and some don't even reach calibrated state at all (tried swapping DDR2 modules too, no change in result).
The calibrated DQ/DQS DELAY values observed with chipscope are in mid-range (MSB (6th bit) '0', 5th bit '1' ...).
Using the same controller in my data processing core I observed rare single bit errors during read operations (fe. 50th data bit changed from 1 -> 0 ).
Tried the same tests with some Kingston 1Gb modules (timing parameters modified in MIG according to values red from SPD), but results were worse than by Micron modules...
Can someone suggest some way, or method to find the root of the problem, or how to solve it?
01-19-2012 02:50 AM
Well, you already know the problem... You just have to decide to fix it.
"If it don't work in simulation, it won't work on the board."
01-19-2012 09:04 PM
Hope this helps.
01-20-2012 12:38 AM
Thanks for your answers!
I would like to understand the problem, as I don't see why the skew difference between DQS-to DQ-IDDR delays (without BUFIO) could cause this kind of errors.
As I understand from ug086, and xapp858 (page 22, fig 19) during the read calibration phase DQ IDELAY should compensate the skew differences on DQS, as delay is increased until readback matches with training pattern. Or is it because of the DQS gate calib. stage, which occurs later on?
Strange thing is, I get better results (less or no errors) if i disable ODT in the core (I had it on default 75ohm, and I dont have ext. termination on the DDR2 side).
My question is: is it possible to correct the DQS skew problem inside the chip (fe. with directed routing constrains, and strict stage1-2 capture logic placementing, or maybe by rewriting some portions of the calibration logic) or is it absolutely necessary to rewire the DQS signals to CC pins?
(Inspecting the delays from DQS to DQ IDDR groups in FPGA editor has shown a delay variation from 1.1ns to 1.8 ns. A pinout using BUFIOs has a constant value of 0.4ns to all of the DQ-s; ddr2 clk is 5ns)
Thank you for your time!
02-01-2012 12:11 AM
Run IBIS simulation on your board to find out the best parameter of ODT, DCI or other terminators.