Forum Discussion
Altera_Forum
Honored Contributor
Honored ContributorVIP Control is Mutilating my Image!!!
Hello All,
I have an interesting problem. I've managed to put together a video processing path: cvi->scaler->frame buf->cvo Which works reasonably well scaling SXGA to SVGA for display on an LCD. Very simple. See 1st image below image. i then add a nios2/e with the standard JTAG UART and sysid peripherals. For ease I'm using 4k of on chip ram. I've connected the control port to all the above blocks. For the result look at the 2nd image below. This has only happened since upgrading my Quartus to 9.1. The sp1 upgrade did not fix the issue. It appears that instead of a line of 800 pixels arriving at the cvo, i'm getting 800 + n (where 5 > n > 10). This causes the square to be splayed diagonally. I've built this dozens of times with different size fifos on the cvo/cvi, and I think that my timing constraints are ok. See attached my sopc config. If I reduce the incoming SXGA signal by a few pixels (never consistent between builds) then the image lines up again and looks normal. But resetting the sopc will cause the distortion again. It's like the sopc is auto-detecting x pixels each time it comes out of reset, and then outputting x + n. Another note is that bit 10 of the cvi status register never sets - indicating that a valid resolution is never detected. My HS & VS signals are both logic +ve, and they only occur when the data_valid signal is 0 so they should be disturbing a frame. i've checked the data_valid window against the incoming pixel clock and it measures a perfect 1280px (or what ever I set the video to) and is stable with expected jitter and good amplitude. Has anyone see this issue before? did any of the vip ip blocks change so significantly between 9.0 and 9.1 as to cause this issue? All help greatly appreciated, thanks in advance. Cheers, Brent.36 Replies
Altera_ForumOne other thing: I can only ever read 0xffffffff from the scaler registers; including the status register!!
- Altera_Forum
BREAKING DEVELOPMENT:
if i pull the control port out of the scaler, and just let it do it's thing default, it corrects the skew problem. Question: what am I missing with the scaler? I'm executing these lines ONLY for the scaler to initialise: void scaler_enable(void){
iowr( scaler_base, control, vip_stop );
iowr( scaler_base, scaler_reg_size_x, l2_x_size );
iowr( scaler_base, scaler_reg_size_y, l2_y_size );
iowr( scaler_base, control, vip_go );
}
and for readback:
alt_printf( "\nscaler registers:\n" );
alt_printf( " control: %x\n", iord( scaler_base, control ) );
alt_printf( " status: %x\n", iord( scaler_base, status ) );
alt_printf( " size x: %x\n", iord( scaler_base, scaler_reg_size_x ) );
alt_printf( " size y: %x\n", iord( scaler_base, scaler_reg_size_y ) ); where: #define scaler_reg_control 0
# define scaler_reg_status 1
# define scaler_reg_size_x 2
# define scaler_reg_size_y 3
- Altera_Forum--- Quote Start --- One other thing: I can only ever read 0xffffffff from the scaler registers; including the status register!! --- Quote End --- Maybe you just posted the wrong image, but I do not see a control port for the scaler in your SOPC system.
- Altera_Forum
Adding the control port to the scaler does more than just enable you to control the scaling ratio and set the go bit.
It also enables runtime control of the scaler, meaning that it enables the logic within the scaler that decodes the VIP control packets on the streaming interface and automatically determine the input video height and width. Without this, the scaler just always assumes the input resolution is what you declared in the megawizard. Have you looked at the video control packets coming out of the CVI and made sure they are correct? If the CVI is not correctly detecting your video input resolution, this would likely explain all of your issues. P.S. Send me your design. We'll fix you up. Jake - Altera_Forum
Hi Jake,
How do I tap and read the control packets? I'll zip up and post my project to you asap. Thanks for your help... again! - Altera_Forum
Use signaltap on the avalon streaming output of the CVI (data, datavalid, startofpacket, endofpacket, ready). The avalon control packets begin with a data field of 0xf asserted with startofpacket and datavalid. Refer to page 4-7 of the user's guide:
http://www.altera.com/literature/ug/ug_vip.pdf Jake - Altera_Forum
Is there any way to enable Incremental Compilation with the 'web' edition of Quartus II? The re-compile times are going to make this difficult...
- Altera_Forum
Here is a screengrab from SignalTap. FYI, my path has 3 colour planes in parallel 4bits wide each. I tapped the input to the scaler, which below the CVI in the system. Looks like the control packets are ok:
- width = 0x04F9= 1273 pixels which is acceptable - (but should be 1280 strictly) - height = 0x0400 = 1024 lines which is perfect - interlacing field = 0x2, progressive which is correct. The packets are consistent, but only occur once, when the VIP is turned on, shouldn't these occur more frequently? Or does a control packet only occur when there is a change in settings? I'm going to re-introduce the control port on the scaler, then tap it's output, then successively each downstream. - Altera_Forum
The width of 1273 is not acceptable because it's wrong. Also, you should get a control packet at the beginning of every single frame of video. It really seems to me that the CVI is not able to detect your video input properly.
I'm working on trying to get your project setup to work on a board that I've got. In my case, I'm going to fake the video input with a generator feeding into the CVI. I have a board with a DVI input and a DVI output but I don't want to dust it off. Jake - Altera_Forum
Hi Jakob,
Attached are some fresh screen grabs of my video signals. These are signals coming out of the FPGA though some spare pins that i have for TAP purposes. You'll see the calculated measurements of the signal on the grabs. There is a bit of jitter, about +/- 100ps which I think it good for a recovered clock. Given that my mean pixel clock is 108.9MHz, DE +ve period is 11.75us I should clock in 1279.6 pixels. The 0.4 pixels is acceptable error. I guess you are correct, seeing 1273 pixels in the control packet could be a symptom of a problem... I've also attached another SignalTap grab, this time coming out of the scaler (with control port attached). The final image on the LCD is exhibiting similar image distortion to that described above. The control packet reads: - width 1273 px - height 1024 lines - progressive It's the same as the control packet that I saw entering the scaler!? Also, the dout_valid signal is dipping a lot, does this look normal? Could all this come from having exceeded the fmax of the system? (TimingQuest says no) - is the scaler just not turning on?
