SRAM works with short read cycles, fails with longer ones
Dmitry, in order to get the solution to your issue, you will need systemically troubleshoot it. TonyM, Trevor, Dave, Michael and Gregory provided several guesses, which need to be systemically qualified within your design. I will provide some summary below for you:


your board is having some FPGA, with IS62WV51216BLL-55TLI chip connected to it through 10 centimeter long tracks;
no information on power routing, or power decoupling is available;
you shown the code selecting the address, no information is available how you sample the data into FPGA design.
no board pictures are available, we can not see design of your board and how it is made.


Let's look into the configuration:

always@(posedge clk) begin
 if( reset ) begin


Your analyzer readings are missing reset signal. You will have to prove that reset signal is always low when issue exhibits.

Now let's look into diagrams. As you noticed value changes E0A0 -> ECA0 -> EC9F -> 00D0, with change to 00D0 happening inside the read cycle, and being an issue you report. This SRAM is not registered in its input and I/O pins, thus if it starts outputting some wrong signals, several issues may occur:


power issue. If there would be intermittent power problem, RAM chip would anyway end up with right value being read as it has unregistered inputs. You can try to increase read cycle even more, to see if value changes again from 00D0 to EC9F. If power would go bad completely, there would be data corruption in the RAM contents, as it does not happen (and second time you can read the correct data) I hardly believe it is power issue.
control or address signal issue. Do you have pull-ups on the data lines? If you would have them, then inactivity will be read as FFFF, otherwise it can be read anything. I would recommend turning weak pull-ups on at the FPGA side. It is really hard to say what may happen to the control/address lines, as commentators pointed that what you have is how FPGA sees the situation, and not what really happens on the interconnect between FPGA and SRAM.


I would recommend you the following:


turn weak pull-ups on on the data lines to ensure that if you have chip selection/out enable issues it is seen as FFFF on the bus;
catch the buggy read cycle and halt the system, using logic probe seeing logic levels on the pins. For this you can fill RAM with some predefined content (e.g. 0001 - 0203 - 0405 - ...), and read addresses in loop until you get unexpected value, and halt clock when it happens. Using multimeter/logic probe measure voltages of all signals - control, data and address - to find out how it looks from the outside of FPGA.
as people already said in comments, check physical connections. You take magnifier and look at each PCB joint, you use a needle putting it between chip's pins (if it is not BGA but TSOP) with some force to ensure that when you apply small force pins are not get torn off the pads (be very gentle not to bend pins and tear pads away!).