I coded a very, very simple 8-bit adder in VHDL and its Behavioral Simulation ran fine. Its Timing Simulation though gave a terrible result: more than 100 ns to perform a sum on a Virtex 6 board (Speed Grade 3); at least, that's what I see from ISim (Xilinx's surrogate for Modelsim).
I did absolutely nothing with Timing Constraints, I mean I don't even know where the defaults ones are; I don't know whether this might be the problem. Same thing for pin assignment or else; I just wrote the code (actually inside a very small schematic) and clicked on Implement and then Timing Simulation.
Synthesis is optimized for speed.
Ah, I said "very simple 8-bit adder", and what I meant was
I wonder about the purpose of a 500 MHz for the design. Which strange constructs are there in addition? How about a hidden reset signal?
The adder and I/O delay would give several ns total delay, Most likely less than 10 ns. Everything else needs to be created intentionally (or possibly inadvertently).
I don't work with Xylinx or ISIm, just as a guess: does it possibly model internal power on reset?
I would nevertheless revert to a reasonable clock frequency like 100 Mhz.
To see the actual adder propagation delay, you can use it unregistered and change the input data.
I don't work with Xylinx or ISIm, just as a guess: does it possibly model internal power on reset?
I would nevertheless revert to a reasonable clock frequency like 100 Mhz.
To see the actual adder propagation delay, you can use it unregistered and change the input data.
That just doesn't look right. As suggested reduce the clock to something like 100 MHz. Also add the EN and RESET signals. Yes, even if they don't do something exciting. Maybe even assert and de-assert your RESET just to be sure. And if reset doesn't do anything useful in your opinion, then just get rid of it in the entire module. If it does something useful, then better testbench it.
That just doesn't look right. As suggested reduce the clock to something like 100 MHz. Also add the EN and RESET signals. Yes, even if they don't do something exciting. Maybe even assert and de-assert your RESET just to be sure. And if reset doesn't do anything useful in your opinion, then just get rid of it in the entire module. If it does something useful, then better testbench it.
I did change the values of RESET but it didn't help; however, changing the inputs somewhere after 100 ns produced the wanted results (a sum performed in less than 4 ns from the first rising edge).
I have no idea about the reasons of such a long freeze at the start; someone talked about global reset/GRS on Xilinx boards.