fpga Nexys-A7 100T DDR2 example implements with timing and design errors in Vivado v2022.2

[Brenden]

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:

Quote

[Timing 38-469] The REFCLK pin of IDELAYCTRL sys_1_i/mig_7series_0/u_sys_1_mig_7series_0_0_mig/u_iodelay_ctrl/u_idelayctrl_200 has a clock period of 5.275 ns (frequency 189.583 Mhz) but IDELAYE2 sys_1_i/mig_7series_0/u_sys_1_mig_7series_0_0_mig/u_memc_ui_top_axi/mem_intfc0/ddr_phy_top0/u_ddr_mc_phy_wrapper/u_ddr_mc_phy/ddr_phy_4lanes_0.u_ddr_phy_4lanes/ddr_byte_lane_C.ddr_byte_lane_C/ddr_byte_group_io/input_[0].iserdes_dq_.idelay_dq.idelaye2 has REFCLK_FREQUENCY of 200.000 Mhz (period 5.000 ns). The IDELAYCTRL REFCLK pin frequency must match the IDELAYE2 REFCLK_FREQUENCY property.

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:

[zygot]

I'm guessing that there's either a connection issue with your IPI diagram or a setting with the MiG IP. I don't use the IPI flow, so I don't have an opinion on where the problem lies. You might be able to find clues in the synthesis reports, but I'd double check the settings in the MiG IP. Options for setting up IP native mode are often different than for AXI mode. IDELAY requires specific clock frequencies, like 200 MHz. I don't use MicroBlaze, but perhaps there's an issue there. Obviously, synthesis is associating a different clock source for the MiG refclk than you intend. Try and track down why that is. Read the synthesis messages carefully for clues.

Another source of potential problems is the board file information and how versions of Vivado interpret it.. Edited January 9, 2023 by zygot

[asmi]

The problem has nothing to do with IPI nor does it have anything to do with Microblaze. You are simply feeding reference clock which is not 200 MHz, and the error message is clearly stating that.

[zygot]

2 hours ago, asmi said:

The problem has nothing to do with IPI nor does it have anything to do with Microblaze.

While this statement should be correct, that doesn't necessarily mean that it is. When FPGA tools control design flow chores the possibility of bugs in the IP for different tool versions exists. That's because most IP is a conglomeration of scripts and software. Using any vendor IP can lead to issues for the user but the IPI flow is different from an all HDL flow. Either way, you need to get used to figuring out how to let synthesis and implementation messages inform you as to possible sources of where errors originate.

In the IPI flow, be sure to validate your design. Sometimes clock frequencies get rounded to some bizarre value or not rounded to a value that you specify. This generally leads to validation error messages. If you wire up your IPI design incorrectly you can certainly validate a deign that isn't correct and will fail synthesis or later implementation stages.

Edited January 9, 2023 by zygot

[asmi]

3 hours ago, zygot said:

While this statement should be correct, that doesn't necessarily mean that it is.

Yes it is absolutely correct, as the error message clearly states what the problem is. And I suspect that there was a validation message to that effect, but OP didn't notice or decided to ignore it.

3 hours ago, zygot said:

When FPGA tools control design flow chores the possibility of bugs in the IP for different tool versions exists. That's because most IP is a conglomeration of scripts and software. Using any vendor IP can lead to issues for the user but the IPI flow is different from an all HDL flow. Either way, you need to get used to figuring out how to let synthesis and implementation messages inform you as to possible sources of where errors originate.

The whole IPI flow is little more than a rather simple parameters propagation system, which also auto-calculates some parameters and so releaves designer from having to assign them manually. There is no "magic" in that flow, it fundamentally is an HDL flow in all but a single aspect, which is auto-calculation of some parameters (which you can technically do yourself as well, but it's going to be more involved that simply launching vailation and examining caclulated values). If you open generated HDL files, you will see the same things you would write by yourself to wire all parts together. So it's a huge time-saver, especially if for some reason you can't use SystemVerilog and so you will have to wire up every single wire one by one (in SV you can use interfaces to avoid that, this saves huge amount of time wiring up anything with AXI buses). The only real problem with that is SV is not yet supported by IPI (it doesn't even "see" anything declared in *.sv files), which is a real bummer for me, forcing me to manually create Verilog wrappers for the modules which I plan to instantiate in IPI. Hopefully it will be rectified soon.

