HDL Implementation of Video Generator Test for 16-bit PVB's

[ElEctric_EyE]

Arlet wrote:

I did notice that the documentation also mentions a RAMB8, which is double ported, but only half the size. This could be very useful for small FIFOs.

Another option would be to store only the end points of the lines, and generate the lines dynamically. This is not a beginner's project, though

My LineGen module will eventually do this, but maybe you have a different idea with the FIFO? It will have to figure out how to generate the X, Y values from 2 endpoints. But right now I just use 3 tests using the X pixel counter. Once I am successful with the vertical (0,X), horizontal (X,0) and diagonal (X,X), I will work on the algorithms for all other possibilities. But as you mentioned earlier, I need to first figure out how to sort the values, or a better way to put them in the RAM. In the end though, this whole effort won't be worth it if it takes too many cycles. You might as well have a processor plot the pixels through software.

What I have just now done successfully, is gone back to the RAMB16_S18_S18 and utilized both ports, one for X, one for Y and it works, so 31 BRAMs left.

[Arlet]

I mean generate the intermediate points while drawing the display, so you're only using the RAM for the end points. One RAM will hold a few hundred lines. One other RAM will hold a bitmap for one scanline. At every line on the display, you 1) erase the bitmap, 2) quickly determine value for X0-X1 that intersect current Y for each of the lines. 3) Draw pixels X0-X1 in bitmap. 4) Send bitmap to FIFO.

[ElEctric_EyE]

Arlet wrote:

... 2) quickly determine value for X0-X1 that intersect current Y for each of the lines...

This is going to be most difficult! But I would imagine you would use a large shifter (horizontal/2), start with a certain value determined by the subtraction of certain values in the endpoints for most lines primarily horizontal. Then use another set of rules for lines primarily vertical...

[Arlet]

I'd calculate X = Y * A / B, where B is a power of two, and A is pre-calculated and stored in the BRAM. Generating the pixel coordinates on the fly needs to be fast, since you only have the time of one hsync period to determine all intersections. The multiply only takes 1 cycle.

[ElEctric_EyE]

I think I'm going to start another thread about utilizing FPGA BRAM for the highest speed graphic functions. I have a few questions but I will save them for that thread.
This thread's stated purposes have been completed back here on page 9.