Glitches in post-layout (PAR) simulation

Hey all,

I've managed to synthesize a particular DSP core on Actel's fusion
FPGA. I'm using this as a benchmark to assess their suitability for
further integration. I'm a bit new when it comes to Actel. Anyway, it
seems that when running post-PAR simulation I end up having a periodic
pattern of 1ns wide glitches in my output signal every like 4 or
slightly less sampling periods. My design is fully synchronous. I have
no clue whatsoever about the source of the glitches. I even tried to
leave some temporal margin before doing the final output assignment
(for thigs to settle down) but it didn't work. Would really appreciate
it if anybody can give me an insight on possible problematic sources.
I'm yet to run my design in hardware as I'm still waiting for the kit
to arrive.

Thanks in advance guys.

Cheers,

Manny wrote:
> Anyway, it
> seems that when running post-PAR simulation I end up having a periodic
> pattern of 1ns wide glitches in my output signal every like 4 or
> slightly less sampling periods. My design is fully synchronous. 

What happens if you slow down the clock?
Did static timing pass?

     -- Mike Treseler

Actually static timing did pass. As far as I could infer, these
glitches are due to long routing propagation delays and only consitute
negligible time (1ns) relative to the clock period. So they are pretty
much clock independent. In my testbench, I added an explicit intertial
delay (2ns) when assigning my output signal. Now everything is ok but I
still get warning messages in simulation. Was wondering whether it'll
have any noticeable impact when running in hardware?

Cheers,
-Manny

Mike Treseler wrote:
> Manny wrote:
> > Anyway, it
> > seems that when running post-PAR simulation I end up having a periodic
> > pattern of 1ns wide glitches in my output signal every like 4 or
> > slightly less sampling periods. My design is fully synchronous.
>
> What happens if you slow down the clock?
> Did static timing pass?
> 
>      -- Mike Treseler

Manny wrote:
> Actually static timing did pass. As far as I could infer, these
> glitches are due to long routing propagation delays and only consitute
> negligible time (1ns) relative to the clock period. So they are pretty
> much clock independent.

Maybe, but it might be worth a sim run to check it.

Are the glitches on a registered output?
Are all tb and uut clock inputs on exactly the same signal?

> In my testbench, I added an explicit intertial
> delay (2ns) when assigning my output signal. Now everything is ok but I
> still get warning messages in simulation. Was wondering whether it'll
> have any noticeable impact when running in hardware?

If it does, the problem is confirmed.
If it doesn't, nothing is confirmed.

      -- Mike Treseler

Manny, you claim that your design is fully synchronous. I take it that
all flip-flops are clocked by a common clock. On the signals between
these flip-flops you can (and probably will) have glitches as a result
of logically combining signals with different routing delays. That is
perfectly ok, as long as you manage to met all set-up time
requirements.
When you use a combinatorially decoded signal as output, you will see
the glitch, and you either can live with it, or you need to synchronize
the output with a flip-flop. That will definitely eliminate the glictch
(at the expense of a one-clock-period delay).
peter Alfke, Xilinx Applications.
====================
Manny wrote:
> Actually static timing did pass. As far as I could infer, these
> glitches are due to long routing propagation delays and only consitute
> negligible time (1ns) relative to the clock period. So they are pretty
> much clock independent. In my testbench, I added an explicit intertial
> delay (2ns) when assigning my output signal. Now everything is ok but I
> still get warning messages in simulation. Was wondering whether it'll
> have any noticeable impact when running in hardware?
>
> Cheers,
> -Manny
>
> Mike Treseler wrote:
> > Manny wrote:
> > > Anyway, it
> > > seems that when running post-PAR simulation I end up having a periodic
> > > pattern of 1ns wide glitches in my output signal every like 4 or
> > > slightly less sampling periods. My design is fully synchronous.
> >
> > What happens if you slow down the clock?
> > Did static timing pass?
> > 
> >      -- Mike Treseler

As a matter of fact, it's a registered output. This is the weird thing
about it. There should be not glitches. My testbench is:

        real_out <= hex2real(filter_out, 16.0)*4.0 after 2 ns;
