1.
You mean if there are multiple paths due to different clocks, I have to look for the path with from/to same clock with worst case slack is the critical path. But 8.607ns is also not within same clocks. Its from clk to clk_100. Isn't it?
Yes it is from clk to clk_100.
Now your cross clock domain might be the worst case path but you'll have to analyze all the clock-to-clock paths to determine which is the worst.
2.
Where this 34.428 (4*8.607) comes from?
I deduced it from the timing reports as the edge to edge timing shows launch edge at 30 ns (clk_100) and the capture edge at 40 ns (clk). So the timing diagram of the two clocks must look like this:
Code:
0 10 20 30 40
___ ___ ___ ___ ___
clk_100 __| |___| |___| |___| |___| |
______________ ___
clk __| |_______________|
^ ^
launch capture
edge edge
Therefore if the clk_100 has a minimum period of 8.607 ns then the minimum period of clk would be 4 times that or 4*8.607 (34.428 ns).
Does that make more sense?
3.
Why the Minimum period is 25.219ns in this design? Why not 8.607ns?
I already explained this above, the functional minimum would be 8.607 ns for clk_100 and 34.428 ns for clk, if you want the transfers between the two domains to keep working correctly.
4. If we have to run this design in real on FPGA, this 25.219ns will determine the maximum frequency to operate? or it will correspond to 8.607ns?
Same answer as Q2 &Q3. I think you need to do more studying about calculating setup and hold timing of a register to register path. Look up "How to calculate setup and hold time", you should get a lot of results on google.
I have attached the timing constraints screenshot. The first constraint is the actual clock constraint define in ucf file while other constraint auto generating as we are using DCM to scale down this original clock to multiple clocks.
You don't show any paths to/from the *0.8, *0.6667, *0.5, and *.4. Just be aware that you better have a methodology for handling asynchronous clock domains if you ever use the 0.8, 0.6667, and 0.4 as they will have edges which are less than 10 ns and in the case of the 0.6667 clock there will actually setup time requirements that are extremely close to 0 ns and impossible to meet. From what I've seen from the current STA results you aren't doing any cross clock domain synchronization between the 100 MHz and the 25 MHz (I guessed correctly), which is okay as the rising edges of the slower clock always lines up with a rising edge of the faster clock (integer multiple of the slower clock). This will also be the case with the 0.5 or 50 MHz clock, which you will be able to cross between the three clocks 100 MHz, 50 MHz, and 25 MHz without synchronization. Just make sure you use some clock crossing scheme if you start using any of the other clocks.