10-22-2017 09:00 PM
I am working on setting up a video pipeline that does chroma resampling , de interlacing and RGB conversion.
As a first step, i have skipped de-interlacing and does only chroma resampling and RGB conversion (CCM using a custom RGB conversion equation) on fields (half resolution frames) which worked very well. I have used chroma resampler from VIPP not VPSS.
Now as a second step, am trying to introduce deinterlacer (also from VIPP) to get the full fledged video frame. I have introduced the deinterlacer before CCM as the max bit depth of color components is 12 bit for both resampler and deinterlacer.
I have two issues here
1) What should be the aclk frequency of my de-interlacer and CCM (RGB conversion)?
I use a base pixel rate of 27MHz for the interlaced fields. Which of the following is a valid combination of aclk?
a) 27MHz to Resampler, 54MHz to Deinterlacer and CCM
b) 27MHz to Resampler and DeInterlacer, 54MHz to CCM
c) 27MHz to all three IPs
d) 54MHz to all three IPs - Not a feasible case as my resampler input is at 27MHz.
2) Whatever be the combination of clocks i use, i get an error in block design which says, FREQ_HZ does not match between ports Video_Out of Resampler (148500000) and Video_in of Denterlacer (54000000).
The Video_In and Video_out ports of DeInterlacer and CCM show 54000000 in the port properties while that of Resampler show 148500000. The Video In port of Resampler is made external. However when i try changing the CLK_HZ parameter of the port, i get another similar error for the mismatch between port and video_in CLK_HZ parameter.
How does the CLK_HZ property of an IP get auto set to a particular value?
I have attached a snapshot of the block design of this pipe line for reference. Please suggest on this as well as on the MIG if you see anything improper.
If you are suggesting use of VPSS, please suggest on the clock set up of the same for achieving the above pipeline. VPSS does chroma resampling in two stages 420 to 422 , 422 to 444. Chroma Resampler does this for me in single pass (Ignoring Internals).
10-22-2017 09:39 PM
The second problem I mentioned in the above post, got resolved when i followed the steps below
1) I have deleted the clk_27MHz port which was there earlier.
2) Created it again using Create Port option and set the Freq Parameter to 27MHz
3) Validated the Block Design
The error is gone and what i see now that the resampler, deinterlacer and CCM all three are in 27MHz clock domain.
However, I still want to understand the clock combination.
How do the deInterlacer and CCM work/handle the doubled vertical resolution with the same clock?
If i give 54MHz to DeInterlacer, The signals on DeInterlacer Video_In will be of two clocks wide as Resampler Video_out is at 27MHz.
If i give 54MHz to CCM, i may again get the FREQ_HZ mismatch between DeInterlacer and CCM AXI-S video ports.
10-25-2017 02:06 AM
You can use the same clock aclk for all the three IP. In this case it should be at least the output video frequency. But the frequency can also be lower for the other IPs (double for the deinterlacer).
Only the s_axi_aclk clock should be the same or you would need to use a VDMA (or a FIFO).
If all the frequencies are the same, then the change between the 2 "video resolutions" will be handled by the AXIS interface.
Hope that helps,
10-28-2017 05:22 AM
10-28-2017 09:28 AM
The AXI4-Stream video interface is asynchronous to the video, so it does not have to run at the video clock rates. As long as you set the AXIS clock at least as high as the highest clock rate in the system, it will work.
The AXI4-Stream video bus does not transfer any horizontal or vertical blanking information, only active video data. Sync timing information is also not transferred. Start of frame (SOF) is tagged by a high on the TUSER bit on the first pixel transferred in each video frame, and the end of each line (EOL) is tagged with a single pulse high on the TLAST bit. These two bits are all you need to keep track of where you are in the video field.
Because horizontal and vertical blanking information is not transferred, data can be transferred faster than the incoming video frame rate. Each AXI4-Stream IP master sends video only when the next downstream IP requests it, and each AXI4-Stream IP slave requests data from the upstream master only as fast as it can receive it. FIFOs are typically used inside the IP to buffer transfers and eliminate "back-pressure" to keep the throughput high.
Video timing information is reintroduced only in the output AXI4-Stream to Video Out IP block. A Video Timing Controller IP block set up as a timing generator will generate all the necessary horizontal and vertical syncs and blanking for the output, and this timing information will control the output AXI4-Stream to Video Out IP block to request data as needed to fit the output timing requirements.
In your case, if you have 27MHz video coming in and 54MHz data going out, you can make the intermediate AXI4-Stream AXIS clock 54MHz or higher. I typically run the AXIS clock at 100MHz when using the MIG in an Artix-7 for SDI video. The input 27MHz clock will only be used as the input clock in the Video In to AXI4-Stream IP block, and the 54 MHz output clock will only be used in the AXI4-Stream to Video Out IP block clock (if you have the blocks set for independent clocks). You could alternately set up the AXI4-Stream to Video Out IP to run a common clock of 54MHz and run your AXIS clock on the same 54MHz clock if you don't need to run a higher intermediate AXIS clock.
One more point: if you need to increase the throughput of your AXI4-Video stream and can't run a higher AXIS clock, you can run at two pixels per clock, effectively doubling your throughput for the same clock rate. You can also run four or eight pixels per clock to increase throughput even more. This comes in handy when you are using the MIG as a frame buffer for video frame synchronization, and you need to read and write multiple video streams all in real-time, or when you want to run a wider bus to allow for lower clock rates in the AXI4-Stream path.