+ Post New Thread
Results 1 to 16 of 16
  1. #1
    Member level 1
    Points: 233, Level: 2
    Pastel's Avatar
    Join Date
    Jun 2019
    Posts
    38
    Helped
    1 / 1
    Points
    233
    Level
    2

    Unwanted glitches on the output pins in verilog program

    Hello guys!

    I'm an absolute newbie in the FPGA world. I have some knowledge in programming microcontrollers, but
    sometimes C don't meet the timing specs, so I have to go one step further. First, here is what I'm using:
    - De0 Nano board (from Terasic, with Cyclone IV).
    - Quartus lite, the latest version that supports Cyclone IV, version 18.1
    - Windows 10
    - Oscilloscope plugged at the output.

    I wanted to make a simple counter, that puts the signals to the output pins. Here is what I wrote.
    NB: I will not go into the details of routing the q vector to the output, it does (more or less) what I
    expect and there are signals on the 8 lsbs.

    Code:
    module Counter(q, clk);
    	output reg [15:0]q;
    	input clk;	
    	always@(posedge clk) begin
    		q <= q+1;
    	end	
    endmodule
    The code is pretty simple, but it raises many questions.
    1. The functionality is almost what I intended to do, but there is a glitch on MSB and data2. Could anybody explain
    why it happens? I can understand why the data don't switch all at the same time because I use wires that may have
    some noise, and since this happens under one ns, then there is a place where the signals are not fully defined
    (under the label "parallel"). But what happens to MSP and Data2? Why these small glitches?

    2. I was assuming the counter would roll by itself and return to 0 after 2^16 cycles. But then since it doesn't work
    I also tried to test if q == 65535 begin q <= 0; end but it doesn't change anything.

    3. I wrote q <= q+1. Sometimes, I find some online examples like q <= 16'b1. What would it change? Is it
    necessary to do this. Apparently in this example, it doesn't change anything, but I suppose there are good reasons
    to write like this.

    4. Is it necessary to use the quartus simulator if I have an oscilloscope on the output? What is the advantage of
    this simulation?

    Thanks for any hint!

    Pastel

    •   AltAdvertisement

        
       

  2. #2
    Full Member level 6
    Points: 2,010, Level: 10

    Join Date
    Jan 2019
    Posts
    373
    Helped
    93 / 93
    Points
    2,010
    Level
    10

    Re: C don't meet the timing specs (FPGA, counter)

    did you attach the logic analyzer directly to the output pins of the uC using only the logic analyzer wires?

    what is the specification its not meeting?
    what is the actual measurement that's not being met?

    what happens at 2^16 clock edges? apparently its not turning to 0.
    what does it do?



  3. #3
    Member level 1
    Points: 233, Level: 2
    Pastel's Avatar
    Join Date
    Jun 2019
    Posts
    38
    Helped
    1 / 1
    Points
    233
    Level
    2

    Re: C don't meet the timing specs (FPGA, counter)

    Hello!
    Thanks for your reply.
    I don't know how this became the title... (C don't meet the timing specs)...
    Basically I wrote the program above, and there are some glitches on the MSB and the second signal.

    1. The specs: As I'm sending a 16 bit counter output on the GPIO pins, I would expect that the
    GPIO just count, and that they are mostly synchronous (say within less than 1 ns). But there are
    pulses on MSB and Data2 that I don't understand. They happen when all the signals are mostly
    settled. But I will hookup analog channels this afternoon, just to see what happens.
    So what doesn't work as intended is the fact that there are some glitches on the signals.

    what happens at 2^16 clock edges? apparently its not turning to 0.
    OK, the capture I choosed wasn't a good one. Here is a zoom out view.

    Click image for larger version. 

