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?
-
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 TweedOct 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\$– CloudJROct 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 TweedOct 28, 2018 at 14:43
-
\$\begingroup\$ Would definitely do that, but this is an academic project :D \$\endgroup\$– CloudJROct 28, 2018 at 14:44
1 Answer
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.
-
\$\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\$– CloudJROct 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\$– JulesOct 28, 2018 at 16:42