Frequency Divider is lightweight, I would not awoid it. Another way to divide frequency "for free" would be using a chained clock, derived from single desigh-wide clock (project attached), but it is hard to advise without seeing actual project
Hi. I don't really avoid Frequency Divider, but I'd like to understand why the "cleaner" solution does not seem to work as I expect.
Unfortunately your suggestion of deriving both clocks from one design-wide clock did not make a difference. I have edited and attached your project so that it now contains two D-Flip Flops to illustrate the issue. As you can see, the Path Delay Requirement uses the master clock as basis, not Clock_1 as I'd expect / want.
ChainedClocks_01_2.zip 1.3 MB
smaxein, I think that now I understand problem better. Component FIFOIn is based on Datapath, and input clock is intrnally synchronized with the BUS_CLOCK, no matter what clock you attach to it. I don't believe that using 'other' low-frequency clock can save project's timing, apart from subtitle variations due to fitter optimization. Other way to improve timing is to change temperature range to 0..+85 in the system tab of Design-Wide Resources panel. You may try also to uncheck 'sync with master-clock' in Advanced settings of the clock attached to FIFOIn This app note covers tricks to resolve timing issues http://www.cypress.com/file/179056/download1 of 1 people found this helpful
Thank you, I will read this AN later today.
I did wonder how the FIFOIn clock input works, but for this topic I believe this is not actually relevant since as I showed above, the same thing happens with simple D-Flip-Flops. The STA also shows the source and destination clocks for the signals as expected.
The AN helped me understand a few things better, and I played around some more with a logic analyzer and routing clocks to pins, so I now have a much better understanding of what actually happens in the clock system. I still think it would be possible to set up two clocks that are both synchronized to the master clock and *also* have a known phase relationship which can be used to relax timing constraints, but it appears that the system is just not intended to take advantage of that.
For anyone interested, here is what I figured out. I think it's a fairly complete picture of the solutions that could work but don't, and those that do work but have some drawbacks.
What's the problem again?
You have a signal synchronized to a clock "Clock 1" going to a block that is synchronized to a clock "Clock 2". The two clocks are derived from the same "Source clock" which is in turn derived from the master clock. All clocks are also synchronized to the master clock. I would expect that the path delay requirement for that signal depends on Source Clock, but instead it depends on the master clock.
Consider that you have a signal going from a 4KHz clock to a 2KHz clock in your design, both derived from the same 10KHz clock. The actual path delay requirement would be 10KHz (or maybe even lower if we assume that the dividers of Clock 1 and Clock 2 are synchronized), but the fitter will assume a path delay requirement corresponding to the master clock, which could be 60MHz. This would put a lot more pressure on the fitter to find short paths between these really uncritical components, and ultimately may cause the fitter to not find an acceptable solution for the design.
What doesn't work
If you divide one clock from another and synchronize to the master clock, this will introduce three master clock cycles of delay to the new clock. So unless the source clock is divided from the master clock with some multiple of 3, you will not get a useful phase alignment. And even if it is, the fitter doesn't take advantage of that (I'd have been very surprised if it did ;)).
However, in the scenario above, both Clock 1 and Clock 2 get the same 3 cycle delay when being derived from the source clock, so they are actually always phase aligned with each other (though not to the source clock). Still, the fitter does not take advantage of that predictable relationship.
It would also be possible to skip Source Clock entirely and derive both Clock 1 and Clock 2 directly from the master clock, and have their dividers synced to get the desired phase alignment. The description of CLKDIST_LD in the registers TRM talks about how to achieve that. However, the fitter would then have to assume that the dividers always stay in sync, and long story short, it won't care.
So in short, the only thing the fitter cares about is that both clocks are synchronized to the master clock. It ignores that the clocks have evenly divisible frequencies and are phase aligned.
Another option would be to not synchronized the derived clock to the master clock but simply accept that it is delayed a bit from the source clock. However, the system does not treat such a clock as synchronized to the source clock plus a delay, but instead throws up its hands and declares the derived clock to be asynchronous, so it cannot work out timings at all.
What does work
Using a frequency divider component to generate Clock 1 and Clock 2 from Source Clock takes up a few macrocells, but you do end up with signals that the fitter understands as being synchronized to the Source Clock and that you can use as a clock. Generating the Clock 1 and Clock 2 as actual clocks and then synchronizing them to the source clock with a Sync component will achieve a similar result (though with a delay, obviously) and uses part of a Status register resource.
However, since the results of those two options is really routed signals and not clocks, they don't *quite* act as clocks, but will instead be used to gate the Source Clock. One pulse of the routed signal will enable one pulse of Source Clock for the clocked component. This probably removes some headaches with timing but also creates an additional one cycle delay.
As far as I can tell, the issues with the non-working solutions are only limitations in the fitter, not restrictions due to the hardware. I doubt we will get improvements in that specific area (it would probably quite a bit of work), but it might allow the fitter to find solutions for some designs that it currently cannot. Meanwhile, we can use the solutions I described which use routed clocks, but I see these as workarounds since they take up UDB resources and introduce delays which are not technically necessary to achieve the same thing.
Whew, that became much longer and took much more time than I intended. Maybe I should start a blog some day ;)