- Newest
- Most votes
- Most comments
Dear customer
Thank you so much for your interest in AWS. Just to make sure, so you tried few different approaches and some of them seem to be working. But just wanted to make sure, if any of the working apporaches is okay and why using "clock gating" is a highly discouraged option. Is that correct?
Thanks
Thanks for looking into this.
Suppose my questions at this point are:
- What is the canonical way to implement a gated clock on F1? Spitballing but maybe I should be gating something other than clock_main_a0, e.g. whatever clock drives it if it's accessible in the CL.
- If the MMCM cascade pair is the canonical approach, why is using an MMCM cascade pair highly discouraged? (Clock gating itself is fully supported and not discouraged by Xilinx.)
- If the MMCM cascade pair is the canonical approach, is there a way to have the MMCM output clock treated as the same as the MMCM input clock from a Xilinx tools perspective? They are the same clock even in phase from what I can tell but place and route isn't behaving like they're different.
What I'm doing now is workable but suboptimal for my design, especially around question 3, as I need to put two registers or false path between the shell and post MMCM CL clock transition to make anything meet 250 MHz timing.
Dear customer
1.) clk_main_a0 is generated inside the shell and the clock driving clk_main_a0 is not accessible to CL.
2.) MMCM connected to clk_main_a0 with set_property CLOCK_DEDICATED_ROUTE ANY_CMT_COLUMN is a valid possible option for clock gating on F1. It is discourage because of the "extra delay", which is expected with this clocking structure. One possibility is to try PLL Vs MMCM to see if the delay improves.
3.) Cross clock crossings timing paths are expected as a new clocking structure is created with MMCM or PLL. Clk_main_a0 is different than the new clocking structure so it’s timed differently. However, it is recommended to make sure that these paths can be set_false_path as normally they are true paths that need synchronizers
Thanks
Thanks. Seems like the MMCM cascade pair is just a weird thing to do from a Xilinx content but makes sense for the F1 use case. For anyone else looking into this, I ended up treating the shell and CL clocks as async and run my design off the CL clocks as it wasn't a huge deal with my design. I did notice thought that using the MMCM feedback clock with a post BUFG generated mirror clock brought down the clk_main_a0 to CL clock skew so it was possible to rely on the phase relationship to cross clock domains for 250 MHz but didn't seem to be the case at 500 MHz.
Relevant content
- asked a year ago
- asked 3 years ago
- asked 4 years ago
- AWS OFFICIALUpdated 8 months ago
- AWS OFFICIALUpdated 2 years ago
- AWS OFFICIALUpdated 2 years ago
- AWS OFFICIALUpdated 10 days ago
Some observations and follow up question now that I've been working with the gated clock design:
It solved my primary timing problem and seems to be a good choice for my design, though there are secondary issues. The post MMCM clock has an inferior pessimism of ~0.10ns vs the clock_main_a0 so is generally inferior. The Xilinx tools treat clock_main_a0 differently than the MMCM clocks so I'm having timing problems at the interface between the shell and CL, which I can work around by inserting a register and constraining that register to the same SLR as the shell signal (without the constraint the tools kept putting the register after a SLR crossing and failing timing). I'm kind of surprised by 3 and curious if this is the expected behavior or there's something I should be doing with the MMCM to get the post MMCM clocks treated as effectively the same as clock_main_a0? The design didn't have any timing problems at these points before.