Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Register Log in

URGENT. GLITCHES in output

Status
Not open for further replies.
X

xman24

Junior Member level 2
Joined
Oct 10, 2010
Messages
23
Helped
0
Reputation
0
Reaction score
0
Trophy points
1,281
Activity points
1,444
Hi..

I am doing a bit stuff detector module for my project.

assign bit_stuff_detect= (ONES_COUNT==3'd6 && input==1'b0) ? 1'b1:1'b0;
assign bit_stuff_error= (ONES_COUNT==3'd6 && input==1'b1) ? 1'b1:1'b0;

always@(posedge clk)
{

...................................
ONES_COUNT<=ONES_COUNT+1; // Number of ones countiing on posedge of clk
................................
................................
................................
}



So in the above code I am getting a glictch with logic one for a small instance of time when the input is 1111110 on the bit_stuff_error line in timing diagram. i got bit_stuff_detect high as per combinational logic..but the unwanted glitch is there in output!!! Pls hep....I know the problem is with the usage of combinational logic along with clocked logic(here it is ONES_COUNT which works with posedge clk).

input will change only in posedge of clk.

:roll: Please help,How to avoid the glitch that happened in above case... please be specific to the above example when you reply...

Thanks...
 

Hi,

So the glitch occurs when "input" goes 1 to 0?

Is ONES_COUNT going from 111 to 000 at the same time that "input" goes 0?

What is the timing relationship between "input" and "posedege of clk" ?

Btw, it is always safe to synchronize the decode of a counter because there are instances where a combinatorial decode will cause a glitch in silicon.

ie: 011 > 100 could go through the states 111 then 101 then 100. As you can see, if you were decoding 111 would would get a glitch.
 
  • Like
Reactions: xman24

    X

    xman24

    Points: 2
    Helpful Answer Positive Rating
Thanks for replying...

Yes the the glitch happens when input goes from 1 to 0.

The input will change only in the posedge of clock..

ya, ONES_COUNT is going to 0 when it reaches 6.

so the actual code is

always@(posedge clk)
begin

