Problem with VIP suite on Cyclone V device

Hi Ted,

Thanks Ted for your reply. All the mode configuration registers of CVO read 1 and the underflow bit is also 1.

Also I have noticed the CVO input video packet, the control packet data alternates between 0F,00,02,0D,00,01,02,00,0F,00 and 0F,00,02,0D,00,01,02,00,0B,00.

According to the above data packets , width = 2D0h= 720 ,height =120F /120B = 4623/ 4619

I do not understand the height part of the packet . Is it correct?

Following are my CVO settings

image width: 720

image height: 576

Bits per pixel per color plane: 8

Number of color planes: 2

Color plane format: sequence

Allow output channels in sequence : checked

Interlaced video: checked

Syncs signals: Embedded in video

Active picture line: 23

Field 1

Ancillary packet insertion line :8

Embedded syncs-Field1

Horizontal blanking :144

Vertical blanking :2

Interlaced and field 0 parameters

F rising edge line :313

F falling edge line :1

Vertical blanking rising edge line :311

Ancillary packet insertion line :321

Embedded syncs Field 0

Vertical blanking :24 lines

pixel fifo size: 55296 (4 times [(1440+288)*8])i.e 4 lines of data

Fifo level : 55295

I have tried various combinations but the output does not appear proper and the underflow bit is always high.

Video in and out use same clock: checked

Use control port : checked

Runtime configurable video modes : 1 modes

Width of vid_bus :1 bits

Regards,

Vidya

--- Quote Start ---

Also I have noticed the CVO input video packet, the control packet data alternates between 0F,00,02,0D,00,01,02,00,0F,00 and 0F,00,02,0D,00,01,02,00,0B,00.

According to the above data packets , width = 2D0h= 720 ,height =120F /120B = 4623/ 4619

I do not understand the height part of the packet . Is it correct?

--- Quote End ---

No, it is not correct. Did you transcribe the packet data incorrectly?

0F,00,02,0D,00,00,01,02,00,0F
0F,00,02,0D,00,00,01,02,00,0B

The above packet would have made more sense (trailing 0F and 0B are the interlacing fields for F0/F1 frames).

And height 0120h=288 = (576/2)

Hi Ted,

You are right. I transcribed the packet data wrongly by missing 00 which is valid for two clock cycles. But then I can not figure why the CVO is underflowing.

I'm attaching the output with CVO fifo depth 720, start size 719 namely TPG_CVO_output1.bmp and

the output with CVO fifo depth 13824 , start size 13823 namely TPG_CVO_output2.bmp

Can you help me in figuring out where the problem could be?

Thanks & Regards,

Vidya

Hi Ted,

I tried with Frame buffer in front of CVO. I get the output as in TPG_VFB_CVO.bmp with rolling video.

The test pattern that I see is not the same as given in the VIP user guide Test pattern generator output.

Also I have attached signal tap signals capture vip_osd.jpg. You can see that the CVO underflows during 17th line. Can this mean something ? I'm clueless here.

Thanks & Regards,

Vidya

It means your CVO is sinking data faster than your frame buffer is sourcing it. I am guessing your frame buffer Avalon-MM ports are either running too slow or configuration mismatches resulting in inefficient operation of the memory interface?

You'll want to make sure the frame buffer has frame repeating enabled, and then you may want to end up with the Avalon-MM Master ports running on a separate (faster) clock domain than the Avalon-ST ports. Basically, you need to make sure the frame buffer is configured correctly and it has adequate resources to fetch data faster than the CVO can process it. You can do this with either faster clocks or with wider Avalon-MM width. In normal use, the frame buffer should be more than capable of keeping the CVO FIFO nearly full for the entire frame.

From your original post, it sounds like you want CVO clock 27MHz with 16bpp. If your DDR3 is 216MHz, your Avalon-MM is probably half that but double wide (108MHz, 32-bit ? 64-bit?) This is plenty of capacity as long as the frame buffer is using the separate clock domain for the Avalon-MM ports and is using bursts to stream the data. If you've already checked all these things, you can increase the depth of the frame buffer FIFO's and burst lengths and confirm they have an impact on your 17th row underflow.

Hi Ted,

Thanks a lot for your suggestions. I tried with frame repetition on and increased the Frame buffer Avalon MM write and read fifo sizes. Now I get a proper test pattern at the output with no underflow of CVO but still it seems to be somewhat distorted. I have attached the output image. Could it be the problem with any other CVO or Frame buffer setting?

Regards,

Vidya

I'm not sure what that distortion is. However, if you've got no underflow, you are done configuring the Frame Buffer and your issue is elsewhere.

Can you summarize your processing chains?

TPG->CVO = works, no artifact ?

TPG->VFB->CVO = artifact shown in TPG_VFB_CVO3.bmp ?

Hi Ted,

My processing chain is summarized as below:

TPG->ITL->CPR->CVO , No proper test pattern output plus CVO underflow bit is high.

TPG->ITL->CPR->VFB->CVO, Proper test pattern with distortion(artifact) , underflow bit is low.

Regards,

Vidya