Glitches in post-layout (PAR) simulation

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:

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?

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

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

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:

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

Peter, from now on I should stop using the word glitch. There is no gating and the design is synchronous. What I meant to say is the following: starting from the flipflops, there are non-uniform delays among the output of flipflops until reaching the output buffer pad (routing-caused). Now I figured it out. I shouldn't be reading my output as: real_out

I've just did this:

tb : PROCESS BEGIN wait until (reset = '1');

for i IN 0 TO 2091 loop filter_in

Peter, don't worry. I'd most probably end up supplementing a fusion with a spartan-3L. I think there is a no way in the world to fit complex DSP operations solely in soft fabric. It would be nice to boot up the spartan from the fusion's embedded flash and probably use their ADC also. It's just that the application is power critical and I'm not sure about how well spartan-3L would perform as a battery-powered device.

Cheers,

-Manny