I got myself a spartan-3an evaluation board in order to learn fpga programming and some verilog. It's taken a little while to stop seeing it in terms of a sequential programming language and to start seeing it in terms of connections between blocks of hardware but I'm getting there.

I've made a small "program" that takes a image defined in "ram" and displays it on the vga port. The ram is just a set of reg's like this

reg ram[4095:0]; // Video memory for 64x64 pixel display

I used the patterns in the help and the compiler has inferred that it should put this into a blockmem and it all works nicely.

My doubt is about timing though.

I have one "always" block incrementing a counter for the vga horizontal position, and one incrementing a counter for the vga vertical position. Then I have another always block that uses that counter to generate an address into a "reg" that indxes the memory.

There is then another "always" block triggered by a clock that reads that memory.

My doubt is this - I'm generating the sync pulses based on the counters. That's fine, but I'm generating the address in the video memory too from those counters to read the pixel. However that read will occur on the next clock pulse so my pixel data will be output one clock cycle later than I'm expecting. I'll calculate the address on one clock cycle but not have the pixel data available until the next one.

Have I understood that situation correctly? And if so, what do I do about it? Ignore it because it won't be visible? I could probably buffer the sync pulses too and delay them in the same way. Or I could pre adjust the calculated memory address to compensate in advance.

What do people generally do in this kind of situation? Or is every case different?


2 Answers 2


Have I understood that situation correctly?

Yes - if some part of your output data is available later than other parts, you have to delay the other parts so they line up.

It's not a fudge, or a "bad" thing to do - it's just what has to be done to make the outputs right.

I could probably buffer the sync pulses too and delay them in the same way.

That's what I'd do. (EDIT: And as Yann reminded me, delaying signals can be very cheap in Xilinx FPGAs - 16 ticks can fit in a single look-up table + 1 more in the flipflop that's next to the LUT)

Or I could pre adjust the calculated memory address to compensate in advance.

That's another option, but will probably take more logic.

  • 1
    \$\begingroup\$ Note that even deeper pipelines don't need to cost much in the Spartan 3A family. Up to 16 bits deep fits in one LUT configured as a shift register. It may also be useful to consider whether the counter needs to match an addressing scheme (in a FIFO, for instance, you only need a sequence, not an up counter) and you could do the delay by changing the values you compare to generate the sync pulses. \$\endgroup\$ Commented Apr 12, 2011 at 10:47

Generic way to deal with things that take more than one clock cycle is pipelining, e.g. in your case you could create two stage pipeline, in first stage you generate the address and read signals for the memory, and in second stage you process the result and generate the sync pulses when appropriate.

However because in your simple case you only need to deal with the synchronicity of sync pulses, the simplest thing to do would be to delay them by one clock cycle by a flip-flop.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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