VHDL timing

[Altera_Forum]

Hi all, 

I am new to VHDL so I suppose that my question is pretty basic:  Suppose I have a simple buffer with input, output and enable. The input is connected to the output if enable = '1'. When enable = '0', the output is high Z.  My question is: If I enable the buffer and set a value to the input in the same clock, when will I see the input value on the output?  Thanks, Dvido

[Altera_Forum]

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

[Altera_Forum]

@ batfink: Thanks for the detailed answer. 

Let's say that I am not simulating the design but burning it to an actual CPLD. Isn't there a race condition between the enable and input signals? Can I always assume that the buffer's output will change immediately?

[Altera_Forum]

--- Quote Start ---  Let's say that I am not simulating the design but burning it to an actual CPLD. Isn't there a race condition between the enable and input signals?  --- Quote End ---    That would depend on the characteristics of the PLD and the routing / logic delays for your particular layout. You could potentially get a glitch on the output - it depends what the on/off and propagation delays are for the buffer and which signal arrives first.  You could always run a gate level simulation with timing delays to check this - but it could change for each compilation.  If it's really an issue then you might want to think about your design in a bit more detail.    --- Quote Start ---  Can I always assume that the buffer's output will change immediately?  --- Quote End ---    The output will never change immediately on an actual chip - there will always be some delay there - you need to work out how much is OK for your design.  Depending on what device you're using you could add timing constraints so that you don't end up with a glitch at the output.  have a think about what the signals are actually doing when they get to the outside world and whether you have a problem or not before diving into constraints or changing your design.