VHDL SRAM Controller interface

Question

I'm designing a VGA controller in VHDL and for video memory I decided to use SRAM memory. In order to manage the RAM I created a controller that must be interfaced with the VGA Controller. So far I have always programmed with sequential languages and so I have some problem in interfacing the two controllers. For example: write a data in the SRAM takes a T time and when the controller has finished the operation it will trigger a READY signal. How do I make sure that the VGA controller wait for this signal? From what I have seen the VHDL WAIT statement can't be synthesized.

Answer 1

Simply count the cycles. There's no such "time" in synthesizable design. You have N cycles for write plus datasheet will tell K cycles to wait. That's it, use a counter until N+K reaches.

Answer 2

You stated you are designing the VGA controller, and the SRAM interface. I would suggest you ditch the 'ready' signal. Generating video isn't like requesting a disk sector or something; when it's time for the next pixel, it's time for the next pixel, whether the memory system is ready or not. If your VGA controller is waiting for a 'ready' signal, and not propagating the next pixel into the output section, you're going to get at least a glitch on the screen, b/c the electron beam (metaphorically speaking) is not going to stop. Worse, if you insist on generating all N pixels on a line (and you should), and enough of them slip like this, and the timing on entire line will be blown to the point that the monitor will lose horizontal sync.

Certainly there are a lot of systems where memory access time is non-deterministic, and you have to rely on 'ready' signals, but video generation isn't that kind of problem. Generally your memory access time is driven by your pixel rate. If you need a new pixel every 25ns, for example, then every 25ns you simultaneously do two things: (1) you latch the data, and (2) update the buffer address. But the RAM has to be significantly faster than this pixel time. Out of the 25ns you have to deduct the setup time for your data latch, hold time for same, and time for the buffer address to settle. If your latch needs data stable for 5ns before the clock edge, and 3ns after, that means the RAM has to be faster than 25-5-3, i.e., 17ns or better.

You can get some relief from the timing depending on what you define as a pixel. If you intend to generate only black and white pixels, and you have an 8 bit wide memory, and you need a pixel every 25ns, then you only need a memory access every 200ns. If you can grab N pixels worth of data per access, you only need an access every Nth pixel time.

Now you mentioned writing to the memory. If you're generating video, that's a read-only proposition. So I infer that you intend to dynamically alter the video buffer in some way. This means you now have two sources of access to the RAM. Oft times, people throw a dual port RAM at the problem. Lacking dual port, you must arbitrate who gets access to the video buffer RAM. You can either just let the writer have priority, in which case you get glitches if the writer writes during the active scan area, or you can try to synchronize the accesses, which cuts the required response time in half again.

Bottom line is, you really don't want a 'wait' in your VGA/RAM interface, b/c the monitor is not going to wait around, it will display something when the next pixel time arrives, no matter what.