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.

Unwanted glitches on the output pins in verilog program

Status
Not open for further replies.

Pastel

Member level 3
Joined
Jun 30, 2019
Messages
55
Helped
2
Reputation
4
Reaction score
1
Trophy points
8
Activity points
969
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
 

Attachments

  • PW_000.png
    PW_000.png
    27 KB · Views: 151
  • PW_001.png
    PW_001.png
    6.1 KB · Views: 190

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?
 

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.

PW_005.png

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
 

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
 

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:
GPIO-0rot.png
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
 

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.
 

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
 

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.
 

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
 

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.
 

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

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
 

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

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 <=.
 

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
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top