Take the 2-minute tour ×
Electrical Engineering Stack Exchange is a question and answer site for electronics and electrical engineering professionals, students, and enthusiasts. It's 100% free, no registration required.

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?

share|improve this question
add comment

2 Answers

up vote 2 down vote accepted

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.

share|improve this answer
1  
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. –  Yann Vernier Apr 12 '11 at 10:47
add comment

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.

share|improve this answer
    
Thanks for the reply, it's all starting to make sense. Sorry that I can only accept one answer ( –  John Burton Apr 12 '11 at 20:50
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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