Forum Discussion
ContributorVVP Protocol Converter Not work
ContributorHi Wincent_Altera ,
Conversion between 4->2 and 4->2 should be work, I am not seeing any complaints from Platform Designer.
And Quartus generates the design successfully.
I switch the mode from Lite to Full, the situation remained the same.
Neither is running.
Do you know where is a UG mentioned about how to program the Lite mode?
As I found from the LUT reference, I suppose only video data is needed.
How about the register address "75" for vvpBpsCode ?
Thank you.
Regular ContributorHi JLee25 ,
Is this from our example design, sorry to said I never try out such customization before.
But I can advise based on my own experience for your reference, feel free to point out if my understanding is wrong.
Yes, the UG does mention how Lite mode must be programmed, and based on that I do not think video data alone is sufficient here.
For the Pixels in Parallel Converter, 4→2 and 2→4 are supported. The UG says it supports any conversion from 1 to 8 pixels in parallel.
However, it also says the IP must know how many pixels are in each video line.
In Full mode, it gets that from the image information packet in the stream.
In Lite mode, the stream has no image information, so you must provide the line information through the register map / control agent interface.
For the Protocol Converter in Lite to Avalon mode, the UG says you must program the incoming width through the register map so the IP can determine valid pixels on the last beat of each line, and it also uses width, height, and interlace from the register map to generate the Avalon-ST control packet. The documented Lite-mode registers are IMG_INFO_WIDTH (0x0120), IMG_INFO_HEIGHT (0x0124), IMG_INFO_INTERLACE (0x0128), IMG_INFO_COLORSPACE (0x0130), IMG_INFO_SUBSAMPLING (0x0134), IMG_INFO_COSITING (0x0138), and CTRL (0x0154) to start the IP.
So for Lite mode, the UG indicates this is not just “send video data and it should run”; the frame/image information must also be programmed correctly. Regarding register address 75 / vvpBpsCode, I do not see that name in the documented Protocol Converter register map in the UG section for this IP. Based on the published register table, I would avoid depending on it unless there is another official source that documents it.
For the Chroma Resampler, if Lite mode is enabled, the UG says the memory-mapped control interface is required.
In Lite mode, you need to set at least IMG_INFO_WIDTH (0x0120), IMG_INFO_HEIGHT (0x0124), and IMG_INFO_SUBSAMPLING (0x0134). For your 4:2:2 → 4:4:4 CRS case, I would also check that the instance was built with 4:4:4 output support enabled, and that the runtime OUTPUT_MODE is set to 3 = 4:4:4 if you are controlling it via registers.
At this point, based on the UG, my main suspicion is not that 4→2 / 2→4 is unsupported, but that the downstream VVP IPs are not receiving the frame/image metadata they need to begin processing in Lite mode, or valid image information packets in Full mode.
Regards,
Wincent_Altera
