UniPHY IP does not complete calibration after asserting and deasserting global_reset_n or soft_reset_n signal low for UniPHY IP. EMIF debug toolkit cannot be connected to that interface (link project to device). This condition does not change even if multiple resets are issued later. This condition can be recovered only by reconfiguring the device.
These symptoms can be caused by the internal reset structure of the EMIF UniPHY IP. An asynchronous reset assertion to the logic driving the address bus of an M20K RAM can cause asynchronous logic propagation. This can impact functionality of M20K address row/column decoders, opening more than one word line which can result in charge sharing between bit cells, corrupting the contents of the M20K. Note that the probability of M20K corruption due to asynchronous reset assertion is very low.
PLL reset during M20k read or write operation can also contribute to embedded RAM/ROM corruption because PLL lock loss may result in a clock glitch during reset and this may impact functionality of M20K address row/column decoders.
This corruption affects the UniPHY IP because it contains a Nios (R) II processor that is used for calibration, and the processor's program code is stored in M20K RAM. If the corruption occurs within the Nios (R) II program memory, this can cause the Nios (R) II sequencer to lock up, resulting in incomplete calibration. Recovery from this situation is only possible by reprogramming the device, as M20K contents are only loaded during device programming.
It is important to note that common EMIF failures listed below does not necessarily mean the M20K RAM is corrupted or Nios (R) II sequencer is locked up
- If calibration never passes (i.e. calibration always fails).
- If calibration margins are very slim, and occasionally fail calibration.
- If design passed calibration, and occasional data errors are observed while running the design.
- If design says it passed calibration, but design is not working as expected.