Apparent Reset Glitch on Synchronous Reset

Question

While running SW tests, at random times it looks like all my internal registers are getting cleared to their reset values. This is true for both registers and SOPC modules. Depending on the SW I run, this happens at different locations and at random times. My best guess is that I am getting a glitch on the reset line.

However, the reset signal is generated synchronously so I don't understand how it could glitch. There are two reset sources which both have at least 2 levels of synchronization to the clock. The internal reset signal is the output of a DFF.

I have captured the event using signal tap and I do not see any of the FF's invloved in the reset changing value.

If I add or remove signals from SignalTap and recompile I change the behavior of the system. Sometimes it will fail and other times I can't reproduce the failure.

Since I can recompile the code with no logic changes (only SignalTap changes) and get the problem to go away it's not clear to me if I make changes to the logic that I can prove I have solved the problem.

Any thoughts?

Thanks,

Stefan

altera_forum · Answer

I think some more debugging is going to need to be done. Let's just say a glitch is occuring, and let's make it long, like 100ps. If the fanout of the net is to many registers, the delay to all of its destinations will vary by much more than 100ps. Since it's a synchronous reset, then this 100ps pulse would have to hit every register at exactly the same time as the clock edge is hitting them, which I would say is close to impossible. My guess is that it's not just a glitch, but a full logic change for a cycle. Are you able to capture it with SignalTap?

If you can't outright capture it in signaltap, anohter idea is to have the signal clock a toggle register or a 2-bit counter. Then capture the toggle register or counter by SignalTap. If the glitch is long enough to set all your registers, it should cause the flop or counter to switch states, and you should be able to capture that in SignalTap. If you can't capture that, then I doubt that is the signal that is truly causing the problem.

And when you change SignalTap and the results change, are you doing a full recompile, so your whole design is re-fit, or are you doing an incremental compile, so only the SignalTap nets are changing?

altera_forum · Answer

I'm doing a full recompile. I'm using the web version in my office.

I think I was not quite clear on the internal reset signal. The internal reset signal is used asynchronously throughout the design, both in top level blocks and passed to SOPC Builder.

This internal reset signal is being generated from the output of a DFF whose input is the OR of 2 other DFF outputs.

Using SignalTap I captured the failure event. I was watching 12 asynchronously reset registers and the 3 DFF's involved in the reset. I do not see the 3 reset DFF's change value. I do see all 12 of the other design registers that were high get cleared on the same clock edge in SignalTap.

The same clock is used throughout the design.

I'll implement the toggle suggestion you had and try that tomorrow.

Thanks,

Stefan

altera_forum · Answer

Hi Stefan ,

In your design , is there any reset case like this one ?

------------------------------------------------------------------

library ieee;

use ieee.std_logic_1164.all;

use ieee.std_logic_arith.all;

use ieee.std_logic_unsigned.all;

entity glitch is

generic

(

RESET_VAL : natural := 170;

WIDTH : natural := 8

);

port

(

areset : in std_logic;

clk : in std_logic;

ena : in std_logic;

Q : out std_logic_vector(WIDTH-1 downto 0)

);

end entity glitch;

architecture behavioral of glitch is

signal cnt : integer range 0 to RESET_VAL-1 := 0;

begin

process (areset, clk, cnt)

begin

if areset = '1' then

cnt <= 0;

elsif cnt = RESET_VAL-1 then

cnt <= 0;

elsif clk = '1' and clk 'event then

if ena = '1' then

cnt <= cnt + 1;

end if;

end process;

Q <= conv_std_logic_vector(cnt, WIDTH);

end behavioral;

------------------------------------------------------------------

I have tried this before , I evaluated it in a MAX II Device EPM570T100C5

Everything works fine in TIMING simulation in Quartus II

However when I downloaded the program to the CPLD

(actually it is not only a counter design , a total of 570 LE)

Then I checked the signal waveform on the scope

I have found that the coutner part is reset to zero in an average of 19 rounds

but it failed to reset (not returning to zero) at 20th round in an average

The solution is :

process (areset, clk, cnt)

begin

if areset = '1' then

cnt <= 0;

elsif clk = '1' and clk 'event then

if ena = '1' then

if cnt = RESET_VAL-1 then

cnt <= 0;

else

cnt <= cnt + 1;

end if;

end process;

I am not sure if this is your case , Hope it helps

Cheuk

altera_forum · Answer

--- Quote Start ---

process (areset, clk, cnt)

begin

if areset = '1' then

cnt <= 0;

elsif cnt = RESET_VAL-1 then

cnt <= 0;

elsif clk = '1' and clk 'event then

if ena = '1' then

cnt <= cnt + 1;

end if;

end process;

--- Quote End ---

I would be careful not to deviate from the template:

process (areset, clk)

begin

if areset = '1' then

--async initializations with constants

elsif clk = '1' and clk 'event then

if ena = '1' then

-- sync assignments

end if;

end process;

altera_forum · Answer

Note that, although it is recommended to follow a coding pattern for doing resets, enables, etc., this is more for the purpose of easily readable/writable code, as well as making sure you can take advantage of the dedicated logic surrounding the FFs. (The Quartus II handbook talks about FF signal priority in Recommended Coding Styles). For example, the clock enable has priority over a synchronous reset. If you code the synchronous reset with priority, then this can't be implemented in the dedicated register silicon and will have to be done in the LUT before it(i.e. the clock enable will be a feedback mux) in the LUT, and you're design will get bigger/slower.

That being said, if you code in a different manner, it should still always work. A feedback mux in the LUT should function just like an enable. If something doesn't work, there's almost always a good reason.

When dealing with asynchronous resets, be sure to understand Reset/Recovery. Almost all designs have asynch resets, and yet Reset/Recovery is one of the least understood topics in static timing analysis. It is off in the Classic Timing Analyzer by default, but can be turned on under Assignments -> Settings -> Timing Analysis -> More Settings -> Reset/Recovery Analysis. It is on by default in TimeQuest.

Note that this is not the issue with the original post. If you fail Reset/Recovery, it just means your registers will go into the reset or come our of the reset state one clock earlier or later than expected. But it will not "glitch". As for this glitch, I still do not believe it is a glitch, at least in the classical sense. Is everything on the same clock domain(the original three registers that create the glitch as well as the registers the reset feeds)? Do the three reset signals have any FF controls, like their own asynch reset, or do they just use the D, CLK and Q port? Just some more things to look at. (And for clarification, the title says Synchronous Reset, but it feeds all the destination registers through the asynch reset port, correct?)

Forum Discussion

Apparent Reset Glitch on Synchronous Reset

8 Replies

Recent Discussions

Debugging the FPGAs connected in passive serial mode

MegaWizard Plug-In Manager : ALTPLL [Corrupted in Quartus Prime Lite 25.1]

LTC Connector DE10-Standard FPGA

Agilex 5 PWRMGT IO pin connections

CPRI F-Tile Dynamic Reconfiguration