Clocked Video Input II vid_datavalid width is 1 regardless of pixels in parallel parameter

[marqs_ic]

Hi,

I'm feeding oversampled video into CVI II IP and trying to make it only read every Nth pixel. There seems to be vid_datavalid signal for exactly this purpose, but its width does not get expanded when "pixels in parallel" is increased from 1, thus the feature becomes unusable when processing is parallelized which seems like a bug. I tried to work around this by adjusting vid_de accordingly, but that seems to break mode detection in certain cases.

[ZH_Intel]

Hi marqs_ic,

Currently we are confirming the details with our internal team.

We will get back to you as soon as possible.

Thank you.

Best Regards,

ZulsyafiqH_Intel

[ZH_Intel]

Hi marqs_ic,

Apologize for the delayed response.

May I confirm that the video format you are using is of embedded synchronization or separate synchronization?

Based on the Video and Image Processing Suite User Guide, vid_de is for separate synchronization mode only.

You may refer below link for more information:

Video and Image Processing Suite User Guide - 7.11.1. Clocked Video Input II Interface Signals 

Thank you for your patience.

Best Regards,

ZulsyafiqH_Intel

[marqs_ic]

Yes, I'm using separate synchronization mode.

For now I managed to work around the issue by using a FIFO to store valid samples and reading N samples at once (equivalent to pixels in parallel). When there are are less than N samples in FIFO, read is not done and VIP vid_datavalid bit is deasserted for that cycle. It would be still good if vid_datavalid width matched "pixels in parallel" which feels like how the IP is supposed to work.

[ZH_Intel]

Hi marqs_ic,

Good day.

Based on your reply, I believe that the vid_datavalid bit is deasserted due to not oversampling the input video.

According to the VIP Suite user guide, the CVI need to tie the signal high if you are not oversampling your input video.

CVI for Seperate Synchronization Format Video

Link: Video and Image Processing Suite User Guide - 3.1.3. Separate Synchronization Format 

Would you mind sharing with me how you do that?

Any documentation/guide you are referring at?

Thank you.

Best Regards,

ZulsyafiqH_Intel

[ZH_Intel]

Hi marqs_ic,

Good day.

I wish to follow up with you on this case. Do you still have further inquiries on this issue? I will remain this loop open for 2 days.

If we do not receive any response from you to the previous answer that I have provided.

This thread will be transitioned to community support.

If you have a new question, feel free to open a new thread to get support from Intel experts.

Otherwise, the community users will continue to help you on this thread.

Thank you.

Best Regards,

ZulsyafiqH_Intel

[marqs_ic]

Sorry for late reply. As an answer to your earlier question, the video fed into CVI II IP is oversampled as said in the first post, thus tieing vid_datavalid high is not a solution.

A simple example would be video oversampled by 3, i.e. every 3rd pixel needs to be marked as valid so that only those will be processed downstream. If the video pipeline runs e.g. 2 pixels in parallel, then I'd assume vid_datavalid width should be 2 as well so that each pixel fed into the pipeline via CVI II can be individually set as valid or invalid.

Now that vid_datavalid is a single bit regardless of pixels in parallel, it's only possible to set a group of 2 consecutive pixels as valid or invalid. My workaround thus is a FIFO where only valid pixels are stored and which reads 2 pixels per clock if there are enough stored in the FIFO.

It would be good if the feature was fixed or at least its current limitations would be documented.

[ZH_Intel]

Hi marqs_ic,

Good day.

Thank you for the explanation.

May I clarify how did you check the vid_datavalid?

Thank you.

Best Regards,

ZulsyafiqH_Intel

[marqs_ic]

I've checked the width of vid_datavalid from top-level verilog generated by Platform Designer, and its width is 1 while e.g. vid_de width matches VIP 'pixels in parallel' (2 in my case):

input  wire [1:0]   alt_vip_cl_cvi_0_clocked_video_vid_de,
input  wire         alt_vip_cl_cvi_0_clocked_video_vid_datavalid,

[ZH_Intel]

Hi marqs_ic,

Good day.

Currently we are confirming this via simulation with our internal team.

Allow us some time to look into your issue. I shall come back to you with findings.

At the same time, could you share your design with us?

Thank you.

Best Regards,

ZulsyafiqH_Intel

[marqs_ic]

The design is available on github here. As mentioned above, the issue is worked around by only storing valid samples in FIFO (dc_fifo_in_inst) and reading N samples (2 in this project) at once when available. CVI datavalid is asserted for the cycle following FIFO read request (i.e. when new data gets output).

[ZH_Intel]

Hi marqs_ic,

Good day.

Currently we are still confirming this via simulation with our internal team.

Allow us some time to look into your issue. I shall come back to you with findings.

The design shared, is this based on any of our design examples? or a reference design?

Thank you.

Best Regards,

ZulsyafiqH_Intel

[marqs_ic]

Hi,

I'm not sure why simulation would be needed to confirm the issue. Just instantiating CVI II IP in Platform Designer (configured with at least 2 pixel in parallel) and generating verilog shows that vid_datavalid input port width is always 1. The overall design is not based on any examples or reference design.

[ZH_Intel]

Hi marqs_ic,

Good day.

Just to update you, I am still liaising and waiting feedback from our internal team on this issue.

Will update you as soon as I have their feedback.

Thank you.

Best Regards,

ZulsyafiqH_Intel

[ZH_Intel]

Hi marqs_ic,

Good day.

Thank you for your patience.

After further discussion with our internal team, I am afraid the CVI II does not support this usage model and as this is a non common use of it.

The method that you are trying to use the core in, is in a way that it does not support and at the moment, there is no plan to do so.

Thank you.

Best Regards,

ZulsyafiqH_Intel

[marqs_ic]

I see. I'd then appreciate if VIP documentation was updated with a statement that oversampling is not supported in this kind of scenario as-is and needs workarounds (as in my example above).

[ZH_Intel · Accepted solution]

Hi marqs_ic,

Good day.

Thank you for your input.

Will convey it to our internal team on this.

Do you still have further inquiries on this issue?

If there is no further question, I will transition this thread to community support. 

Thank you.

Best Regards,

ZulsyafiqH_Intel

[marqs_ic]

I don't have further inquiries on this issue.

[ZH_Intel]

Hi marqs_ic,

I’m glad that your question has been addressed, I now transition this thread to community support. If you have a new question, feel free to open a new thread to get the support from Intel experts. Otherwise, the community users will continue to help you on this thread.

Thank you.

Best Regards,

ZulsyafiqH_Intel