Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Altera_Forum
Honored Contributor I
793 Views

overflow in clocked video input (HD-SDI as input)

Hi  

 

I'm doing frame buffering for HD-SDI video (720p). 

The connection of several important components in my design is: 

SDI rx-->CVI-->SGDMA-->DDR3 

 

My problem is that the copied data in DDR3 are not correct.  

I'm guessing the overflow in CVI may cause me this problem. 

(The first one or two lines are correct but the following lines are incorrect.  

Incorrect data are repeated two-byte data such as YCbYCb (0xa8 0x2c 0xa8 0x2c ...).  

I'm expecting something like YCbYCr (0xa8 0x2c 0xa8 0x87).  

(0xa8 0x2c 0xa8 0x87 indicate two pixels in the color bar) 

 

So I check this forum and find that CVI overflow may cause this problem. 

Then, I check the overflow bit in CVI status register and find the overflow bit is 1'b1.  

 

The FIFO setting in CVI is 1920 pixels for HD-SDI and I've tried to increase it.  

However, the problem still exists.  

 

What should I do to avoid the overflow in CVI in order to get correct copied data in DDR3? 

Does anyone have some ideas about it? 

Thanks a lot.
0 Kudos
4 Replies
Altera_Forum
Honored Contributor I
49 Views

I spend several days observing the signal waveform in my design by using SignalTapII. 

 

The SGDMA ready signal (which is one of avalon-st signal) becomes low after the first two lines. 

Then, the overflow in CVI happens. 

 

So I suspect whether SGDMA (st-to-mm) has written to DDR3 correctly and check the input and output signals of SGDMA. 

For the pixels in the first two lines, I can see their corresponding data in the writedata signals of avalon-mm interface to DDR3 controller.  

The pixels of the rest lines are not seen in the avalon-st interface due to the low ready signal and backpressure. 

So I think the write operation should work fine. 

 

Now I really don't know what makes SGDMA deassert the ready signal and causes CVI overflow. 

Could anyone please give me some ideas? 

Thanks.
Altera_Forum
Honored Contributor I
49 Views

The memory bandwith may not be enough? Why SGDMA, connect the CVI to framebuffer in QSYS would be fine.

Altera_Forum
Honored Contributor I
49 Views

Hi GuoYu 

 

Thank you for the reply. 

 

I'm also thinking about using the frame buffer IP, but I need to find out the address of the current frame data in DDR. 

For example: 

If I'm using double buffering, how to compute the starting address of the first buffer and the second one? 

Furthermore, which buffer is being written and which buffer is being read? 

(VIP user guide says "at any time, one buffer is used by the writer component to store input pixels, while the second buffer is locked by the reader component that reads the output pixels from the memory) 

 

I cannot figure out the answer for the above questions, so I decide to use SGDMA.
Altera_Forum
Honored Contributor I
49 Views

Eventually, I use frame buffer to solve this problem. 

 

For the starting address problem of each buffer, I set the base address of frame buffer as 0x00000000. 

So the first buffer starts at the first address of the memory (DDR3). 

The second and third buffer starting address can be computed easily according to the video resolution and bytes per pixel.
Reply