3 hours ago, zygot said:

In the IPI flow, be sure to validate your design. Sometimes clock frequencies get rounded to some bizarre value or not rounded to a value that you specify. This generally leads to validation error messages. If you wire up your IPI design incorrectly you can certainly validate a deign that isn't correct and will fail synthesis or later implementation stages.

IDE will perform validation automatically if not done manually when you launch synthesis. Successful validation does not guarantee that synthesis and especially place & route will be successful because it doesn't check for many things which affect these stages - for example it doesn't examine constraints file, whose content can obviously lead to placement and routing failures.

[JRys]

I've used the Getting-Started-with-ipi guide several times with Vivado 2020 and 2022.1 and the NexysA7-100. However, in Vivado 2022.2 the board file selection changed. Now, you must download and install the board file by click on the status icon. The getting-started-with-ipi guide calls this out for those using Vivado 2022.2. On this dialog, select Digilent as the vendor and then find the Nexys A7-100. Click the status icon to download and install the correct board file. To make sure there isn't a problem, today I walked through the guide all the way to exporting the hardware design. I did not get the critical timing errors.

 

[Brenden]

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.

On 1/11/2023 at 4:03 AM, JRys said:

The getting-started-with-ipi guide calls this out for those using Vivado 2022.2. On this dialog, select Digilent as the vendor and then find the Nexys A7-100. Click the status icon to download and install the correct board file.

@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.

[JRys]

Hello,

I used Version 1.2. I believe 1.3 was uploaded yesterday. I tried both and the MIG controller consistently reported 200MHz for the ui_addn_clk_0 terminal. I had to copy the new board_files folder(attached) to Vivado in order for it to report 1.3. Extract the attached zip to \Xilinix\Vivado\2022.2\data\boards\ overwriting the \board_files\. Restart Vivado 2022.2 and retest the MIG by creating a new project and block diagram.

John

board_files.zip

[Brenden]

13 hours ago, JRys said:

Hello,

I used Version 1.2. I believe 1.3 was uploaded yesterday. I tried both and the MIG controller consistently reported 200MHz for the ui_addn_clk_0 terminal. I had to copy the new board_files folder(attached) to Vivado in order for it to report 1.3. Extract the attached zip to \Xilinix\Vivado\2022.2\data\boards\ overwriting the \board_files\. Restart Vivado 2022.2 and retest the MIG by creating a new project and block diagram.

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.

Edited January 13, 2023 by Brenden

[zygot]

On 1/12/2023 at 12:33 AM, Brenden said:

I told the IPI to generate a 200MHz clock but it actually generates 189.583Mhz.

I think that this might be your problem. If you use a clock input to the Mig PLL structure that is a pin, then you can't connect that pin to another MMCM/PLL. This can be a problem for designs that include a Mig and lots of other logic, when a board only has 1 or two external clock input pins. The solution that the MiG Ip provides is to allow you to use the unused clock outputs from it's internal PLL design that are then passed externally out of the Mig toplevel entity for use in the user design that instantiates the MiG IP. In short, it appears that your design is likely mis-wired. The additional clock that you had the MiG create is not for use by the Mig infrastructure.

