Apparent Reset Glitch on Synchronous Reset

[Altera_Forum]

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]

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]

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]

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 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 if;  end if;  end process;  I am not sure if this is your case , Hope it helps Cheuk

[Altera_Forum]

--- 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 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 if; end process;

[Altera_Forum]

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

[Altera_Forum]

Apparently I was a bit sleepy when I wrote the original email cause I agree the title is confusing (although I didn't think so at the time :-) ). 

 Yes, all the Reset registers and the reset of the design use the same clock.  The reset registers only use D, CLK, and Q.  The signals that I captured under SignalTap run the gambut: Altera's PIO output, external bus address latch, data register in SOPC Module, control signals from state machine. Design has combination of verilog for SOPC modules and AHDL for state machine block plus some schematics.  I added a counter and some other logic that just uses the clock and an asynch reset to see if these are cleared as well. Of course, with this new logic I can't reproduce the problem. I'm still tinkering to get one that fails again.  We're also looking into noise on the voltage pins. This would have to clear the registers in the FPGA (appear like reset) but NOT touch the FPGA image since the FPGA is still programmed. Is there anything else like this that could cause problems that we should check in the PCB?  Thanks for all your help.  Stefan

[Altera_Forum]

I finally captured some new information. 

 I added two 15bit Altera MegaCore lpm_counters to the top level BDF and added the output of both to SignalTap. - CounterR has clk and an asynch reset - CounterNoR has clk only.  After power on I see the CounterR count lag by 17h which makes sense since it will start later due to reset signal.  I captured the error, and I see CounterR being cleared to 0 BUT CounterNoR keeps counting without errors. On the next clock CounterR is 1 so it is not held cleared.  Here are the 5 clock values surrounding the error: CounterR: 30B5 30B6 0000 0001 0002 CounterNoR: 30CC 30CD 30CE 30CF 30D0  I have the FF that generates the asynch reset signal as well as the asynch reset signal being captured in SignalTap and I don't see them go active - same behavior as before.  After typing all this I captured the counters and they have the same 0x30CE offset.  This seems to imply that it is the reset signal causing problems.   I'll try to get the asynch reset on a pin and hook up a scope and see what I see. We're a bit pin constrained so this may take a bit to find a pin that doesn't conflict with other logic.  Thanks,  Stefan

[Altera_Forum]

try put the reset signal as a clock to a TFF with T=1. Monitor Q. This should capture and enlarge any gliches, making it easier to see. Remember these glitches may be sub ns, never making it to a phyical pin, let alone a scope probe but still being able to wreck hawock a reset.