Clock skew problem

[Altera_Forum]

Hello, 

 I am actually facing problems related to clock skew. Timing analisys reports a clock skew problem between the output of a latch and an input of a register( 40 bit wide bus ).  I had in mind that Quartus is supposed to solve those kind of problems on his own! Am I right?   I tried to add some delay inbetween to be sure that the data remains stable by inserting two inverters, but this has no effect at all. I guess those ones are removed automatically by the compiler as it sees this is useless...  I don't see any other way to solve this... Can I somehow force the compiler to not remove those two inverters, and so being able to add a small delay (at least 0.178 ns ) to avoid the clock skew?

[Altera_Forum]

Hi Titouan, 

 you are right: If you insert just a signal in VHDL or Verilog then this local signal is removed. You can add LCELL modules to add a combinational delay and you even can increase the numner of LCELL inserted with the assignment editor. But this is not the way I'd propose. My advice: Try to make your design a synchronous design. And don't use a latch.  Regards, Harald

[Altera_Forum]

Can you give more details? What FPGA are you using (model and speed grade). Which timing analysis tool are you using (Classic or Timequest)? How fast is the clock running? Can you give more details about the registers? What is the fanout of the source signal? Are any of the registers located in the I/O ring? 

 Jake

[Altera_Forum]

Quartus won't fix skew, exactly. Clock skew usually comes from when a design has a gated/ripple clock that feeds the destination register, but the main clock feeds the source register. When the data transfer between these registers is short, a hold violation can occur. The only way for Quartus to fix the skew would be to add delay on the clock path to the source register. This is most likely on a global, and routed directly to the source register, so it's not a good idea to take that signal off the global. (And you're just moving the problem to the stage before this.) 

 What Quartus can do is add delay to the data path. This fixes the hold problem, just not the actual clock skew. This is not done by default though. Go to Assignments -> Settings -> Fitter and change the Hold Time Optimization to All Paths(which means it will add delays to internal paths), and also turn on the Optimize Fast Corner checkbox, so it is adding delays to help fix the fast corner.  The reason this is not on by default is it's recommended to not gate clocks from the beginning. If the gated clock could be changed to a clock enable or something like that, then the structure is better from a good design practice standpoint. If Quartus fixed internal hold violations automatically, many designers wouldn't even realize they were gating clocks, or that it's not an ideal thing to do. Of course, I've seen plenty of designs by excellent designers, where they absolutely had to gate the clocks and there was nothing they could do about it, but it's just not recommended if it can be avoided.

[Altera_Forum]

--- Quote Start ---  ... it's recommended to not gate clocks from the beginning. If the gated clock could be changed to a clock enable or something like that, then the structure is better from a good design practice standpoint.  --- Quote End ---     For more about this, see http://www.alteraforum.com/forum/showthread.php?t=2388.

[Altera_Forum]

Sorry for the late reply... I have been busy with some other stupid stuff. 

Anyway, I am back to the problem , which is solved now, thanks to you guys.  I followed the recommandation from Rysc, and indeed it working perfeclty, as I have no uge timing constraints ( just a speed loss of 2.5%,after turning on  the hold time optimization ).  Thanks Brad for the link to the ripple and gated clock, I found it very interesting.  Cheers