Timing issues with sequential logic circuits deployed to an FPGA

[MatthewP]

Hello,

We've built a 12 hour clock with counters, seven-segment displays, etc., and then deploy it from a PLD to a Digilent board with an FPGA.

For the least significant digit of the hours, we have a binary counter that resets as it counts to 3 (please see attached image). However, when exported to the FPGA, it instead resets as it counts to 2. Since we are not having this issue when running the Multisim simulation, we suspect it is a timing issue. It seems that as the counter output rolls over from 1 to 2 (from 0001 to 0010 in binary), there is a lag in the last digit updating from 1 to 0, so for a short period of time, the counter outputs 0011, hence triggering the counter to reset early.

Would this issue indeed be caused by timing? If so, are there any modifications we could make to ensure this situation does not occur?
We have been having other cases of this issue as well, so it would be great if there exists a universal fix that ensures timing on the FPGA board is the same as the timing in the Multisim simulation.

Thanks,

Matt

[RichieTheBard]

I'm unsure as to why this would present this time errors, but would it be a possibility to use some logic functions to stop the change from taking place until the lsb has actually changed.

[MatthewP]

My understanding is that when deployed to an FPGA, there is an actual difference in the length of the route of one branch of the circuit compared to another.

So, when the rising edge of the clock arives, the least significant bit hasn't changed (yet, but it's just about to) and one or more of the other bits have.

For other digits, I check that the binary number is exactly 1010 (when the counter hits 10 on the 0's digit of the minutes, for example). In this case, we're checking that it's exactly 11. But it registers as 11 too early because it was 01, is in the midst of changing to 10, but the msb has changed when the rising edge of the clock arrives and the lsb hasn't changed yet.

The clock runs fine in simulation, but when deployed to the FPGA, it rolls over the digit too early.