cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
j0n
Adventurer
Adventurer
1,720 Views
Registered: ‎09-28-2017

MIG 7 Routing conflict detected [35-279]

Jump to solution

Hi, 

I am trying to implement my design after generating the Xilinx MIG7 IP for DDR3 memory. 

One of the design choices was to set the system clock and reference clock in the MIG7 wizard as "no buffer" since I will supply the clock to the MIG7 interface internally (using the device input clock to a MMCME2 and from it output a 400 MHz clock to the MIG).

Synthesis goes fine and I checked the synthesized design schematic (looks fine), but then during implementation I get a critical warning and notice that several MIG signals are not routing. The first critical warning I am trying to solve: 

[Route 35-279] Routing Conflict Detected. Wire RIOI3_TBYTESRC_X57Y93/IOI_OCLK_0 needed to route FE_FPGA_MIG_v3_GENE.DDR3_Xilinx_Controller/u_mig_7series_0_mig/u_memc_ui_top_std/mem_intfc0/ddr_phy_top0/u_ddr_mc_phy_wrapper/u_ddr_mc_phy/ddr_phy_4lanes_1.u_ddr_phy_4lanes/ddr_byte_lane_D.ddr_byte_lane_D/oserdes_clk_delayed is used up by ClockMMCMModule_inst/O2169[1]

I could locate O2169[1] in my synthesized schematic from my ClockMMCMModule, it is one of its outputs. Does this mean that this output is somehow using away resources that the MIG requires to route its signals?

I have tried looking in the implemented design Device View and cannot find why this conflict is happening. I have also not been able to locate the wire RIOI3_TBYTESRC_X57Y93/IOI_OCLK_0 because the search function apparently does not work for wires..?

I believe I followed the guidelines correctly and let the MIG generate the pinning locations + constraints of the bank it is using (I have not touched it). As for the system clock to the device, i placed it in an adjacent bank. Any guidance in this matter would be appreciated.


 

0 Kudos
1 Solution

Accepted Solutions
jheslip
Xilinx Employee
Xilinx Employee
1,628 Views
Registered: ‎06-30-2010
effectively what you have here is cascaded MMCM => PLL which is not supported, if you look at Fig 1-52 that @ryana mentioned you can see that the Sys_CLK connects to a PLL. so when you use the MMCM output =? Sys_CLK that will connect to a PLL internally in the IP, if you double click on the SYS_CLK input in the schematic view you will see the connection.
Assuming you want to use some of the MMCM outputs in the rest of your design and save an on board oscillator, what you should do is use that MMCM in parallel so have your differential SYS_CLK going to both the MIG SyS_CLK AND the MMCM input.
-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------

View solution in original post

15 Replies
jheslip
Xilinx Employee
Xilinx Employee
1,706 Views
Registered: ‎06-30-2010
the MIG clocking requirements are quite strict, when using an internal clock such as this case it must be within the Same SLR and the same column. The fact that you have it in an adjacent bank I assume these have been met, where is the MMCM placed?

It looks like this O2169[1] is a MIG clock to the idelays, what clock out is it using?

Is the MMCM being used for other on MIG clocks also?
For these types of issues it is sometimes est to go back to a basic design, the example design is usually best and then modify the clock to the final setup you want and verify that all works, if it does then add back in the rest of your design and see what connection is causing the problems.
-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
j0n
Adventurer
Adventurer
1,696 Views
Registered: ‎09-28-2017

Hi jheslip,

Thank you for the quick reply.
I believe they are in the same column too. I am using an Artix7 100T device and the MIG is placed in bank 35 and the input clock to the FPGA is in bank 34.

The O2169[1] is generated from my ClockMMCMModule which basically just contains one MMCME2. The input of this MMCME2 is the FPGA input clock. O2169[1] is an output of this MMCM.
The O2169[1] clock is not an input to the MIG module (I double checked this in schematic). The input clock to the MIG module is one of the other MMCME2 output clocks from the ClockMMCMModule (in total I have 4 clock outputs from this MMCM and I feed them to different modules in the design).