A hazard with the IPI flow is potential confusion over signal naming and how it is presented by the GUI schematic/connection diagram. You could try and trace connections back through the generated Verilog source that is produced ( if it's not encrypted ) but script generated HDL is harder to read through than code written by another person whose thought processes aren't known.

I suspect that somewhere in your IPI design is the correct 200 MHz clock required as a Mig PHY reference clock for IDELAY. I have run into Vivado version related issues with the Mig for particular devices using the HDL flow, so it's still possible that there's a software bug involved, but I suspect that it's more likely a connection issue in your design.

[JRys]

you're welcome to look at my NexysA7 vivado 2022.2 project - attached.

 

NexysA7_Baremental_vivado20221.xpr.zip

[Yizakat]

 

On 1/14/2023 at 1:48 AM, zygot said:

I think that this might be your problem. If you use a clock input to the Mig PLL structure that is a pin, then you can't connect that pin to another MMCM/PLL. This can be a problem for designs that include a Mig and lots of other logic, when a board only has 1 or two external clock input pins. The solution that the MiG Ip provides is to allow you to use the unused clock outputs from it's internal PLL design that are then passed externally out of the Mig toplevel entity for use in the user design that instantiates the MiG IP. In short, it appears that your design is likely mis-wired. The additional clock that you had the MiG create is not for use by the Mig infrastructure.

A hazard with the IPI flow is potential confusion over signal naming and how it is presented by the GUI schematic/connection diagram. You could try and trace connections back through the generated Verilog source that is produced ( if it's not encrypted ) but script generated HDL is harder to read through than code written by another person whose thought processes aren't known.

I suspect that somewhere in your IPI design is the correct 200 MHz clock required as a Mig PHY reference clock for IDELAY. I have run into Vivado version related issues with the Mig for particular devices using the HDL flow, so it's still possible that there's a software bug involved, but I suspect that it's more likely a connection issue in your design.

I think this is exactly the problem.  I encountered this same issue and worked through the HDL to come up with the same calculations as the OP. 

The tutorial/example loops the ui_addn_clk_0 back as the clk_ref_i for the Mig.  This, as you say,  is Mig output driving Mig infrastructure. The clock-divider can't be tweaked to hit 200MHz although it can get pretty close.

The example project download provided by John exhibits exactly the issue being raised (at least, for me,  in my Vivado 2022.2), plus a few other timing problems.

Perhaps these don't impact the functionality of this simple design but I find them hard to ignore.

Like the OP, I provided a 200MHz stable clock to clk_ref_i to address the REFCLK critical warnings (which corrects the negative TPWS).

The negative slack can be corrected by driving other IPs (AXI etc) using the slowest ui_clk (81MHz).  Perhaps some targeted pipe-lining might be better but since DDR2 speed is a limiting factor for me, this is not a problem so I haven't dug any further.  There is probably a better solution.

Resulting in:

  

Edited April 6, 2023 by Yizakat

[JML]

I currently have the same exact problem with my Nexys A7 100T (wen through the tutorial twice and got the same critical warnings). I read through the replies and I don't quite understand what is the solution to the problem.

Any help would be appreciated.

Thanks!

 

[JML]

I have spent the last four days obsessing on this problem and here is the best oslution I've been able to achieve.

As showed before in this thread, the official tutorial still don't work for the Nexys A7-100T (https://digilent.com/reference/programmable-logic/guides/getting-started-with-ipi). My goal is to gain access to the DDR2 memory on the Nexys A7 board from Microblaze. I got the exact same results as @Brenden.

I tried to follow his suggestion that require to create a 200MHz clock for the MIG input clk_ref_i. Using trial and error, I got the ""ideal" clock generator location that got me the least critical warning. I tested a program run in the Microblaze soft core to test read/write to the DDR2 memory and everything was fine. I still need to do a lot more test and include other IP I need for my project.

I attached to the post a PDF cainting the steps I used. (I would like to include my Vivado files, but I have size limitations that prevent me to do so).

I would appreciate any feedback or help that would get rid of these critical warnings (all TIMING-6, see attached doc for more details). Maybe they can be fixed easliy, but I don't know how.

I hope that all this could help to produce a functionning tutorial for the Nexys A7.

Thanks!

Nexys-A7100T_DDR2_Microblaze_Procedure.pdf