Jump to content
  • 0

Atlys HDMI Demo : Rotating VFBC. Need Help !


chcollin

Question

Hi FPGA gurus !

I'm trying to achieve video processing with Atlys board.

My goal is to real-time rotate some VGA Stream (640x480@60) form hdmi input to 720p hdmi output. Rotation is 90° clockwise.

The attached picture sketches what i'm aiming at.

I've been thinking of using HDMI Demo project for this.

I am a total noob to all this FPGA thing, i'm slowy trying to learn but it's not that simple when you don't know anything about electronics =)

From what I have understood, in the HDMI demo the frame in written to DDR2 memory with a single call to the VFBC. TMDS data is pushed in the FIFO and when a new frame is detected, then the Write Command is emitted and stores the whole frame to memory.

I thouht a good design for my project would be to store line by line, configuring the VFBC command with X=1, Y=639 and BaseAdress = [(40*lineStride)+(1160-lineCnt)] * 2.

This way :

  • line 1 (blue) is stored in the frame buffer as a 1 pixel wide column starting at pixel (1159,40)
  • line 2 (green) is stored in the frame buffer as a 1 pixel wide column starting at pixel (1158,40)
  • ...
  • line 640 (orange) is stored in the frame buffer as a 1 pixel wide column starting at pixel (680,40)

My understanding of the HDMI Demo is that modifying user_logic.vhd in hdmi_in is all i have to do, so that instead of writing the whole frame in one vfbc command, the frame should be written line by line with 640 VFBC commands, one for each line, with constant width = 1, constant height = 639 and baseAdress computed as shown above.

Is this correct ? Any Suggestion, hint, advice or help will be highly appreciated as I quite lost with this !!

Cheers

rotation.png

Link to comment
Share on other sites

4 answers to this question

Recommended Posts

OK, OK, i might need to redesign the entire thing because of the 128 byte alignment constraint.

As the width and start_address need to be multiple of 128 bytes, then the minimum value for width is 64, which means i need to rotate 64 lines at a time and then do 7 write commands to the VFBC to render the entire rotated frame.

The following picture shows how data should be wirtten to the frame buffer so that the 128 byte constraint is respected :

F[480][1] F[417][1] F[416][1] F[128][1] F[66][1] F[65][1] F[64][1] F[2][1] F[1][1]
F[480][2] F[417][2] F[416][2] F[128][2] F[66][2] F[65][2] F[64][2] F[2][2] F[1][2]
F[480][3] F[417][3] F[416][3] F[128][3] F[66][3] F[65][3] F[64][3] F[2][3] F[1][3]
       
       
       
F[480][639] F[417][639] F[416][639] F[128][639] F[66][639] F[65][639] F[64][639] F[2][639] F[1][639]
F[480][640] F[417][640] F[416][640] F[128][640] F[66][640] F[65][640] F[64][640] F[2][640] F[1][640]

So the data FIFO for the VFBC write command should look like this :

F[1][640] F[2][640] F[64][640] F[1][639] F[2][639] F[64][639] .. F[1][3] F[2][3] F[64][3] F[1][2] F[2][2] F[64][2] F[1][1] F[2][1]

F[64][1]

which means pixels must be reorderd before being pushed to the FIFO.

64 lines need to be stored before processing reordering.

Each line is 640*16 = 10Kb long, which means I need 64 * 18Kb BRAMs to store 64 lines.

BRAM 1 F[n*64+1][640] F[n*64+1][639] F[n*64+1][3] F[n*64+1][2] F[n*64+1][1]
BRAM 2 F[n*64+2][640] F[n*64+2][639] F[n*64+2][3] F[n*64+2][2] F[n*64+2][1]
BRAM 3 F[n*64+3][640] F[n*64+3][639] F[n*64+3][3] F[n*64+3][2] F[n*64+3][1]
           
BRAM 63 F[n*64+63][640] F[n*64+63][639] F[n*64+63][3] F[n*64+63][2] F[n*64+63][1]
BRAM 64 F[n*64+64][640] F[n*64+64][639] F[n*64+64][3] F[n*64+64][2] F[n*64+64][1]

pixel data is then poped cyclically from those BRAMs and pushed to the VFBC data FIFO :

Is this design more appropriate ? Looks like it is.

However, I do not have a single idea on how to implement it !!! :D

 

 

 

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...