unexpected CPU/hardware reset

[Altera_Forum]

We have a board custom based on a cyclone III and everything has been working well for months. In a recent batch of boards we received, however, occasionally the system seems to unexpectedly reset. I am not sure if it is a CPU or full reset. I just notice that the sys_clk_timer seems to start over and my application code enters main(). I found that I could prevent the reset from occurring in these new boards by commenting out an IORD() which reads from a custom peripheral's data memory. 

 My first question would be what are all the possible ways for a system reset to occur? Also I am not sure if for our custom peripheral it was necessary to generate a HAL API with <component name> _regs.h, etc in order to use IORD?

[Altera_Forum]

No you can directly use IORD without any problem. 

Could it be a power supply problem? Your peripheral could send a pulse on the FPGA's power supply that triggers a reconfiguration. Do you use PLL? Do they loose lock at one point? If you have a scope you can monitor the FPGA's nStatus pin to check if it is reconfiguring itself.

[Altera_Forum]

When using a different build it seemed that the problem was unrelated to the IORD. Additionally, sometimes when programming the flash I get some garbage in the CFI query table (although verification is OK), 

  CFI query table read from device:  10: 51 52 59 01 00 0A 01 00 00 00 00 17 20 85 95 06 QRY......... ...  20: 09 09 00 02 02 03 00 18 01 00 09 00 02 03 00 80 ................  30: 00 7E 00 00 02 00 00 00 00 FF FF FF FF FF FF FF .~..............  40: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................  50: FF FF 89 1B 44 00 08 59 08 59 64 00 64 00 64 00 ....D..Y.Yd.d.d.  60: 64 00 F8 00 FF FF 00 00 00 00 EC 02 E4 02 EF AD d...............  70: EF AD 40 02 00 00 C7 00 B8 00 48 0F 48 0F EF AD ..@.......H.H...  I also suspect a hardware issue and will look into the things you mention Daixiwen. Thanks.

[Altera_Forum]

It seems that the boards which displayed this problem had Cyclone processors which went from a 65 nm to a 60 nm process. When we downgraded our clock rate for the SDRAM the problem went away.

[Altera_Forum]

--- Quote Start ---  It seems that the boards which displayed this problem had Cyclone processors which went from a 65 nm to a 60 nm process. When we downgraded our clock rate for the SDRAM the problem went away.  --- Quote End ---    Do you use TimeQuest for timing analysis?  If not, you should perform a timing analysis with both boards.  Ideally the change in process should be reflecting in the change in FPGA timing. You should be able to get both boards operating with the same SDRAM clock frequency, but you might need to adjust output timing to different 'optimal' values for each board type.  Cheers, Dave

[Altera_Forum]

A timing analysis was done and there was no change we are aware of to the timing models in going to the new process. According to PCN0904, it is the same in form, fit, and function with the existing data sheets.

[Altera_Forum]

--- Quote Start ---  A timing analysis was done and there was no change we are aware of to the timing models in going to the new process. According to PCN0904, it is the same in form, fit, and function with the existing data sheets.  --- Quote End ---    Is the SDRAM clock single-data-rate (SDR) SDRAM? Is the FPGA generating the clock? Did you have to change the timing of the clock to the SDRAM to get it to work?  Have you probed with a scope to check the timing of the 'working' board versus the new devices?  I'm just wondering whether the timing on the first board was marginal, and now things are properly broken. Have you tried moving the SDRAM clock around (using a PLL phase shift) to see what sort of setup/hold timing margin you have?  Cheers, Dave