Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

XOR blip, pulse, spurious occurance.

Status
Not open for further replies.

minigecko

Technical User
Oct 20, 2005
6
GB
When using a XOR, whether provided be Quartus, made from ANDs and NOTs, or writen myself, the Timing simulation shows a 200ps pulse 8ns after the two inputs change simutaneously. This change should obviously result in No change.

I would like to know why this pulse happens and how i can avoid, or 'deal' with it. Can anyone enlighten me on this issue, or give any info which would help me search for solutions, as I can find no information on it.

Thanks peeps.
 
Hello minigecko,

What you describe is typically the behavior of combinatorical logic. The pulse is called a glitch.

AND, OR, XOR, etc gates are gates that react immediatly when there is a change at the inputs. In fact not really immediatly but a certain gate delay after the change.

The reason you have the glitch is because the inputs do not change really exactly at the same time. The reason for this is routing delay and propagation delay.

Lets consider a two input or gate inputs are A and B and output is C.


Lets say A and B are both zero, so C is also. Now A becomes '1' for 10 ns, B remains zero so C becomes '1' for 10 ns.
Now lets presume that at the same moment A drops low again B becomes high, really 100% edge aligned. But due to routing delay B takes a really litle fraction 100 ps longer to reach the input of the gate. C will drop low for 100 ps and then go high again. You expected however C to remain high.
What you have is a glitch.

This reason is why pure combinatorical or asynchronous design is not so popular and can lead to very difficult bugs to fix.

If A and B were outputs of a flip flop and C was only used further on after being registerd by another flipflop with all flipflops on the same edge of the same clock, this would not be a problem, you would not see the glitch on the clocked C output.

Now first let me congratulate you for performing a timing simulation, because in a functional simulation you would not have seen this. It's a good habbit performing timing simulations, however for complex designs this is not allways practical. That is why complex designs are almost allways fully synchronous (clocked) and even pipelined.
And lets say good designs (even small ones) also.

The reason flipflops where 'invented' was because they were more resistent to glitches than latches. And this is why there are no latches in FPGA but a hole lot of flipflops.

This problem you are having is a nice example of a reason to start considering clocked designs.

Believe me closing timing isn't allways a party in clocked designs, so if you already have no glitches in the design this will only make things easier.

I know this is unpleasant news but it's reality.


regards
jeandelfrigo
 
Thanks once again jeandelfrigo, my design is now clocking synchronous and working nicely. Thanks for the detailed reply, Much appreciated!
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top