Glitch Problem

[Steve.Minshull]

Hi

I'm developing a Pulse-Width-Modulation (PWM) scheme on a Xilinx
spartan 3 digilent demo board to perform sinusoidal current control in
a 3 phase motor. I've managed to just about get it working apart from
some strange behaviour where something unknown causes a glitch and
this results in a spike in the current in the motor. The interesting
thing is that during the course of trying to find the problem I have
wired various signals internal to the FPGA to output pins to view on a
scope. In doing this (purely connecting internal signals to the IO
pins) the problem has been cured. I'm guessing therefore that this is
a timing issue or could anyone suggest an alternative cause? Is there
a method of setting timing constraints for internal signals in ISE?
(I can set timing constraints for inputs and outputs but can't find
anything to set timing constraints on internal signals)

The block proceeding the signal which is routed to the IO (to cure the
problem) is a lookup table that compares a timer count signal with
duty times and produces a control signal. The VHDL code for this
block is:

begin
process (count, d1, d1_d2)
begin
if (count <= d1) then
vector_control <= "00";
elsif ((count > d1) AND (count <= d1_d2)) then
vector_control <= "01";
else vector_control <= "10";
end if;

end process;

ISE has implemented this as some magnitude comparators and a ROM
(implemented in a LUT rather than blockram)

This part of the system is combinatorial and not clocked but inserting
a clocked register on the output of this block does not help.

Any suggestions or comments greatly appreciated.

Steve Minshull

 

[ast]

This part of the system is combinatorial and not clocked but inserting
a clocked register on the output of this block does not help.

Inserting a register on outputs removes glitches for sure.

Or what do you call a glitch ? A pulse shorter than a clock
period or something else ?

 

[Andy]

Hi

I'm developing a Pulse-Width-Modulation (PWM) scheme on a Xilinx
spartan 3 digilent demo board to perform sinusoidal current control in
a 3 phase motor. I've managed to just about get it working apart from
some strange behaviour where something unknown causes a glitch and
this results in a spike in the current in the motor. The interesting
thing is that during the course of trying to find the problem I have
wired various signals internal to the FPGA to output pins to view on a
scope. In doing this (purely connecting internal signals to the IO
pins) the problem has been cured. I'm guessing therefore that this is
a timing issue or could anyone suggest an alternative cause? Is there
a method of setting timing constraints for internal signals in ISE?
(I can set timing constraints for inputs and outputs but can't find
anything to set timing constraints on internal signals)

The block proceeding the signal which is routed to the IO (to cure the
problem) is a lookup table that compares a timer count signal with
duty times and produces a control signal. The VHDL code for this
block is:

begin
process (count, d1, d1_d2)
begin
if (count <= d1) then
vector_control <= "00";
elsif ((count > d1) AND (count <= d1_d2)) then
vector_control <= "01";
else vector_control <= "10";
end if;

end process;

ISE has implemented this as some magnitude comparators and a ROM
(implemented in a LUT rather than blockram)

This part of the system is combinatorial and not clocked but inserting
a clocked register on the output of this block does not help.

Any suggestions or comments greatly appreciated.

Steve Minshull

About the only thing your problem and solution would indicate is a
timing problem. I suspect the above code is not your problem if
putting a register on the output is not fixing it. You do have timing
constraints, and are running static timing analysis, right?

How long (relative to a clock period) are your glitches lasting?

Also, the (count > d1) is superfluous in the elsif condition. It is
implied by the elsif and the previous condition. It should get
optimized out anyway by the tool, but...

Andy

 

[Steve.Minshull]

Inserting a register on outputs removes glitches for sure.

Or what do you call a glitch ? A pulse shorter than a clock
period or something else ?

Good news.

I think I've sorted the problem.

I was latching data into my FPGA using an async signal from a DSP by
performing an edge detect on the async signal and then wired this to
the enable of my latch. Discovered data was not always being latched
in properly. The wrong thing to do obviously. Temporarily solved the
problem by removing the edge detect but I'm thinking a double
buffering scheme would be best.

Cheers for your help.


Steve Minshull

 

[Laurent Pinchart]

Inserting a register on outputs removes glitches for sure.

Or what do you call a glitch ? A pulse shorter than a clock
period or something else ?

Good news.

I think I've sorted the problem.

I was latching data into my FPGA using an async signal from a DSP by
performing an edge detect on the async signal and then wired this to
the enable of my latch. Discovered data was not always being latched
in properly. The wrong thing to do obviously. Temporarily solved the
problem by removing the edge detect but I'm thinking a double
buffering scheme would be best.[/QUOTE]

You *must* never drive two or more related flip-flops with an asynchronous
signal. Fix your problem by inserting a synchronization flip-flop on the
input path before the edge detector.

Regards,

Laurent Pinchart