Brenden

I also tried with 1.3 and got the same result. Tried in 2022.2 and 2021.1 and the same thing happened. The ui_addn_clk_0 also shows 200Mhz in the IPI for me (even before the update from 1.2 to 1.3). However, during synthesis the actual output being generated is 189.58Mhz. The 189.58Mhz is consistent with Verilog the MIG generates but not what I configured in the UI. I mention the calculations in my last post.

Thanks for the tips. Sorry for the late reply. I had my notifications disabled so didn't see your responses. I told the IPI to generate a 200MHz clock but it actually generates 189.583Mhz. The problem seems to be that the MIG generates the clocks using a PLL and MMCM which it creates (per the DDR2 Clocking Architecture in ug586_7Series_MIS) . The PLL is used to generate the recommended 325Mhz clock. It is also used to generate the ui_clk which is 325/4 = 81.25Mhz. This ui_clk is passed into an MMCM also managed by MIG, the MMCM mentioned in the image above. The Wizard seems to try to spin the MMCM up to 1200MHz VCO. Internally is seems to use the calculation M = floor(1200/81.25) = 14. This means the actual VCO is 14 * 81.25 = 1137.5Mhz. When this is divided by 16 (from the screen above) we end up with 189.583Mhz. I guess I technically need a D = 1137.5 / 200 = 5.6875 which I can get pretty close to by setting D indirectly with a faster clock. It seems strange that the MIG wizard did not warn me when the actual clock I asked for could not be generated. I can't see anything in the UI or logs when it generates the Verilog to indicate truncation. If you look at the actual Verilog output you can see the IPI indeed has set M = 14 and D = 6. So I think the synthesis is doing exactly as expected. // *_mig_7series_0_0_mig.v parameter CLKIN_PERIOD = 10000, //ps or 100Mhz parameter CLKFBOUT_MULT = 13, parameter DIVCLK_DIVIDE = 1, parameter CLKOUT0_PHASE = 0.0, parameter CLKOUT0_DIVIDE = 2, parameter CLKOUT1_DIVIDE = 4, parameter CLKOUT2_DIVIDE = 64, parameter CLKOUT3_DIVIDE = 16, // 81.25Mhz = 100Mhz * 13 / 16 parameter MMCM_VCO = 1200, parameter MMCM_MULT_F = 14, // VCO = 81.25 * 14 = 1137.5. parameter MMCM_DIVCLK_DIVIDE = 1, parameter MMCM_CLKOUT0_DIVIDE = 6, // The slow clock = 81.25 * 14 / 6 = 189.583Mhz In the end I just generated the necessary clocks externally in my own MMCM and fed them into the MIG. Not sure if this is a good thing or not by it seems to work without any timing errors. @JRys What versions of the files should I have. I clicked refresh and still only have board versions of 1.2. I never followed https://digilent.com/reference/programmable-logic/guides/installing-vivado-and-vitis#install_digilent_s_board_files because the Nexys A7-100T was always present. When you generate the MIG what are the parameters that IPI/MIG generates within *_mig_7series_0_0_mig.v? Seems strange you wouldn't have the same problem. I have xilinx.com:ip:mig_7series:4.2 but according to change log it has not changed in either of the versions you mention. Strange.

I was following the steps on https://digilent.com/reference/programmable-logic/guides/getting-started-with-ipi to play around with the DDR2 on the board. However, when I follow the steps I end up with a few Timing/Critical errors by default. When I connect ui_addn_clk_0 to clk_ref_i I check that the clock frequency is 200MHz. However when I run the synthesis I get the following error: I noticed that the sys_1_i/mig_7series_0/u_sys_1_mig_7series_0_0_mig/u_iodelay_ctrl/u_idelayctrl_200 is clocked off clk_ref_i which should be 200MHz according to the IP Integrator. However, if I use the "Clock Networks" report it indeed looks like the the 200MHz clock requested in the IP integrator is actually being generated as 189.583Mhz Does someone know how to fix this? Should I just use another clock from outside the MIG? This seems to lead the critical timing errors during Synthesis and Implementation:

I was using the IP integrator to talk to the ADXL362 on the board. I did this by clicking on "Board > Accelerometer > Connect Board Component". When I Implemented the design I noticed that I could not talk to the ADXL362. I eventually looked at the "IO - Place Design" report. It said that: acl_io1_io (MISO) - F14 acl_io0_io (MOSI) - E15 Now this looks backwards to me. From the constraints and the schematic it looks like F14 = MOSI and E15 = MISO. It looks like the board configuration is wrong. When I manually created the AXI SPI and used the constraints and wired F14 = MOSI and E15 = MISO I was able to communicate.