Some glitches in the simualtion waveforms

[Altera_Forum]

Hi, Experts,  

 I met a problem in my VHDL code. My algorithm is to cut in the deadtime in the incoming PWM signals and output them. I have 6 incoming PWM signals to switch 6 IGBTs. So, these 6 pwm signals are divided into three pairs: top1 & bot1, top2&bot2 and top3&bot3.   I did some simulation for "top1&bot1" (deadtime_1.vhd) and "top2&bot2"(deadtime_2.vhd) pwm signals. But, the result is weird: when I only use top1&bot1, the simulation result is good; when I use both "top1&bot1" and "top2&bot2", there are some glitches in waveforms in the simulation....It looks like the clocks are fighting with each other periodically after some cycles.   I attached my vhdl code and simulation results. Please give me some advices...  GREATLY APPREICATE YOUR HELP!!!!!

[Altera_Forum]

In deadtime_1 you have 

 first_pair: process (clkin, pwm_top1_in)  The only signals in the process sensitivity list should be the clock and asynchronous control signals like a reset. It looks like you wanted to use pwm_top1_in as a synchronous input to the register. The synchronous inputs should not be in the sensitivity list.

[Altera_Forum]

Hi,Brad,  

 Thanks for pointing out the mistake. Now, I only keep "clkin" in the sensitivity list, but result is the same....     --- Quote Start ---  In deadtime_1 you have  first_pair: process (clkin, pwm_top1_in)The only signals in the process sensitivity list should be the clock and asynchronous control signals like a reset. It looks like you wanted to use pwm_top1_in as a synchronous input to the register. The synchronous inputs should not be in the sensitivity list.  --- Quote End ---  

[Altera_Forum]

If cali_done and start_cal are asynchronous inputs like a reset, add them to the sensitivity list. If they are synchronous inputs, move them inside the "elsif rising_edge (clkin)".

[Altera_Forum]

See the Quartus handbook and text editor template references at http://www.alteraforum.com/forum/showthread.php?t=1025 for coding style guidelines.

[Altera_Forum]

Thanks for your advice.  

 The "cali_done" and "start_cal" are used as variables. "cali_done" is to indicate the "calibration part is finished, so no need to do calibration again" and "start_cal is to denote initialization is done and can do the calibration now".   They are both asynchronous. I set them in the sensitivity list but the result is the same....  If you look at the deadtime.vhd, I set both deadtime_1 and deadtime_2 as two components. These two components only share the same clock but have different input and output ports. If I do simulation for one component, everything is fine. but, if I do the simualtions for two componets, there are some glitches coming out in one component's waveform (attached in my original post).....Weird....  Many thanks,again!!      --- Quote Start ---  If cali_done and start_cal are asynchronous inputs like a reset, add them to the sensitivity list. If they are synchronous inputs, move them inside the "elsif rising_edge (clkin)".  --- Quote End ---  

[Altera_Forum]

If you are getting the warnings below, then clean up the coding style to eliminate the warnings. 

 Warning (10631): VHDL Process Statement warning at deadtime_1.vhd(69): inferring latch(es) for signal or variable "start_cal", which holds its previous value in one or more paths through the process Warning (10631): VHDL Process Statement warning at deadtime_1.vhd(69): inferring latch(es) for signal or variable "start_pwm", which holds its previous value in one or more paths through the process

[Altera_Forum]

Despite the latch warnings, I don't see anything in the RTL Viewer that would cause glitches on po1_PWM_Bot1. This output probably isn't glitching at all but having normal behavior of a register changing only at its input clock edges. Zoom in on your simulation waveform till you can see the individual clock cycles. That should make it easier to make sense of what is happening on the signals.

[Altera_Forum]

Also make sure that your simulation inputs are timed correctly with respect to the clock so that there are no setup or hold violations. This is important for a timing simulation.

[Altera_Forum]

As a first point, an edge_sensitive process shouldn't have another condition like if(cali_done = 0) then enclosing it, except for an asynchronous input, as said. When used as in the present code, they must be supposed to prevent regular inference of synchronous FF's from the behavioural description.  

 You should translate your overall component structure to a regular edge sensitive design structure, as shown in the Quartus VHDL templates and cali_done to a state variable inside the edge sensitive block.  Another possible reason for glitches is a timing violation caused by inputs to the design. If they are unrelated, they should be synchronized to the clock before entering the logic. In simulation, stimulating signals, that are clock synchronous in real operation, can cause apparent timing violations.

[Altera_Forum]

Hi, Brad & FvM,  

 Thanks a lot for your time and help. I am working on my code to make it warning free with some variable such as cali_done etc.  But, one thing confuses me is that I have two components deadtime_1 and deadtime_2. If I simulate only one component with my current code, the simulation result is very good. Such weird glitches only happen when I simulate two components together. Since the two components have different input and output ports, they should not affect each other at all.   I agree that my coding style is not good and I am improving it. But, I doubt the mistake is caused by this style but some other reasons (?)  Again, I appreciate your help and advice!  ps: FvM, you said" Another possible reason for glitches is a timing violation caused by inputs to the design. If they are unrelated, they should be synchronized to the clock before entering the logic. In simulation, stimulating signals, that are clock synchronous in real operation, can cause apparent timing violations. " I can confirm that the inputs are not related. What do you mean by "In simulation, stimulating signals, that are clock synchronous in real operation, can cause apparent timing violations"?  Thanks, again!

[Altera_Forum]

As I said before, you need your simulation input stimulus to meet the setup and hold requirements of the input pins. I think that is what FvM was referring to. 

 And I still think what you are calling glitches are not actually glitches. People usually use the word "glitch" for a disturbance on a signal that is less than a clock cycle long. I suspect that when you zoom in on your simulation waveforms you will see that whatever is happening on the problem output is a pulse that lasts for at least one full clock cycle.  Because you are doing a timing simulation, you are seeing the effects of everything that changes in the place and route. When you change anything in the source code including changing whether you have one component or both of them present, there is some randomness to the resulting change in the exact timing. It might be only coincidence that it appears to work with one component but not with both components. If you have any timing violations reported by TimeQuest or the Classic Timing Analyzer (assuming you have proper timing constraints), it is not surprising to get unexpected results in timing simulation.

[Altera_Forum]

Based on what you recommended, I re-wrote the code with a regular edge sensitive design structure. However, the result is the same. Maybe there is something other than the structure causes the problem... 

 Still debugging it.....

[Altera_Forum]

If the output signals are assigned inside the edge sensitive process, in other words, the signals are connected to FlipFlop outputs in your design, glitches can only occur in two cases, I think: 

 1. An asynchronous input overriding the synchronous operation is in effect.  2. An input signal is violating setup or hold timing requirement. In this case, your stimulating waveform would be the reason. if a similar situation is also expected in real operation, the respective signals should be synchronized to the clock before entering the logic.  You're able to recognize the reason in your simulation. If it's not obvious from a the displayed signals, you can add internal signals as outputs to the simulation. As already said, timing violation are also reported during simulation and can be traced in detail.

[Altera_Forum]

--- Quote Start ---  1. An asynchronous input overriding the synchronous operation is in effect.  --- Quote End ---    When I looked in the RTL Viewer at the attached state of the design (with the unneeded signal removed from the sensitivity lists), I didn't see any asynchronous control signal used by the output register, and the register was driving the output pin directly with no logic between the pin and the register. This is why I think there is no glitching, only a synchronous change in the register output at each clock edge. The simulation waveform timescale was zoomed out too far to say there was glitching.