1
\$\begingroup\$

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.

\$\endgroup\$
  • \$\begingroup\$ Can you give us part numbers and link to the relevant datasheets? Also, your code would be helpful. \$\endgroup\$ – user17592 Apr 18 '13 at 7:57
  • \$\begingroup\$ This is the SRAM Datasheet. Currently I have not finished the codes but the problem are not the controllers. I would like to know how I can wait for the activation of the READY signal using VHDL. \$\endgroup\$ – user22756 Apr 18 '13 at 8:15
  • \$\begingroup\$ Take a look at this answer: electronics.stackexchange.com/questions/57035/…. I know it isn't for this scenario, but it does contain details on how to use a state machine. The principal is that your controller waits in a certain state until a specific condition causes the state to switch. This is a reliable way of ensuring that your controller behaves in a controlled, predictable manner. \$\endgroup\$ – stanri Apr 18 '13 at 8:28
  • \$\begingroup\$ WAIT until some event IS synthesisable with most tools, though WAIT for time T is not. Alternatively, use a state machine as Stacey suggests. \$\endgroup\$ – Brian Drummond Apr 18 '13 at 8:58
  • 1
    \$\begingroup\$ The SRAM datasheet (like most static SRAMs) does not show a READY signal of any sort. Where is this coming from, and what exactly does it mean? Why is it needed at all? Also, this is a 55 ns part, while most VGA interfaces run at a speed of 25 MHz or more (40 ns cycle). Are you sure it's fast enough? \$\endgroup\$ – Dave Tweed Apr 18 '13 at 20:21
1
\$\begingroup\$

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.

\$\endgroup\$
  • \$\begingroup\$ I already used this method but if I have to write 100 bytes this method become very long and everytime I have to write a byte I have to calculate the clock cycles. Are there other systems to avoid this? \$\endgroup\$ – user22756 Apr 18 '13 at 10:05
  • 1
    \$\begingroup\$ The time required is fixed at design time, so you don't have to calculate anything on every byte. When reading/writing the SRAM you have to wait the required time. \$\endgroup\$ – pjc50 Apr 18 '13 at 10:54
  • \$\begingroup\$ Can you write a little example? \$\endgroup\$ – user22756 Apr 18 '13 at 11:14
  • \$\begingroup\$ This is a bit different example, but You'll get the idea. pastebin.com/ufTQq9aF \$\endgroup\$ – Socrates Apr 18 '13 at 12:03
1
\$\begingroup\$

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.

\$\endgroup\$
  • \$\begingroup\$ Yes, I answered a months-old question. Hopefully the OP succeeded since then, but there's nothing more aggravating than having a problem, doing a search, only to find someone else had the same problem 2-3 years ago, posted a question, and never got their answer, and you're stuck w/o an answer, too. \$\endgroup\$ – JustJeff Oct 31 '13 at 2:48

Your Answer

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