# SRAM works with short read cycles, fails with longer ones

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:

(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: (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:

(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:

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

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

reg [ 19 : 0 ] tcm_address_out_reg;

always@(posedge clk) begin
end



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:

• The point is very simple. If it doesn't work, do exactly like they say. If it still doesn't work, look for a bigger mistake. Crap on memory output may be a symptom of missing decoupling capacitor, bad voltage, fake components, whatever. But to go to investigate it that way you first need to do everything by the book. Don't forget, sometimes datasheet may be not 100% complete, especially for memory which is normally used with a CPU, so just a tiny minority of engineers read it's datasheet – Gregory Kornblum Apr 15 '17 at 11:08
• Well...first off the waveform captures are NOT like the data sheet chip timing diagram in that you are changing the address values during the chip select cycle. Just pointing that out as a difference despite the fact that SRAM read cycles should work just fine from just the address changing to valid data after the tAA access time. I am pretty much on the page with Gregory here in that the problem is most likely something not showing in these timing captures. Could be power surge or droop to the SRAM chip, ground bounce, or even some type of transient contention on the SRAM_DATA pins. – Michael Karas Apr 15 '17 at 12:30
• I was responding to what was posted. I did say that reads from address changing should also work. Do you possibly have signal integrity problems on your address lines? Logic analyzer traces will tend to hide that. – Michael Karas Apr 15 '17 at 13:43
• You also say that the the traces from FPGA to the SRAM are 10cm long. That is long enough and the FPGA outputs have transition times that are fast enough where you probably and really should have 22 to 33 ohm resistors in series with each line at the FPGA outputs. Note that the SignalTap view of the SRAM signals are "isolated" from whatever is going on at the physical board level and you will likely need to use the a regular oscilloscope to investigate the signals themselves at the SRAM to evaluate the SI (signal integrity) that I alluded to before. – Michael Karas Apr 15 '17 at 16:01
• Despite the name, high-density static RAMs do use internal timing generators to control things like sense amplifier precharge, etc. These are driven by the edges on the control lines. Note that the datasheet states that the test conditions assume transition times of 5 ns or less. This is something you'll want to verify in your setup -- slow edges, or edges with a lot of ringing could produce the symptoms you're seeing. – Dave Tweed Apr 15 '17 at 18:19

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!).
• Thanks, I will try those things you mention (I didn't try weak pull-ups yet, and halting the clock). The primary suspect IMO is the ringing Dave has mentioned, so my next step would be to get the proto board to a lab with a decent scope. However, if that yields no results, I'll go through the whole list. – Dmitry Grigoryev Apr 17 '17 at 21:06