02-28-2014 10:39 AM
hi, i had a very basic question regarding fsm, synch signals and how they transition ...
i made a simple 2 state fsm (processed on rising edge of clk) as follows ...
if (input = '1') then
output <= '1';
state <= s1;
output <= '0';
state <= s0;
when s1 =>
state <= s0;
case1(refer sc1.jpg) - in simulation, when i assert input=1 exactly on the rising edge of clock, then output = 1 and state transition to s1 happens one clock cycle later, which is what is said about signals and fsm ... that the signals are updated after 1 clock cycle. refer sc1.jpg
case2 (refer sc2.jpg) - in simulation, if i assert input=1 around the rising edge of clock and the quickly deassert it, then output = 1 and state transition to s1 happens on the same clock edge. refer sc2.jpg.
in case2, should the state/output not transition after 1 clk cycle as well? what is the basic that i'm missing here and why do we have diff bhv in sims?
please let me know ...
thanks and regards,
02-28-2014 08:04 PM
Your understanding is correct, hardware behaves as case-1, but in functional Simulation as the delays are not be considered inputs are sampled almost instantaneously and hence you see the output in the immediate rising edge for Case2
You can do Timing simulation and check if the result is same for both the cases.
Hope this helps
03-01-2014 08:13 AM
In both simulations the machine behaves the same. The "1 cycle" delay is not from the assertion of the input signal. It really means that the state will change on the first rising edge of the clock after the input goes high. For behavioral simulation making the edges of input1 and clk coincident might cause the delay to look like zero, or it might make the delay a full clock cycle depending on the order that the simulator processes the two signals. Behavioral simulation keeps track of the signal dependencies in a way that doesn't show up in the waveforms, i.e. it knows for example that a flip-flop Q will transition after the clk edge, and therefore other flip-flops will not respond to it on the same clock edge, but it won't show this as a measurable time delay. Instead it uses internal "delta" delays that have no associated time. So if your first simulation had input1 sourced by a signal that depends on the rising edge of clk, it would necessarily make the output go high one cycle later. If on the other hand you coded input1 using time delays, it could cause a "race condition" where the output would either go high on the same cycle or the following cycle depending on the order in which the simulator processes the code. In real hardware, input1 should meet setup and hold times with respect to the rising edge of clk in order for the machine to function properly.