Hi Dave, I have always used div_clk = 200MHz (sys_clk_2x).
I have compiled my QDR test design to run of sys_clk (arb_clk) at 200, 225 MHz. I ran into timing issues when compiling for 250MHz. The QDR controller enables the QDR in high frequency mode, which means that the QDR clock must be > 130MHz, so sys_clk is to low. I'm not sure why clocking it below 200MHz (>130MHz) is giving problems. This testing sufficed for time when I did this and I did not explore more clocking options, due to other pressing work. Regards, Henno On Thu, Aug 15, 2013 at 8:45 AM, David MacMahon <[email protected]>wrote: > 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 > > > > -- Kind regards, Henno Kriel Digital Back End: Hardware Team Manager MeerKAT Digitiser: System Architect SKA South Africa Third Floor The Park Park Road (off Alexandra Road) Pinelands 7405 Western Cape South Africa Latitude: -33.94329 (South); Longitude: 18.48945 (East). (p) +27 (0)21 506 7300 (p) +27 (0)21 506 7365 (direct) (f) +27 (0)21 506 7375 (m) +27 (0)84 504 5050
