[SOLVED] Glitch reduction at rtl level

[fragnen]

How can we take care such that when we write rtls, no glitch can occur from that rtl which is being coded?

 

[barry]

Use synchronous design. Use synchronizers when crossing clock domains.

 

[fragnen]

Use synchronous design. Use synchronizers when crossing clock domains.

Even using sync design there can be scenarios that can produce glitches. Secondly all designs cannot be made complete synchronous. It will be good if other methods/ways are suggested.

 

[dpaul]

Even using sync design there can be scenarios that can produce glitches. Secondly all designs cannot be made complete synchronous. It will be good if other methods/ways are suggested.
Show us an example.
Post the RTL (if you know that part is creating the glitch) and the simulation screenshot where you see the glitch.
Merely discussing the theoretical aspects does not make much sense....this thread will just elongate without much meaningful information!

 

[dpaul]

Update....
A proper mix of combi and sequential logic SHOULD NOT produce glitches, if your design is WELL PIPELINED.
That's why if you have a failing design, show us, it can possibly be fixed.

 

[FvM]

Outputs driven by combinational logic (e.g. Mealey FSM outputs) are generally expected to generate glitches when multiple logic inputs change simultaneously. This must not neccessarily happen, but you better use only registered outputs if glitches must be avoided.

 

[fragnen]

There are techniques being used to find out if a rtl which is written can produce glitch or not. Those techniques are used to see whether a rtl which is already written or being written can produce glitch or not. That is the reason for starting this thread with the query at post#1.

 

[barry]

There are techniques being used to find out if a rtl which is written can produce glitch or not. Those techniques are used to see whether a rtl which is already written or being written can produce glitch or not. That is the reason for starting this thread with the query at post#1.

Your original post asked how to write rtl that had no glitches. You said nothing about 'techniques being used to find out...'
Then you made the assertion that synchronous designs can have glitches. We're still waiting to see an example of that...

 

[ThisIsNotSam]

define a "glitch"

 

[dpaul]

@barry ,
Your original post asked how to write rtl that had no glitches. You said nothing about 'techniques being used to find out...'
Then you made the assertion that synchronous designs can have glitches. We're still waiting to see an example of that...

Typical post from @fragnen..............we have been seeing this from him for a couple of years now! It doesn't surprise me anymore when he digresses from his OP and tries to take the thread in another direction.

If @fragnen cannot give an RTL example with simulation screenshots of glitches, I think this thread must be closed.

 

[D.A.(Tony)Stewart]

A "glitch" can occur from asynchronous delays into logic, producing a narrow transient condition. This is eliminated with a clocked flip-flop register. or “registered” by re-synchronization.

A "glitch" can also occur when a logic drives a long trace or wire from inductance which a flyback voltage if impedance happens to be high (no groundplane), resulting in an underdamped pulse. V=LdI/dt as the current turn-off rate approaches 0.

The latter is regardless if the signal is asynchronous or synchronous, and then requires controlled impedances to dampen the response.

 

[barry]

Your first statement just reinforces the concept of why synchronous logic DOESNT have a glitch.

The rest of your post has absolutely nothing to do with this discussion of glitches in rtl.

 

[D.A.(Tony)Stewart]

Your first statement just reinforces the concept of why synchronous logic DOESNT have a glitch.

The rest of your post has absolutely nothing to do with this discussion of glitches in rtl.

You are certainly entitled to your opinion, but if you have a long trace or wire on RTL then it's relevant.

I was just sharing the duality of the word "glitch". Even code eventually becomes analog.

 

[ThisIsNotSam]

You are certainly entitled to your opinion, but if you have a long trace or wire on RTL then it's relevant.

I was just sharing the duality of the word "glitch". Even code eventually becomes analog.

does not compute. RTL has no notion of long traces or wires.

you are mixing a lot of concepts. glitches due to logic switching are not the same as glitches due to crosstalk. no one would ever refer to a crosstalk glitch as an "RTL problem".

 

[D.A.(Tony)Stewart]

does not compute. RTL has no notion of long traces or wires.

you are mixing a lot of concepts. glitches due to logic switching are not the same as glitches due to crosstalk. no one would ever refer to a crosstalk glitch as an "RTL problem".

Sorry to confuse you with these analogies of the word glitch into the analog domain, I'll try to avoid avoid these tangents.

 

[gkram]

Glitches occur in RTL designs when signals with different propagation delay pass through combinational logic. The use of clocked processes in your RTL results in a clocked-logic design and the use of digital registers. In FPGA work, our RTL clocked-logic designs must pass timing analysis. When a clocked-logic design passes timing analysis, the glitches associated with combinational logic will not prevent the design from operating correctly.

 

[ranaya]

How can we take care such that when we write rtls, no glitch can occur from that rtl which is being coded?

If you refer to the glitches emancipated from different path delays in combinatorial clouds (i.e. Multipliers), then totally eliminating glitches is impossible in gate-level. But you can write the code in a way glitches are minimized based on the information of some standard cell library components. i.e. You can define the booth encoder/decoder circuits of a Booth multiplier to be balanced (from AO/OA/AOI/OAI type of cells) and make them symmetrical. This however needs bit-level writing of your design instead of word-level operators.

Read this :

Glitch-Optimized Circuit Blocks for Low-Power High-Performance Booth Multipliers

This article presents a novel implementation scheme of the essential circuit blocks for high-performance, full-precision Booth multipliers leveraging a hybrid logic style. By exploiting the behavior of parasitic capacitance of MOSFETs, a carefully engineered design style is employed to reduce...

ieeexplore.ieee.org

In anycase, finally the glitches are balanced in PnR stage.