Honored ContributorI'm running some very small blocks through Quartus to give an idication on their timing. We are running off an 8ns clock. The problem is that the clock skew in the timing reports is at nearly 3ns, which surprises me, and the clock skew makes analysing the reults a tad more complicated. I'm presuming this clock skew is useful skew - if it is does anybody know how to turn it off?
Honored ContributorEven very small blocks have inputs and outputs and if you compile/simulate them for a real FPGA the clock has to cover the distance from input to output hence the skew.
For speed-estimation purposes may I suggest to double-register both the inputs and the outputs. Then Quartus can place the internal registers close to the logic-under-test and achieve the best timing. However if your are using TimeQuest and specify a realistic timing requirement as you did, the fitter will not try hardest. You will have to push it by specifying a more stringent requirement which it can not easily meet.Honored ContributorThanks for the reply.
Yes I expect some clock skew but I thought around 3ns was a little bit on the large side. Should I expect this much even for a small block when targeting a large Stratix IV device? Maybe the logic is spread out around the massive expanse of the device? Is this the fitter/timer using deliberate useful clock skew? If it is can I turn it off? At the end of the day it's not the end of the world as it's just a case of picking out the data delay from the reports - just thought it would be useful to turn it off if I could. I'll try your suggestion of double registering I/O - thanks.Honored ContributorA large(r) device will have more clock skew (as the distances to cross becomes longer). E.g. I have IO clock skews of around 2.8 ns for a Stratix II GX EP2SGX60F1152C3 device. And unless you play around and assign optimal pin settings yourself the compiler will do a 'lazy' (and quite often a 'lousy') job. If you back-annotate the pins you can see what the compiler produced.
The fitter works with or around clock skew, whatever is appropriate. Clock skew is inherent to fitting your design into some physical device. So you can't turn it off. On the opposite if you perform functional simulation you use the result of synthesis and there is no clock skew, but no notion of speed either.Honored ContributorWhat it is, is that I understand there will always be clock skew - understood. What I was assuming is that the tool was using useful clock skew (i.e. manipulating the the clock arrivals times at registers) and hence why the numbers were large(ish), and how could I instruct it not to - and force the register placement closer and reduce clock skew.
I think the underlying question is this; is the tool using useful skew for optimization? Thanks.Honored ContributorI suggest that you put the clock through a global buffer before the source and destinations. This will give you very low clock skew, even across the device. There is a Fitter option to turn on Beneficial Skew (on a LAB basis), but that it only to help meet Hold time.
Honored ContributorA clock skew of 3 ns, sounds high to me, for the same clock.
Usually the skew is a few hundred PS for clocks, unless something is breaking the the clock fanout such that the global clock buffers can not be used, so it's using standard routing resources. If it's a small section of logic, you may try logic locking the logic in a small region of the FPGA. If you have multiple clocks, you may try to force the critical clock to use the global clock networks. You may want to look closer at the clock delay paths, and see if you have some gating or other logic in one path that isn't in the other. This could add to your skew issues.Honored ContributorHonored ContributorUnfortunately it's company code so I can't post, but the motivation behind all this is...
The design team regularly come to me with very small blocks that they are considering integrating into the main design. What the first question they ask is "will it time if we add it to the design". Now adding it to the design takes time and the builds themselves take hours so I need a quick and simple method to answer their question. They way I did it this time is just build the small block on the full design device giving the tool free reign to do what it wants - I don't think this is the best way to do it as hence I'm now looking at build a 'small block' methodology based on previous suggestions (logic lock, double register and clock buffers etc). So far I've adopted the 'virtual pins' script from the Altera web site for blocks with masses of I/O and I've also developed a generic constraints script. Any suggestions welcome.
