I have a design that will use rather many clocks, because several external components bring their own, and I'd like to verify that it will be possible to route all those clocks in a sensible way. Ideally, I'd like to do this first so I can see whether I need to add additional clock buffers to the board before I do the first spin.
My approach so far has been to implement a bit of dummy logic that just shovels data around in a clock-dependent manner between the hard IP blocks and see whether that compiles, but in the current project, this seems to have hit a limit, and interpreting the warnings has become guesswork.
For the current project: I have an 5CGXFC5C6F23C7, which should be fed a 500 MHz refclock for the PMAs through REFCLK0L and REFCLK1L, and which should run DDR3 memory on both the top and bottom hard IP controllers as well as four RGMII ports distributed across the remaining I/O banks.
The dummy project seems to compile alright, but I get lots of critical warnings about jitter if I try to derive a clock for the DDR3 blocks from the REFCLK0L input via the (0,13) fPLL, because the only connection from (0,13) to (0,53) and (68,0) is via a GCLK network, and I'd be feeding a divider output into a PLL again. Since the (0,13) and (0,29) VCOs are running at 1500 MHz fixed (as TX clocks for the PMAs), I can't route a PHOUT across either.
The best idea I have so far is a gross hack where I merge the PLLs for the DDR3 into the transceivers, which would limit the DDR3 interfaces to 750MHz -- or I could change the board to add more clock inputs, and route the clocks around the FPGA, but I doubt that would be much better than just accepting the warning about the GCLK network, and would be considerable effort in extra components, and would therefore have to be decided early.
Since I doubt that this is the last complex project, I'd like to know what would be the best method to verify that the clock tree I'm planning makes sense.