Hi, Henno, I rebuilt a ROACH2 design using the 100 MHz sys_clk for the qdr_controllers' div_clk input. When running that bitstream, the QDR calibration always failed. Then I tried rebuilding the design using the 143 MHz fabric clock for div_clk. The QDR calibration always failed when running that bitstream as well.
That made me wonder/worry about the relationship between the qdr_controller's clk0 (i.e. the fabric clock) and div_clk (i.e. the IODELAY tap setting clock) inputs. If the QDR calibration fails when running div_clk at or below the clk0 frequency, does that imply that the QDR calibration would fail when running clk0 faster than than the nominal 200 MHz div_clk? To test this, I built a simple test model using the 4 QDRs. This test model was clocked from aux_clk. I specified the aux_clk clock frequency to be 240 MHz and manually modified (i.e. re-hardcoded) the hardcoding in the aux_clk MMCM config so that the MMCM could be driven from 135 MHz to 240 MHz without failing a DRC in the map phase. When running this design, I found that the QDRs calibrated fine from 200 MHz almost all the way to 240 MHz. Around 239 MHz I started to get some calibration errors. By 240 MHz I was getting lots. On the low end, I tried 180 MHz and got total calibration failure. I haven't fully explored things, but I found the preliminary results somewhat discouraging. The low end behavior is contradicted somewhat by the empirical success of others running clk0 more slowly than the 200 MHz div_clk, but maybe there are "good" (aka "lucky") and "bad" (aka "unlucky") clock ratios? Can you think of anything that I might have inadvertently changed or broken? At which fabric clock frequencies have you tested/verified QDR calibration? My guess is that the basic test is done using the 100 MHz sys_clk and/or 200 MHz sys_clk2x. Have you tested at other fabric frequencies? Thanks, Dave On Aug 1, 2013, at 11:10 AM, David MacMahon wrote: > Hi, Henno, > > Thanks for the reply. > > On Aug 1, 2013, at 12:50 AM, Henno Kriel wrote: > >> The IODELAY_CTRL block need to be clocked at 200MHz +/- 10MHz. From the >> datasheet it is not clear whether you can clock the IODELAY block at a >> different frequency - it just states that the average tap delay at 200MHz is >> 78ps. > > Yes, the IODELAYCTRL element must be clocked at 200 MHz +/- 10 MHz, but I > think that's separate and distinct from the IODELAY's clock input C. Page 98 > of "Virtex-6 FPGA SelectIO Resources User Guide UG361 (v1.3) August 16, 2010" > mentions that the IODELAY's clock input C "should be connected to the same > clock in the SelectIO logic resources (when using ISERDES and OSERDES, C is > connected to CLKDIV).". This implies that this clock input C is very > independent from the IODELAYCTRL clock, so there is no FPGA > limitation/constraint that would prevent the use of sys_clk here instead of > sys_clk2x. Whether the qdr_controller will work that way remains to be seen. > >> I'm not sure what the effect would be if you clocked it at 100MHz, but let >> us know what your experience is. > > I'll let you know! > > Thanks again, > Dave >
