Z. W. wrote:
> The FPGA state machine will lock up to a certain unknown state
When I read this, in my mind immediately pops up: "Asynchronous Inputs!"
Try that with Google translate:
http://www.lothar-miller.de/s9y/categories/35-Einsynchronisieren
(Its german. And its VHDL, but the problem is the very same)

And here one must keep in mind: the most async input is the reset.

> due to the noise from SMPS.
Thats very, very strange! And it sounds like a try for a cheap excuse 
for a self made problem.
Billions of electronic devices are running with SMPS, why not yours? Ist 
it poorly self designed? Or why can you blame the SMPS for the problems?

Please don't judge before standing in my shoes.

I am in oil gas industry and trying to pack all the circuits in a very
tiny space to work at 200ºC. Parts selection that can work at this grade
is very limited. Those fancy filter scheme is not going to work for my
case. I can only live with the noise. The power supply is
transformerless and the input range is from 150V ~ 250V and output can
be low as 26V and 50mA. We have done multiple tests confirm the lock up
is due to the noise. And only the ADC module is locking up. The code
size is too large that it has to be seperated into two FPGA module that
works at 200C. When the code is running at commercial grade there was no
problem.

The asynchronous input will be synchronized. The asynchronized reset is
generated by OPAMP with two different time constant capacitor and
resistor at different voltage rail during circuit startup. Once this
signal is trigger, the reset module in FPGA will extend it for couple ms
to synchronize it.

My question was about the consequence of incorrect reset I wrote.
Usually it is
if(reset)
   A <= 0;
else if ( )
   A<= 1;



If people (especially the moderator) in this forum is that
condescending, I will stop here and go somewhere else for help.

Z. W. wrote:
> Please don't judge before standing in my shoes.
Where did I judge?
I asked information you didn't provide in the first post...

> If people (especially the moderator) in this forum is that
> condescending, I will stop here and go somewhere else for help.
If you want want it "soft and warm" you'll have to.
But as I said: answer those questions and think about them. It was my 
leisure time I took to try to help you. I simply could have written 
nothing instead...

> My question was about the consequence of incorrect reset I wrote.
What is "incorrect" with this version?

> We have done multiple tests confirm the lock up is due to the noise.
At what clock speed? How many clocks do you have in your design?
> When the code is running at commercial grade there was no problem.
Then it is some kind of async input. Do you have reasonable timing 
constraints?

> The code size is too large that it has to be seperated into two FPGA
> module
FPGA is full? Did you check for SSO bouncing?

Z. W. wrote:
> if (reset)
>         delay   <= 0;
>   if (inc_delay & !reset)
>     delay  <= delay + 1'b1;
Because there is no "else" you will get a flipflop with sync reset. You 
will have to give more lines of code to get a clear picture try to start 
at keyword always...