0 Kudos
jheslip
Xilinx Employee
Xilinx Employee
1,691 Views
Registered: ‎06-30-2010
If its an Artix-7 then there is no SLT, Bank 34 and 35 should be adjacent, if you can try and reproduce this in the example design can you share the DCP?
-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
ryana
Moderator
Moderator
1,667 Views
Registered: ‎11-28-2016

Hello @j0n,

The first part is concerning since it's not supported by the MIG:


One of the design choices was to set the system clock and reference clock in the MIG7 wizard as "no buffer" since I will supply the clock to the MIG7 interface internally (using the device input clock to a MMCME2 and from it output a 400 MHz clock to the MIG).


The MIG expects the system clock to enter the FPGA at a clock capable IO within the same I/O column as the memory interface.  
From UG586:
mig_clocking.PNG

The next part of the error sounds like a conflict resource between what the MIG wants to use and with the clocking elements selected in the user design.  Start with the Design Guidelines section starting on page 192.  Next take a look at the Clocking Architecture section starting on page 120.  These talk about the MIG expectations regarding MMCMs and PLLs. From the sounds of the behavior it's likely the MIG is trying to use something that's already used by user logic.

mig_clk_arch.PNG

j0n
Adventurer
Adventurer
1,649 Views
Registered: ‎09-28-2017

Hi @ryana 

Thank you for the input. Regarding your first point: 

I have the system clock going into a clock capable IO in the adjacent bank which satisfies the requirement of it being in the same I/O column as far as I can tell (maybe I misunderstood an am mistaken with this?). This is bank 34 (region X1Y1) and 35 (ragion X1Y2) of the Artix 7 100T.

Your snippet from UG586 says "the PLL must be located in the bank containing the clock sent to the memory". I believe this is what I am doing. 

sys_clk enters FPGA at clock capable IO in bank 35 -----> the MMCM is in this same region X1Y2 ------> MMCM output to the MIG in bank 34

Do you still think the way I am doing this could be incorrect?

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Update on possible solution: 

So I went back to the basics while looking at the example design as @jheslip proposed.
I then regenerated my MIG7 IP in the design, this time trying to let the tool place all the pins in one bank by itself. I had actually modified my .XDC because originally the MIG placed everything in two banks. This time I disabled data masking and chip select so all the address and control pins fit in two byte groups. So all the data signals fit in two groups as well, allowing the MIG to place everything in one bank. Since this was done, and using the same clocking structure as I mentioned in the first part of the post, the design has no problems routing any signal. 
I know it is not recommended to manually override the constraints of the MIG generator, so maybe this is where it went all wrong?

0 Kudos
jheslip
Xilinx Employee
Xilinx Employee
1,640 Views
Registered: ‎06-30-2010

@j0n @ryana discussed this yesterday we were a bit unclear as to the clocking used, if it was SysCLK IN => Your Own MMCM then an MMCM output to MIG then that would be an issue. The No Buffer usage is intended to allow the user to use that SYS CLK with both the MIG core and Another MMCM. 

Could you add a screenshot of the clocking topology perhaps?

Based on your latest test it sounds like you are good to go, the MIG DRCs are very robust and if they are allowing the clocking topology that you have then that suggests it is valid, again we can take a look at the topology if you would like to add it here.

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
j0n
Adventurer
Adventurer
1,635 Views
Registered: ‎09-28-2017

Hi @jheslip

Here is a screenshot of the synthesized schematic (I edited a little bit in paint to make it more clear and pin/signal names according to what we have discussed. The design is big so I had to cut and paste the MIG closer to the clock module for convenience). 

schematic.png

Basically, sys_clk differential comes in. Goes to a IBUFDS, the output is the input clock of the MMCME2 in my clock module. The clock output of the MMCM is buffered with BUFG and fed directly to the MIG sys_clk_i port. 

I am not sure if this is what you mean would cause an issue.

