5
\$\begingroup\$

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.

\$\endgroup\$
3
\$\begingroup\$

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.

\$\endgroup\$
  • \$\begingroup\$ But can't you run static RAMs slower? Isn't that half the point of them? \$\endgroup\$ – Prof. Falken Jun 10 '12 at 22:53
  • \$\begingroup\$ @AmigableClarkKant Of course. I don't see where I've implied otherwise? \$\endgroup\$ – mng Jun 11 '12 at 0:22
  • \$\begingroup\$ "Operating an external 100 MHz interface" sounds very daunting and scary to this very novice person. But in light of your comment, I think I understand "You can start low and slow" better. I'd write "at first don't try to cram out all performance of the RAM. Run very slowly at first and make sure that works before you try to run it at the speeds it's specified for." (Do I understand you correctly?) \$\endgroup\$ – Prof. Falken Jun 11 '12 at 1:20
  • \$\begingroup\$ Great thank you. I can probably run the memory at 60Mhz or so for my project which should give me a fair bit of headroom. I guess there is no easy way to simulate most of this is there? So mostly I'd have to look at the timing reports and the fpga data sheets? \$\endgroup\$ – John Burton Jun 11 '12 at 7:43
  • \$\begingroup\$ @AmigableClarkKant Yes basically. But the limiting factor is probably going to be the FPGA. \$\endgroup\$ – mng Jun 11 '12 at 19:06
2
\$\begingroup\$

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.

\$\endgroup\$
  • \$\begingroup\$ When I was thinking of simulating ram I was thinking of doing so on an fpga using block ram, but of course that would be difficult. I guess I could do so in a simulator of course. \$\endgroup\$ – John Burton Jun 12 '12 at 12:39
  • \$\begingroup\$ Always doit in a simulator first - you get lots more iterations per hour than building in an FPGA. Also, BlockRAMs are synchronous (have a clock) whereas your SRAM is asynchronous. You'd have to build an async RAM model out of the little memories that the LUTs can form to be getan async model. And even then the timing would be different. \$\endgroup\$ – Martin Thompson Jun 12 '12 at 13:24
2
\$\begingroup\$

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.

\$\endgroup\$
  • \$\begingroup\$ Good advice, that makes a lot of sense. \$\endgroup\$ – John Burton Jul 6 '12 at 15:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.