Floading Point divider, throughput/latency

As I previously checked, setting the data at the rising edge gives correct results in a timing simulation, e.g. using Quartus V9 simulator. That's what you also can expect in a real device, because FPGA registers have a zero hold time requirement.

The ModelSim results are with functional simulation however, which is apparently causing the problems. At first sight, I wanted to agree with Tricky:

--- Quote Start ---

All data in the testbench waits for the rising edge of the clock, so input should be safe.

--- Quote End ---

But it this actually true? The VHDL specifation guarantees, that a process is "executed" completely, before the signals are updated. The execution order of multiple processes is however undefined. Also we don't know, how altfp_div is organized internally. Possibly combinational logic is placed before the first register level. If the code is not well considered, simulation artefacts may occur, effectively creating pathes of different length in terms of simulation delta cycles up to the first register. This won't matter in synthesized logic, when actual LE delays apply.

If it's so, the suggestion to set the data on falling edge, or generally a few simulation time steps away from active clock edge, will help.

P.S.:

--- Quote Start ---

I wander if this is a bug in the behavioural code for the divider

--- Quote End ---

Yes, I suppose so. It should be avoidable by better considering delta cycle delays.