Using 60MHz as Master clock and bus clock for my project, I ran into some setup time issues between various components in my design, so I decided to use a slower 30MHz clock (which I dubbed CLK_DIV2) for my components except where a faster clock is needed. I figured that that would give the fitter some more room to find a solution, and it seems to have improved things somewhat.
I am using another clock (CaptureClock, 6MHz, derived from CLK_DIV2 with a divider of 5) to capture data into a FIFO, using the FIFOIn component from the PSoC Sensei blog. The captured data is synchronized to CLK_DIV2.
I would expect the path delay requirement for the captured data from the sync blocks to the FIFO to be at 30MHz, since the source clock has that frequency and the destination clock is divided down from the source clock (and thus should be "in phase" with it). However, when investigating more timing warnings I found that the report file shows a 60MHz requirement.
Looking into the TRM I saw that the CaptureClock will not really be divided down from CLK_DIV2 but instead both will be derived from the BUS_CLK, but I see no reason why they couldn't be set up to be "in phase" so that there will always be two BUS_CLK cycles between a rising edge on CLK_DIV2 and a rising edge on CaptureClock.
I can achieve what I want using the Frequency Divider component, but that takes up UDB resources and may put more "pressure" on the fitter again.
So: Is there a way to configure my two clocks CLK_DIV2 and CaptureClock so that the path delay requirement between them is determined by CLK_DIV2 instead of by the master clock?
Solved! Go to Solution.
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.
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 😉