How to remove glitches on Incoming signals ?

[Altera_Forum]

Hi *, 

  I have signals coming to the FPGA which are not clean . All these signals are asynchronous signals. I want to remove the glitches on these signals and then feed them to the inputs of my entities/modules.   I am doing resynchronisation(2-stage) inside my entities/modules. therefore, i don't any glitches on these external signals.  Regards, Anil

[Altera_Forum]

One method is to lowpass filter your signal with an analogue (passive) low-pass filter and buffer it with a chip external to the FPGA having a Schmitt trigger input. Not sure if Altera devices have Schmitt trigger inputs, thats why I suggest it as an external chip. Added benefit is protection of fpga from destructive signals but is requires an extra chip of course.

[Altera_Forum]

HC14 or similar is a great idea in analog land, for detecting edges. A minimum width threshold (glitch detector) is a useful block to have in digital land, especially if your minimum width is tied to registers (not hardwired); you can then tune the glitch rejection if need be. 

 A combination of both is even better.  Note if you have a very short asynchronous pulse and want to register that to internal logic, the likelihood is you'll get some occasional wierd effects in the digital domain, perhaps missing some pulses altogether. Chain several FFs together, all clocked with global clock of course, even as many as 6-8 FFs, to have a better chance of getting a clean input.  (I can't remember why this is so; can anyone explain this? something to do with delays in the implementation of the gates. There's an app note about it somewhere.)

[Altera_Forum]

Dealing with asynchronous signals can get a lot of different answers, and that's because "asynchronous" can be used to define many different types of interfaces, all with different characteristics, so it helps to define exactly what you know about your signals and what you're trying to do with them. Some of the suggestions are for truly ugly singals. Glitchy, non-monotonic, perhaps with periods faster than the clock rate, etc. are examples. More often than not, asynchronous refers to pretty well defined signals, but we just don't know the phase(or don't have a clock on chip that has a 0 PPM difference.) If it's a signal that toggles slower than the clock(and depending on the part, there's no reason you can't use a PLL and create a 400MHz clock to sample them), than just sample it with multiple chained registers(the multiple registers are to let any metastability work its way out of the system. If you have a fast clock, then you'll have less time to let them work themselves out and want the data delay between registers to be as quick as possible. I would recommend putting the registers in a single lab assignment next to the pin.)  

 (I'll probably get blasted as there are more elegant solutions, like voting mechanism,s or an edge detection circuit, etc. Again, it all depends on your system and what your requirements are.)  Another issue that often comes up, since you say signals, plural, is do they need to be captured together, or are they truly asynchronous to each other. Just another issue to take into account.

[Altera_Forum]

Hi *, 

  thanks for some answers. Let me explain the problem in a better way. I have two pcb boards. One contains a processor, and the other contains the FPGA with my design. Now i connect both the PCB's using cables. The processor is sending asynchronous signals to the FPGA. At the moment, i don't have any chance of using any external mechanisms to remove glitches.   I would appreciate only solutions, where i can remove the glitches, once the signals enter the FPGA. because these glitches are mostly likely caused by the cables or some noise and so on.   Is there anything in Quartus, which tells me that, i don't want any glitches on the input pins, or if they come, they must be suppressed.  Regards, Anil

[Altera_Forum]

So you are stuck with what signals you've got inside the chip.  

There is no ready made solution. It depends on your signal. For some cases a pulse of 100ns is a glitch for others its a valid signal. What I suggest you to do is to look at the problem with digital designer glasses on and ask: "How can I design a digital state-machine which will distinguish a false signal from a valid signal". Imagine all the senarios which are likely to occour. You will probably end up finding that you will have to discriminate against pulse width, so you need a counter to hold track of time. Bottom line: you will be designing a state-machine to solve your problem. But be prepared to face a problem without a solution: if your glitch has same shape (time duration) as a valid signal and you have no further information about the signal such as relation to previous events, then there is no way to distinguish good from bad. Your only chance is if you can redesign the communication protocol, such that it is will detect errors, I.e. you must change the transmitter card as well. There are countles ways to make error resiliant channels.  In case you will be doing re-design of the interconnect, seriously consider using differential signaling. Chances are that much of your noise is due to common mode differences between your cards. Differential signaling makes life much simpler in that respect. Many Altera chips have LVDS ports.  Attached is a way to build a scmitt trigger input using an internal gate in the FPGA and a couple of resistors. I have not tried this myself in practice, only simulated, so do simulate and test before commiting.