if(input==1)
begin
ONES_COUNT=ONES_COUNT+1;
if(ONES_COUNT==3'd6)
begin
ONES_COUNT=3'd0;
end
end

end
 

ok, so the "input" signal is going "active" (0) while the count is going from "check" (110) to clear (000).

This is like the inputs of a 2-NAND going from 10 to 01 while passing through 11 >> glitch.

Can you synchronize "input" or is "input" asynchronous?

Even better, maybe you can synchronize bit_stuff_detect and bit_stuff_error. The glitches can and will happen but they won't be sampled.
 

i dint get the statement that you said about input and nand gat..and switching from 01 to 10,etc..

I am getting glitch because, after the ONES_COUNT goes to 6 and asyncronously i am checking my input whether its becoming 0 or 1. My logic output should be like, if I have a 0 in input after counting 6 ones then bit_stuf_detect must show 1 for that time period when input 0 ends. My bit_stuff_error must be high if ONES_COUNT is 6 and I if I have an input with 1 again,it must check asyncronuosly so that I will get the output at the same time when input is 1..

But this logic is resulting in glitch..How to eliminate this, is there any other logic to implement the above thing??


And I need to have async bit_stuff_detect and bit_stuff_error in my design...

Input is syncronized with clock.....
 

Hi, sorry about the confusion.

My NAND example was to show how silicon could behave when you add timing to the logic; signals will not arrive instantaneously; some
sooner than others. These types of transitions will cause glitches on the outputs of combinatorial logic; in fact we get lots of glitches in designs after every clock transition; we just are not sampling these signals during the "settling time".

Now to your problem, INPUT is changing at the same time as ONES_COUNT; this will glitch at specific times.

Not knowing the system specification, I can't tell you how to de-skew the signals synchronously.

All I can say, is that it makes sense to glitch and you better not clock/rest anything with the glitchy signals.

Are you sure you can't sample the bit_stuff outputs off posedge of clk? This would solve your problem while delaying the signals one clock.
 
  • Like
Reactions: xman24

    X

    xman24

    Points: 2
    Helpful Answer Positive Rating
Hey! Thanks..I got the point that you were trying to say with NAND gate! :smile: Thanks

Then, About my problem.. Actually, I cant synchronize my bit_stuff output because, it will delay my output by one clock pulse and henceforth, it will delay my other module.. this outputs are needed for disabling one shiftregister operation for the one clock period so that the stuffed bit is not shifted inside the register in the next block that I am going to design.

My specification is like

bit_stuff_detect should be high when the serial input which is synchronized with clock (input value changes only during posedges of clk) is having 1111110, and this bit_stuff_detect signal should be high for the clock period when input is 0(111111'0').


bit_stuff_error should be high when the serial input which is synchronized with clock (input value changes only during posedges of clk) is having 1111111, and this bit_stuff_detect signal should be high for the clock period when input is 1(7th one, 111111'1').


this is my spec, and what is your logic to design this... Pls help.
 

Hi, I think I found something in your RTL.

In your "actual" code I see that you are using BLOCKING instead of NON_BLOCKING assignments. Typically we use <= and not = for registered logic.

<= behaves like silicon

How is "input" generated? BLOCKING or NON_BLOCKING?

That may explain the glitch.

I would still not recommend driving any clocks/resets with a direct decode of combinatorial logic.
 

jpvSoccer said:
Hi, I think I found something in your RTL.

In your "actual" code I see that you are using BLOCKING instead of NON_BLOCKING assignments. Typically we use <= and not = for registered logic.

<= behaves like silicon

How is "input" generated? BLOCKING or NON_BLOCKING?

That may explain the glitch.

I would still not recommend driving any clocks/resets with a direct decode of combinatorial logic.
Click to expand...


In my actual code its nonblocking for registered logic...for here, as an example i wrote the code inside always block with '=' but actually its '<=' in my code. input is also blocking ..its serial input that is coming to this block and it will change only on posedge of clk...
Do you have gmail id, can I have a chat with you ??
 

Both outputs bit_stuff_detect and bit_stuff_error are generated by combinations logic. The output of any combinational logic circuit must be generally expected to have glitches if more than one inputs are changing simultaneously. This is e.g. the case with the counter bits, that all go to the logic.

As a first remark, the glitches don't matter, if the signals are processed in a clock sensitive always block clocked by the same clock.

The solution is however simple. If you want the outputs glitch-free, you have to register them.
 
It seems to me that it's just a typical synchronous logic and glitch doesn't matter. The glitch happens all the time within the comb logic until all the signal settles, but what matters is the signal state upon the capturing edge of the clock. Since both of Input and COUNT is synchronous, I don't see the reason why you want to treat bit_stuff_* as async.
Furthermore, if you treat both of bit_stuff_* as 'async' like you said, on the receiving block, you probably need make sure that there is ZERO delay difference (which is impossible) between bit_stuff_error and bit_stuff_detect otherwise when these two signals go out of sync each other due to a small time lag, your receiving block may go into a state not expected like both of them is '1'.

if you want to avoid glitch, you have only 2 options. One is flopping it, another is picking the input patterns that don't cause a glitch. For example, if 2 input AND, avoid 10 -> 01 transition.
 
Last edited:
xman24 said:
assign bit_stuff_detect= (ONES_COUNT==3'd6 && input==1'b0) ? 1'b1:1'b0;
assign bit_stuff_error= (ONES_COUNT==3'd6 && input==1'b1) ? 1'b1:1'b0;

always@(posedge clk)
{

...................................
ONES_COUNT<=ONES_COUNT+1; // Number of ones countiing on posedge of clk
................................
}

So in the above code I am getting a glictch with logic one for a small instance of time when the input is 1111110 on the bit_stuff_error line in timing diagram. i got bit_stuff_detect high as per combinational logic..but the unwanted glitch is there in output!!!

input will change only in posedge of clk.

:roll: Please help,How to avoid the glitch that happened in above case... please be specific to the above example when you reply...
Click to expand...

Hi,

You can try below code. It will remove glitch but you need to check functionality.

Code: 
always @ (posedge clk)
  begin
    if (ONES_COUNT==3'd5 && input==1'b0)
      bit_stuff_detect <= 1'b1;
    else
      bit_stuff_detect <= 1'b0;
  end

always @ (posedge clk)
  begin
    if (ONES_COUNT==3'd5 && input==1'b1)
      bit_stuff_error <= 1'b1;
    else
      bit_stuff_error <= 1'b0;
  end

HTH
Shitansh Vaghela
 
Status
Not open for further replies.

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top