| ??? 08/23/06 05:58 Read: times |
#122824 - FPGA clock skew Responding to: ???'s previous message |
Jez Smith said:
The problem was a large logic design successfully placed and routed into an Altera cyclone fpga,both the behavioural and functional simulations looked good,the static timing tool showed that the setup and hold times where being met, there were no asynchronous signals and yet the thing gave incorrect answers when it was tried out in a live FPGA, so what was going wrong ?
The answer was clock skew, which is where the clock shared between adjacent registers is delayed by more than the propagation delay of the logic between the source register and the sink register, the clock was arriving late at the sink register so corrupt data was being read by the sink register. Waitaminute ... Are we talking about source and sink registers inside the FPGA? Is the clock on a low-skew clock line, or is it using local routing? Didn't the static timing analyzer tell you that you weren't meeting skew requirements? most static timing tools cannot calculate clock skew so setup/hold times are going to be misleading at higher clock frequencies. Quartus' STA certainly does! There are several ways to prevent clock skew causing reliability problems in fast logic, the first and simplest is to insert delays into the logic between the source and sink registers so that the propagation delay matches the clock skew,but estimating clock skew between registers isnt easy and is highly dependant on things like supply voltage,temperature,device technology and so on. ... and then you have to ensure that the delays you've added don't get optimized away. Bad practice! A second solution is to clock source and sink registers with different clock phases which does give you about half a clock cycle more time for the clock to sort itself out. Actually, no, it cuts your timing in half. Say you clock the source register on the rising edge of the clock; your signal appears some clock-to-out time later. It then has to meet the setup and hold requirements around the rising edge of the clock, which occurs half a period later. If skew's really the problem, you've just made it worse! A third solution is to arrange the clock tree so that the clock source feeds the sink register before the source register, this is something which isnt always easy to achieve in practice. Impossible in an FPGA, unless you're a total floorplanning freak. the fourth solution,and possibly the best is where they are available use clock phase locked loops which automatically adjust the clock phase to compensate for clock skew throughout the entire device, most FPGA manufacturers include some form of clock manager module which includes a phase locked loop or delay locked loop and it was this which sorted out the problem device which is now running happily with no problems. Of course the PLL or DLL requires that the clocks be put onto a global clock network. I really think your problem was that your clock was originally on local routing resources (which can incur a large skew penalty); using the PLL forced it onto the proper global routing resource. Routing very high-speed clocks on local resources is a recipe for disaster? What was your clock frequency? I don't have Quartus installed here, as we're a Xilinx shop. However, I remember that it certainly complained if you put a clock onto a non-clock input pin or if you used local routing. Xilinx gives you a clock skew report, and when you use a global clock net, skew is on the order tenths or hundreds of nanoseconds, even without the DLL. -a |
