- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
In FPGA design, when we design a combinational logic, there may appear glitch since the time property is not ideal in each components. And sometime glitch may cause problem. But how can avoid glitch or reduce glitch?
I usually put a flip flop after the output of combinational logic, although with ff, the design is not pure combinational logic, but since combinational logic usually is just the component inside a system so it works. I just wonder whether there are anyother approach to avoid glitch? Thanks very much!Link Copied
6 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- Quote Start --- But how can avoid glitch or reduce glitch? --- Quote End --- Glitches will always occur. The key is to understand where a glitch is acceptable, and where one is not. When designing with FPGAs, you generally want to implement synchronous logic. This typical of logic is characterized by registers feeding combinatorial logic with outputs captured by additional registers. The combinatorial logic outputs / register inputs may have glitches on them, however, that is acceptable so long as the glitches have settled to a logic state (high or low) prior to the register setup time, and those levels stay at that logic state for the register hold time. This timing can be analyzed using TimeQuest. When you have signals leaving or entering the FPGA, you want to make sure those signals are synchronous to your FPGA logic. In the case of inputs, you can either use a synchronous timing constraint (since the external logic uses a clock in common to the FPGA) or you can use synchronizers (a dual-DFF inside the FPGA) to synchronize the external asynchronous signal to the FPGA logic. In the case of FPGA outputs, you should generally try to drive those signals from a register output, as that ensures the signals are glitch free. If the output signals are going to logic clocked by the same clock as the FPGA, then you would setup a TimeQuest timing constraint indicating the timing. If the outputs are going to asynchronous logic, eg., an SRAM, then the fact that you have registered the signals, means there will be no glitches that could result in erroneous writes to SRAM. Cheers, Dave
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks very much, David.
Sometimes I use combinational logic to make an enable or reset signal for IP core in FPGA, like: assign enable=a&&b; assign reset = c||d; then enable and reset will connect to IP core's enable and reset pin. However, since glitch the IP core may be enabled or reseted in unexpected time. So I use a ff to overcome this: always @(posedge clk) begin enable1<=enable; reset1<=reset; end In this typical case, besides add a flip-flop, another other approach can solve the problem? Thanks!- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You have two glitch cases;
1) Enable. If the enable signal routes to the d input of a register, then TimeQuest will indicate whether the combinatorial delay along the path of a and b, and the combinatorial signal a&&b is small enough that it does not violate the register timing. 2) Reset. If the reset signal routes to the asynchronous reset port on a register, then you must synchronize that signal to the clock used by the register to ensure that the reset recovery/removal timing of the register is met. In the case of your reset logic input signals coming from arbitrary sources, a single flip-flip (register) to eliminate glitches is not sufficient, you need to use at least two layers of registers, and the clock input to those registers needs to be the same clock as used by the registers it is resetting. If you have multiple clock domains, then you need multiple reset synchronizers. Cheers, Dave- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- Quote Start --- You have two glitch cases; 2) Reset. If the reset signal routes to the asynchronous reset port on a register, then you must synchronize that signal to the clock used by the register to ensure that the reset recovery/removal timing of the register is met. In the case of your reset logic input signals coming from arbitrary sources, a single flip-flip (register) to eliminate glitches is not sufficient, you need to use at least two layers of registers, and the clock input to those registers needs to be the same clock as used by the registers it is resetting. If you have multiple clock domains, then you need multiple reset synchronizers. Cheers, Dave --- Quote End --- Thanks, Dave. It is very helpful. But I can figure out why a single flip-flip (register) to eliminate glitches is not sufficient but two series connected flip-flop will works. If the first ff is violated by metastable,how can the second ff get the right state? Thanks!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- Quote Start --- I can't figure out why a single flip-flip (register) to eliminate glitches is not sufficient but two series connected flip-flop will works. If the first ff is violated by metastable,how can the second ff get the right state? --- Quote End --- It cannot guarantee it, it just reduces the probability that the output of the second register will be metastable. If you test your hardware and find metastability issues, then you can increase the number of registers in the synchronizer chain. Cheers, Dave
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I got it. Thanks, Dave!

Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page