Vivado 2014.2 MMCM and BUFGMUX multiple syncronous clock

Question

Hi,
I am working on KC705 and I use Vivado 2014.2. The block diagram of the clocking structure and the system as below.
I generated 3 clocks (250 MHz, 125 MHz, 62.5 MHz) from the input clock (250 MHz).  Because of the BUFG-BUFG error I select clocking wizard output with no buffer option. Then I select the clocks by using BUFGMUX. Finally, I have 4 clocks that I used in the whole design. All clocks should be synchronous to each other.
How can I constraint these clocks? I tried to specify period seperately for each clock but the timing did not met.
Thanks,
Muhammet

Answer 1

So, first, you don't need to add any constraints. You don't say how the clocks are generated, but I assume you are using an MMCM. If so, then the tool can derive all the clocks from the input clocks - simply do a create_clock on the input clock and all the other clocks will be automatically generated (you don't need any create_generated_clock commands).
The multiplexed clock will be complicated - the output of the two cascaded BUFGMUXes will carry all three clocks; the 250, the 125 and the 62.5. The tools will actually perform timing analysis on all FFs on this domain 8 times - between each pair of clocks. But, since all the clocks are multiples of eachother, this will effectively constrain paths to the 250MHz clock.
The paths between the multiplexed clock and all other clock domains will be effectively timed at 250MHz. Assuming that there are legal crossings between the MUXed clock and all three domains (regardless of which mode is selected for the MUXed clock), this too is correct. If there are some restrictions (like there will never be an active path from the MUXed domain to the 62.5MHz domain when the MUXed domain is selecting one of the faster clocks), then exceptions will be required to loosen the requirements on these paths.
All that being said, this is a BAD thing to do in an FPGA. Having different outputs of an MMCM take paths through different numbers of BUFGs introduces very nasty clock skew between the different domains. This will result in huge hold time violations that need to be fixed between the un-MUXed domains and the MUXed domain. This will likely fail timing analysis, and even if it does pass, will require lots of extra routing resources to fix the hold violations.
I am not entirely certain what you are trying to accomplish by using the different domains. Since the 250MHz clock can be selected, all logic will have to be able to run at that speed, so there is no timing advantage to using the slower domains. If the slower domains are needed for functional reasons, then, rather than using clock MUXing, I would suggest using a single BUFGCE for the "multiplexed" domain, driven by the 250MHz output of the MMCM, and enabling the CE all the time (for 250MHz operation), every other clock (for 125MHz operation), or every 4th clock (for 62.5MHz operation). Using the BUFGCE, no generated clocks will be created - the tool will view the BUFGCE as a simple clock buffer, and everything will end up being timed on the 250MHz domain. In this case, there is only one domain on the output of the BUFGCE (250MHz), rather than 3 clocks - this will actually speed up place and route (since there are less timing paths).
All 4 domains will end up going through exactly one BUFG or BUFGCE (which are identical resources), and hence will have no extra clock skew - this will avoid the hold time issue I described above.
The only caveat is if you are planning to use the falling edge of the "multiplexed" domain. In all modes, the clock will be high for only one half period of the 250MHz domain; for 250MHz operation this will result in a normal 50/50 duty cycle. For 125MHz, though, the duty cycle will only be 25% and for the 62.5 it will be 12.5%. Again, this is only an issue if you use the falling edge for clocking logic (which is a bad design practice) or if you use an IDDR or ODDR for interfaces.
Avrum