08-08-2013 02:21 AM
I am developping a code which makes use of a MIG module on a spartan 6 FPGA.
Now I supply the command, write, read and system clocks (c3_p0_cmd_clk, c3_p0_wr_clk, c3_p0_rd_clk, c3_sys_clk respectively) from an IP core clock generator. In total I use 3 clock generator modules; connected in series (the clock input of each of the modules comes from another clocking module).
When I try to 'Generate Programming file', the ISE returns an error saying that the design is unrouteable. When I go in design summary -> place and route report it says:
This design is unrouteable.
To evaluate the problem please use fpga_editor.
Routing Conflict 1:
Net:Clocking_module/clkout1 on pin I0 on location BUFGMUX_X2Y12
Net:GLOBAL_LOGIC0 on pin I1 on location BUFGMUX_X2Y11
Conflict detected on wire: PINFEED(9102,371)
The first net 'BUFGMUX_X2Y12' is the output buffer of one of the clocking modules which supplies the 'c3_p0_wr_clk'.
The second net, 'BUFGMUX_X2Y11' is a 'BUFGCE' buffer module in the 'memc3_infrastructure.vhd', namely 'U_BUFG_CLK1'. The input of this buffer comes from a 'PLL_ADV' module namely 'u_pll_adv' also in 'memc3_infrastructure.vhd'. The input of this pll is 'sys_clk_ibufg' which is mapped from the 'c3_sys_clk '.
I have tried removing the buffers so to remove the conflict for testing purposes but it still won't work..
Thanks for your time. Good day
08-11-2013 08:11 AM
The BUFGMUX's in Spartan-6 come in pairs that share routing resources on the input pins. I0 of one clock buffer shares resources with I1 on the other and vice versa. You cannot have more than one signal connected to these paired pins. Since in your case one of the signals is GLOBAL_LOGIC0 which is not a valid clock net, I suggest looking into whether that connection could be removed which would alleviate the conflict. Another option is to move one of the BUFGMUX's to another site to alleviate the conflict.
08-13-2013 02:22 AM
Thanks for your reply.
I have been working on this issue since, but I haven't found a solution yet.
I have used 'FPGA editor' to ensure that the conflicting buffer isn't used. When I re-ran ISE, the conflicting buffers were re-mapped to another location and again the same conflict was prompted. So i re-did the same thing. Next time i ran ISE, it prompted that there is no available location to put the buffers.
I noticed from FPGA editor, that I only have two BUFGMUX instances, one for each MIG instance I have ; the memc_infrastructure.vhd uses a BUFGMUX. One of the BUFGMUX has the BUFG immediately adjacent to it unused, whereas the other has. The conflict is prompted for the latter case.
Whatever displacement I do to any of the conflicting buffers will still return an error.
With regards to your other point, you have said that 'GLOBAL_LOGIC0 ' is not a valid clock net.. What do you mean by this, and how can I change this 'setting'?
Thanks for your time.
08-13-2013 05:38 AM
Whilst searching the design summary reports for clues I notice that the chip I'm using (xc6slx150 -3fgg484) has just 16 BUFG/BUFGMUXs available and I am using 15. So maybe that's why the conflict is un avoidable, as there is no other space to avoid the conflict.
Using the FPGA editor I can see where the BUFG/ BUFGMUX are being used. They are all being used in the Clocking modules I generated via the IP Core generator. as shown in the attached image. So if these DCMs are strictly required, how can I avoid using BUFGs? Can I just remove them? What would be the effect?
Thanks for your time.
08-13-2013 07:25 AM
Attached with this post is an image describing how the various clocking modules i have instantiated via the ip core, are connected. The numbers in bold written near the signal names correspond to the numbers in the left most column of the table attached to my last post.
08-13-2013 01:36 PM
GLOBAL_LOGIC0 is a constant zero, aka GND. It cannot be used as a clock signal unless the intent is to stop the clock. You'd be better off using the clock enable at the register since the clock logic is on the edge of being over utilized.
08-13-2013 11:24 PM
That's a lot of clocks. Do you really need ALL of them? Could you do any clock optimisation?
For example, you generate a 54MHz and a 108MHz clock. Is it possible to just generate the 108MHz and then use a localised clock enable to operate at 54MHz?
Could chipscope use a different clock (135MHz isn't synchronous to any other clock in the system, so what data is being captured at this frequency)?
Possibly with less clocks, you may have a routeable design ...
08-14-2013 12:24 AM
Thanks for your reply guys.
The Instance from where the GLOBAL_LOGIC0 is coming is defined below:
U_BUFG_CLK1 : BUFGCE port map ( O => mcb_drp_clk_sig, I => mcb_drp_clk_bufg_in, CE => locked );
Now this is generated by the ip core generator, in the memc_infrastructure.vhd of one of the MIG I am using. So I really have no control on it. If its a GLOBAL_LOGIC0 I can do nothing I guess.. or should I just comment this instance? Will the MIG still work properly?