0 Kudos
jheslip
Xilinx Employee
Xilinx Employee
1,629 Views
Registered: ‎06-30-2010
effectively what you have here is cascaded MMCM => PLL which is not supported, if you look at Fig 1-52 that @ryana mentioned you can see that the Sys_CLK connects to a PLL. so when you use the MMCM output =? Sys_CLK that will connect to a PLL internally in the IP, if you double click on the SYS_CLK input in the schematic view you will see the connection.
Assuming you want to use some of the MMCM outputs in the rest of your design and save an on board oscillator, what you should do is use that MMCM in parallel so have your differential SYS_CLK going to both the MIG SyS_CLK AND the MMCM input.
-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------

View solution in original post

j0n
Adventurer
Adventurer
1,619 Views
Registered: ‎09-28-2017

Hi @jheslip

Thanks again. I see, that does make sense and it is clear I am doing something that is not supported for the MIG. 

"so when you use the MMCM output =? Sys_CLK that will connect to a PLL internally in the IP, if you double click on the SYS_CLK input in the schematic view you will see the connection."

Do you mean, internally in the MIG IP? If so, then yes. When I follow the sys_clk signal eventually it arrives at the "u_ddr3_infrastructure" module located inside the MIG. The sys_clk signal goes to a PLLE2_ADV. 

"Assuming you want to use some of the MMCM outputs in the rest of your design and save an on board oscillator, what you should do is use that MMCM in parallel so have your differential SYS_CLK going to both the MIG SyS_CLK AND the MMCM input."

I think I had a wrong understanding of how the MIG was working, these are the values I entered on the wizard: 

screen1.PNGscreen2.PNG
If I understand now correctly, the Clock Period refers to the clock frequency that my DDR3 will be operating at. Is this correct?

For the input clock period, this is the input to the MIG's PLL that we have been discussing. 
The issue I see is that I only have one on board oscillator operating at 200 MHz. Does this mean that my Input Clock Period value should be 200 MHz?  I cannot seem to find a 200 MHz option, only numbers around it on the drop down list. I suppose I need to choose a different Clock Period value to be able to choose 200 MHz for the Input Clock Period?  

0 Kudos
jheslip
Xilinx Employee
Xilinx Employee
1,615 Views
Registered: ‎06-30-2010
Correct internally, you will see within the MIG IP there is the PLL on the SYS CLK, under normal usage that is driven directly from the differential IO which is part of the IP. When you select no buffer then the user has some control over the Differential Io and can use that same clock to drive a separate MMCM in parallel.

regarding the 2 clock speeds screenshots, the one on the left is the interface clock and the one on the right is the Sys CLK frequency, this is dependant on the interface speed and also the M and D values that we have characterized, so the frequencies available are limited by that.

I assume there is one close to 200Mhz? Let's say there are a 198Mhz and 204Mhz, I would suggest picking the 204Mhz.

What will happen in this case is the interface will run slightly slower if you pick 204Mhz and your interface is running at 666Mbps (333Mhz) the PLL will be doing a 1.63 Multiplication. If you then supply a 200 Mhz clock the PLL will still do a 1.63 Multiplication but the output will now be at 326Mhz (652Mbps). However if you were to go with the 198mhz setting that would be a 1.68 Multiplication, if you then supplied a 200mhz clock you could run at 36Mhz (672Mbps) which could mean that the design is under constrained, so I would always recommend to take the more cautious approach and run slightly slower if the optional oscillator is not available.
-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
j0n
Adventurer
Adventurer
1,605 Views
Registered: ‎09-28-2017

Hi @jheslip,

Thanks you for the clear explanation. 
I ended up settling for a 326.26 MHz for the interface clock period. With this value I can get a close enough value for the PLL input clock of 200.763 MHz. 
I suppose an advantage for this is that according to UG586 page 41: 

"The Use System Clock option appears when the input frequency is between 199 and 201 MHz (that is, the Input Clock Period is between 5,025 ps (199 MHz) and 4,975 ps (201 MHz)."

So I can select Use system clock for that reference clock making life a bit easier :) 

I still keep using system clock as no buffer, but now feed the clock to the MIG in the recommended way: 

system_clock to the differential buffer, from here I have a connection going to the MMCME2 and another one going to the MIG:

 schematic3.png

This synthesizes and implements with no routing conflicts (or errors). 

