Delays and glitches in simulation

[Altera_Forum]

Hi, 

 I wonder if I misunderstand something or the Qartus simulation is not able to consider state changes I want to display. I started with the Quartus demo program 'light'. I noticed that the change in the output signal 'f' occurs cca 1.3 ns  after the change in the input signal. Although there is a little difference in the transition time between the 0->1 and 1->0 transitions, there is no effect visible in the output signal 'f'. I intended to increase this difference, so I inserted 4 more inverters  on one signal path.  module lights(x1, x2, f, dummy); input x1, x2; output f, dummy; wire x1i/* synthesis keep */; wire x2i /* synthesis keep */; wire x12or /* synthesis keep */= x1 | x2; assign x1i = ~x1; wire x21 = ~x2 /* synthesis keep */; wire x22 = ~x21 /* synthesis keep */; wire x23 = ~x22 /* synthesis keep */; wire x24 = ~x23 /* synthesis keep */; assign x2i = ~x24; assign f = (x1 & x2i)|(x1i & x2); assign dummy = x12or; endmodule   According to the wave diagrams, 0->1 transition needs 1.5 ns, the 1->0 transition needs 1.6 ns. However, the transition following the 1->0 transition needs only 0.4 ns. The 5 inversions require altogether 3 ns time, both for 1->0 and 0->1 transitions. This exceeds my knowledge in arithmetics. Also, I produced signal 'dummy' just to find out the time consumption of ORing and outputting a signal. This is 4.8 ns. The 5 times inverted signal produces a change in 6.4 ns, so I conclude that the 5-times inversion takes some 1.6 ns, which is about the time of one-time inversion, and the half of the time needed to produce the 5-times inverted signal. I am really confused. :confused:  In this way, the time difference between the appearance of the two inverted signals on the OR gate is in the order of the operation of a gate. So, I expected that during this transient period there will be a "glitch" in the signal 'f', but according to the wave diagram, there is no such glitch. Should it be? (I include also my vwf file)  HEADER { VERSION = 1; TIME_UNIT = ns; DATA_OFFSET = 0.0; DATA_DURATION = 200.0; SIMULATION_TIME = 0.0; GRID_PHASE = 0.0; GRID_PERIOD = 10.0; GRID_DUTY_CYCLE = 50; } USER_TYPE("__bvc") { VALUES = "Undefined"; } SIGNAL("x1") { VALUE_TYPE = NINE_LEVEL_BIT; SIGNAL_TYPE = SINGLE_BIT; WIDTH = 1; LSB_INDEX = -1; DIRECTION = INPUT; PARENT = ""; } SIGNAL("x2") { VALUE_TYPE = NINE_LEVEL_BIT; SIGNAL_TYPE = SINGLE_BIT; WIDTH = 1; LSB_INDEX = -1; DIRECTION = INPUT; PARENT = ""; } SIGNAL("f") { VALUE_TYPE = NINE_LEVEL_BIT; SIGNAL_TYPE = SINGLE_BIT; WIDTH = 1; LSB_INDEX = -1; DIRECTION = OUTPUT; PARENT = ""; } SIGNAL("x1i") { VALUE_TYPE = NINE_LEVEL_BIT; SIGNAL_TYPE = SINGLE_BIT; WIDTH = 1; LSB_INDEX = -1; DIRECTION = COMBINATORIAL; PARENT = ""; } SIGNAL("x2i") { VALUE_TYPE = NINE_LEVEL_BIT; SIGNAL_TYPE = SINGLE_BIT; WIDTH = 1; LSB_INDEX = -1; DIRECTION = COMBINATORIAL; PARENT = ""; } SIGNAL("x21") { VALUE_TYPE = NINE_LEVEL_BIT; SIGNAL_TYPE = SINGLE_BIT; WIDTH = 1; LSB_INDEX = -1; DIRECTION = COMBINATORIAL; PARENT = ""; } SIGNAL("x22") { VALUE_TYPE = NINE_LEVEL_BIT; SIGNAL_TYPE = SINGLE_BIT; WIDTH = 1; LSB_INDEX = -1; DIRECTION = COMBINATORIAL; PARENT = ""; } SIGNAL("dummy") { VALUE_TYPE = NINE_LEVEL_BIT; SIGNAL_TYPE = SINGLE_BIT; WIDTH = 1; LSB_INDEX = -1; DIRECTION = OUTPUT; PARENT = ""; } TRANSITION_LIST("x1") { NODE { REPEAT = 1; LEVEL 0 FOR 100.0; LEVEL 1 FOR 90.0; LEVEL 0 FOR 10.0; } } TRANSITION_LIST("x2") { NODE { REPEAT = 1; LEVEL 0 FOR 50.0; LEVEL 1 FOR 50.0; LEVEL 0 FOR 50.0; LEVEL 1 FOR 50.0; } } TRANSITION_LIST("f") { NODE { REPEAT = 1; LEVEL X FOR 200.0; } } TRANSITION_LIST("x1i") { NODE { REPEAT = 1; LEVEL U FOR 200.0; } } TRANSITION_LIST("x2i") { NODE { REPEAT = 1; LEVEL U FOR 200.0; } } TRANSITION_LIST("x21") { NODE { REPEAT = 1; LEVEL U FOR 200.0; } } TRANSITION_LIST("x22") { NODE { REPEAT = 1; LEVEL U FOR 200.0; } } TRANSITION_LIST("dummy") { NODE { REPEAT = 1; LEVEL U FOR 200.0; } } DISPLAY_LINE { CHANNEL = "f"; EXPAND_STATUS = COLLAPSED; RADIX = Binary; TREE_INDEX = 0; TREE_LEVEL = 0; } DISPLAY_LINE { CHANNEL = "dummy"; EXPAND_STATUS = COLLAPSED; RADIX = Binary; TREE_INDEX = 1; TREE_LEVEL = 0; } DISPLAY_LINE { CHANNEL = "x1"; EXPAND_STATUS = COLLAPSED; RADIX = Binary; TREE_INDEX = 2; TREE_LEVEL = 0; } DISPLAY_LINE { CHANNEL = "x1i"; EXPAND_STATUS = COLLAPSED; RADIX = Binary; TREE_INDEX = 3; TREE_LEVEL = 0; } DISPLAY_LINE { CHANNEL = "x2"; EXPAND_STATUS = COLLAPSED; RADIX = Binary; TREE_INDEX = 4; TREE_LEVEL = 0; } DISPLAY_LINE { CHANNEL = "x2i"; EXPAND_STATUS = COLLAPSED; RADIX = Binary; TREE_INDEX = 5; TREE_LEVEL = 0; } DISPLAY_LINE { CHANNEL = "x21"; EXPAND_STATUS = COLLAPSED; RADIX = Binary; TREE_INDEX = 6; TREE_LEVEL = 0; } DISPLAY_LINE { CHANNEL = "x22"; EXPAND_STATUS = COLLAPSED; RADIX = Binary; TREE_INDEX = 7; TREE_LEVEL = 0; } TIME_BAR { TIME = 100000; MASTER = TRUE; } ;