-- *** Test Bench - User Defined Section ***
   	tb : PROCESS
   	BEGIN
        wait until (reset = '1');

        for i IN 0 TO 2091 loop
			filter_in <= real2hex(filter_in_force(i), 16.0);
			real_in <= hex2real(filter_in, 16.0);

			table_in <= filter_in_force(i);
			table_out <= filter_out_expected(i);

			wait until (clk_sampling = '0');
		end loop;
   	END PROCESS;
-- *** End Test Bench - User Defined Section ***

filter_out is an already registered output. Is it because I've taken
real_out outside of the main testbench process? In my output assignment
process, I've defined a temp variable in which I'm storing the
glitching signal. I then wait for a handshaking signal before assigning
temp to the output (synchronously). Still with all this, 1ns-wide
glitches are visible on my output signal.

Thanks a lot, 
-Manny

On a clocked flip-flop (without any strange asynchronous inputs) there
can never be a 1 ns glitch.
You have either done something very strange, or you have a defective
part (unlikely)
Flip-flop outputs do not glitch, if clocked correctly.
Could it be that you have a bad clock with glitching edges?
Peter Alfke
===============
Manny wrote:
> As a matter of fact, it's a registered output. This is the weird thing
> about it. There should be not glitches. My testbench is:
>
>         real_out <= hex2real(filter_out, 16.0)*4.0 after 2 ns;
> -- *** Test Bench - User Defined Section ***
>    	tb : PROCESS
>    	BEGIN
>         wait until (reset = '1');
>
>         for i IN 0 TO 2091 loop
> 			filter_in <= real2hex(filter_in_force(i), 16.0);
> 			real_in <= hex2real(filter_in, 16.0);
>
> 			table_in <= filter_in_force(i);
> 			table_out <= filter_out_expected(i);
>
> 			wait until (clk_sampling = '0');
> 		end loop;
>    	END PROCESS;
> -- *** End Test Bench - User Defined Section ***
>
> filter_out is an already registered output. Is it because I've taken
> real_out outside of the main testbench process? In my output assignment
> process, I've defined a temp variable in which I'm storing the
> glitching signal. I then wait for a handshaking signal before assigning
> temp to the output (synchronously). Still with all this, 1ns-wide
> glitches are visible on my output signal.
> 
> Thanks a lot, 
> -Manny

Manny wrote:
> As a matter of fact, it's a registered output. This is the weird thing
> about it. There should be not glitches. My testbench is:

Your testbench should be generating
a constant clock, say clk_s, and
waiting on the same clock *edges* like this:

   wait until rising_edge(clk_s);

Your uut clock should be  port mapped to
the same clk_s.

See the testbench here for details:

 http://home.comcast.net/~mike_treseler/

     -- Mike Treseler

Ok. I've just checked the netlist 'cause you guys got me worried.
Everything is alright. That is, my output port is being clocked by the
system's clock properly. The best explanation I could come up with is
that individual output port bits have sort of delay mismatch and this
is basically what's being manifested as glitches. I presume that after
constraining things a bit tighter now, the glitches should be gone.
What I meant to ask after all is the following: though post-PAR
simulation shows glitches on the output, it doesn't necessarily mean
that running design in hardware will fail? isn't it the case?

Thanks a lot,
-Manny

Manny, you said that the output was registered.
Now you imply that there might be gating between the register and the
real output.
A registered output will not glitch.
A combinatorial output is very likely to glitch.
Make up your mind...
Peter Alfke
==============
Manny wrote:
> Ok. I've just checked the netlist 'cause you guys got me worried.
> Everything is alright. That is, my output port is being clocked by the
> system's clock properly. The best explanation I could come up with is
> that individual output port bits have sort of delay mismatch and this
> is basically what's being manifested as glitches. I presume that after
> constraining things a bit tighter now, the glitches should be gone.
> What I meant to ask after all is the following: though post-PAR
> simulation shows glitches on the output, it doesn't necessarily mean
> that running design in hardware will fail? isn't it the case?
> 
> Thanks a lot,
> -Manny