1
\$\begingroup\$

I got a Quartus project with a mod 22 counter using 74193 from a friend. It works just fine when I run a simulation before a compilation on my PC, but after I compile it on my PC, it stops working correctly. Is it possible to check what settings are different during compilation?

enter image description here

Before compilation simulation before compilation

After compilation on my PC enter image description here

\$\endgroup\$
4
  • 1
    \$\begingroup\$ Whenever pre-synthesis and post-synthesis simulations differ, look for race conditions in your logic. You have many, and this is not a good fit for FPGA implementation, which is oriented toward fully-synchronous design. \$\endgroup\$
    – Dave Tweed
    Oct 28, 2018 at 14:30
  • \$\begingroup\$ The reason for this is that I need to go back to state 22 after 0 (when counting down) and currently I can't see better way to do this using 74193 \$\endgroup\$
    – CloudJR
    Oct 28, 2018 at 14:34
  • 1
    \$\begingroup\$ Then maybe it's time to expand your horizons and look beyond the 74193. Define the behavior you want using an HDL, and let the tools do all of the work for you! \$\endgroup\$
    – Dave Tweed
    Oct 28, 2018 at 14:43
  • \$\begingroup\$ Would definitely do that, but this is an academic project :D \$\endgroup\$
    – CloudJR
    Oct 28, 2018 at 14:44

1 Answer 1

Reset to default
4
\$\begingroup\$

The difference between the two is not that compilation broke your design, but rather the first case is an RTL simulation (i.e. everything is ideal), whereas the second case is a Gate-Level simulation, which factors in the propagation delays estimated for the actual real implementation.

Your circuit design works in the ideal case, however once you factor in real propagation delays within the circuit, race conditions and logic hazards become a major problem. The same would be the case if you were to build the circuit from actual physical logic ICs.

When designing for FPGA, and even if building out of logic ICs, you need to be very careful in how you design your circuitry - especially when those designs start including asynchronous reset paths. Mixing asynchronous and synchronous logic within the same data path can cause you major headaches like you are seeing.

\$\endgroup\$
2
  • \$\begingroup\$ That makes perfect sense, thank you! It seems that I will have to find a better way to reset to state 22 after 0 (when counting down) \$\endgroup\$
    – CloudJR
    Oct 28, 2018 at 14:43
  • \$\begingroup\$ Have you considered adding a latch to the outputs of your counters in order to make sure everything is synchronized to the clock signal? Then you have an entire clock cycle to arrange for a reset (but you have a single cycle delay at initialisation before counting begins). \$\endgroup\$
    – Jules
    Oct 28, 2018 at 16:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.