UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Explorer
Explorer
6,053 Views
Registered: ‎09-22-2010

Unrouteable design

Hi Guys,

 

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:

 

ERROR:Route:472 -
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..

 

Any ideas?

 

Thanks for your time. Good day

 

 

0 Kudos
7 Replies
Xilinx Employee
Xilinx Employee
6,010 Views
Registered: ‎07-01-2008

Re: Unrouteable design

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.

Explorer
Explorer
5,987 Views
Registered: ‎09-22-2010

Re: Unrouteable design

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.

 

regards

0 Kudos
Explorer
Explorer
5,979 Views
Registered: ‎09-22-2010

Re: Unrouteable design

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.

Capture3.PNG
0 Kudos
Explorer
Explorer
5,968 Views
Registered: ‎09-22-2010

Re: Unrouteable design

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.

image001.png
0 Kudos
Xilinx Employee
Xilinx Employee
5,958 Views
Registered: ‎07-01-2008

Re: Unrouteable design

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.

0 Kudos
Mentor hgleamon1
Mentor
5,949 Views
Registered: ‎11-14-2011

Re: Unrouteable design

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

----------
"That which we must learn to do, we learn by doing." - Aristotle
0 Kudos
Explorer
Explorer
5,943 Views
Registered: ‎09-22-2010

Re: Unrouteable design

Thanks for your reply guys.

 

@bwade

 

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?

 

Thanks again

0 Kudos