[Altera_Forum]

Using not gates and logic to delay signals is a very bad idea. The actual delay is dependant upon the routing generated during compilation and temperature, so your delay will change every time you re-compile the chip. 

 It is much safer to use synchronous logic with extra timing specs attached to output pins if you really need to delay an output signal.

[Altera_Forum]

--- Quote Start ---  Using not gates and logic to delay signals is a very bad idea. The actual delay is dependant upon the routing generated during compilation and temperature, so your delay will change every time you re-compile the chip.  It is much safer to use synchronous logic with extra timing specs attached to output pins if you really need to delay an output signal.  --- Quote End ---    I highly agree with you, and do not want to use it in production code. My only purpose was to discover whether similar (non-intentional) situation could be (and should be?) discovered using waveform analyzis. The other question about the timing arithmetics is just the consequence of the analyzis. My quess was, that after compilation, the routing and delays are fixed, and can be calculated. (and I am not interested whether in another compilation will be the same value)

[Altera_Forum]

No, you cannot guarantee routing delays on any given compilation because the delays are also affected by temperature.

[Altera_Forum]

--- Quote Start ---  No, you cannot guarantee routing delays on any given compilation because the delays are also affected by temperature.  --- Quote End ---    Sorry, I say again: I do not want to guarantee anything. It is just for teaching, to demonstrate unwanted effects. I only wanted to know, whether the University Program waveform analyzis tool is capable of doing that. I see that in ModelSim there exist a kind of glitch filtering.

[Altera_Forum]

The simulator has a resolution limit, by default set to 100ps I think (maybe even 1 ns). So any glitches smaller than this will not show up. You can change the resolution limit in the modelsim.ini file or with the -t option to the vsim comand. It can be set as low as 1fs.