Name:	PW_005.png 
Views:	11 
Size:	100.8 KB 
ID:	154078

    So basically it works as intended except that there are some glitches in the 3 MSBs.
    As the data will be latched on the falling edge of the clock, it's not a real problem, but I would
    likt to know the reason, and also how I can avoid that kind of behavior.

    Thanks again.

    Pastel



  4. #4
    Super Moderator
    Points: 77,678, Level: 67
    Achievements:
    7 years registered
    Awards:
    Most Frequent Poster 3rd Helpful Member

    Join Date
    Apr 2014
    Posts
    15,747
    Helped
    3587 / 3587
    Points
    77,678
    Level
    67

    Re: Unwanted glitches on the output pins in verilog program

    Hi,

    Can it be that you confuse yourself?....at least I'm confused.

    There are a lot of inconsitencies
    Please explain:
    * what do you mean with "uC"?
    * what do you mean with "MSP"? (It's not found in your code)
    * what do you mean with "data2"? (It's not found in your code)
    * what do you mean with "second bit"?
    * what do you mean with "MSB"? (Usually this means "most significant bit" .... but of what?)
    To avoid confusion: use the identical names as in your code only.

    What is the input clock frequency? And how is the external as well as the internal clock generated?
    Did you set the timing constraints? --> show us
    Show us the compiler errors and warnings.

    I don't know how this became the title...
    this is the most confusing for me. If you didn't write it on your own....what did you write then?

    Klaus
    Please dont contact me via PM, because there is no time to respond to them. No friend requests. Thank you.



  5. #5
    Member level 1
    Points: 233, Level: 2
    Pastel's Avatar
    Join Date
    Jun 2019
    Posts
    38
    Helped
    1 / 1
    Points
    233
    Level
    2

    Re: Unwanted glitches on the output pins in verilog program

    Hello!

    Thanks for your reply.

    First things first:
    this is the most confusing for me. If you didn't write it on your own....what did you write then?
    At first I wrote "absolute newbie question" or something like that. As it's absolutely non informative, one moderator
    changed the title with what I wrote first. This brings us to your first question:
    C was the background explanation I gave: I know more or less how to program a microcontroller, but there are some
    cases it's way too slow and the C cannot meet the timing. Therefore I'm learning FPGA right now.

    Now for the other questions:
    MSP was a typo for MSB (maybe due to the fact that I'm a heavy MSP430 user).
    MSB, data2 etc... can be found on the picture I posted, these are the name of the traces on the oscilloscope I am using.
    second bit is the same as data2.

    Now for the clock frequency, it's 50 MHz. This explains why the first signal (bottom) has a frequency of 25 MHz (on the
    last picture I posted, it's clearly around 40 ns).

    If I summarize with a bit more detail:
    - De0 Nano board (from Terasic, with Cyclone IV). I have set the I/O as follows:
    * Clock (50 MHZ) taken from pin R8.
    * Data output to the first connector of the board, as indicated in the following picture:
    Click image for larger version. 

Name:	GPIO-0rot.png 
Views:	1 
Size:	58.5 KB 
ID:	154081
    I have setup the r[15:0] output to GPIO_0xx, therefore pads D3, C3, A2, A3, B3, B4, A4, B5,
    A5, D5, B6, A6, B7, D6, A7, C6 (corresponding to r[0] ... r[15] respectively.
    - Quartus lite, the latest version that supports Cyclone IV, version 18.1
    - Windows 10
    - Oscilloscope plugged at the output.
    The oscilloscope trace naming is:
    MSB, corresponding to r[7], then data2 (r[6]) .... data7 (r[1]), LSB (r[0]

    So I think this time the description is accurate, but if something is missing, please tell me.

    Now the problem:
    On the scope screen, I have no problem with LSB (half of the input clock), Data7 to Data4.
    But from data3, you can notice that there are some glitches in the middle of the signals.
    When I add 1 to a number (after all, that's all I'm doing), I can't figure out why there would
    be an unstable status of the MSBs signals.

    Thanks for any hint.

    Pastel



  6. #6
    Super Moderator
    Points: 260,190, Level: 100
    Awards:
    1st Helpful Member

    Join Date
    Jan 2008
    Location
    Bochum, Germany
    Posts
    45,438
    Helped
    13824 / 13824
    Points
    260,190
    Level
    100

    Re: Unwanted glitches on the output pins in verilog program

    It's expectable that the individual bits of a binary counter don't switch exactly at the same time. The effect is called delay skew. We see it e.g. in the transition from 0x43 to 0x44 in post #1.

    If post #1 shows the output of a simple binary counter, the glitches in the transition from 0xbf to 0xc0 are however not expectable. Similarly a synchronous binary counter as described in your code should not show the glitches in post #3. It looks more like wrong data acquisition by the logic analyzer, e.g. due to ground bounce. Or it's a completely different circuit. Do you actually sample the counter output, without logic in between? Otherwise show the complete Verilog code.

    Don't see yet how the question is related to uC. If you have an interface between FPGA and uC, there would be control signals qualifying the data words.



    •   AltAdvertisement

        
       

  7. #7
    Member level 1
    Points: 233, Level: 2
    Pastel's Avatar
    Join Date
    Jun 2019
    Posts
    38
    Helped
    1 / 1
    Points
    233
    Level
    2

    Re: Unwanted glitches on the output pins in verilog program

    Hello!
    Thanks for your reply.
    Ok, talking about a C was a mistake, there is no C in this experiment. I was just saying
    that I'm learning FPGA for tasks that a C cannot do.
    Let's stress it again: there is no C in this experiment, just what I have listed:
    - One FPGA board (de0 nano from Terasic, with Cyclone IV).
    - Quartus II, version 18.1
    - PC with windows 10.
    - Oscilloscope (plugged as explained one post earlier and checking
    the 8 lsbs of the q signal of my code.

    That's the complete verilog code.
    NB: I'm not used to this scope. I was using the digital probe, and I switched to analog, which allowed me to
    view the real signals. There is quite some swing on the outputs, and with all the wires I'm using, it causes reflections and quite large switching noises.
    Things are stable now. I was suspecting the code first, but the measurement method was wrong.

    Back to some of the things I'm still unsure about (on post 1)
    In my program, I wrote q <= q+1;
    Is it necessary to write 16'b1 instead of 1, or is it fine like this.
    Similarily, if I have a register like this:
    output reg[15:0] q;
    What would happen if I write:
    q <= 1;
    Is there a chance it initializes only the last bit? Or will it initialize the lsb to 1 and all others to 0?

    Thanks,

    Pastel



    •   AltAdvertisement

        
       

  8. #8
    Super Moderator
    Points: 260,190, Level: 100
    Awards:
    1st Helpful Member

    Join Date
    Jan 2008
    Location
    Bochum, Germany
    Posts
    45,438
    Helped
    13824 / 13824
    Points
    260,190
    Level
    100

    Re: Unwanted glitches on the output pins in verilog program

    In my program, I wrote q <= q+1;
    Is it necessary to write 16'b1 instead of 1, or is it fine like this.
    Makes no difference for synthesized hardware.

    Similarily, if I have a register like this:
    output reg[15:0] q;
    What would happen if I write:
    q <= 1;
    Is there a chance it initializes only the last bit? Or will it initialize the lsb to 1 and all others to 0?
    q <= 1 writes unsigned decimal 1 to the register vector, setting all register bits.

    Is there a chance it initializes only the last bit?
    Sure, q[0] <= 1.



  9. #9
    Super Moderator
    Points: 77,678, Level: 67
    Achievements:
    7 years registered
    Awards:
    Most Frequent Poster 3rd Helpful Member

    Join Date
    Apr 2014
    Posts
    15,747
    Helped
    3587 / 3587
    Points
    77,678
    Level
    67

    Re: Unwanted glitches on the output pins in verilog program

    Hi,

    Thanks for clearing up some things.

    Now for the other questions:
    MSP was a typo for MSB (maybe due to the fact that I'm a heavy MSP430 user).
    MSB, data2 etc... can be found on the picture I posted, these are the name of the traces on the oscilloscope I am using.
    second bit is the same as data2.
    So, MSB means MSB of "q" --> q15
    (Try to use the same names in code as at scope, to avoid confusions.)
    data2 = q2 = second bit
    Then...
    data1 = q1 = first bit
    data0 = q0 = ? (how do you call this bit)
    (We had the same naming problem in our company, thus we decided just to use "q0", "q1"...)

    I have setup the r[15:0] output
    Why now "r" ? In the code I see just "q"...

    A 16 bit adder needs to calculate the carry from bit to bit (depending how it is implemented).
    This needs time. In worst case there are 15 gates connected in series.
    Are you sure the the FPGA can run a 16 bit adder with 50MHz clock?
    (Usually it shouldn't be a problem.)
    Here I need to repeat my question about timing constraints and error/warning messages...

    To avoid glitches (caused by combinatorial logic) one it's generally a good idea to add a DFF to the outputs.

    Klaus
    Please dont contact me via PM, because there is no time to respond to them. No friend requests. Thank you.



  10. #10
    Super Moderator
    Points: 260,190, Level: 100
    Awards:
    1st Helpful Member

    Join Date
    Jan 2008
    Location
    Bochum, Germany
    Posts
    45,438
    Helped
    13824 / 13824
    Points
    260,190
    Level
    100

    Re: Unwanted glitches on the output pins in verilog program

    A 16 bit adder needs to calculate the carry from bit to bit (depending how it is implemented).
    This needs time. In worst case there are 15 gates connected in series.
    Are you sure the the FPGA can run a 16 bit adder with 50MHz clock?
    (Usually it shouldn't be a problem.)
    Here I need to repeat my question about timing constraints and error/warning messages...

    To avoid glitches (caused by combinatorial logic) one it's generally a good idea to add a DFF to the outputs.
    The binary counter described in post #1 has already DFFs at the outputs. The adder output is only internal and not visible unless routed to pins explicitly.

    A binary counter can hardly generate the output shown in post #1, even if overclocked (timing constraints violated). In the first place it will show wrong counting sequences then.



  11. #11
    Full Member level 6
    Points: 2,010, Level: 10

    Join Date
    Jan 2019
    Posts
    373
    Helped
    93 / 93
    Points
    2,010
    Level
    10

    Re: Unwanted glitches on the output pins in verilog program

    according to
    https://www.terasic.com.tw/cgi-bin/p...o=593&PartNo=2

    the deo-nano has "On-board 50MHz clock oscillator" so your clock at 50MHz should not be outside its capability

    look at pages 52 and 53 of the user manual for a slightly different counter program.
    try that



    •   AltAdvertisement

        
       

  12. #12
    Super Moderator
    Points: 260,190, Level: 100
    Awards:
    1st Helpful Member

    Join Date
    Jan 2008
    Location
    Bochum, Germany
    Posts
    45,438
    Helped
    13824 / 13824
    Points
    260,190
    Level
    100

    Re: Unwanted glitches on the output pins in verilog program

    DE0-Nano simple_counter.v isn't different in any kind from the post #1 design, except for 32 bit width.



  13. #13
    Full Member level 6
    Points: 2,010, Level: 10

    Join Date
    Jan 2019
    Posts
    373
    Helped
    93 / 93
    Points
    2,010
    Level
    10

    Re: Unwanted glitches on the output pins in verilog program

    From the DEO-Nano User Manual

    module simple_counter (CLOCK_5, counter_out);
    input CLOCK_5 ;
    output [31:0] counter_out;
    reg [31:0] counter_out;
    always @ (posedge CLOCK_5) // on positive clock edge
    begin
    counter_out <= counter_out + 1;// increment counter// increment counter
    end
    endmodule // end of module counter


    the program posted by Pastel in post #1

    module Counter(q, clk);
    output reg [15:0]q;
    input clk;
    always@(posedge clk) begin
    q <= q+1;
    end
    endmodule

    What I see as different are the two lines in the sample:
    output [31:0] counter_out;
    reg [31:0] counter_out;

    versus the one line used by Pastel
    output reg [15:0]q;

    clearly the length and the variable name are not the issue
    I'm not conversant enough with deo nano to know if there is a difference or not
    just making a suggestion



  14. #14
    Super Moderator
    Points: 260,190, Level: 100
    Awards:
    1st Helpful Member

    Join Date
    Jan 2008
    Location
    Bochum, Germany
    Posts
    45,438
    Helped
    13824 / 13824
    Points
    260,190
    Level
    100

    Re: Unwanted glitches on the output pins in verilog program

    The only difference is between using standard Verilog2001 and antiquated Verilog1995 port declaration syntax.



  15. #15
    Super Moderator
    Points: 31,575, Level: 43
    ads-ee's Avatar
    Join Date
    Sep 2013
    Location
    USA
    Posts
    7,305
    Helped
    1719 / 1719
    Points
    31,575
    Level
    43

    Re: Unwanted glitches on the output pins in verilog program

    I would like to see the actual code used to create the design as a zip file not typed into the browser.

    The behavior of the outputs looke like = was used instead of the what is shown in the posted code which has <=.

    I have another post (which I'm not going tofind th link to) which shows how = can generate combinational logic after a registered output. It has the synthesis results of both = and <=.



  16. #16
    Member level 1
    Points: 233, Level: 2
    Pastel's Avatar
    Join Date
    Jun 2019
    Posts
    38
    Helped
    1 / 1
    Points
    233
    Level
    2

    Re: Unwanted glitches on the output pins in verilog program

    Hello!
    I can't see the difference between actual code and what I could have "typed" into the browser.
    In fact, I have used the actual code, cut & pasted into the browser.
    And beside this, I found out, thanks to the replies I had, that by tuning the scope's threshold
    a bit higher, the glitches disappear.
    What happens is that if only the 3 lsbs change at once, there is no problem. But if 4 change at
    once, it yields some crosstalk and shakes the surrounding lines. That's about it, it's not a coding
    issue.
    Thanks,
    Pastel



--[[ ]]--