How to remove the glitch like this?

[Altera_Forum]

I want to design a control module to scan a image sensor chip. In the design, it needs three clock signals as: load_ck, shift_ck, CK. 

 For scanning each pixel, it cost 32 basic clock cycles, during 0 to 5, load_ck will be basic clock signal and in else time keep 0. For load_ck, it only be basic clock in 8th cycle. For CK, it will be basic clock from 15 to 30. So my verilog code is as:  assign CK=(counterScan>14 && counterScan<31)? clk_200ns:1'b0; assign load_ck=(counterScan<6)? clk_200ns:1'b0;  assign shift_ck=(counterScan==8)? clk_200ns:1'b0;   But in simulation, the result is as attachment. It is very clear there are glitches appear in the waveform. This phenomena may appear in some computational logic design. How can I remove this to make clear wave signal?  Thanks very much.

[Altera_Forum]

The clocks you are creating: 

  assign CK=(counterScan>14 && counterScan<31)? clk_200ns:1'b0; assign load_ck=(counterScan<6)? clk_200ns:1'b0; assign shift_ck=(counterScan==8)? clk_200ns:1'b0;   are combinatorial. That is the source of your glitches (different combinatorial paths through the device). If this was a post P&R simulation, the glitches would likely be worse.  You need to create the clock signals inside a clocked process in the FPGA, i.e., those clock pulses need to be output from registers in the FPGA.  This means if you need to generate a 10MHz output clock, your FPGA needs to be running at at-least 20MHz. It could also be running faster.  Because you will be using a register to generate the output signal, that signal will be delayed by an FPGA clock period. In general this is not too hard to deal with, you just need to be aware of it.  Cheers, Dave

[Altera_Forum]

--- Quote Start ---  The clocks you are creating:   assign CK=(counterScan>14 && counterScan<31)? clk_200ns:1'b0; assign load_ck=(counterScan<6)? clk_200ns:1'b0; assign shift_ck=(counterScan==8)? clk_200ns:1'b0;   are combinatorial. That is the source of your glitches (different combinatorial paths through the device). If this was a post P&R simulation, the glitches would likely be worse.  You need to create the clock signals inside a clocked process in the FPGA, i.e., those clock pulses need to be output from registers in the FPGA.  This means if you need to generate a 10MHz output clock, your FPGA needs to be running at at-least 20MHz. It could also be running faster.  Because you will be using a register to generate the output signal, that signal will be delayed by an FPGA clock period. In general this is not too hard to deal with, you just need to be aware of it.  Cheers, Dave  --- Quote End ---     Hi Dave, do you mean like this:  always @(posedge clk_fast) begin if (counterScan>14 && counterScan<31) CK<=clk_200ns; else CK<=0 end  where clk_fast should be much faster than clk_200ns, right?

[Altera_Forum]

Besides other signals, you are creating CK as a gated clock from clk_200 ns. Without discussing the general timing problems brought up by gated or generated clocks, I see two options to do it in a proper synchronous way: 

- have a higher system clock, at least 100 ns period. This won't be a problem unless the 5 MHz clock is your primary input clock - refer to the gated clock design suggested in the Quartus software handbook. It uses a register clocked at the negative edge to delay the gate signal.

[Altera_Forum]

--- Quote Start ---  Besides other signals, you are creating CK as a gated clock from clk_200 ns. Without discussing the general timing problems brought up by gated or generated clocks, I see two options to do it in a proper synchronous way: - have a higher system clock, at least 100 ns period. This won't be a problem unless the 5 MHz clock is your primary input clock - refer to the gated clock design suggested in the Quartus software handbook. It uses a register clocked at the negative edge to delay the gate signal.  --- Quote End ---    Thanks very much. I think the 1st option you mentioned is I have posted. Is replacing the combinational logic gated clock with register gated clock a general approach to avoid the glitch?   And do you mean the " Quartus software handbook" is the pdf file I can download from the Altera website?  Thanks again.

[Altera_Forum]

Yes, the pdf file. There's no other publication with this name.

[Altera_Forum]

Thanks, FvM. And is replacing the combinational logic gated clock with register gated clock a general approach to avoid the glitch?

[Altera_Forum]

You need to visualise the fpga as several combinatorial modules with register at its input side and register at its output side: 

 reg input => comb => register output  and from input pin to output pins you may have several such modules in cascade. The smaller the comb section the better fmax.  The comb section is for decisions - your work The register section serves many purposes. The main purpose is to avois samplig the comb decisions when they are not well cooked yet(glitchy or in the way) . This is the fundamental concept of fpga design, also called synchronous i.e. synchronised to central time pulse.  Another secondary purpose of registers is memory elements.

[Altera_Forum]

Thanks very much, kaz!

[Altera_Forum]

If I replace the combinational logic output to register output like: 

 always @(posedge clk_fast) begin if (counterScan>14 && counterScan<31) CK<=clk_200ns; else CK<=0 end  but there are still glitches, what should I do to remove the glitch?  Thanks very much.

[Altera_Forum]

--- Quote Start ---  If I replace the combinational logic output to register output like:  always @(posedge clk_fast) begin if (counterScan>14 && counterScan<31) CK<=clk_200ns; else CK<=0 end  but there are still glitches, what should I do to remove the glitch?   --- Quote End ---    Its unlikely that there are glitches on CK. However, your logic might be incorrect, and you are getting a single FPGA clock of CK high followed by low, followed by high for a larger number of FPGA clocks (or vice versa). You might interpret that as a 'glitch', however, its not, its a pulse that your synchronous logic created.  Capture a Signal Tap II logic analyzer trace of CK and look at the signal with an oscilloscope.  Cheers, Dave

[Altera_Forum]

--- Quote Start ---  Its unlikely that there are glitches on CK. However, your logic might be incorrect, and you are getting a single FPGA clock of CK high followed by low, followed by high for a larger number of FPGA clocks (or vice versa). You might interpret that as a 'glitch', however, its not, its a pulse that your synchronous logic created.  Capture a Signal Tap II logic analyzer trace of CK and look at the signal with an oscilloscope.  Cheers, Dave  --- Quote End ---    Yes, Dave, you are right. Actually, there is no glitches appear in simulation after I changed my code as I posted. The question I ask is I just assume there are still glitches.   As you mentioned, now I understand is: if I make my design as I posted, in this case, there should not be any more glitches.