Signal falsely changes to '1' after clock starts

[lounug]

Hi, 

I got a very rare case that I have never seen before after years developing Intel FPGA Design and verifying the design using SignalTap.

A std_logic signal that has initial value of '0' and reset to '0' (asynchronous reset) somehow toggles to '1'. I found this out by using the SignalTap Power-Up Trigger.

A simplified code snippet that assigns this signal would be:

I expect the signal "init_w" will ONLY go to '1' when STATE = sPATH_1.

But it goes to '1' immediately after clock is ticking.

This is shown by "cnt_debug" signal, which is a 24-bit counter that counts at every rising edge of "clk" after FPGA is booted up.

Did anyone have ever this problem/bug/case before?

Any ideas/solution/any comment from Intel Devs or Admin would be greatly appreciated.

Thank you in advance.

[FvM]

How is reset generated in the design, is it released synchronous to clock? If not state machine may have irregular transitional states that are not seen in SignalTap recording. Also is clk PLL generated or directly driven form an external source?

[lounug]

Hi FvM, 

thanks for your reply.

Regarding your question about reset, I just checked with my colleagues, the reset pin is indeed always toggled to inactive, as soon as the FPGA is booted up.

Regarding the clocking, the clock is 50MHz generated by PLL, and the PLL itself gets 25MHz clock from external oscillator on the circuit board that is connected to the FPGA clock pin.

Do you think the problem can be caused by the reset?

We have tested this design/FPGA with more than 50000 power on/off cycle, and the error trigger (shown above) is seen at most in random, in average once every 750 power on/off cycle. 

But when the product does not function properly (hence the error trigger is latched by SignalTap) it is always because of this one specific signal "init_w", not any other signal.

So I really wonder, if the problem comes from any reset behaviour, why doesn't this affect other signals in the design?

Look forward for your reply again.

In parallel, I will try to modify the reset behaviour to test if it changes the error events. 

[FvM · Accepted solution]

You should definitely try a reset synchronizer. For implementation, see paragraph recommended design practice - asynchronous reset in Quartus manual.

[lounug]

Thank you for the suggestion, I will test the design using synchronous reset

[SyafieqS]

Did you manage work on previous suggestion?

[lounug]

I am currently running test using the suggestion! It will be running for a few days

[SyafieqS]

Let me know if there is any update

[lounug]

It is working until now, yesterday I already marked the reply as solution as you can see above

[SyafieqS]

I’m glad that your question has been addressed, I now transition this thread to community support. If you have a new question, Please login to ‘https://supporttickets.intel.com’, view details of the desire request, and post a feed/response within the next 15 days to allow me to continue to support you. After 15 days, this thread will be transitioned to community support. The community users will be able to help you on your follow-up questions.

p/s: If any answer from community or Intel support are helpful, please feel free to mark as solution, give Kudos and rate 5/5 survey