As Ive had my holiday set back by stupid flight delays caused by terrorists trying to blow me up even after I told them not too, I thought would write about a nasty bug which showed up in a high speed fpga coupled to a 8052.
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.This is a problem which occurs more frequently with even higher clock frequencies and faster logic,high clock fanout and very high clock frequencies cause the dedicated clock distribution channels to behave more and more as transmission lines within the FPGA. Manufactures are keen to tell you how fast their logic is but they are not so keen to tell you about the problems this might cause.Its not a problem which is easy to spot because it doesnt always get flagged as a setup/hold violation in a simulator, if your fault coverage isnt too good then you are going to miss it,most static timing tools cannot calculate clock skew so setup/hold times are going to be misleading at higher clock frequencies.
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.
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.
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.
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.
if only i could get my holiday sorted I would be happy.