Interfacing static ram to fpga

Question

I while ago I asked this question about interfacing static ram to an fpga for the purposes of a vga frame buffer I wanted to make as a little hobby project. It became clear to me at the time that the project was too difficult for my level of knowledge (as I'm basically a c++ programmer and knew little about electronics) but since then I've built a few smaller cpld based projects so now feel I know enough to look at the project I want to build again :)

I'm thinking of using this memory chip as it seems to fit my requirements. The data sheet indicates that I can read a data byte every 10ns and that I have to set up the address a minimum 10ns before I want to read the data. It has a "Data Hold from Address Change" time of 3ns.

This implies to me that assuming a 10ns clock I can simply set the address lines each clock cycle, and read back the data from the previous address. That the data output will be valid at or before the next 10ns clock, and will remain valid for at least 3ns after I change the address , so it's safe to read it.

Is this a reasonable thing to so (setting the address at the same time as I read back the data from the previous address). From looking at the data sheet it seems so.

This is the fastest it would work, I could also use a slower clock if pushing the timing to the limit like this was a problem, I just wanted to understand if I'd understood the data sheet correctly.

Answer 1

I assume you're looking at "Read Cycle No. 1". Yes, that's the correct interpretation of the datasheet.

Now you have to worry about the FPGA side, which has its own setup/hold times and delays. If you have enough frequency headroom on the FPGA you don't need to worry much about this beyond basic timing constraints; the tools will abstract things away to some extent. But eventually you will find something that needs to be micromanaged, so it helps to start thinking about these issues now. I suggest completing the HDL side of your project (read those timing reports) before finalizing your hardware design.

Operating an external 100 MHz interface on budget FPGA families is probably going to require some care. You can start low and slow, though, like a few tens of MHz, before really getting your feet wet.

Answer 2

Regarding simulations, building your own SRAM model would be a useful learning experience - timing checks can be simulated as described in this link

Alternatively, the Hamburg VHDL archive has some models of SRAMs which might be useful and/or instructive.

Once you have built your test bench and got it working on your HDL code, you can also generate a post-PAR netlist and use that in the testbench. This model will have some actual delays modelled (and timing requirements), which will give you some confidence that you are getting something useful at the end.

Answer 3

You seem to understand the SRAM side pretty well, so I won't touch on that.

Coming from CPLDs, which don't have many flip flops, you may not be familiar with pipelining. Essentially, it is the act of inserting flip flops into the logic path in order to reduce the cycle time. Considering that your FPGA will be sucking down 800 MB/s, you will almost certainly need to pipeline your design in order to achieve timing closure.

Consider calculating 2x+1. This is two operations, a multiply and an add. If you try to do both operations in a single clock cycle, it might take 20 ns (value pulled out of thin air for convenience) for the signal to work its way through both the multiplier and the adder. However, if you pipelined it so the multiply happens in one stage and gets fed to a flip flop, and then the add happens in a second stage, then you can reduce your clock period to 10ns, since it only takes 10ns for the signal to propagate from one flip flop to the next.

I would recommend starting WAY slower, if you have 10ns access time then I would begin with something much safer, like 100ns accesses. Just make sure that you can read and write a bit pattern to RAM and then echo that pattern out to a scope. Once you know you can read and write to the RAM correctly, then you start adding your pipeline stages, while still keeping the 100ns accesses. This step is just to make sure that the data is propagating through the pipeline correctly, as it's very easy to be off by one stage. Your goal here is to add enough stages that the timing report indicates a 10ns clock cycle is feasible ("achieving timing closure" in the parlance). Once you get enough stages in the pipeline and they are working correctly, then ramp your clock speed up.