I have a source clock 125MHz (ck125), and it has a derived clock
25MHz(ck25). I find that Quartus generates ck25 by the clock tree of ck125. To a register A (regA), ck125 has a clock arrival time 4ns. To the register which generates ck25 and is clocked by ck125, the ck125 also has a clock arrival time 4ns. A register B (regB) is clocked by ck25, and there is path from regB to regA. Shortest clock path from ck125 to regA is 4.5ns. Longest clock path from ck25 to regA is 12ns. Quartus say the Largest clock skew is -7.5ns, and the Largest regB to regA requirement is 0.5ns. (125MHz is 8ns period, 8 - 7.5 = 0.5 ) Unfortunately, i have a path from regB to regA is1ns. What can i do...? QQ
=46rom your description, I'm guessing that your derived clock ck25 is done via flip flops and trying to synthesize a 25 MHz clock from a 125 MHz clock....this method is prone to failure in FPGA land due to the unavoidable skew between these two 'clocks' as you're witnessing.
The much better approach is to simply clock everything with the 125 MHz clock and use ck25 as a clock enable.
Example: process(Clk125) begin if rising_edge(Clk125) then if (Ck25 =3D '1') then -- Put stuff here that needs to be 'clocked' by 25 MHz end if; end if; end process;
ck25 simply needs to be a one clock cycle pulse that is active every
5th clock cycle, you should be able to modify your existing code that generates ck25 to do this.
The other method would be to use a PLL to divide down the 125 MHz to create a real 25 MHz clock that is phase aligned with the 125 MHz...but it would be simpler to try the clock enable approach first and see where you end up.
Just to make things worse, I think you might also only be looking at half of the problem. If you tell Quartus to also a fast timing model analysis you might find that you have hold time issues on some of the clock domain crossings. But even if you don't have any now, if you were to find some way to control the delay of ck25 to get rid of the setup problem then it is even more likely that you'd see the hold time problem.
Bottom line....there is no way to generate a clock signal as the output of a flip flop clocked by some other clock and not create skew between those two clocks. That is the root of the problem that is showing up for you as setup issues (and possibly hold time issues as well). It's not a Quartus issue, or even an FPGA issue, it's nothing that you can add some magic constraint to engineer a fix. That's why there are PLLs/DLLs inside the more modern FPGAs because they can generate derived clocks from a source clock in a completely different manner and by doing so, they can precisely manage the phase relationship of the source and derived clocks.
On a more positive note, it's possible that the original designers know all about the clock domain crossings and designed things such that when ck125 is generating a signal that is to be sampled by ck25 that they do not allow that signal to change around the time that the rising edge of ck25 is going to occur. Also any signal that gets clocked by ck25 and then gets sampled by ck125 does not get sampled around the time that ck25's rising edge has just occurred.
If that's the case for each and every signal, then these clock domain transfers are being handled properly by design and all you have to do to get rid of the setup (and or hold) violations is to specify a multi- cycle constraint on those signals. Although a multi-cycle constraint 'could' be used by the synthesis engine to possibly optomize something, what it is mostly doing is saying that these signals are allowed to take more than one clock cycle to settle out so when performing the timing analysis the 8 ns clock period of ck125 is relaxed to say 16 ns or 24 ns (depending on what value you set multi_cycle to to correspond to 2 or 3 clock cycles).
The problem is that it is far too easy to convince yourself that something will be stable for more than one clock cycle and not changing when you don't want it to be when in fact it isn't. Adding the multi_cycle constraint in some sense is simply saying that you don't want to be bothered with reports of supposed violations, the danger being that you analyzed it incorrectly. To analyze it though, you need to do a thorough simulation and inspection/understanding of the code to see if these assumptions are correct...and then re-run and re-check if the design changes in any way because that change may be done in such a way that it now violates the required multi cycle assumption.
Lastly, if none of the above applies and the boss insists on no design changes then there isn't much of anything you can do other than change the random number seed, cross your fingers and hope....that isn't engineering and it won't be a robust solution but you might get lucky because luck will be your only ally.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.