Electronic – SRAM works with short read cycles, fails with longer ones

fpgasram

I observe a rather weird behavior of an IS62WV51216BLL-55TLI SRAM chip connected to an FPGA. When I run it with the shortest read cycles possible, it works as expected:

enter image description here
(here, I read the expected value 0xCF9C3063. One tick is 6.25 ns)

However, when I try to use longer read cycles, it mysteriously fails:
enter image description here
(here, I read the value 0x136000D0 instead of 0x1360EC9F. One tick is 6.25 ns)

As you can see, the right data appears on the data bus at some point, but is quickly replaced by a bogus value. This happens sporadically at a different address every time, and re-reading the same address a second time works fine:

enter image description here
(here, I read the value 0x18E06439 the first time, and the expected value 0x18E0E71F the second time)

Does anybody have a reasonable explanation for this? Is there something wrong with my read cycle? Here's the read cycle from the datasheet above, for reference:
enter image description here

All my diagrams were made with SignalTap (logic analyzer built into FPGA) running at 160MHz. All output pins of the SRAM controller are registered:

// ** Output Pin tcm_address_out 

reg                       tcm_address_outen_reg;     

always@(posedge clk) begin
 if( reset ) begin
   tcm_address_outen_reg <= 'b0;
 end
 else begin
   tcm_address_outen_reg <= 'b1;
 end
 end             


reg [ 19 : 0 ] tcm_address_out_reg;   

 always@(posedge clk) begin
 tcm_address_out_reg   <= tcs_tcm_address_out[ 19 : 0 ];
  end


assign  tcm_address_out[ 19 : 0 ] = tcm_address_outen_reg ? tcm_address_out_reg : 'z ;

The tcm_address_out signal is then connected to the sram_addr pins seen on the diagrams above, which are in turn connected to the A0–A18 pins of the SRAM IC. Other pins are connected in a similar manner. The length of wires/traces between an FPGA pin and a SRAM pin is about 10 cm. The SRAM IC has 1uF + 100nF ceramic caps between GND and VDD pins of both sides.

PS. I have tried to keep \$\overline{CS}\$ asserted the whole time, which didn't improve things. I have also tried a modification where \$\overline{OE}\$ is asserted 12.5ns after \$\overline{CS}\$ and is deasserted for 12.5ns between consecutive reads (while keeping \$\overline{CS}\$). That didn't help:

enter image description here

Best Answer

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!).
Related Topic