12-08-2014 08:09 AM
As explained in ug586, I am trying to use the MIG quick start example design in order to verify the DDR3 interface on our custom board with Artix 7. I have 2 questions regarding that:
1. "dbg_init_calib_complete" signal always asserts ca. 3 seconds after deassertion of "ui_clk_sync_rst", although it takes only ~120 us during simulation. Is that normal?
2. As seen on the picture below, I always get a compare error ("dbg_tg_compare_error" asserts) with the first "dbg_cmp_data_valid" assertion, although the compare data and the read data are the same (but "dbg_rddata_valid_r" is not asseted, which is strange). I have not changed anything within the example_top design. I have just added a MMCM to provide the needed 100 and 200MHz clock sources. Could you give me a hint beyond the page 254 of ug586?
Note: Vivado 14.4 and the latest MIG version are being used.
12-08-2014 08:17 AM - edited 12-08-2014 08:26 AM
1. Based on your core configuration 120 us is possible and once calib_complete is asserted it always stays high, this should be fine.
2. Error should not toggle, if this is with example design and you changed the clocks, did you use No_Buf option?
also is this system or reference clock? did you change it in sim_tb_top as well?
Also please check below link for general guidliness on deriving clocks from existing MMCM
12-08-2014 08:29 AM
12-08-2014 08:34 AM
1. Yes, 3 sec in HW is normal
2. If it is in HW please change check if it is write or read issue, you can use debug steps from AR43879 pdf and do step by step analysis http://www.xilinx.com/support/answers/43879.html
12-08-2014 08:37 AM
12-09-2014 12:34 AM
Note: Starting with the release of MIG 7 Series v1.9, this debug content has been moved to the 7 Series FPGAs Memory Interface Solutions User Guide. Please reference the "Debugging DDR3/DDR2 Designs" section.
It seems that this AR# 43879, troubleshooting guide has been merged to the UG586. I have already refered to the mentioned section and I could trigger directly to the happening error, as explained starting from page 254.
I always get a compare error ("dbg_tg_compare_error" asserts), although the compare data and the read data are the same.
This case is not covered within the mentioned section.
I suspect that the example design has a kind of flaw, rather than the DDR3 controller itself...
I would be very glad, if you can give me a hint: What could be the problem with the example design? or
12-10-2014 01:26 AM
We do not have any Known issus on example design asserting error flag in absence of data errors.
Even though data is same I suspect there might be alignment issues like address and data mismatch.
How many boards have this issue and how often teh error flag is asserted ? I would suggest to change address and data patterns so that you might have some clues on what is happening.
Also in place of traffic gen you can have a simple fsm write your own known data, read and comapre it and see how it goes.
Hope this helps