Electronic – How to generate wait until division is over in verilog

I assume that you mean that you have a combinational (not asynchronous) logic which represents critical timing path which limits the frequency, right?

Your Static Timing Analysis (STA) tool have no idea that you allow this component to spend several clock cycles before you expect to get a valid output. Synthesis still thinks that the propagation from the input stage to the output stage should take place in a single clock cycle. It makes its best to optimize this path, but still, the propagation delay is too long.

You have several options:

1. The best option in such cases is to split the combinational path into few smaller path, and add register for sampling the intermediate results of the reduced paths. This will reduce the propagation delays, but will add latency - you will get the valid output delayed by the number of sampling stages.
2. If you do not want to mess with this logic (it is too complex, or it is "silicon proven", or any other reason), you can do what you did: add sampling stages before and after the logic, and add additional control logic which knows how many cycles to wait for the valid data (and not allow the inputs to change). However, you must communicate such an unusual intent to all the tools. Information like this was given a general name: "design constraints". Now, I don't know how to specify design constraints for your FPGA (I think it will not take you more than 10 minutes to understand how). What constraint do you need to add? These kind of combinational paths which take more than one cycle are called "multi-cyle-paths" (MCPs). Find it in the documentation of your FPGA\IDE.

NOTE: there is yet another design constraint which may help you - "false path" (FP). When you define some path as FP, no tool will try to derive any timing for this path. This is useful for DFT stuff, clock muxes etc. However, even you may be tempted to use it in this case (FPs are much more simple to define properly than MCPs), don't do it! MCPs constraints must be validated by formal tools, therefore if you define MCP as FP you are masking many potential bugs.

If you are wondering about how the <= operator works; it is what is called a 'nonblocking assignment.' What this means is that the left hand side of all of the <= are performed for a particular event (e.g. rising clock edge) and then once those are all evaluated, the result is placed in the output. This allows you to write shift registers without temporary variables. None of the values change until the left hand calculations are completed, then the results are moved over to the right hand side. It is generally not a good idea to use nonblocking assignments for combinatorial logic. Generally they are only used to create latches and registers and you use regular blocking assignments for combinatorial logic. When synchronized with a clock signal, you can generally consider <= operations to be D flip-flops that sample the input and transfer it to the output atomically on a single clock edge.

'Race conditions' where intermediate indeterminate results appear on the outputs of combinatorial functions are hard to avoid and they can depend greatly on how the design is actually implemented on an ASIC or FPGA. However, most designs are synchronous and so as long as the output settles within one clock period this is not a problem. There are tools that can check the timing performance of a design to check all of the path delays to ensure that the results will always be valid for a given clock frequency, but this is highly dependent not on the actual HDL code but on the way the design is placed and routed.

Synthesizers (not compilers!!!!) will generally perform optimization on combinatorial logic. There are limits to how much the synthesizer can do (e.g. it will not re-architect your system) so you have to know more or less how it will end up being implemented. If you're working on an FPGA, generally the synthesis and place and route will pack any logic function that fits onto LUTs. So if you can separate out a single logic function with up to 4 inputs and 1 output, this will end up on a single LUT and the only delay that matters is the propagation delay of the LUT, which is the same for all of its inputs. In the case of your example function, both pieces of code may be implemented identically on one LUT with three inputs and one output.