--- Quote Start ---
I have some "inferring latches for variable ... which holds its previous value in one or more paths through the always construct".
--- Quote End ---
Don't use latches.
--- Quote Start ---
I have some Tri-state nodes which do not directly drive top level pins.
In my internal modules there are some bi-directional busses,
which is why there are tri-states that don't drive the outside world.
--- Quote End ---
There's no tri-state functionaltiy in the FPGA so why code as if there is and rely on the tools 'fixing' things for you?
Convert to multiple busses, one for each Tx point.
--- Quote Start ---
Clock multiplexers found and protected.
--- Quote End ---
If you're using a single clock domain why is it being multiplexed?
Use clock enables instead!
--- Quote Start ---
I am setting up data and then waiting at least one clock cycle before I
clock it into the next register
--- Quote End ---
That isn't the usual approach for synchronous design. If you're using the same clock to launch and capture signals and the tools know how fast the clock is things _should_ work. (You can have multi-cycle paths but that's the exception rather than rule). You're not doing board design, let the tools worry about timing while you worry about finctionality.
Can you get some input from an experienced FPGA designer? When you've seen how things should be done (no latches, proper synchronous process templates, clock enables etc) it's much easier to get things working.
As long as you're getting signals into and out of the FPGA OK your simulation results should match real world results.
I hope this helps a bit,
Nial.
Honored Contributor
