This design is unrouteable. The router will not continue.

[DuyTrung]

Hi

I am working on a NetFPGA-1G project on a CML board(xc7k325t-ffg676) connected to FMC. When creating a bitstream, I received an error response Route:471 - This design is unrouteable. The router will not continue. To evaluate the problem please use fpga_editor. The nets listed below can not be routed.

I have wired the rgmii signals according to the Schematic of the FMC board.

http://ethernetfmc.com/downloads/EthFMC_SCH_RevE-1.PDF

Could you help me with that, please?

 

Thanks

[zygot]

You aren't supplying much information but likely it's an issue with your location constraints.

When P&R fails you should look through all of the synthesis and implementation warnings and messages up to that point. Look for anything indicating that lines in your constraints file(s) were rejected. Look for any indication that logic was optimized out of your design ( though I don't think that this is an issue for you ).

I've been able use all 4 Ethernet PHYs on the board using the HDL design flow. I had to manage Rx delays for all of them. I didn't find any of the open source material that's available to be of much use so I just developed projects as if it were a custom board prototype with no support.

[zygot]

Also, make sure that you are setting the FPGA device and package correctly in your project. And, make sure that you have a license for the Kintex-325T device or you won't be able to create a bitstream file an configure the board.

[elodg]

Unroutability of top-level ports to pins usually arises when the output primitives (ODDR/OSERDES) are placed in a different region than where the pins are. It can be due to explicit LOC constraint on the primitives or placed there automatically because of restrictions on the clock region (MMCM is in a different region). Usually there are other warnings/errors that help you figure out what is happening.

[zygot]

It's certainly possible to provide the tools with placement constraints that cause conflicts and result in a P&R failure but I've never run into this. I suppose that this might be more likely in the IPI flow since the designer is relying on the tools to handle the details. I don't ever remember having the experience of the tools automatically placing resources that result in a failure to route, at least not for DDR IO. I've certainly run into tools bugs with respect to MGT placement; in particular for using the NetFPGA-CML-1G PCIe interface where the Kintex package is different than for the KC705 board device,

Slogging through the warnings and information messages when a build can't get through bitgen is certainly a good standard practice to adhere to. When the error and warning message are confusing ( more often than I'd like ) opening the Implementation to peruse the reports and placement views can sometimes be helpful... if the tools get that far.

I've done a lot of designs involving RGMII Ethernet PHY interfaces without getting stopped by the inability of the tools to route the design. Achieving timing closure for complicated designs in which clocking restrictions are likely to be run into is a more familiar experience. I can say that, in general, Xilinx devices and tools are easier to work with than Intel devices and tools as far as clocking regions are concerned.

On very rare occasions I've been totally stumped by failure to create a configuration bitstream. Then it's off to hoping that a web search will provide a clue as to how to proceed. Different versions of the tools do have different bugs. It also doesn't help that Xilinx has a bad habit of depreciating the syntax for constraints every other tool version release and that the tools aren't always clued into the changes as far as the TCL and template features go. Still, there are a lot of (usually) helpful features in Vivado to deal with most issues once you learn where they are and how to use them. Edited April 22, 2022 by zygot