0 Kudos
jheslip
Xilinx Employee
Xilinx Employee
1,600 Views
Registered: ‎06-30-2010
looks good I think you are all set for this now
-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
j0n
Adventurer
Adventurer
1,585 Views
Registered: ‎09-28-2017

Hi @jheslip,

Can I ask you one last additional question that I cannot figure out? It is regarding the PLL calculation inside the MIG. Or should I make a new topic for this question?

In UG586 page 120, Input Clock Guidelines, I can see that it shows the relationship between input period and memory period as Input Period = (Memory Period x M) / (D x D1)

Now my memory period is 326.26 MHz and the input period is 200.763. I cannot solve for these values using the parameter values in the verilog file of the MIG. 
In mig_7series_v4_1_infrastructure.v, the MIG has generated: 

parameter CLKFBOUT_MULT   = 4,        // write PLL VCO multiplier
   parameter DIVCLK_DIVIDE   = 1,        // write PLL VCO divisor
   parameter CLKOUT0_PHASE   = 45.0,     // VCO output divisor for clkout0
   parameter CLKOUT0_DIVIDE   = 16,      // VCO output divisor for PLL clkout0
   parameter CLKOUT1_DIVIDE   = 4,       // VCO output divisor for PLL clkout1
   parameter CLKOUT2_DIVIDE   = 64,      // VCO output divisor for PLL clkout2
   parameter CLKOUT3_DIVIDE   = 16,      // VCO output divisor for PLL clkout3
   parameter MMCM_VCO             = 1200,     // Max Freq (MHz) of MMCM VCO
   parameter MMCM_MULT_F          = 4,        // write MMCM VCO multiplier
   parameter MMCM_DIVCLK_DIVIDE   = 1,        // write MMCM VCO divisor
   parameter MMCM_CLKOUT0_EN       = "FALSE",  // Enabled (or) Disable MMCM clkout0
   parameter MMCM_CLKOUT1_EN       = "FALSE",  // Enabled (or) Disable MMCM clkout1
   parameter MMCM_CLKOUT2_EN       = "FALSE",  // Enabled (or) Disable MMCM clkout2
   parameter MMCM_CLKOUT3_EN       = "FALSE",  // Enabled (or) Disable MMCM clkout3
   parameter MMCM_CLKOUT4_EN       = "FALSE",  // Enabled (or) Disable MMCM clkout4
   parameter MMCM_CLKOUT0_DIVIDE   = 1,  // VCO output divisor for MMCM clkout0
   parameter MMCM_CLKOUT1_DIVIDE   = 1,  // VCO output divisor for MMCM clkout1
   parameter MMCM_CLKOUT2_DIVIDE   = 1,  // VCO output divisor for MMCM clkout2
   parameter MMCM_CLKOUT3_DIVIDE   = 1,  // VCO output divisor for MMCM clkout3
   parameter MMCM_CLKOUT4_DIVIDE   = 1,  // VCO output divisor for MMCM clkout4
   parameter RST_ACT_LOW           = 1,
   parameter tCK                   = 1250,

Using the above values, Input Period = (Memory Period x M) / (D x D1) then Input Period = (326.26 * 4) / (1 * 16) = 81.565 MHz
This is not the expected 200.763 MHz. Do you know what I am calculating wrong? I just want to double check that the MIG has set the correct parameters for the desired clocks that I defined in the wizard.

I am also interested in knowing how you calculated the factors 1.63 and 1.68 in your example in your reply post above, since I would like to perform the same type of calculation of bandwidth but with my new input and memory interface frequencies. 

0 Kudos
jheslip
Xilinx Employee
Xilinx Employee
1,580 Views
Registered: ‎06-30-2010
a new topic would be best on this, the example I gave was just a simple division 666/ 198 or 204 as I didn't have your MIG IP setup to do an exact calculation.
-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
j0n
Adventurer
Adventurer
1,575 Views
Registered: ‎09-28-2017

I see, I understand now how the 1.63 and 1.68 came about (cannot believe I did not realize this). I will make a new thread for the specific PLL question. Thanks.

0 Kudos