VHDL timing

Simple answer: instantly

Complex answer:

Your input and enable signals are both scheduled to change at the same moment in simulation time. The simulator will pause simulation time and then take one of those signals (say enable) and go through your code looking for all processes which have that "enable" in the sensitivity list. The simulator will find your buffer process and work out what the output should be with the new enable and old input value.

The simulator then looks back to its transaction queue for this moment in simulation (we haven't advanced in time yet) and see also that the input signal change needs to be dealt with. The simulator then does the same again - finds all the processes with "input" in their sensitivity list including your buffer. It will then step through your buffer process and work out what the output should be based on the new enable and new input value.

Because the buffer output has now changed (twice - but the first one will either be overwritten by the second or skipped) the simulator will look for any process with the buffer's output in the sensitivity list.

And so on until there are no further signal changes for this moment in simulation time. The simulator will only then allow simulation time to continue to the next event that has been scheduled.

You can see delta cycles displayed in the simulator (although you can largely forget about them) and there are various attributes which can be used in the delta cycle context but these don't tend to get used very often.

END OF COMPLEX BIT

If you want to model a delay in the buffer then you can write something like:

output <= input after 20 ns;

Until you synthesise and place and route your design you don't have much idea what the actual logic and routing delays will be, so you design and simulate your functionality (zero delay RTL code); then when you place and route your design you tell Quartus how fast it needs to work and any setup or hold times etc. Quartus then tells you if it can't meet that timing and can give you a gate level VHDL netlist with real delays annotated in an sdf file - this pair can then be simulated again (with your original testbench) if you wish to further prove your timing is OK.

Hope this helps