Video and Image Processing Suite User Guide
Version Information
Updated for: |
---|
Intel® Quartus® Prime Design Suite 19.4 |
1. Video and Image Processing IP Cores
Intel® 's Video and Image Processing (VIP) Suite IP cores are available in the DSP library of the Intel® Quartus® Prime software and may be configured to the required number of bits per symbols, symbols per pixel, symbols in sequence or parallel and pixels in parallel.
The VIP Suite offers the following IP cores:
- 2D FIR II Intel® FPGA IP
- Avalon-ST Video Monitor Intel® FPGA IP (Available only in Platform Designer (Standard) edition)
- Avalon-ST Video Stream Cleaner Intel® FPGA IP
- Chroma Resampler II Intel® FPGA IP
- Clipper II Intel® FPGA IP
- Clocked Video Input II Intel® FPGA IP
- Clocked Video Input Intel® FPGA IP (Available only in Platform Designer (Standard) edition)
- Clocked Video Output II Intel® FPGA IP
- Clocked Video Output Intel® FPGA IP (Available only in Platform Designer (Standard) edition)
- Color Plane Sequencer II Intel® FPGA IP
- Color Space Converter II Intel® FPGA IP
- Configurable Guard Bands Intel® FPGA IP
- Control Synchronizer Intel® FPGA IP (Available only in Platform Designer (Standard) edition)
- Deinterlacer II Intel® FPGA IP
- Frame Buffer II Intel® FPGA IP
- Gamma Corrector II Intel® FPGA IP
- Interlacer II Intel® FPGA IP
- Mixer II Intel® FPGA IP
- Scaler II Intel® FPGA IP
- Switch II Intel® FPGA IP
- Test Pattern Generator II Intel® FPGA IP
- Trace System Intel® FPGA IP (Available only in Platform Designer (Standard) edition)
- Warp Lite IP
These IP cores transmit and receive video according to the Avalon Streaming (Avalon-ST) video standard. Most IP cores receive and transmit video data according to the same Avalon-ST Video configuration, but some explicitly convert from one Avalon-ST Video configuration to another. For example, you can use the Color Plane Sequencer II IP core to convert from 1 pixel in parallel to 4.
All VIP IP cores require even frame widths when using 4:2:2 data; odd frame widths create unpredictable results or distorted images. The Clipper II IP core requires even clip start offsets and the Mixer II IP core requires even offsets when using 4:2:2 data.
The signal names are standard Avalon-ST signals, and so by default, not enumerated. Some IP cores may have additional signals.
All IP cores in the VIP Suite support pixels in parallel, with the exception of Clocked Video Input (CVI), Clocked Video Output (CVO), Control Synchronizer, and Avalon-ST Video Monitor IP cores. Most of the IP cores support 8 pixels in parallel and 8K resolutions.
VIP IP Cores | Minimum Input/Output Resolution in Pixels (Width × Height) | Maximum Input/Output Resolution in Pixels (Width × Height) |
---|---|---|
Clocked Video Input II | 32 × 32 | 8192 × 8192 |
Clocked Video Output II | 32 × 32 | 8192 × 8192 |
Clocked Video Input | 32 × 32 | 2600 × 2600 |
Clocked Video Output | 32 × 32 | 2600 × 2600 |
Control Synchronizer | 32 × 32 | 1920 × 1080 |
Deinterlacer II | 32 × 32 | 4096 × 2160 1 |
Warp Lite IP | 128 × 128 | 1920 × 1080 |
Other IP cores | 32 × 32 | 8192 × 8192 |
1.1. Release Information
Item | Description |
---|---|
Version | 19.1 |
Release Date | April 2019 |
Ordering Code | IPS-VIDEO (Video and Image Processing Suite) |
Intel verifies that the current version of the Intel® Quartus® Prime software compiles the previous version of each IP core, if this IP core was included in the previous release. Intel reports any exceptions to this verification in the Intel FPGA IP Release Notes. Intel does not verify compilation with IP core versions older than the previous release.
1.2. Device Family Support
Device Family |
Support |
---|---|
Intel® Stratix® 10 | Final |
Intel® Arria® 10 | Final |
Intel® Cyclone® 10 LP | Final |
Intel® Cyclone® 10 GX | Final |
Intel® MAX® 10 | Final |
Arria® II GX/GZ | Final |
Arria® V GX/GT/SX/ST | Final |
Arria® V GZ | Final |
Cyclone® IV E/GX | Final |
Cyclone® V | Final |
Stratix® IV | Final |
Stratix® V | Final |
Other device families | No support |
The following terms define device support levels for Intel FPGA IP cores:
- Advance support—the IP core is available for simulation and compilation for this device family. Timing models include initial engineering estimates of delays based on early post-layout information. The timing models are subject to change as silicon testing improves the correlation between the actual silicon and the timing models. You can use this IP core for system architecture and resource utilization studies, simulation, pinout, system latency assessments, basic timing assessments (pipeline budgeting), and I/O transfer strategy (data-path width, burst depth, I/O standards tradeoffs).
- Preliminary support—the IP core is verified with preliminary timing models for this device family. The IP core meets all functional requirements, but might still be undergoing timing analysis for the device family. It can be used in production designs with caution.
- Final support—the IP core is verified with final timing models for this device family. The IP core meets all functional and timing requirements for the device family and can be used in production designs.
1.3. Latency
The latency is described using one or more of the following measures:
- the number of progressive frames
- the number of interlaced fields
- the number of lines when less than a field of latency
- a number of cycles
The latency is measured with the assumption that the IP core is not being stalled by other functions on the data path; (the output ready signal is high).
IP Core | Mode | Latency |
---|---|---|
2D FIR Filter Latency | Filter size: N × N | (N–1) lines + (n cycles) |
Mixer II | All modes | n cycles |
Avalon-ST Video Stream Cleaner | All modes | n cycles |
Chroma Resampler II | Input format: 4:2:2; Output format: 4:4:4 | n cycles |
Input format: 4:2:0; Output format: 4:4:4 or 4:2:2 | 1 line + n cycles | |
Clipper II | All modes | n cycles |
Clocked Video Input/Clocked Video Input II | All modes | n cycles |
Clocked Video Output/ Clocked Video Output II |
All modes | n cycles |
Color Plane Sequencer II | All modes | n cycles |
Color Space Converter II | All modes | n cycles |
Control Synchronizer | All modes | n cycles |
Deinterlacer II |
|
n cycles |
|
1 field + n cycles | |
|
2 lines + n cycles | |
|
1 field + 2 lines, or 2 lines 40% to 60% (depending on phasing) of the time, the core performs a weave forward so there is no initial field of latency. |
|
Frame Buffer II | All modes | 1 frame + n cycles |
Gamma Corrector II | All modes | n cycles |
Interlacer II | All modes | n cycles |
Scaler II |
|
(N –1) lines + n cycles |
Switch II | All modes | n cycles |
Test Pattern Generator II | Not applicable. | |
Warp Lite IP | All modes | Up to 100 lines. The amount varies across the frame depending on the level of distortion specified. |
1.4. In-System Performance and Resource Guidance
IP Core | Configuration | ALMs | M20K | DSP Blocks |
---|---|---|---|---|
Mixer II |
|
1,890 | 0 | 12 |
Clocked Video Input II |
|
855 | 14 | 0 |
Clocked Video Output II |
|
2,251 | 12 | 0 |
Color Space Converter II |
|
865 | 1 | 12 |
Frame Buffer II |
|
2,232 | 33 | 2 |
Clipper II |
|
963 | 0 | 0 |
Warp Lite |
|
6,530 | 395 | 21 |
1.5. Stall Behavior and Error Recovery
During control packet processing, the IP cores might stall frequently and read or write less than once per clock cycle. During data processing, the IP cores generally process one input or output per clock cycle. There are, however, some stalling cycles. Typically, these are for internal calculations between rows of image data and between frames/fields.
When stalled, an IP core indicates that it is not ready to receive or produce data. The time spent in the stalled state varies between IP cores and their parameterizations. In general, it is a few cycles between rows and a few more between frames.
If data is not available at the input when required, all of the IP cores stall and do not output data. With the exceptions of the Deinterlacer and Frame Buffer in double or triple-buffering mode, none of the IP cores overlap the processing of consecutive frames. The first sample of frame F + 1 is not input until after the IP cores produce the last sample of frame F.
IP Core | Stall Behavior | Error Recovery |
---|---|---|
2D FIR Filter II |
|
An error condition occurs if an endofpacket signal is received too
early or too late for the run-time frame size. In either case,
the 2D FIR Filter always creates output video packets of the
configured size.
|
Mixer II | All modes stall for a few cycles
after each output frame and between output lines. Between frames, the IP core processes non-image data packets from its input layers in sequential order. The core may exert backpressure during the process until the image data header has been received for all its input. During the mixing of a frame, the IP core:
Because of pipelining, the foreground pixel of layer N is read approximately N active cycles after the corresponding background pixel has been read.
|
The Mixer II IP core processes
video packets from the background layer until the end of packet is
received.
|
Avalon-ST Video Stream Cleaner |
All modes stall for a few cycles between frames and between lines. |
|
Chroma Resampler II |
All modes stall for a few cycles between frames and between lines. Latency from input to output varies depending on the operation mode of the IP core.
When not stalled, always processes one sample from the more fully sampled side on each clock cycle. For example, the subsampled side pauses for one third of the clock cycles in the 4:2:2 case or half of the clock cycles in the 4:2:0 case. |
|
Clipper II |
|
|
Clocked Video Input/ Clocked Video Input II 2 |
|
If an overflow is caused by a downstream core failing to receive data at the rate of the incoming video, the Clocked Video Input sends an endofpacket signal and restart sending video data at the start of the next frame or field. |
Clocked Video Output/ Clocked Video Output II |
|
|
Color Plane Sequencer II |
|
|
Color Space Converter II |
|
|
Control Synchronizer |
|
|
Deinterlacer II | Stores input video fields in the
external memory and concurrently uses these input video fields to
construct deinterlaced frames.
|
|
Frame Buffer II |
|
|
Gamma Corrector II |
|
|
Interlacer II |
|
|
Scaler II |
The internal latency of the IP core depends on the scaling algorithm and whether any run time control is enabled. The scaling algorithm impacts stalling as follows:
Enabling run-time control of resolutions affects stalling between frames:
|
|
Switch II |
|
— |
Test Pattern Generator II |
|
— |
Warp Lite |
All modes produce a few cycles of stall if the line store fills. The line store size ensures it shouldn’t fill unless a mismatch occurs between input and output rates. |
The Warp Lite IP has a built in stream cleaner to handle error conditions. Receiving an endofpacket signal too early causes the stream cleaner to pad the packet up to the frame size specified by the preceding control packet. Receiving an endofpacket signal too late causes the stream cleaner to clip the packet to the frame size specified by the preceding control packet. Receiving a video packet without a preceding control packet causes the stream cleaner to discard the video packet. |
2. Avalon Streaming Video
The individual video formats supported (i.e. NTSC, 1080p, UHD 4K) depend primarily on the configuration of the Avalon streaming video standard and the clock frequency. The IPs may transmit pixel information either in sequence or in parallel, in RGB or YCbCr color spaces, and under a variety of different chroma samplings and bit depths, depending on which is the most suitable for the end application. The Avalon streaming video protocol adheres to the Avalon streaming standard packet data transfers, with backpressure and a ready latency of 1.
A “ready latency” of 1 is used for Avalon streaming video. The example shows the receiving video sink drops its ready signal in cycle 3, to indicate that it is not ready to receive any data in cycles 4 or 5. The video source responds by extending its valid, endofpacket and data signals into cycle 6. As the ready signal returns high in cycle 5, the video source data in cycle 6 is safely registered by the sink.
The symbols D0, D1… can be pixel color plane data from an Avalon streaming video image packet or data from a control packet or a user packet. The type of packet is determined by the lowest 4 bits of the first symbol transmitted.
Type Identifier D0[3:0] |
Description |
---|---|
0x0 (0) | Video data packet |
0x1–0x8 (1–8) | User data packet |
0x9–0xC (9–12) | Reserved |
0xD (13) | Clocked Video data ancillary user packet |
0xE (14) | Reserved |
0xF (15) | Control packet |
2.1. Avalon-ST Video Configuration Types
Most color spaces require more than one symbol to represent each pixel. For example, three symbols are needed for each of the red, green and blue planes of the RGB color space.
Avalon-ST Video allows for multiple pixels to be transmitted in parallel. When the number of pixels transmitted in parallel is greater than one, the optional Avalon-ST empty signal is added to the data transfer interface between the IP cores.
2.2. Avalon-ST Video Packet Types
2.2.1. Avalon-ST Video Control Packets
An Avalon-ST Video control packet comprises the identifier nibble, and 9 other nibbles which indicate the height, width and interlacing information of any subsequent Avalon-ST Video packets.
Nibble | Description |
---|---|
D0 | Width[15:12] |
D1 | Width[11:8] |
D2 | Width[7:4] |
D3 | Width[3:0] |
D4 | Height[15:12] |
D5 | Height[11:8] |
D6 | Height[7:4] |
D7 | Height[3:0] |
D8 | Interlacing[3:0] |
When the Interlacing nibble indicates an interlaced field, the height nibble gives the height of the individual fields and not that of the equivalent whole frame—for example, a control packet for 1080i video would show a height of 540, not 1080.
Interlaced/Progressive | Interlacing[3] | Interlacing[2] | Interlacing[1] | Interlacing[0] | Description |
---|---|---|---|---|---|
Interlaced | 1 | 1 | 0 | 0 | Interlaced F1 field, paired with the following F0 field |
0 | 1 | Interlaced F1 field, paired with the preceding F0 field | |||
1 | x | Interlaced F1 field, pairing don’t care | |||
0 | 0 | 0 | Interlaced F0 field, paired with the preceding F1 field | ||
0 | 1 | Interlaced F0 field, paired with the following F1 field | |||
1 | x | Interlaced F0 field, pairing don’t care | |||
Progressive | 0 | x | 0 | 1 | Progressive frame, deinterlaced from an f1 field |
0 | 0 | Progressive frame, deinterlaced from an f0 field | |||
1 | x | Progressive frame |
2.2.2. Avalon-ST Video Video Packets
The Avalon-ST Video protocol further defines that any other symbol data transmitted in the first cycle (or beat) of the transmission is ignored. Uncompressed and rasterized, the pixel data is transmitted in the symbols that follow in subsequent cycles, starting with the top-left pixel.
Avalon-ST Video packets support RGB and YCbCr color spaces, with 4:4:4 or 4:2:2 chroma sub-sampling, with or without an optional alpha (transparency) channel. The 4:2:0 color space is only handled by the Clocked Video interfaces and the chroma resampler. For the other VIP IP cores, the 4:2:0 color space should be converted to or from 4:2:2 for processing.
Color channel data for RGB video packets is transmitted in the order of Blue, Green, Red. You can observe this order directly on the bus for symbols in sequence Avalon-ST configurations. For symbols (and pixels) in parallel configurations, the blue symbol occupies the least significant symbol position (D0) as shown the figure below, with the (x,y) raster position shown in brackets.
For 4:4:4 YCbCr data, chroma sample Cb is in the least significant position (or first symbol to be transmitted in a symbols in sequence configuration), Cr is the mid symbol, with the luminance (Y) occupying the most significant symbol position. The figure below shows an example with symbols in parallel.
For 4:2:2 YCbCr video, with sub-sampled chroma, the Cr and Cb symbols alternate, such that each Luma symbol is associated with either a Cr or Cb symbol as shown in the figure below.
For video with an alpha layer, the alpha channel occupies the first (least significant) symbol with the remaining color channels following as per the usual ordering with Blue or Cb occupying the next symbol after the alpha as shown in the figure below.
2.2.3. Avalon-ST Video User Packets
The Avalon-ST Video protocol only requires for the payload data to begin on the second cycle of transmission (the first cycle must contain the user packet identification nibble). The content or length of these packets are ignored.
2.3. Avalon-ST Video Operation
Intel recommends that every video frame (or field, in the case of interlaced video) is preceded by a control packet. User packets may be presented in any order and may be re-ordered by some configurations of the VIP IP cores (e.g. the Deinterlacer II IP core when configured with 1 field of buffering). However, Intel recommends that the user packets precede the control packet.
The VIP IP cores always transmit a control packet before any video packet, and the user packets either follow or precede this control packet, depending upon the function of the IP core. When a VIP IP core receives an Avalon-ST Video control packet, the IP core decodes the height, width, and interlacing information from that packet and interprets any following Avalon-ST Video packets as being video of that format until it receives another control packet.
Most IP cores handle user packets, simply passing them through, or in the case of the Frame Buffer II IP core, writing and then reading them to memory. For IP cores that change the number of bits per symbol or symbols per pixel, additional padding is introduced to the user data.
All IP cores transmit a control packet before sending a video packet, even if no control packet has been received.
Stalling behavior (behavior when either a core is ready but there is no valid input data, or when a core has valid output data but the receiving core is not ready to receive it) varies according to the different cores. However, stalls propagate up and down the pipeline except where they can be absorbed through buffering within the cores themselves.
2.4. Avalon-ST Video Error Cases
If a video packet has a different length to the one implied by the preceding control packet’s height, width and interlacing fields, it is termed as an early end of packet or late end of packet. All the VIP IP cores are able to accept this type of erroneous video, but the resultant output video may exhibit cropped or stretched characteristics. For example, the Deinterlacer II IP core has an integral stream cleaner which allows it to accept such packets when configured in complex motion adaptive modes.
If an Avalon-ST Video packet violates the Avalon-ST protocol in some way, for example by not raising startofpacket or endofpacket, this is a more serious error case and often results in a video pipeline locking up due to a freeze of the Avalon-ST bus.
3. Clocked Video
The Clocked Video Input II (CVI II) IP core converts clocked video into the Avalon-ST Video control and data packets and the Clocked Video Output II (CVO II) IP core converts Avalon-ST video packets into clocked video. These two IP cores interface between Avalon-ST Video cores and video interface standards such as BT.656 and others as used in Displayport, Serial Digital Interface (SDI), and High-Definition Multimedia Interface (HDMI).
3.1. Video Formats
The IP cores create and accept the following formats:
- Video with synchronization information embedded in the data (in BT656 or BT1120 format)
- Video with separate synchronization (H sync, V sync) signals
The BT656 and BT1120 formats use time reference signal (TRS) codes in the video data to mark the places where synchronization information is inserted in the data.
3.1.1. Embedded Synchronization Format: Clocked Video Output
The IP cores create a sample for each clock cycle on the vid_data bus.
There are two extra signals only used when connecting to the SDI IP core. They are vid_trs, which is high during the 3FF sample of the TRS, and vid_ln, which produces the current SDI line number. These are used by the SDI IP core to insert line numbers and cyclical redundancy checks (CRC) into the SDI stream as specified in the 1.5 Gbps HD-SDI and 3 Gbps 3G-SDI standards.
The CVO IP cores insert any ancillary packets (packets with a type of 13 or 0xD) into the output video during the vertical blanking. The IP cores begin inserting the packets on the lines specified in its parameters or mode registers (ModeN Ancillary Line and ModeN F0 Ancillary Line). The CVO IP cores stop inserting the packets at the end of the vertical blanking.
3.1.1.1. Clocked Video Output and SDI II TX Interface
The rate that the SDI II TX core uses to pull the data depends on the SDI standard. The table below describes the officially supported cadences.
SDI Standard | tx_dataout_valid Cadence from SDI II TX Core |
---|---|
SD-SDI (10 bit) | 1H 4L 1H 5L |
SD-SDI (20 bit) | 1H 10L |
HD-SDI | 1H 1L |
3G-SDI | Always H |
6G-SDI | Always H |
12G-SDI | Always H |
3.1.2. Embedded Synchronization Format: Clocked Video Input
When in 10-bit mode, the IP cores ignore the bottom 2 bits of the TRS and XYZ words to allow easy transition from an 8-bit system.
Bits | 10-bit | 8-bit | Description |
---|---|---|---|
Unused |
[5:0] | [3:0] | These bits are not inspected by the CVI IP cores. |
H (sync) |
6 | 4 | When 1, the video is in a horizontal blanking period. |
V (sync) |
7 | 5 | When 1, the video is in a vertical blanking period. |
F (field) |
8 | 6 | When 1, the video is interlaced and in field 1. When 0, the video is either progressive or interlaced and in field 0. |
Unused |
9 | 7 | These bits are not inspected by the CVI IP cores. |
For the embedded synchronization format, the vid_datavalid signal indicates a valid BT656 or BT1120 sample. The CVI IP cores only read the vid_data signal when vid_datavalid is 1.
The CVI IP cores extract any ancillary packets from the Y channel during the vertical blanking. Ancillary packets are not extracted from the horizontal blanking.
- Clocked Video Input IP core—The extracted packets are produced through the CVI IP core's Avalon-ST output with a packet type of 13 (0xD).
- Clocked Video Input II IP core— The extracted packets are stored in a RAM in the IP core, which can be read through the control interface.
3.1.3. Separate Synchronization Format
The CVO IP cores create horizontal and vertical syncs and field information through their own signals. The CVO IP cores create a sample for each clock cycle on the vid_data bus. The vid_datavalid signal indicates when the vid_data video output is in an active picture period of the frame.
Signal Name | Description |
---|---|
vid_h_sync | When 1, the video is in a horizontal synchronization period. |
vid_v_sync | When 1, the video is in a vertical synchronization period. |
vid_f | When 1, the video is interlaced and in field 1. When 0, the video is either progressive or interlaced and in field 0. |
vid_h | When 1, the video is in a horizontal blanking period, (only for Clocked Video Output IP core). |
vid_v | When 1, the video is in a vertical blanking period, (only for Clocked Video Output IP core). |
vid_de | When asserted, the video is in an active picture
period (not horizontal or vertical blanking). This signal must be driven for correct
operation of the IP cores. Note: Only for Clocked Video Input IP cores.
|
vid_datavalid |
|
The CVI IP cores only read the vid_data, vid_de, vid_h_sync, vid_v_sync, and vid_f signals when vid_datavalid is 1. This allows the CVI IP cores to support oversampling where the video clock is running at a higher rate than the pixel clock.
3.1.4. Video Locked Signal
When the vid_locked signal has a value of 1, the CVI IP cores take the input clocked video signals as valid, and read and process them as normal. When the signal has a value of 0 (if for example the video cable is disconnected or the video interface is not receiving a signal):
- Clocked Video Input IP core: The IP core takes the input clocked video signals as invalid and do not process them.
- Clocked Video Input II IP core: The vid_clk domain registers of the IP core are held in reset and no video is processed. The control and Avalon-ST Video interfaces are not held in reset and will respond as normal. The vid_locked signal is synchronized internally to the IP core and is asynchronous to the vid_clk signal.
If the vid_locked signal goes invalid while a frame of video is being processed, the CVI IP cores end the frame of video early.
3.1.5. Clocked Video and 4:2:0 Chroma Subsampling
When processing 4:2:0 streams, you need to use chroma resampler to convert to 4:2:2 or 4:4:4 before or after any video processing is performed. The video streams can be converted back to 4:2:0 for transmission from the pipeline with another chroma resampler.
The connectivity cores (SDI, HDMI and DisplayPort) present data at their interfaces in accordance with their respective standards, not in line with the AV-ST mappings. Before the data is processed, it must be arranged in an Avalon-ST compliant manner. The input and output preparation areas present a gray area in the pipeline where video packets are Avalon-ST video compliant but the arrangement of data within the packet may not match the expectations of the processing blocks.
3.1.5.1. Avalon-ST Video Control Packets for 4:2:0 Video
When the Chroma Resampler II IP core receives or transmits an Avalon-ST video carrying a frame in 4:2:0 format, the control packet of the associated frame will have a horizontal resolution that is half the actual resolution of the frame.
The triplet of 2 luma and 1 chroma values in 4:2:0 represent 2 pixels but they are carried in a single “pixel” of symbols in the AV-ST domain. Because the triplet is counted as a single pixel, the value of the horizontal resolution carried in control packets will be half that of the resolution the data actually represents.
For example, a UHD frame received in 4:4:4 will have a control packet specifying 3840x2160. The same resolution frame received in 4:2:0 will have a control packet indicating 1920x2160.
- When converting from 4:2:0 to either 4:2:2 or 4:4:4, the horizontal width will be doubled.
- When converting from 4:4:4 or 4:2:2 down to 4:2:0 the horizontal width is halved.
If you choose to create your own 4:2:0 processing blocks, the half horizontal width control packet requirement must be met.
3.1.5.2. 4:2:0 Clocked Video
The CVI II and CVO II IP cores are agnostic of the video standard being driven through them.
For 4:2:2, the “empty” data on the unused input data line becomes a color plane of “empty” data at the output of the CVI II. Likewise, the 4:2:0 triplet gets mapped into a single 3 color plane pixel at the output. This has a significant impact on handling 4:2:0.
The CVI II IP core automatically creates control packets where the horizontal width is half the real frame width. To select its timing parameters, the CVO II IP core compares the control packet dimensions against those held in the mode banks. To match a 4:2:0 control packet, the mode bank width must be recorded as half of the actual frame dimension so that it matches the control packet. If the full width is entered to the mode bank, the correct timing parameters will not be matched.
3.1.5.3. Resampling 4:2:0
When the 4:2:0 samples brought into the pipeline, they should be resampled to 4:2:2 or 4:4:4 to be compatible with the other processing IP cores.
The table below summarizes the conversions required to move from each sampling scheme to a specific pipeline sampling scheme. For systems requiring color space conversion and chroma resampling, the order of chroma resampler and color space converter in the system is determined by whether the pipeline target is RGB or YCbCr.
Input Format | Pipeline Format | Conversion |
---|---|---|
RGB | RGB | None |
YCbCr 4:4:4 | RGB | Color Space Conversion |
YCbCr 4:2:2 | RGB |
|
YCbCr 4:2:0 | RGB |
|
YCbCr 4:4:4 | YCbCr 4:4:4 | None |
YCbCr 4:2:2 | YCbCr 4:4:4 | Chroma Resampling |
YCbCr 4:2:0 | YCbCr 4:4:4 | Chroma Resampling |
RGB | YCbCr 4:4:4 | Color Space Conversion |
YCbCr 4:4:4 | YCbCr 4:2:2 | Chroma Resampling |
YCbCr 4:2:2 | YCbCr 4:2:2 | None |
YCbCr 4:2:0 | YCbCr 4:2:2 | Chroma Resampling |
RGB | YCbCr 4:2:2 |
|
The Chroma Resampler II IP core makes assumptions about the arrangement of pixel sub-samples for its resampling. It could be because that the connectivity core does not supply pixels with the sub-samples in this order. If this is the case, then use a color plane sequencer to rearrange the sub-samples into the correct order.
Refer to the Chroma Resampler II IP Core for the expected sample ordering.
4. VIP Run-Time Control
All the IP cores have an optional simple run-time control interface that comprises a set of control and status registers, accessible through an Avalon-MM slave port. A run-time control configuration has a mandatory set of three registers for every IP core, followed by any function-specific registers.
Address | Data | Description | |
---|---|---|---|
0 | Bits 31:1 = X | Bit 0 = Go | Control register |
1 | Bits 31:1 = X | Bit 1 = Status | Status register |
2 | Core specific | Interrupt register |
When you enable run-time control, the Go bit gets deasserted by default. If you do not enable run-time control, the Go is asserted by default.
Every IP core retains address 2 in its address space to be used as an interrupt register. However this address is often unused because only some of the IP cores require interrupts.
5. Getting Started
The Video and Image Processing Suite IP cores are installed as part of the Intel® Quartus® Prime Standard Edition installation process.
5.1. IP Catalog and VIP Parameter Editor
Double-click on any IP core name to launch the parameter editor and generate files representing your IP variation. The parameter editor prompts you to specify your IP variation name, optional ports, architecture features, and output file generation options. The parameter editor generates a top-level .qsys file representing the IP core in your project. Alternatively, you can define an IP variation without an open Intel® Quartus® Prime project. When no project is open, select the Device Family directly in IP Catalog to filter IP cores by device.
Use the following features to help you quickly locate and select an IP core:
- Search to locate any full or partial IP core name in IP Catalog.
- Right-click an IP core name in IP Catalog to display details about supported devices, installation location, and links to documentation.
Upgrading VIP Designs
In the Intel® Quartus® Prime software, if you open a design from previous versions that contains VIP components in a Platform Designer system, you may get a warning message with the title "Upgrade IP Components". This message is just letting you know that VIP components within your Platform Designer system need to be updated to their latest versions, and to do this the Platform Designer system must be regenerated before the design can be compiled within the Intel® Quartus® Prime software. The recommended way of doing this with a VIP system is to close the warning message and open the design in Platform Designer so that it is easier to spot any errors or potential errors that have arisen because of the design being upgraded.
VIP IP Interoperability
The IP in the VIP Suite interoperate with each other. Their streaming interfaces use the same standard of data transmission layered on top of Avalon streaming interface. You can connect them together in Platform Designer and create a chain to build a video processing pipeline. The automatic insertion of Avalon streaming adapters in Platform Designer is disabled for video IP cores. Inserting width adapters breaks the semantics of the Avalon streaming video protocol. You must manually insert the Color Space Sequencer IP to perform data width conversion.
5.1.1. Specifying IP Core Parameters and Options
- In the Platform Designer IP Catalog (Tools > IP Catalog), locate and double-click the name of the IP core to customize. The parameter editor appears.
- Specify a top-level name for your custom IP variation. This name identifies the IP core variation files in your project. If prompted, also specify the target FPGA device family and output file HDL preference. Click OK.
-
Specify parameters and options for your IP variation:
- Optionally select preset parameter values. Presets specify all initial parameter values for specific applications (where provided).
- Specify parameters defining the IP core functionality, port configurations, and device-specific features.
- Specify options for generation of a timing netlist, simulation model, testbench, or example design (where applicable).
- Specify options for processing the IP core files in other EDA tools.
Note: The Video and Image Processing IP cores support only ModelSim* simulation software. - Click Finish to generate synthesis and other optional files matching your IP variation specifications. The parameter editor generates the top-level .qsys IP variation file and HDL files for synthesis and simulation. Some IP cores also simultaneously generate a testbench or example design for hardware testing.
- To generate a simulation testbench, click Generate > Generate Testbench System. Generate Testbench System is not available for some IP cores that do not provide a simulation testbench.
- To generate a top-level HDL example for hardware verification, click Generate > HDL Example. Generate > HDL Example is not available for some IP cores.
The top-level IP variation is added to the current Intel® Quartus® Prime project. Click Project > Add/Remove Files in Project to manually add a .qsys ( Intel® Quartus® Prime Standard Edition) or .ip ( Intel® Quartus® Prime Pro Edition) file to a project. Make appropriate pin assignments to connect ports.
5.2. Installing and Licensing IP Cores
The Intel® Quartus® Prime software installs IP cores in the following locations by default:
Location | Software | Platform |
---|---|---|
<drive>:\intelFPGA_pro\quartus\ip\altera | Intel® Quartus® Prime Pro Edition | Windows |
<drive>:\intelFPGA\quartus\ip\altera | Intel® Quartus® Prime Standard Edition | Windows |
<home directory>:/intelFPGA_pro/quartus/ip/altera | Intel® Quartus® Prime Pro Edition | Linux* |
<home directory>:/intelFPGA/quartus/ip/altera | Intel® Quartus® Prime Standard Edition | Linux |
5.2.1. Intel FPGA IP Evaluation Mode
- Simulate the behavior of a licensed Intel® FPGA IP core in your system.
- Verify the functionality, size, and speed of the IP core quickly and easily.
- Generate time-limited device programming files for designs that include IP cores.
- Program a device with your IP core and verify your design in hardware.
Intel® FPGA IP Evaluation Mode supports the following operation modes:
- Tethered—Allows running the design containing the licensed Intel® FPGA IP indefinitely with a connection between your board and the host computer. Tethered mode requires a serial joint test action group (JTAG) cable connected between the JTAG port on your board and the host computer, which is running the Intel® Quartus® Prime Programmer for the duration of the hardware evaluation period. The Programmer only requires a minimum installation of the Intel® Quartus® Prime software, and requires no Intel® Quartus® Prime license. The host computer controls the evaluation time by sending a periodic signal to the device via the JTAG port. If all licensed IP cores in the design support tethered mode, the evaluation time runs until any IP core evaluation expires. If all of the IP cores support unlimited evaluation time, the device does not time-out.
- Untethered—Allows running the design containing the licensed IP for a limited time. The IP core reverts to untethered mode if the device disconnects from the host computer running the Intel® Quartus® Prime software. The IP core also reverts to untethered mode if any other licensed IP core in the design does not support tethered mode.
When the evaluation time expires for any licensed Intel® FPGA IP in the design, the design stops functioning. All IP cores that use the Intel® FPGA IP Evaluation Mode time out simultaneously when any IP core in the design times out. When the evaluation time expires, you must reprogram the FPGA device before continuing hardware verification. To extend use of the IP core for production, purchase a full production license for the IP core.
You must purchase the license and generate a full production license key before you can generate an unrestricted device programming file. During Intel® FPGA IP Evaluation Mode, the Compiler only generates a time-limited device programming file (<project name> _time_limited.sof) that expires at the time limit.
Intel® licenses IP cores on a per-seat, perpetual basis. The license fee includes first-year maintenance and support. You must renew the maintenance contract to receive updates, bug fixes, and technical support beyond the first year. You must purchase a full production license for Intel® FPGA IP cores that require a production license, before generating programming files that you may use for an unlimited time. During Intel® FPGA IP Evaluation Mode, the Compiler only generates a time-limited device programming file (<project name> _time_limited.sof) that expires at the time limit. To obtain your production license keys, visit the Self-Service Licensing Center.
The Intel® FPGA Software License Agreements govern the installation and use of licensed IP cores, the Intel® Quartus® Prime design software, and all unlicensed IP cores.
6. VIP Connectivity Interfacing
While the Color planes transmitted in parallel and Number of color planes parameters define an interface that is capable of carrying the sampling methods, they do not enforce the transmission of particular sub-samples in particular symbols of the Avalon-ST video packet.
You have to understand the arrangement of the color planes on entry to the pipeline and any reconfiguration of this order performed by the components within the pipeline. This is a particular concern around the connectivity points. The connectivity IP cores present data arranged according to their respective standards. When connected to a clocked video component, the clocked video components will package the data as it is presented to the IP core. They do not re-arrange it. In simple terms, on each clock cycle during the active video, the Clocked Video Input (CVI) IP core samples the entire data bus and divides the samples into pixels according to the Number of color planes, Bits per color plane, and Pixels in parallel parameters used to configure the module.
If the configuration selected were PiP=1 and CP=4, but a 10-bit RGB signal were being fed on Data [29:30], the output pixels will still be 40 bits in size, the unused data bits having been sampled.
The converse function of the Clocked Video Output (CVO) drives the entire data bus on each clock cycle. To drive 10-bit RGB on Data[29:0] in the PiP=1 and CP=4 configuration, the VIP pipeline would have to generate 40-bit pixels containing the 30 data bits and 10 null bits.
6.1. Avalon-ST Color Space Mappings
The CVI and CVO blocks offer a simple mechanism to present data in the AV-ST video format but they do not offer functions to remap the many different data mappings the connectivity cores present.
6.1.1. Interfacing with High-Definition Multimedia Interface (HDMI)
For YCbCr 4:4:4, it is necessary to perform the translation shown in the figure below to meet the Avalon-ST requirements. If the system only handles YCbCr, then you can use the Color Plane Sequencer II IP core to perform this remapping. If the system handles both RGB and YCbCr, then you need to use the Color Space Converter II IP core to convert between RGB and YCbCr and also to remap the color plane ordering for YCbCr 4:4:4.
If the system only handles YCbCr, then you can use the Color Plane Sequencer II IP core to remap the symbols. If the system handles both RGB and YCbCr, then you need to use the Color Space Converter II IP core to remap the chroma samples.
6.1.2. Interfacing with DisplayPort
If the system only handles YCbCr, then you can use the Color Plane Sequencer II IP core to perform the remapping. If the system handles both RGB and YCbCr, then you need to use the Color Space Converter II IP core to convert between RGB and YCbCr and also to remap the color plane ordering for YCbCr 4:4:4.
6.1.3. Interfacing with Serial Digital Interface (SDI)
The SDI-clocked video interface deals in the SDI symbols, not the video samples. This means that only certain of the SDI mappings are directly compatible with Avalon-ST video requirements. The figure below shows the 8- and 10-bit YCbCr 4:2:2 mappings.
You can transport other mappings into the Avalon-ST domain but to rearrange the samples into a compatible format, immediate remapping into the Avalon-ST format is required. The clocked video units do not perform any remapping function.
If a single pixel configuration is used, then the horizontal resolution would be correct in the Avalon-ST control packet. If the 2 pixel solution were selected, the Avalon-ST control packet would report a width 2x the actual horizontal resolution (since an entire extra line is carried on Link B but it’s pixels would be counted as part of Link As). In both cases, the Avalon-ST control packet would report a vertical resolution ½ the actual resolution since 2 lines have been handled as 1. Any remapping logic has to account for this.
In this case using 1 pixel, 4 color planes in parallel will mean that the control packet reflects the true dimensions of the incoming image. If 2 pixels with 2 color planes is configured, then the control packet will report a horizontal width 2x the actual width.
The 12-bit data mappings also require processing to recombine the relevant SDI symbols into the correct pixel components.
If you select 2 pixel in parallel configuration, then the control packets from a CVI will report 2x actual width. Going into the CVO, the packets would need to report 2x the actual width.
6.1.4. Unsupported SDI Mappings
The CVI can only identify streams demarked in this way. The CVO can only generate streams demarked in this way.
This means that the SMPTE-425 Level B mappings are not directly supported by the clocked video units. Because both Level B-DL and Level B-DS mappings modify the arrival order of TRS codes, these streams must be demultiplexed before clocked video inputs. After clocked video outputs, the streams must be multiplexed together.
6.1.5. 12G-SDI
You can enable the support for 12G-SDI by turning on the Support 6G and 12G-SDI parameter in the CVI II and CVO II IP parameter editors. Turning on the Support 6G and 12G-SDI parameter enables the SDI Resampler block within a CVI II or CVO II instance. The SDI resampler enables the support for 12G-SDI format.
The SDI Resampler also supports 6G-, 3G-, HD-, and SD-SDI formats. Conversion to Avalon-ST video format is possible only for configurations with 4 pixels in parallel. With the presence of the SDI Resampler, the CVI II and CVO II IPs are able to provide seamless switching between 12G-, 6G-, 3G-, HD-, and SD-SDI formats.
6.1.5.1. 12G-SDI with Clocked Video Input II
The 12G-SDI option uses the two-sample interleave (2SI) pattern, which transmits two lines simultaneously, The simultaneous transmission of two lines means that the active width received by the CVI II IP core in between two sets of horizontal SYNC is two times the actual width. The CVI II IP core applies the appropriate scaling before reporting to the Active Sample Count status register and the Avalon-ST video control packet. The 2SI pattern also requires that the clocked video input to be remapped to raster scan order for processing in a VIP pipeline. The CVI II IP core performs the remapping.
When a 3G-SDI packet is carried over a 12G-SDI link, the CVI II IP core captures 3 null pixels for every active pixel. The SDI Resampler discards these null pixels to reestablish the 3G-SDI sample order in the Avalon-ST video frame, as shown in the figure below.
Parameters | Support 6G and 12G-SDI Off | Support 6G and 12G-SDI On |
---|---|---|
SDI Resampler | Not available | Present |
Pixels in parallel | 1 | 4 |
Standard width range | 1–16 | 3 |
Multi-rate Mode | 3G-SDI, HD-SDI, SD-SDI | 12G-SDI, 6G-SDI, 3G-SDI, HD-SDI, SD-SDI |
Square Division Quad format | Not supported | Not supported |
2 Sample-interleave (2SI) format | Not supported | Supported |
12G-SDI with 8 streams interleaved | Not supported | Supported |
12G-SDI with 16 streams interleaved | Not supported | Not supported |
6G-SDI with 4 streams interleaved | Not supported | Not supported |
6G-SDI with 8 streams interleaved | Not supported | Supported |
3G-SDI Level A | Supported | Supported |
3G-SDI Level B | Not supported | Not supported |
HD-SDI | Supported | Supported |
SD-SDI | Supported | Supported |
4:4:4 | Not supported | Not supported |
4:2:2 | Supported | Supported |
4:2:0 | Not supported | Not supported |
Minimum active frame size | 32x32 |
|
Active width supported | Modulo 1 |
|
Active height supported | Modulo 1 | Modulo 1 |
Clipping | Supported | Not supported |
Padding | Supported | Not supported |
6.1.5.2. 12G-SDI with Clocked Video Output II
Parameters | Support 6G and 12G-SDI Off | Support 6G and 12G-SDI On |
---|---|---|
SDI Resampler | Not available | Present |
Pixels in parallel | 1 | 4 |
Standard width range | 1–16 | 3 |
Multi-rate Mode | 3G-SDI, HD-SDI, SD-SDI | 12G-SDI, 6G-SDI, 3G-SDI, HD-SDI, SD-SDI |
Square Division Quad format | Not supported | Not supported |
2 Sample-interleave (2SI) format | Not supported | Supported |
12G-SDI with 8 streams interleaved | Not supported | Supported |
12G-SDI with 16 streams interleaved | Not supported | Not supported |
6G-SDI with 4 streams interleaved | Not supported | Not supported |
6G-SDI with 8 streams interleaved | Not supported | Supported |
3G-SDI Level A | Supported | Supported |
3G-SDI Level B | Not supported | Not supported |
HD-SDI | Supported | Supported |
SD-SDI | Supported | Supported |
4:4:4 | Not supported | Not supported |
4:2:2 | Supported | Supported |
4:2:0 | Not supported | Not supported |
Minimum active frame size | 32x32 | Fixed resolution: 32x32 Note: For switching resolutions, if the frame is smaller than the combined capacity of
the CVO IP core’s FIFOs and pipelines, the behavior is undetermined. Use the set of
standard resolutions defined in the CTA-861-G specifications.
|
Active width supported | Modulo 1 |
|
Active height supported | Modulo 1 |
|
Dynamic control over Go bit | Supported | Cannot be disabled once enabled. |
Low latency mode | Supported | Not supported |
7. Clocked Video Interface IP Cores
IP Cores | Feature |
---|---|
CVI IP cores
|
|
CVO IP cores
|
|
7.1. Supported Features for Clocked Video Output IP Cores
Features | Clocked Video Output II | Clocked Video Output |
---|---|---|
HDMI SD/HD | Yes | Yes |
3G-SDI | Yes | Yes |
HDMI 4K | Yes | No |
12G-SDI | Yes Note: Low
Latency Mode is not supported if you turn on the Use
6G and 12G-SDI
parameter.
|
No |
Genlock | No | Yes |
Low latency mode | Yes Note: Low
Latency Mode is not supported if you turn on the Use
6G and 12G-SDI
parameter.
|
Yes |
Full frame mode | Yes | No |
7.2. Control Port
Initially, the IP core is disabled and does not transmit any data or video. However, the Clocked Video Input IP cores still detect the format of the clocked video input and raise interrupts; and the Clocked Video Output IP cores still accept data on the Avalon-ST Video interface for as long as there is space in the input FIFO.
The sequence for starting the output of the IP core:
- Write a 1 to Control register bit 0.
- Read Status register bit 0. When this bit is 1, the IP core starts
transmitting data or video. The transmission starts on the next start of frame or
field boundary. Note: For CVI IP cores, the frame or field matches the Field order parameter settings.
The sequence for stopping the output of the IP core:
- Write a 0 to Control register bit 0.
- Read Status register bit 0. When this bit is 0, the IP core stops
transmitting data. The transmission ends on the next start of frame or field
boundary. Note: For CVI IP cores, the frame or field matches the Field order parameter settings.
The starting and stopping of the IP core synchronize to a frame or field boundary.
Video Format | Field Order | Output |
---|---|---|
Interlaced | F1 first | Start, F1, F0, ..., F1, F0, Stop |
Interlaced | F0 first | Start, F0, F1, ..., F0, F1, Stop |
Interlaced | Any field first | Start, F0 or F1, ... F0 or F1, Stop |
Progressive | F1 first | No output |
Progressive | F0 first | Start, F0, F0, ..., F0, F0, Stop |
Progressive | Any field first | Start, F0, F0, ..., F0, F0, Stop |
7.3. Clocked Video Input Format Detection
Format | Description |
---|---|
Picture width (in samples) |
|
Picture height (in lines) |
|
Interlaced/Progressive |
|
Standard |
Note: In
3G,
6G, and 12G
modes,
the CVI II IP core only supports YCbCr input color format with
either 8 or 10 bits for each component.
|
7.3.1. Format Detection in Clocked Video Input
After determining an aspect of the incoming videos format, the IP core enters the value in the respective register, sets the registers valid bit in the Status register, and triggers the respective interrupts.
Status | Interrupt | Active Sample Count | F0 Active Line Count | F1 Active Line Count | Total Sample Count | F0 Total Sample Count | F1 Total Sample Count | Description |
---|---|---|---|---|---|---|---|---|
00000000000 | 000 | 0 | 0 | 0 | 0 | 0 | 0 | Start of incoming video. |
00000001000 | 000 | 1,920 | 0 | 0 | 2,200 | 0 | 0 | End of first line of video. |
00100001000 | 100 | 1,920 | 0 | 0 | 2,200 | 0 | 0 | Stable bit set and interrupt fired —Two of last three lines had the same sample count. |
00100011000 | 100 | 1,920 | 540 | 0 | 2,200 | 563 | 0 | End of first field of video. |
00110011000 | 100 | 1,920 | 540 | 0 | 2,200 | 563 | 0 | Interlaced bit set—Start of second field of video. |
00111011000 | 100 | 1,920 | 540 | 540 | 2,200 | 563 | 562 | End of second field of video. |
10111011000 | 110 | 1,920 | 540 | 540 | 2,200 | 563 | 562 | Resolution valid bit set and interrupt fired. |
7.3.2. Format Detection in Clocked Video Input II
When the IP core detects a resolution, it uses the resolution to generate the Avalon-ST Video control packets until a new resolution is detected.
When the resolution valid bit in the Status register is 1, the Active Sample Count, F0 Active Line Count, F1 Active Line Count, Total Sample Count, F0 Total Line Count, F1 Total Line Count, and Standard registers are valid and contain readable values. The interlaced bit of the Status register is also valid and can be read.
7.4. Interrupts
IP Core | Internal Interrupts | Description |
---|---|---|
Clocked Video Input IP core | Status update interrupt | Triggers when a change of resolution in the incoming video is detected. |
Stable video interrupt |
|
|
Clocked Video Input II IP core | Status update interrupt | Triggers when the stable bit, the resolution valid bit, the overflow sticky bit, or the picture drop sticky bit of the Status register changes value. |
End of field/frame interrupt |
You can use this interrupt to trigger the reading of the ancillary packets from the control interface before the packets are overwritten by the next frame. |
You can independently enable these interrupts using bits [2:1] of the Control register. The interrupt values can be read using bits [2:1] of the Interrupt register. Writing 1 to either of these bits clears the respective interrupt.
7.5. Clocked Video Output Video Modes
If you turn off Use control port in the parameter editor for the CVO IP cores, then the output video format always has the format specified in the parameter editor.
The CVO IP cores can be configured to support between 1 to 13 different modes and each mode has a bank of registers that describe the output frame.
- Clocked Video Output IP Core
- When the IP core receives a new control packet on the Avalon-ST Video input, it searches the mode registers for a mode that is valid. The valid mode must have a field width and height that matches the width and height in the control packet.
- The Video Mode Match register shows the selected mode.
- If a matching mode is found, it restarts the video output with those format settings.
- If a matching mode is not found, the video output format is unchanged and a restart does not occur.
- Clocked Video Output II IP
Core
- When the IP core receives a new control packet on the Avalon-ST Video input, it searches the mode registers for a mode that is valid. The valid mode must have a field width and height that matches the width and height in the control packet.
- The Video Mode Match register shows the selected mode.
- If a matching mode is found, it completes the current frame; duplicating data if needed before commencing output with the new settings at the beginning of the next frame.
- If a matching mode is not found, the video output format is unchanged.
- If a new control packet is encountered before the expected end of frame,
the IP core completes the timing of the current frame with the remaining
pixels taking the value of the last pixel output. The IP core changes modes
to the new packet at the end of this frame, unless you enabled the Low
Latency mode. During this period, when the FIFO fills, the IP core
back-pressures the input until it is ready to transmit the new frame.Note: This behavior differs from the Clocked Video Output IP core where the IP core abandons the current frame and starts the timing for the new frame immediately.
For both CVO IP cores, you must enable the Go bit to program the mode control registers. The sync signals, controlled by the mode control registers, reside in the video clock domain. The register control interface resides in the streaming clock domain. Enabling the Go bit, indicating that both clocks are running, avoids situations where a write in the streaming side cannot be issued to the video clock side because the video clock isn't running.
The mode registers can only be written to if a mode is marked as invalid.
- For Clocked Video Output IP core,
the following steps reconfigure mode 1:
- Write 0 to the Mode1 Valid register.
- Write to the Mode 1 configuration registers.
- Write 1 to the Mode1 Valid register. The mode is now valid and can be selected.
- For Clocked Video Output II IP core,
the following steps reconfigure mode 1:
- Write 1 to the Bank Select register.
- Write 0 to the Mode N Valid configuration register.
- Write to the Mode N configuration registers, the Clocked Video Output II IP core mirrors these writes internally to the selected bank.
- Write 1 to the Mode N Valid register. The mode is now valid and can be selected.
You can configure a currently-selected mode in this way without affecting the video output of the CVO IP cores.
If there are multiple modes that match the resolution, the function selects the lowest mode. For example, the function selects Mode1 over Mode2 if both modes match. To allow the function to select Mode2, invalidate Mode1 by writing a 0 to its mode valid register. Invalidating a mode does not clear its configuration.
7.5.1. Interrupts
The CVO IP cores produce a single interrupt line.
This interrupt line is the OR of the following internal interrupts:
- Status update interrupt—Triggers when the Video Mode Match register is updated by a new video mode being selected.
- Locked interrupt—Triggers when the outgoing video SOF is aligned to the incoming SOF.
Both interrupts can be independently enabled using bits [2:1] of the Control register. Their values can be read using bits [2:1] of the Interrupt register. Writing 1 to either of these bits clears the respective interrupt.
7.6. Clocked Video Output II Latency Mode
You can enable the low latency mode by setting the Low latency mode parameter to 1 in the Clocked Video Output II parameter editor. In the low latency mode, when there is an early end of frame, or a change of resolution, the IP core immediately updates the selected mode, resets the internal counters, and starts transmitting the new frame. This happens even if the timing is only part way through the previous frame.
If you choose not to enable the low latency mode, an early end of packet or change of resolution pauses reading of the FIFO until the timing of the current frame is completed. Only at this point, the IP core updates any new timings and starts transmitting new frame. The implication of this mode is that if a partial video frame is received by the IP core, when the FIFO has filled, it will generate back pressure until the current frame (including vertical sync) has completed.
7.7. Generator Lock
You can configure the IP cores to output, using vcoclk_div for Clocked Video Output IP cores and refclk_div for CVI IP cores.
With the exception of Clocked Video Input II IP core, these signals are divided down versions of vid_clk (vcoclk) and vid_clk (refclk) aligned to the start of frame (SOF). By setting the divided down value to be the length in samples of a video line, you can configure these signals to produce a horizontal reference.
A CVO IP core can take in the locked PLL clock and the SOF signal and align the output video to these signals. This produces an output video frame that is synchronized to the incoming video frame.
Clocked Video Input IP Core
For Clocked Video Input IP core, you can compare vcoclk_div to refclk_div, using a phase frequency detector (PFD) that controls a voltage controlled oscillator (VCXO). By controlling the VCXO, the PFD can align its output clock (vcoclk) to the reference clock (refclk). By tracking changes in the refclk_div signal, the PFD can then ensure that the output clock is locked to the incoming video clock.
You can set the SOF signal to any position within the incoming video frame. The registers used to configure the SOF signal are measured from the rising edge of the F0 vertical sync. Due to registering inside the settings of the CVI IP cores, the SOF Sample and SOF Line registers to 0 results in a SOF signal rising edge:
- six cycles after the rising edge of the V sync in embedded synchronization mode
- three cycles after the rising edge of the V sync in separate synchronization mode
A rising edge on the SOF signal (0 to 1) indicates the start of frame.
Format | SOF Sample Register | SOF Line Register | Refclk Divider Register |
---|---|---|---|
720p60 | 1644 << 2 | 749 | 1649 |
1080i60 | 2194 << 2 | 1124 | 2199 |
NTSC | 856 << 2 | 524 | 857 |
Clocked Video Input II IP Core
For Clocked Video Input II IP core, the SOF signal produces a pulse on the rising edge of the V sync. For interlaced video, the pulse is only produced on the rising edge of the F0 field, not the F1 field. A start of frame is indicated by a rising edge on the SOF signal (0 to 1).
7.8. Underflow and Overflow
Underflow
Overflow
The FIFO can accommodate any bursts as long as the input rate of the upstream Avalon-ST Video components is equal to or higher than that of the incoming clocked video. If this is not the case, the FIFO overflows. If overflow occurs, the CVI IP cores produce an early endofpacket signal to complete the current frame. It then waits for the next start of frame (or field) before resynchronizing to the incoming clocked video and beginning to produce data again. The overflow is recorded in bit [9] of the Status register. This bit is sticky, and if an overflow occurs, it stays at 1 until the bit is cleared by writing a 0 to it. In addition to the overflow bit, you can read the current level of the FIFO from the Used Words register.
The height and width parameters at the point the frame was completed early will be used in the control packet of the subsequent frame. If you are reading back the detected resolution, then these unusual resolution values can make the CVI IP cores seem to be operating incorrectly where in fact, the downstream system is failing to service the CVI IP cores at the necessary rate.
7.9. Timing Constraints
Clocked Video Input and Clocked Video Output IP Cores
To constrain these IP cores correctly, add the following files to your Intel® Quartus® Prime project:
- <install_dir>\ip\altera\clocked_video_input\ alt_vip_cvi.sdc
- <install_dir>\ip\altera\clocked_video_output\alt_vip_cvo.sdc
When you apply the .sdc file, you may see some warning messages similar to the format below:
- Warning: At least one of the filters had some problems and could not be matched.
- Warning: * could not be matched with a keeper.
These warnings are expected, because in certain configurations the Intel® Quartus® Prime software optimizes unused registers and they no longer remain in your design.
Clocked Video Input II and Clocked Video Output II IP Cores
For these IP cores, the .sdc files are automatically included by their respective .qip files. After adding the Platform Designer system to your design in the Intel® Quartus® Prime software, verify that the alt_vip_cvi_core.sdc or alt_vip_cvo_core.sdc has been included.
When you apply the .sdc file, you may see some warning messages similar to the format below:
- Warning: At least one of the filters had some problems and could not be matched.
- Warning: * could not be matched with a keeper.
These warnings are expected, because in certain configurations the Intel® Quartus® Prime software optimizes unused registers and they no longer remain in your design.
Intel recommends that you place a frame buffer in any CVI to CVO system. Because the CVO II IP core generates sync signals for a complete frame, even when video frames end early, it is possible for the CVO II IP core to continually generate backpressure to the CVI II IP core so that it keeps ending packets early.
Placing a frame buffer may not be appropriate if the system requires latency lower than 1 frame. In this case, enable the Low Latency mode when you configure the CVO II IP core.
7.10. Handling Ancillary Packets
AFD Extractor (Clocked Video Input IP Core)
When the output of the CVI IP cores connects to the input of the AFD Extractor, the AFD Extractor removes any ancillary data packets from the stream and checks the DID and secondary DID (SDID) of the ancillary packets contained within each ancillary data packet. If the packet is an AFD packet (DID = 0x41, SDID = 0x5), the extractor places the contents of the ancillary packet into the AFD Extractor register map.
You can get the AFD Extractor from <install_dir>\ip\altera\clocked_video_input\afd_example.
Address | Register | Description |
---|---|---|
0 | Control |
|
1 | — | Reserved. |
2 | Interrupt |
When bit 1 is 1, the core detects a change to the AFD data and the sets an interrupt. Writing a 1 to bit 1 clears the interrupt. |
3 | AFD | Bits 0-3 contain the active format description code. |
4 | AR | Bit 0 contains the aspect ratio code. |
5 | Bar data flags |
|
6 | Bar data value 1 | Bits 0-15 contain bar data value 1. |
7 | Bar data value 2 | Bits 0-15 contain bar data value 2. |
8 | AFD valid |
|
Ancillary Packets (Clocked Video Input II IP Core)
When you turn on the Extract Ancillary Packets parameter in embedded sync mode, the CVO IP core extracts any ancillary packets that are present in the Y channel of the incoming video's vertical blanking. The ancillary packets are stripped of their TRS code and placed in a RAM. You can access these packets by reading from the Ancillary Packet register. The packets are packed end to end from their Data ID to their final user word.
The RAM is 16 bits wide—two 8-bit ancillary data words are packed at each address location. The first word is at bits 0–7 and the second word is at bits 8–15. A word of all 1's indicates that no further ancillary packets are present and can appear in either the first word position or the second word position.
Use the Depth of ancillary memory parameter to control the depth of the ancillary RAM. If available space is insufficient for all the ancillary packets, then excess packets will be lost. The ancillary RAM is filled from the lowest memory address to the highest during each vertical blanking period—the packets from the previous blanking periods are overwritten. To avoid missing ancillary packets, the ancillary RAM should be read every time the End of field/frame interrupt register triggers.
AFD Inserter (Clocked Video Output)
When the output of the AFD Inserter connects to the input of the CVO IP cores, the AFD Inserter inserts an Avalon-ST Video ancillary data packet into the stream after each control packet. The AFD Inserter sets the DID and SDID of the ancillary packet to make it an AFD packet (DID = 0x41, SDID = 0x5). The contents of the ancillary packet are controlled by the AFD Inserter register map.
You can get the AFD Extractor from <install_dir>\ip\altera\clocked_video_output\afd_example.
Address | Register | Description |
---|---|---|
0 | Control |
|
1 | — | Reserved. |
2 | — | Reserved. |
3 | AFD | Bits 0-3 contain the active format description code. |
4 | AR | Bit 0 contains the aspect ratio code. |
5 | Bar data flags | Bits 0-3 contain the bar data flags to insert. |
6 | Bar data value 1 | Bits 0-15 contain bar data value 1 to insert. |
7 | Bar data value 2 | Bits 0-15 contain bar data value 2 to insert. |
8 | AFD valid |
|
7.11. Modules for Clocked Video Input II IP Core
Modules | Description |
---|---|
Sync_conditioner |
|
Resolution_detection |
|
Write_buffer_fifo |
|
Control |
|
Av_st_output |
|
Sdi_resampler |
|
7.12. Clocked Video Input II Signals, Parameters, and Registers
7.12.1. Clocked Video Input II Interface Signals
Signal | Direction | Description |
---|---|---|
main_reset_reset | Input | The IP core asynchronously resets when you assert this signal. You must deassert this signal synchronously to the rising edge of the clock signal. |
main_clock_clk | Input | The main system clock. The IP core operates on the rising edge of this signal. |
dout_data | Output | dout port Avalon-ST data bus. This bus enables the transfer of pixel data out of the IP core. |
dout_endofpacket | Output | dout port Avalon-ST endofpacket signal. This signal is asserted when the IP core is ending a frame. |
dout_ready | Input | dout port Avalon-ST ready signal. The downstream device asserts this signal when it is able to receive data. |
dout_startofpacket | Output | dout port Avalon-ST startofpacket signal. This signal is asserted when the IP core is starting a new frame. |
dout_valid | Output | dout port Avalon-ST valid signal. This signal is asserted when the IP core produces data. |
dout_empty | Output | dout port Avalon-ST empty signal. This signal has a non-zero value only when you set the Number of pixels in parallel parameter to be greater than 1. This signal specifies the number of pixel positions which are empty at the end of the dout_endofpacket signal. |
status_update_int | Output |
control slave port Avalon-MM interrupt signal. When
asserted, the status registers of the IP core have been updated and the
master must read them to determine what has occurred. Note: Present only if you turn on Use control port.
|
vid_clk | Input | Clocked video clock. All the video input signals are synchronous to this clock. |
vid_data | Input | Clocked video data bus. This bus enables the transfer of video data into the IP core. |
vid_de | Input | Clocked video data enable signal. The
driving core asserts this signal to indicate that the data on vid_data is part of the active picture
region of an incoming video. This signal must be driven for correct
operation of the IP core. Note: For separate synchronization mode only.
|
vid_datavalid | Input | Enabling signal for the CVI II IP
core. The IP core only reads the vid_data, vid_de,
vid_h_sync, vid_v_sync, vid_std, and vid_f
signals when vid_datavalid is 1. This
signal allows the CVI II IP core to support oversampling during when the
video runs at a higher rate than the pixel clock. Note: If you are not oversampling your input video, tie
this signal high.
|
vid_locked | Input | Clocked video locked signal. Assert
this signal when a stable video stream is present on the input. Deassert
this signal when the video stream is removed. When 0, this signal triggers an early end of output frame packet and does not reset the internal registers. When this signal recovers after 0, if the system is not reset from outside, the first frame may have leftover pixels from the lock-lost frame, |
vid_f | Input | Clocked video field signal. For
interlaced input, this signal distinguishes between field 0 and field 1.
For progressive video, you must deassert this signal. Note: For separate synchronization mode only.
|
vid_v_sync | Input | Clocked video vertical
synchronization signal. Assert this signal during the vertical
synchronization period of the video stream. Note: For separate synchronization mode only.
|
vid_h_sync | Input | Clocked video horizontal
synchronization signal. Assert this signal during the horizontal
synchronization period of the video stream. Note: For separate synchronization mode only.
|
vid_hd_sdn | Input | Clocked video color plane format
selection signal . This signal distinguishes between sequential (when
low) and parallel (when high) color plane formats. Note: For run-time switching of color plane transmission
formats mode only.
|
vid_std | Input | Video standard bus. Can be connected to the rx_std signal of the SDI IP core (or any other interface) to read from the Standard register. |
vid_color_encoding | Input | This signal is captured in the
Color Pattern register and does
not affect the functioning of the IP core. It provides a mechanism for
control processors to read incoming color space information if the IP
core (e.g. HDMI RX core) driving the CVI II does not provide such an
interface. Tie this signal to low if no equivalent signal is available from the IP core driving CVI II. |
vid_bit_width | Input | This signal is captured in the
Color Pattern register and does
not affect the functioning of the IP core. It provides a mechanism for
control processors to read incoming video bit width information if the
IP core (e.g. HDMI RX core) driving the CVI II does not provide such an
interface. Tie this signal to low if no equivalent signal is available from the IP core driving CVI II. |
vid_total_sample_count | Input | The IP core creates this signal if you do not turn on the Extract the total resolution parameter. The CVI II IP core operates using this signal as the total horizontal resolution instead of an internally detected version. |
Vid_total_line_count | Input | The IP core creates this signal if you do not turn on the Extract the total resolution parameter. The CVI II IP core operates using this signal as the total vertical resolution instead of an internally detected version. |
sof | Output | Start of frame signal. A change of 0 to 1 indicates the start of the video frame as configured by the SOF registers. Connecting this signal to a CVO IP core allows the function to synchronize its output video to this signal. |
sof_locked | Output | Start of frame locked signal. When asserted, the sof signal is valid and can be used. |
refclk_div | Output | A single cycle pulse in-line with the rising edge of the h sync. |
clipping | Output | Clocked video clipping signal. A
signal corresponding to the clipping bit of the Status register synchronized to vid_clk. This signal is for information only and no action is required if it is asserted. |
padding | Output | Clocked video padding signal. A
signal corresponding to the padding bit of the Status register synchronized to vid_clk. This signal is for information only and no action is required if it is asserted. |
overflow | Output | Clocked video overflow signal. A
signal corresponding to the overflow sticky bit of the Status register synchronized to vid_clk. This signal is for information
only and no action is required if it is asserted. Note: Present only if you turn on Use control port.
|
vid_hdmi_duplication[3:0] | Input | If you select Remove duplicate pixels in the parameter, this 4-bit bus is added to the CVI II interface. You can drive this bus based on the number of times each pixel is duplicated in the stream (HDMI-standard compliant). |
Signal | Direction | Description |
---|---|---|
av_address | Input |
control slave port Avalon-MM address bus. Specifies a word
offset into the slave address space. Note: Present only if you turn on Use control port.
|
av_read | Input |
control slave port Avalon-MM read signal. When you assert
this signal, the control port drives
new data onto the read data bus. Note: Present only if you turn on Use control port.
|
av_readdata | Output |
control slave port Avalon-MM read data bus. These output
lines are used for read transfers. Note: Present only if you turn on Use control port.
|
av_waitrequest | Output |
control slave port
Avalon-MM wait request bus. This signal indicates that the slave is
stalling the master transaction.
Note: Present only if you turn on Use control port.
|
av_write | Input |
control slave port Avalon-MM write signal. When you assert this signal, the control port accepts new data from the
write data bus. Note: Present only if you turn on Use control port.
|
av_writedata | Input |
control slave port Avalon-MM write data bus. These input
lines are used for write transfers. Note: Present only if you turn on Use control port.
|
av_byteenable | Input |
control slave port Avalon-MM byteenable bus. These lines indicate which bytes are
selected for write and read transactions.
|
7.12.2. Clocked Video Input II Parameter Settings
Parameter | Value | Description |
---|---|---|
Bits per pixel per color plane | 4–20, Default = 8 | Select the number of bits per pixel (per color plane). |
Number of color planes | 1–4, Default = 3 | Select the number of color planes. |
Color plane transmission format |
|
Specify whether to transmit the color planes in sequence or in parallel. If you select multiple pixels in parallel, then select Parallel. |
Number of pixels in parallel | 1, 2, 4, or 8 | Specify the number of pixels transmitted or received in parallel. |
Field order |
|
Specify the field to synchronize first when starting or stopping the output. |
Enable matching data packet to control by clipping | On or Off |
When there is a change in resolution,the control packet and video data packet transmitted by the IP core mismatch. Turn on this parameter if you want to clip the input video frame to match the resolution sent in control packet. When the current input frame resolution is wider and/or taller than the one specified in the control packet, then the IP core clips them to match the control packet dimensions. |
Enable matching data packet to control by padding | On or Off |
Turn on this parameter if you also want to pad the incoming frame if it is smaller and/or shorter than the resolution specified in the control packet. Note: This parameter is available only when you turn on
Enable matching data packet to
control by clipping. Depending on the size of the
mismatch, padding operation could lead to frame drops at the
input.
|
Overflow handling | On or Off |
Turn this parameter if you want the to finish the current frame (with dummy pixel data) based on the resolution specified in the control packet if overflow happens. The IP core waits for the FIFO to become empty before it starts the padding process. By default (turned off), if an overflow is encountered, current frame is terminated abruptly. Note: Depending on size of the frame left to finish and
the back pressure from downstream IP, overflow handling operation
could lead to frame drops at the input.
|
Sync signals |
|
Specify whether to embed the synchronization signal in the video stream or provide on a separate wire. |
Support 6G and 12G-SDI | On or Off | Turn on to enable 6G-SDI or 12G-SDI
support for CVI II IP core. Turning on this option will fix the number
of pixels in parallel to 4. Note: This option is available only when you select the
Embedded in video option
for the Sync signals
parameter.
|
Allow color planes in sequence input | On or Off | Turn on if you want to allow run-time switching between sequential and parallel color plane transmission formats. The format is controlled by the vid_hd_sdn signal. |
Extract field signal | On or Off | Turn on to internally generate the field signal from the position of the V sync rising edge. |
Use vid_std bus | On or Off | Turn on if you want to use the video
standard, vid_std. Note:
Platform Designer always
generates the vid_std signal even
when you turn off this parameter. The IP core samples and stores
this signal in the Standard
register to be read back for software control. If not needed, leave
this signal disconnected.
|
Width of vid_std bus |
External sync: 1–16, Default = 1 Embedded sync: 3, Default = 3 |
Specify the width of the vid_std bus, in bits. |
Extract ancillary packets | On or Off | Turn on to extract the ancillary packets in embedded sync mode. |
Depth of the ancillary memory | 0–4096, Default = 0 | Specify the depth of the ancillary packet RAM, in words. |
Extract the total resolution | On or Off | Turn on to extract total resolution from the video stream. |
Enable HDMI duplicate pixel removal |
|
Specify whether to enable a block to
remove duplicate pixels for low rate resolutions. When you select
Remove duplicate pixel, the
IP core generates an additional 4-bit port to connect to the HDMI IP
core. This port extracts the duplication factor from the HDMI IP
core. Note: The CVI II IP core currently supports only
duplication factors of 0 (no duplication) or 1 (each pixel
transmitted twice).
|
Interlaced or progressive |
|
Specify the format to be used when no format is automatically detected. |
Width | 32–8192, Default = 1920 | Specify the image width to be used when no format is automatically detected. |
Height – frame/field 0 | 32–8192, Default = 1080 | Specify the image height to be used when no format is automatically detected. |
Height – field 1 | 32–8192, Default = 480 | Specify the image height for interlaced field 1 to be used when no format is automatically detected. |
Pixel FIFO size | 32–4096, Default = 2048 | Specify the required FIFO depth in pixels. |
Video in and out use the same clock | On or Off | Turn on if you want to use the same signal for the input and output video image stream clocks. |
Use control port | On or Off | Turn on to use the optional stop/go control port. |
7.12.3. Clocked Video Input II Control Registers
Address | Register | Description |
---|---|---|
0 | Control |
|
1 | Status |
|
2 | Interrupt | Bits 2 and 1 are the interrupt status
bits:
|
3 | Used Words | The used words level of the input FIFO. |
4 | Active Sample Count | The detected sample count of the video streams excluding blanking. |
5 | F0 Active Line Count | The detected line count of the video streams F0 field excluding blanking. |
6 | F1 Active Line Count | The detected line count of the video streams F1 field excluding blanking. |
7 | Total Sample Count | The detected sample count of the video streams including blanking. |
8 | F0 Total Line Count | The detected line count of the video streams F0 field including blanking. |
9 | F1 Total Line Count | The detected line count of the video streams F1 field including blanking. |
10 | Standard | The contents of the vid_std signal. |
11-13 | Reserved | Reserved for future use. |
14 | Color Pattern |
|
15 | Ancillary Packet | Start of the ancillary packets that have been extracted from the incoming video. |
15 + Depth of ancillary memory | End of the ancillary packets that have been extracted from the incoming video. |
7.13. Clocked Video Output II Signals, Parameters, and Registers
7.13.1. Clocked Video Output II Interface Signals
Signal | Direction | Description |
---|---|---|
main_reset_reset | Input | The IP core asynchronously resets when you assert this signal. You must deassert this signal synchronously to the rising edge of the clock signal. |
main_clock_clk | Input | The main system clock. The IP core operates on the rising edge of this signal. |
din_data | Input | din port Avalon-ST data bus. This bus enables the transfer of pixel data into the IP core. |
din_endofpacket | Input | din port Avalon-ST endofpacket signal. This signal is asserted when the downstream device is ending a frame. |
din_ready | Output | din port Avalon-ST ready signal. This signal is asserted when the IP core function is able to receive data. |
din_startofpacket | Input | din port Avalon-ST startofpacket signal. Assert this signal when the downstream device is starting a new frame. |
din_valid | Input | din port Avalon-ST valid signal. Assert this signal when the downstream device produces data. |
din_empty | Input | din port Avalon-ST empty signal. This signal has a non zero value only when you set the Number of pixels in parallel parameter to be greater than 1. This signal specifies the number of pixel positions which are empty at the end of the din_endofpacket signal. |
underflow | Output | Clocked video underflow signal. A
signal corresponding to the underflow sticky bit of the Status register synchronized to vid_clk. This signal is for information
only and no action is required if it is asserted. Note: Present only if you turn on Use control port.
|
status_update_int | Output |
control slave port Avalon-MM interrupt signal. When
asserted, the status registers of the IP core have been updated and the
master must read them to determine what has occurred. Note: Present only if you turn on Use control port.
|
vid_clk | Input | Clocked video clock. All the video output signals are synchronous to this clock. |
vid_data | Output | Clocked video data bus. This bus transfers video data out of the IP core. |
vid_datavalid | Output | Clocked video data valid signal.
Assert this signal when a valid sample of video data is present on
vid_data. Note: This signal is equivalent to the CVI II IP core's
vid_de signal.
|
vid_f | Output | Clocked video field signal. For
interlaced input, this signal distinguishes between field 0 and field 1.
For progressive video, this signal is unused. Note: For separate synchronization mode only.
|
vid_h | Output | Clocked video horizontal blanking
signal. This signal is asserted during the horizontal blanking period of
the video stream. Note: For separate synchronization mode only.
|
vid_h_sync | Output | Clocked video horizontal
synchronization signal. This signal is asserted during the horizontal
synchronization period of the video stream. Note: For separate synchronization mode only.
|
vid_ln | Output | Clocked video line number signal.
Used with the SDI IP core to indicate the current line number when the
vid_trs signal is asserted. Note: For embedded synchronization mode only.
|
vid_mode_change | Output | Clocked video mode change signal. This signal is asserted on the cycle before a mode change occurs. |
vid_std | Output | Video standard bus. Can be connected to the tx_std signal of the SDI IP core (or any other interface) to read from the Standard register. |
vid_trs | Output | Clocked video time reference signal
(TRS) signal. Used with the SDI IP core to indicate a TRS, when
asserted. Note: For embedded synchronization mode only.
|
vid_v | Output | Clocked video vertical blanking
signal. This signal is asserted during the vertical blanking period of
the video stream. Note: For separate synchronization mode only.
|
vid_v_sync | Output | Clocked video vertical
synchronization signal. This signal is asserted during the vertical
synchronization period of the video stream. Note: For separate synchronization mode only.
|
vcoclk_div | Output | A divided down version of vid_clk (vcoclk). Setting the Vcoclk
Divider register to be the number of samples in a line
produces a horizontal reference on this signal. A PLL uses this
horizontal reference to synchronize its output clock. Note: Present only if you turn on Use control port.
|
vid_sof | Output | Start of frame signal. A rising edge
(0 to 1) indicates the start of the video frame as configured by the SOF
registers. Note: Present only if you turn on Use control port.
|
vid_sof_locked | Output | Start of frame locked signal. When
asserted, the vid_sof signal is valid
and can be used. Note: Present only if you turn on Use control port.
|
sof | Input | Start of frame signal. A rising edge
(0 to 1) indicates the start of the video frame as configured by the SOF
registers. Connecting this signal to a CVI IP core allows the output
video to be synchronized to this signal. Note: Present only if you turn on Accept synchronization inputs.
|
sof_locked | Input | Start of frame locked signal. When
asserted, the sof signal is valid and
can be used. Note: Present only if you turn on Accept synchronization inputs.
|
sdi_cvo_rden | Input | This signal connects to the SDI II IP core's
tx_dataout_valid output signal. This signal
indicates to the CVO II IP core to advance the state of the clocked
video data and attributes. Note: This signal is only available when you
select the Embedded in video option for the
Sync signals parameter. It will not be
present for external sync interfaces such as DisplayPort and
HDMI.
|
Signal | Direction | Description |
---|---|---|
av_address | Input |
control slave port Avalon-MM address bus. Specifies a word
offset into the slave address space. Note: Present only if you turn on Use control port.
|
av_read | Input |
control slave port Avalon-MM read signal. When you assert
this signal, the control port drives
new data onto the read data bus. Note: Present only if you turn on Use control port.
|
av_readdata | Output |
control slave port Avalon-MM read data bus. These output
lines are used for read transfers. Note: Present only if you turn on Use control port.
|
av_waitrequest | Output |
control slave port
Avalon-MM wait request bus. This signal indicates that the slave is
stalling the master transaction.
Note: Present only if you turn on Use control port.
|
av_write | Input |
control slave port Avalon-MM write signal. When you assert this signal, the control port accepts new data from the
write data bus. Note: Present only if you turn on Use control port.
|
av_writedata | Input |
control slave port Avalon-MM write data bus. These input
lines are used for write transfers. Note: Present only if you turn on Use control port.
|
av_byteenable | Input |
control slave port Avalon-MM byteenable bus. These lines indicate which bytes are
selected for write and read transactions.
|
7.13.2. Clocked Video Output II Parameter Settings
Parameter | Value | Description |
---|---|---|
Image width/Active pixels | 32–8192, Default = 1920 | Specify the image width by choosing the number of active pixels. |
Image height/Active lines | 32–8192, Default = 1200 | Specify the image height by choosing the number of active lines. |
Bits per pixel per color plane | 4–20, Default = 8 | Select the number of bits per pixel (per color plane). |
Number of color planes | 1–4, Default = 3 | Select the number of color planes. |
Color plane transmission format |
|
Specify whether to transmit the color planes in sequence or in parallel. If you select multiple pixels in parallel, then select Parallel. |
Allow output of channels in sequence | On or Off |
|
Number of pixels in parallel | 1, 2, 4, or 8 | Specify the number of pixels
transmitted or received in parallel. Note: Number of pixels in parallel are only supported if
you select On separate wires
for the Sync signals
parameter.
|
Interlaced video | On or Off | Turn off to use progressive video. |
Sync signals |
|
Specify whether to embed the
synchronization signal in the video stream or to provide the
synchronization signal on a separate wire.
|
Support 6G and 12G-SDI | On or Off | Turn
on to enable 6G-SDI or 12G-SDI support for CVO II IP core. Turning on
this option will fix the number of pixels in parallel to 4. Note: This option is available only when you select the
Embedded in video option
for the Sync signals
parameter.
|
Default SDI video standard |
|
Specify
the default SDI video standard. Note: This option is available only when
you select the Embedded in video option for
the Sync signals parameter.
6GB and 12GA options are available only when you turn on the Support 6G and 12G-SDI parameter. |
Active picture line | 32–65536, Default = 0 | Specify the start of active picture line for Frame. |
Frame/Field 1: Ancillary packet insertion line | 32–65536, Default = 0 | Specify the line where ancillary packet insertion starts. |
Embedded syncs only - Frame/Field 1: Horizontal blanking | 32–65536, Default = 0 | Specify the size of the horizontal blanking period in pixels for Frame/Field 1. |
Embedded syncs only - Frame/Field 1: Vertical blanking | 32–65536, Default = 0 | Specify the size of the vertical blanking period in pixels for Frame/Field 1. |
Separate syncs only - Frame/Field 1: Horizontal sync | 32–65536, Default = 44 | Specify the size of the horizontal synchronization period in pixels for Frame/Field 1. |
Separate syncs only - Frame/Field 1: Horizontal front porch | 32–65536, Default = 88 | Specify the size of the horizontal front porch period in pixels for Frame/Field 1. |
Separate syncs only - Frame/Field 1: Horizontal back porch | 32–65536, Default = 148 | Specify the size of the horizontal back porch in pixels for Frame/Field 1. |
Separate syncs only - Frame/Field 1: Vertical sync | 32–65536, Default = 5 | Specify the number of lines in the vertical synchronization period for Frame/Field 1. |
Separate syncs only - Frame/Field 1: Vertical front porch | 32–65536, Default = 4 | Specify the number of lines in the vertical front porch period in pixels for Frame/Field 1. |
Separate syncs only - Frame/Field 1: Vertical back porch | 32–65536, Default = 36 | Specify the number of lines in the vertical back porch in pixels for Frame/Field 1. |
Interlaced and Field 0: F rising edge line | 32–65536, Default = 0 | Specify the line when the rising edge of the field bit occurs for Interlaced and Field 0. |
Interlaced and Field 0: F falling edge line | 32–65536, Default = 0 | Specify the line when the falling edge of the field bit occurs for Interlaced and Field 0. |
Interlaced and Field 0: Vertical blanking rising edge line | 32–65536, Default = 0 | Specify the line when the rising edge of the vertical blanking bit for Field 0 occurs for Interlaced and Field 0. |
Interlaced and Field 0: Ancillary packet insertion line | 32–65536, Default = 0 | Specify the line where ancillary packet insertion starts. |
Embedded syncs only - Field 0: Vertical blanking | 32–65536, Default = 0 | Specify the size of the vertical blanking period in pixels for Interlaced and Field 0. |
Separate syncs only - Field 0: Vertical sync | 32–65536, Default = 0 | Specify the number of lines in the vertical synchronization period for Interlaced and Field 0. |
Separate syncs only - Field 0: Vertical front porch | 32–65536, Default = 0 | Specify the number of lines in the vertical front porch period for Interlaced and Field 0. |
Separate syncs only - Field 0: Vertical back porch | 32–65536, Default = 0 | Specify the number of lines in the vertical back porch period for Interlaced and Field 0. |
Pixel FIFO size | 32–(memory limit), Default = 1920 | Specify the required FIFO depth in pixels, (limited by the available on-chip memory). |
FIFO level at which to start output | 0–(memory limit), Default = 1919 | Specify the fill level that the FIFO must have reached before the output video starts. |
Video in and out use the same clock | On or Off | Turn on if you want to use the same signal for the input and output video image stream clocks. |
Use control port | On or Off | Turn on to use the optional Avalon-MM control port. |
Generate synchronization outputs | On or Off | When you turn on Use control port, this option becomes available. Turning on this option generates the vid_vcoclk_div, vid_sof, and vid_sof_locked output signals. You can use these signals to generate timing reference signals to synchronize video. |
Accept synchronization inputs | On or Off | When you turn on Generate synchronization outputs, this option becomes available. Turning on this option generates the sof and sof_locked input signals. These signals enable the CVO II IP core to align the synchronization outputs to within 1 line of inputs. |
Set vco_clk_divider increment to pixels in parallel | On or Off | When you turn on Generate synchronization outputs, this
option becomes available. Turning on this option enables you to set
vco_clk_divider to increment in 2
different modes:
|
Low latency mode | 0–1, Default = 0 |
|
Run-time configurable video modes | 1–13, Default = 1 | Specify the number of run-time
configurable video output modes that are required when you are using the
Avalon-MM control port. Note: This parameter is available only when you turn on
Use control port.
|
Width of vid_std bus |
External sync: 1–16, Default = 1 Embedded sync: 3, Default = 3 |
Select the width of the vid_std bus, in bits. |
7.13.3. Clocked Video Output II Control Registers
Address | Register | Description |
---|---|---|
0 | Control |
|
1 | Status |
|
2 | Interrupt | Bits 9 and 8 are the interrupt status bits:
|
3 | Video Mode Match | Before any user specified modes are matched, this
register reads back 0 indicating the default values are selected.
Once a match has been made, the register reads back in a one-hot
fashion, e.g. 0x0001=Mode0 0x00020=Mode5 |
4 | Bank Select | Writes to the ModeN registers will be reflected to the mode
bank selected by this register. Up to 13 banks are available depending on parameterization. Selection is by standard binary encoding. |
5 | ModeN Control | Video ModeN 1 Control.
|
6 | ModeN Sample Count | Video mode N sample count. Specifies the active picture width of the field. |
7 | ModeN F0 Line Count | Video mode N field 0/progressive line count. Specifies the active picture height of the field. |
8 | ModeN F1 Line Count | Video mode N field 1 line count (interlaced video only). Specifies the active picture height of the field. |
9 | ModeN Horizontal Front Porch | Video mode N horizontal front porch. Specifies the length of the horizontal front porch in samples. |
10 | ModeN Horizontal Sync Length | Video mode N horizontal synchronization length. Specifies the length of the horizontal synchronization length in samples. |
11 | ModeN Horizontal Blanking | Video mode N horizontal blanking period. Specifies the length of the horizontal blanking period in samples. |
12 | ModeN Vertical Front Porch | Video mode N vertical front porch. Specifies the length of the vertical front porch in lines. |
13 | ModeN Vertical Sync Length | Video mode 1 vertical synchronization length. Specifies the length of the vertical synchronization length in lines. |
14 | Mode1 Vertical Blanking | Video mode N vertical blanking period. Specifies the length of the vertical blanking period in lines. |
15 | ModeN F0 Vertical Front Porch | Video mode N field 0 vertical front porch (interlaced video only). Specifies the length of the vertical front porch in lines. |
16 | ModeN F0 Vertical Sync Length | Video mode N field 0 vertical synchronization length (interlaced video only). Specifies the length of the vertical synchronization length in lines. |
17 | ModeN F0 Vertical Blanking | Video mode N field 0 vertical blanking period (interlaced video only). Specifies the length of the vertical blanking period in lines. |
18 | ModeN Active Picture Line | Video mode N active picture line. Specifies the line number given to the first line of active picture. |
19 | ModeN F0 Vertical Rising | Video mode N field 0 vertical blanking rising edge. Specifies the line number given to the start of field 0's vertical blanking. |
20 | ModeN Field Rising | Video mode N field rising edge. Specifies the line number given to the end of Field 0 and the start of Field 1. |
21 | ModeN Field Falling | Video mode N field falling edge. Specifies the line number given to the end of Field 0 and the start of Field 1. |
22 | ModeN Standard | The value output on the vid_std signal. |
23 | ModeN SOF Sample | Start of frame sample register. The sample and
subsample upon which the SOF occurs (and the vid_sof signal triggers):
|
24 | ModeN SOF Line | SOF line register. The line upon which the SOF occurs
measured from the rising edge of the F0 vertical sync.
This is a 13-bit register. |
25 | ModeN Vcoclk Divider | Number of cycles of vid_clk (vcoclk)
before vcoclk_div signal triggers.
This is a 14-bit register. |
26 | ModeN Ancillary Line | The line to start inserting ancillary data packets. |
27 | ModeN F0 Ancillary Line | The line in field F0 to start inserting ancillary data packets. |
28 | ModeN H-Sync Polarity | Specify positive or negative polarity for the
horizontal sync.
|
29 | ModeN V-Sync Polarity | Specify positive or negative polarity for the vertical
sync.
|
30 | ModeN Valid | Video mode valid. Set to indicate that this mode is valid and can be used for video output. |
To ensure the vid_f signal rises at the Field 0 blanking period and falls at the Field 1, use the following equations:
- F rising edge line ≥ Vertical blanking rising edge line
- F rising edge line < Vertical blanking rising edge line + (Vertical sync + Vertical front porch + Vertical back porch)
- F falling edge line < active picture line
7.14. Clocked Video Input Signals, Parameters, and Registers
7.14.1. Clocked Video Input Interface Signals
Signal | Direction | Description |
---|---|---|
rst | Input | The IP core asynchronously resets when you assert this signal. You must deassert this signal synchronously to the rising edge of the clock signal. |
is_clk | Input | Clock signal for Avalon-ST ports dout and control. The IP core operates on the rising edge of the is_clk signal. |
is_data | Output | dout port Avalon-ST data bus. This bus enables the transfer of pixel data out of the IP core. |
is_eop | Output | dout port Avalon-ST endofpacket signal. This signal is asserted when the IP core is ending a frame. |
is_ready | Input | dout port Avalon-ST ready signal. The downstream device asserts this signal when it is able to receive data. |
is_sop | Output | dout port Avalon-ST startofpacket signal. This signal is asserted when the IP core is starting a new frame. |
is_valid | Output | dout port Avalon-ST valid signal. This signal is asserted when the IP core produces data. |
overflow | Output | Clocked video overflow signal. A signal
corresponding to the overflow sticky bit of the
Status register synchronized to
vid_clk. This signal is for information only and
no action is required if it is asserted.
Note: Present only if you turn on
Use control port.
|
refclk_div | Output | A single cycle pulse in-line with the rising edge of the h sync. |
sof | Output | Start of frame signal. A change of 0 to 1 indicates the start of the video frame as configured by the SOF registers. Connecting this signal to a CVO IP core allows the function to synchronize its output video to this signal. |
sof_locked | Output | Start of frame locked signal. When asserted, the sof signal is valid and can be used. |
status_update_int | Output |
control slave port Avalon-MM
interrupt signal. When asserted, the status registers of the IP core have been
updated and the master must read them to determine what has occurred.
Note: Present only if you turn on
Use control port.
|
vid_clk | Input | Clocked video clock. All the video input signals are synchronous to this clock. |
vid_data | Input | Clocked video data bus. This bus enables the transfer of video data into the IP core. |
vid_datavalid | Input | Clocked video data valid signal. Assert this signal when a valid sample of video data is present on vid_data. |
vid_f | Input | Clocked video field signal. For interlaced
input, this signal distinguishes between field 0 and field 1. For progressive
video, you must deassert this signal.
Note: For separate synchronization mode only.
|
vid_h_sync | Input | Clocked video horizontal synchronization
signal. Assert this signal during the horizontal synchronization period of the
video stream.
Note: For separate synchronization mode only.
|
vid_hd_sdn | Input | Clocked video color plane format selection signal. This
signal distinguishes between sequential (when low) and parallel (when
high) color plane formats. Note: For run-time switching of color plane transmission
formats mode only.
|
vid_v_sync | Input | Clocked video vertical synchronization signal.
Assert this signal during the vertical synchronization period of the video
stream.
Note: For separate synchronization mode only.
|
vid_locked | Input | Clocked video locked signal. Assert this signal
when a stable video stream is present on the input. Deassert this signal when
the video stream is removed.
CVO II IP core: When 0 this signal is used to reset the vid_clk clock domain registers, it is synchronized to the vid_clk internally so no external synchronization is required. |
vid_std | Input | Video standard bus. Can be connected to the rx_std signal of the SDI IP core (or any other interface) to read from the Standard register. |
vid_de | Input | This signal is asserted when you turn on Add data enable signal. This signal indicates the active picture region of an incoming line. |
Signal | Direction | Description |
---|---|---|
av_address | Input |
control slave port Avalon-MM address bus. Specifies a word
offset into the slave address space. Note: Present only if you turn on Use control port.
|
av_read | Input |
control slave port Avalon-MM read signal. When you assert
this signal, the control port drives
new data onto the read data bus. Note: Present only if you turn on Use control port.
|
av_readdata | Output |
control slave port Avalon-MM read data bus. These output
lines are used for read transfers. Note: Present only if you turn on Use control port.
|
av_write | Input |
control slave port Avalon-MM write signal. When you assert this signal, the control port accepts new data from the
write data bus. Note: Present only if you turn on Use control port.
|
av_writedata | Input |
control slave port Avalon-MM write data bus. These input
lines are used for write transfers. Note: Present only if you turn on Use control port.
|
7.14.2. Clocked Video Input Parameter Settings
Parameter | Value | Description |
---|---|---|
Bits per pixel per color plane | 4–20, Default = 8 | Select the number of bits per pixel (per color plane). |
Number of color planes | 1–4, Default = 3 | Select the number of color planes. |
Color plane transmission format |
|
Specify whether to transmit the color planes in sequence or in parallel. |
Field order |
|
Specify the field to synchronize first when starting or stopping the output. |
Sync signals |
|
Specify whether to embed the synchronization signal in the video stream or provide on a separate wire. |
Add data enable signal | On or Off | Turn on if you want to use the data enable signal, vid_de. This option is only available if you choose the DVI 1080p60 preset. |
Allow color planes in sequence input | On or Off | Turn on if you want to allow run-time switching between sequential and parallel color plane transmission formats. The format is controlled by the vid_hd_sdn signal. |
Use vid_std bus | On or Off | Turn on if you want to use the video standard, vid_std. |
Width of vid_std bus | 1–16, Default = 1 | Select the width of the vid_std bus, in bits. |
Extract ancillary packets | On or Off | Select on to extract the ancillary packets in embedded sync mode. |
Interlaced or progressive |
|
Specify the format to be used when no format is automatically detected. |
Width | 32–2600, Default = 1920 | Specify the image width to be used when no format is automatically detected. |
Height – frame/field 0 | 32–2600, Default = 1080 | Specify the image height to be used when no format is automatically detected. |
Height – field 1 | 32–1300, Default = 480 | Specify the image height for interlaced field 1 to be used when no format is automatically detected. |
Pixel FIFO size | 32–(memory limit), Default = 1920 | Specify the required FIFO depth in pixels, (limited by the available on-chip memory). |
Video in and out use the same clock | On or Off | Turn on if you want to use the same signal for the input and output video image stream clocks. |
Use control port | On or Off | Turn on to use the optional stop/go control port. |
Generate synchronization outputs |
|
Specifies whether the Avalon-ST output and
synchronization outputs (sof,
sof_locked,
refclk_div) are generated:
|
7.14.3. Clocked Video Input Control Registers
Address | Register | Description |
---|---|---|
0 | Control |
|
1 | Status |
|
2 | Interrupt | Bits 2 and 1 are the interrupt status bits:
|
3 | Used Words | The used words level of the input FIFO. |
4 | Active Sample Count | The detected sample count of the video streams excluding blanking. |
5 | F0 Active Line Count | The detected line count of the video streams F0 field excluding blanking. |
6 | F1 Active Line Count | The detected line count of the video streams F1 field excluding blanking. |
7 | Total Sample Count | The detected sample count of the video streams including blanking. |
8 | F0 Total Line Count | The detected line count of the video streams F0 field including blanking. |
9 | F1 Total Line Count | The detected line count of the video streams F1 field including blanking. |
10 | Standard | The contents of the vid_std signal. |
11 | SOF Sample | Start of frame line register. The line upon which the SOF occurs measured from the rising edge of the F0 vertical sync. |
12 | SOF Line | SOF line register. The line upon which the SOF occurs measured from the rising edge of the F0 vertical sync. |
13 | Refclk Divider | Number of cycles of vid_clk (refclk) before refclk_div signal triggers. |
7.15. Clocked Video Output Signals, Parameters, and Registers
7.15.1. Clocked Video Output Interface Signals
Signal | Direction | Description |
---|---|---|
rst | Input | The IP core asynchronously resets when you
assert this signal. You must deassert this signal synchronously to the rising
edge of the clock signal.
Note: When the video in and video out do not use the same clock,
this signal is resynchronized to the output clock to be used in the output
clock domain.
|
is_clk | Input | Clock signal for Avalon-ST ports dout and control. The IP core operates on the rising edge of the is_clk signal. |
is_data | Input | dout port Avalon-ST data bus. This bus enables the transfer of pixel data into the IP core. |
is_eop | Input | dout port Avalon-ST endofpacket signal. This signal is asserted when the downstream device is ending a frame. |
is_ready | Output | dout port Avalon-ST ready signal. This signal is asserted when the IP core function is able to receive data. |
is_sop | Input | dout port Avalon-ST startofpacket signal. Assert this signal when the downstream device is starting a new frame. |
is_valid | Input | dout port Avalon-ST valid signal. Assert this signal when the downstream device produces data. |
underflow | Output | Clocked video underflow signal. A signal
corresponding to the underflow sticky bit of the
Status register synchronized to
vid_clk. This signal is for information only and
no action is required if it is asserted.
Note: Present only if you turn on
Use control port.
|
vcoclk_div | Output | A divided down version of vid_clk (vcoclk). Setting the Vcoclk Divider register to be the number of samples in a line produces a horizontal reference on this signal. A PLL uses this horizontal reference to synchronize its output clock. |
sof | Input | Start of frame signal. A rising edge (0 to 1) indicates the start of the video frame as configured by the SOF registers. Connecting this signal to a CVI IP core allows the output video to be synchronized to this signal. |
sof_locked | Input | Start of frame locked signal. When asserted, the sof signal is valid and can be used. |
status_update_int | Output |
control slave port Avalon-MM
interrupt signal. When asserted, the status registers of the IP core have been
updated and the master must read them to determine what has occurred.
Note: Present only if you turn on
Use control port.
|
vid_clk | Input | Clocked video clock. All the video output signals are synchronous to this clock. |
vid_data | Output | Clocked video data bus. This bus transfers video data into the IP core. |
vid_datavalid | Output | Clocked video data valid signal. Assert this signal when
a valid sample of video data is present on vid_data. Note: This signal is equivalent to the CVI IP
core's vid_de signal.
|
vid_f | Output | Clocked video field signal. For interlaced
input, this signal distinguishes between field 0 and field 1. For progressive
video, this signal is unused.
Note: For separate synchronization mode only.
|
vid_h | Output | Clocked video horizontal blanking signal. This
signal is asserted during the horizontal blanking period of the video stream.
Note: For separate synchronization mode only.
|
vid_h_sync | Output | Clocked video horizontal synchronization
signal. This signal is asserted during the horizontal synchronization period of
the video stream.
Note: For separate synchronization mode only.
|
vid_ln | Output | Clocked video line number signal. Used with the
SDI IP core to indicate the current line number when the
vid_trs signal is asserted.
Note: For embedded synchronization mode only.
|
vid_mode_change | Output | Clocked video mode change signal. This signal is asserted on the cycle before a mode change occurs. |
vid_sof | Output | Start of frame signal. A rising edge (0 to 1) indicates the start of the video frame as configured by the SOF registers. |
vid_sof_locked | Output | Start of frame locked signal. When asserted, the vid_sof signal is valid and can be used. |
vid_std | Output | Video standard bus. Can be connected to the tx_std signal of the SDI IP core (or any other interface) to read from the Standard register. |
vid_trs | Output | Clocked video time reference signal (TRS)
signal. Used with the SDI IP core to indicate a TRS, when asserted.
Note: For embedded synchronization mode only.
|
vid_v | Output | Clocked video vertical blanking signal. This
signal is asserted during the vertical blanking period of the video stream.
Note: For separate synchronization mode only.
|
vid_v_sync | Output | Clocked video vertical synchronization signal.
This signal is asserted during the vertical synchronization period of the video
stream.
Note: For separate synchronization mode only.
|
Signal | Direction | Description |
---|---|---|
av_address | Input |
control slave port Avalon-MM address bus. Specifies a word
offset into the slave address space. Note: Present only if you turn on Use control port.
|
av_read | Input |
control slave port Avalon-MM read signal. When you assert
this signal, the control port drives
new data onto the read data bus. Note: Present only if you turn on Use control port.
|
av_readdata | Output |
control slave port Avalon-MM read data bus. These output
lines are used for read transfers. Note: Present only if you turn on Use control port.
|
av_waitrequest | Output |
control slave port
Avalon-MM wait request bus. When this signal is asserted, the
control port cannot accept new
transactions.
Note: Present only if you turn on Use control port.
|
av_write | Input |
control slave port Avalon-MM write signal. When you assert this signal, the control port accepts new data from the
write data bus. Note: Present only if you turn on Use control port.
|
av_writedata | Input |
control slave port Avalon-MM write data bus. These input
lines are used for write transfers. Note: Present only if you turn on Use control port.
|
7.15.2. Clocked Video Output Parameter Settings
Parameter | Value | Description |
---|---|---|
Select preset to load |
|
Select from a list of preset conversions or use the other fields in the dialog box to set up custom parameter values. If you click Load values into controls, the dialog box is initialized with values for the selected preset conversion. |
Image width/Active pixels | 32–2600, Default = 1920 | Specify the image width by choosing the number of active pixels. |
Image height/Active lines | 32–2600, Default = 1080 | Specify the image height by choosing the number of active lines. |
Bits per pixel per color plane | 4–20, Default = 8 | Select the number of bits per pixel (per color plane). |
Number of color planes | 1–4, Default = 3 | Select the number of color planes. |
Color plane transmission format |
|
Specify whether to transmit the color planes in sequence or in parallel. |
Allow output of color planes in sequence | On or Off | Turn on if you want to allow run-time switching between sequential formats, such as NTSC, and parallel color plane transmission formats, such as 1080p. The format is controlled by the ModeXControl registers. |
Interlaced video | On or Off | Turn on if you want to use interlaced video. If you turn on, set the additional Interlaced and Field 0 parameters. |
Sync signals |
|
Specify whether to embed the synchronization
signal in the video stream or to provide the synchronization signal on a
separate wire.
|
Active picture line | 32–65536, Default = 0 | Specify the start of active picture line for Frame. |
Frame/Field 1: Ancillary packet insertion line | 32–65536, Default = 0 | Specify the line where ancillary packet insertion starts. |
Frame/Field 1: Horizontal blanking | 32–65536, Default = 0 | Specify the size of the horizontal blanking period in pixels for Frame/Field 1. |
Frame/Field 1: Vertical blanking | 32–65536, Default = 0 | Specify the size of the vertical blanking period in pixels for Frame/Field 1. |
Frame/Field 1: Horizontal sync | 32–65536, Default = 60 | Specify the size of the horizontal synchronization period in pixels for Frame/Field 1. |
Frame/Field 1: Horizontal front porch | 32–65536, Default = 20 | Specify the size of the horizontal front porch period in pixels for Frame/Field 1. |
Frame/Field 1: Horizontal back porch | 32–65536, Default = 192 | Specify the size of the horizontal back porch in pixels for Frame/Field 1. |
Frame/Field 1: Vertical sync | 32–65536, Default = 5 | Specify the number of lines in the vertical synchronization period for Frame/Field 1. |
Frame/Field 1: Vertical front porch | 32–65536, Default = 4 | Specify the number of lines in the vertical front porch period in pixels for Frame/Field 1. |
Frame/Field 1: Vertical back porch | 32–65536, Default = 36 | Specify the number of lines in the vertical back porch in pixels for Frame/Field 1. |
Interlaced and Field 0: F rising edge line | 32–65536, Default = 0 | Specify the line when the rising edge of the field bit occurs for Interlaced and Field 0. |
Interlaced and Field 0: F falling edge line | 32–65536, Default = 18 | Specify the line when the falling edge of the field bit occurs for Interlaced and Field 0. |
Interlaced and Field 0: Vertical blanking rising edge line | 32–65536, Default = 0 | Specify the line when the rising edge of the vertical blanking bit for Field 0 occurs for Interlaced and Field 0. |
Interlaced and Field 0: Ancillary packet insertion line | 32–65536, Default = 0 | Specify the line where ancillary packet insertion starts. |
Interlaced and Field 0: Vertical blanking | 32–65536, Default = 0 | Specify the size of the vertical blanking period in pixels for Interlaced and Field 0. |
Interlaced and Field 0: Vertical sync | 32–65536, Default = 0 | Specify the number of lines in the vertical synchronization period for Interlaced and Field 0. |
Interlaced and Field 0: Vertical front porch | 32–65536, Default = 0 | Specify the number of lines in the vertical front porch period for Interlaced and Field 0. |
Interlaced and Field 0: Vertical back porch | 32–65536, Default = 0 | Specify the number of lines in the vertical back porch period for Interlaced and Field 0. |
Pixel FIFO size | 32–(memory limit), Default = 1920 | Specify the required FIFO depth in pixels, (limited by the available on-chip memory). |
FIFO level at which to start output | 0–(memory limit), Default = 1919 | Specify the fill level that the FIFO must have reached before the output video starts. |
Video in and out use the same clock | On or Off | Turn on if you want to use the same signal for the input and output video image stream clocks. |
Use control port | On or Off | Turn on to use the optional Avalon-MM control port. |
Run-time configurable video modes | 1–13, Default = 1 | Specify the number of run-time configurable
video output modes that are required when you are using the Avalon-MM control
port.
Note: This parameter is available only when you turn on
Use control port.
|
Accept synchronization outputs |
|
Specifies whether the synchronization outputs
(sof,
sof_locked) from the CVI IP cores are used:
|
Width of vid_std | 1–16, Default = 1 | Select the width of the vid_std bus, in bits. |
7.15.3. Clocked Video Output Control Registers
Address | Register | Description |
---|---|---|
0 | Control |
|
1 | Status |
|
2 | Interrupt | Bits 2 and 1 are the interrupt status bits:
|
3 | Used Words | The used words level of the output FIFO. |
4 | Video Mode Match | One-hot register that indicates the video mode that is selected. |
5 | ModeX Control | Video Mode 1 Control.
|
6 | Mode1 Sample Count | Video mode 1 sample count. Specifies the active picture width of the field. |
7 | Mode1 F0 Line Count | Video mode 1 field 0/progressive line count. Specifies the active picture height of the field. |
8 | Mode1 F1 Line Count | Video mode 1 field 1 line count (interlaced video only). Specifies the active picture height of the field. |
9 | Mode1 Horizontal Front Porch | Video mode 1 horizontal front porch. Specifies the length of the horizontal front porch in samples. |
10 | Mode1 Horizontal Sync Length | Video mode 1 horizontal synchronization length. Specifies the length of the horizontal synchronization length in samples. |
11 | Mode1 Horizontal Blanking | Video mode 1 horizontal blanking period. Specifies the length of the horizontal blanking period in samples. |
12 | Mode1 Vertical Front Porch | Video mode 1 vertical front porch. Specifies the length of the vertical front porch in lines. |
13 | Mode1 Vertical Sync Length | Video mode 1 vertical synchronization length. Specifies the length of the vertical synchronization length in lines. |
14 | Mode1 Vertical Blanking | Video mode 1 vertical blanking period. Specifies the length of the vertical blanking period in lines. |
15 | Mode1 F0 Vertical Front Porch | Video mode 1 field 0 vertical front porch (interlaced video only). Specifies the length of the vertical front porch in lines. |
16 | Mode1 F0 Vertical Sync Length | Video mode 1 field 0 vertical synchronization length (interlaced video only). Specifies the length of the vertical synchronization length in lines. |
17 | Mode1 F0 Vertical Blanking | Video mode 1 field 0 vertical blanking period (interlaced video only). Specifies the length of the vertical blanking period in lines. |
18 | Mode1 Active Picture Line | Video mode 1 active picture line. Specifies the line number given to the first line of active picture. |
19 | Mode1 F0 Vertical Rising | Video mode 1 field 0 vertical blanking rising edge. Specifies the line number given to the start of field 0's vertical blanking. |
20 | Mode1 Field Rising | Video mode 1 field rising edge. Specifies the line number given to the end of Field 0 and the start of Field 1. |
21 | Mode1 Field Falling | Video mode 1 field falling edge. Specifies the line number given to the end of Field 0 and the start of Field 1. |
22 | Mode1 Standard | The value output on the vid_std signal. |
23 | Mode1 SOF Sample | Start of frame sample register. The sample and
subsample upon which the SOF occurs (and the
vid_sof signal triggers):
|
24 | Mode1 SOF Line | SOF line register. The line upon which the SOF occurs measured from the rising edge of the F0 vertical sync. |
25 | Mode1 Vcoclk Divider | Number of cycles of vid_clk (vcoclk) before vcoclk_div signal triggers. |
26 | Mode1 Ancillary Line | The line to start inserting ancillary data packets. |
27 | Mode1 F0 Ancillary Line | The line in field F0 to start inserting ancillary data packets. |
28 | Mode1 Valid | Video mode 1 valid. Set to indicate that this mode is valid and can be used for video output. |
29 | ModeN Control ... | ... |
F rising edge line ≥ Vertical blanking rising edge line
F rising edge line < Vertical blanking rising edge line + (Vertical sync + Vertical front porch + Vertical back porch)
F falling edge line < active picture line
8. 2D FIR II IP Core
- Standard FIR mode
- In this mode, the IP core performs 2D finite impulse response filtering (convolution) using matrices of N×M coefficients, where N is a parameterizable number of horizontal taps (1 <= N <= 16) and M is a parameterizable number of vertical taps (1 <= M <= 16).
- You can set the coefficients used by the filter either as fixed parameters at compile time, or as run-time alterable values which you can edit through an Avalon-MM slave interface.
- With suitable coefficients, the filter can perform operations such as sharpening, smoothing, and edge detection.
- Dedicated edge-adaptive sharpening mode
- You can use this mode to sharpen blurred edges in the incoming video.
8.1. 2D FIR Filter Processing
- Kernel creation
An N×M array of input pixels is created around the input pixel at the same position in the input image as the position of the output pixel in the output image. This center pixel has (N-1)/2 pixels to its left and N/2 pixels to its right in the array, and (M-1)/2 lines above it and M/2 lines below it.
When the pixels to the left, right, above, or below the center pixel in the kernel extend beyond the edges of the image, then the filter uses either replication of the edge pixel or full data mirroring, according to the value of a compile time parameter.
- Convolution
Each pixel in the N×M input array is multiplied by the corresponding coefficient in the N×M coefficient array and the results are summed to produce the filtered value.
The 2D FIR Filter II IP core retains full precision throughout the calculation of each filtered value, with all rounding and saturation to the required output precision applied as a final stage.
- Rounding and saturation.
The resulting full precision filtered value as rounded and saturated according the output precision specification
8.2. 2D FIR Filter Precision
- You may parameterize the input data to between 4-20 bits per color per pixel, and the IP core treats this data as unsigned integer data. You may enable optional guard bands at the input to keep the data inside a reduced range of values.
- You may parameterize the coefficient data up to a total width of 32 bits per coefficient. The coefficients may be signed or unsigned and contain up to 24 fractional bits.
- You may parameterize the output data to between 4-20 bits per color per pixel, and the selected output data width may be different from the input data width.
To convert from the full precision result of the filtering to the selected output precision, the IP core first rounds up the value to remove the required number of fraction bits. Then the IP core saturates the value. You may select how many fraction bits should be preserved in the final output using the 2D FIR II parameter editor. As with the input data, the output data is treated as unsigned, so the IP core clips any negative values that result from the filtering to 0. Any values greater than the maximum value that can be represented in the selected number of bits per color per pixel are clipped to this maximum value.
8.3. 2D FIR Coefficient Specification
The 2D FIR Filter IP core requires a fixed point type to be defined for the coefficients. The user-entered coefficients (shown as white boxes in the parameter editor) are rounded to fit in the chosen coefficient fixed point type (shown as purple boxes in the parameter editor).
- In run-time editable coefficient mode, you must enter the desired
coefficient values through an Avalon-MM control slave interface at run time, and the
coefficient values may be updated as often as once per frame. Note: In this mode, the coefficient values will all revert to 0 after every reset, so coefficients must be initialized at least once on start-up.
- To keep the register map as small as possible and to reduce complexity in the hardware, the number of coefficients that are edited at run time is reduced when any of the symmetric modes is enabled.
- If there are T unique coefficient values after symmetry is considered then the register map will contain T addresses into which coefficients should be written, starting at address 7 and finishing at T+ 6.
- Coefficient index 0 (as described in the symmetry section) should be written to address 7 with each successively indexed coefficient written at each following address. The updated coefficient set does not take effect until you issue a write to address 6 - any value may be written to address 6, it is just the action of the write that forces the commit.
- The new coefficient set will then take effect on the next frame after the write to address 6 Note that the coefficient values written to the register map must be in pre-quantized form as the hardware cost to implement quantization on floating point values would be prohibitive.
Coefficient Mode | Description |
---|---|
Fixed Coefficient |
|
Run-time Editable Coefficient |
|
8.4. 2D FIR Filter Symmetry
The 2D FIR IP core supports symmetry modes for coefficient data.
- No symmetry
- Horizontal symmetry
- Vertical symmetry
- Horizontal and vertical symmetry
- Diagonal symmetry
8.4.1. No Symmetry
There are no axes of symmetry in the 2D coefficient array.
The number of horizontal taps (N) and the number of vertical taps (M) may both be even or odd numbers.
If run-time control of the coefficient data is enabled, the register map will include N×M addresses to allow the value of each coefficient to be updated individually. The coefficients are indexed within the register map in raster scan order.
8.4.2. Horizontal Symmetry
There is 1 axis of symmetry across a vertical line through the center tap in the 2D coefficient array.
In this case, the number of vertical taps (M) may be even or odd, but the number of horizontal taps (N) must be even. With horizontal symmetry enabled, there are only ((N+1)/2)×M unique coefficient values, with the remaining values in the array being mirrored duplicates.
With run-time control of the coefficients enabled, the register map only includes addresses to update the ((N+1)/2)×M unique coefficient values, indexed for an example 5×5 array as shown in the figure below.
8.4.3. Vertical Symmetry
There is 1 axis of symmetry across a horizontal line through the center tap in the 2D coefficient array.
In this case, the number of horizontal taps (N) may be even or odd, but the number of vertical taps (M) must be even. With vertical symmetry enabled, there are only N×((M+1)/2) unique coefficient values, with the remaining values in the array being mirrored duplicates.
With run-time control of the coefficients enabled, the register map only includes addresses to update the N×((M+1)/2) unique coefficient values, indexed for an example 5×5 array as shown in the figure below.
8.4.4. Horizontal and Vertical Symmetry
There are 2 axes of symmetry across a horizontal line and a vertical line through the center tap in the 2D coefficient array.
In this case, the number of horizontal taps (N) and the number of vertical taps (M) must be even. With horizontal and vertical symmetry enabled, there are only ((N+1)/2)×((M+1)/2) unique coefficient values, with the remaining values in the array being mirrored duplicates.
With run-time control of the coefficients enabled, the register map only includes addresses to update the ((N+1)/2)×((M+1)/2) unique coefficient values, indexed for an example 5×5 array as shown in the figure below.
8.4.5. Diagonal Symmetry
There are 4 axes of symmetry in the 2D coefficient array across a horizontal line, a vertical line, and 2 diagonal lines through the center tap.
In this case, the number of horizontal taps (N) and the number of vertical taps (M) must be even, and they must have same value (N = M). With diagonal symmetry enabled, there are only Tu = ((N+1)/2) unique coefficient values in either the horizontal or vertical directions, and a total of (Tu*(Tu+1))/2 unique coefficient values.
With run-time control of the coefficients enabled, the register map only includes addresses to update the (Tu *( Tu +1))/2 unique coefficient values, indexed for an example 5×5 array as shown in the figure below.
8.5. Result to Output Data Type Conversion
The conversion is performed in four stages, in the following order:
- Result scaling—scaling is
useful to quickly increase the color depth of the output.
- The available options are a shift of the binary point right –16 to +16 places.
- Scaling is implemented as a simple shift operation so it does not require multipliers.
- Removal of fractional
bits—if any fractional bits exist, you can choose to remove them through these
methods:
- Truncate to integer—fractional bits are removed from the data; equivalent to rounding towards negative infinity.
- Round - Half up—round up to the nearest integer. If the fractional bits equal 0.5, rounding is towards positive infinity.
- Round - Half even—round to the nearest integer. If the fractional bits equal 0.5, rounding is towards the nearest even integer.
- Conversion from signed to
unsigned— if any negative numbers exist in the results and the output type is
unsigned, you can convert to unsigned through these methods:.
- Saturate to the minimum output value (constraining to range).
- Replace negative numbers with their absolute positive value.
- Constrain to range—if any of the results are beyond a specific range, logic to saturate the results to the minimum and maximum output values is automatically added. The specific range is the specified range of the output guard bands, or if unspecified, the minimum and maximum values allowed by the output bits per pixel.
8.6. Edge-Adaptive Sharpen Mode
In edge-adaptive sharpen mode, the 2D FIR II IP core attempts to detect blurred edges and applies a sharpening filter only to the pixels that are determined to be part of a blurred edge.
8.6.1. Edge Detection
You can determine what constitutes a blurred edge by setting upper and lower blur thresholds (either at compile time or as run-time controlled values). The edge detection is applied independently in the horizontal and vertical directions according to the following steps:
- The target pixel is compared to the pixels immediately to the left and right.
- If both differences to the neighboring pixel are less than the upper blur threshold, the edge detection continues. Otherwise, the pixel is considered to be part of an edge that is already sharp enough that does not require further sharpening.
- If the differences to the pixels to the left and right are below the upper blur threshold, the differences between the target pixel and its neighbors 1, 2, and 3 pixels to the left and right are calculated.
- You may configure the range of pixels over which a blurred edge is
detected.
- Setting the Blur search range register to 1 means that only the differences to the neighbors 1 pixel to the left and right are considered.
- Setting the register to 2 increases the search across the 2 neighboring pixels.
- Setting the register to 3 increases it to the full range across all 3 neighbors in each direction.
- If the difference to any of the enabled neighboring pixels is greater than the lower blur threshold, the target pixel is tagged as a horizontal edge. Otherwise, target pixel is considered to be part of an area of flat color and left unaltered.
8.6.2. Filtering
8.6.3. Precision
- The input bits per color plane is maintained at the output.
- The output of the filtering kernel is rounded to the nearest integer (by adding 8 prior to the divide by 16).
- Any negative values are clipped to 0 and any values greater than the maximum value that can be represented in the selected number of bits per color per pixel are clipped to this maximum value.
8.7. 2D FIR Filter Parameter Settings
Parameter | Value | Description |
---|---|---|
Number of color planes | 1, 2, 3, 4 | Select the number of color planes per pixel. |
Color planes transmitted in parallel | On or Off | Select whether to send the color planes in parallel or in sequence (serially). |
Number of pixels in parallel | 1, 2, 4, 8 | Select the number of pixels transmitted per clock cycle. |
4:2:2 video data | On or Off | Turn on if the input data is 4:2:2 formatted, otherwise the data is
assumed to be 4:4:4
formatted. Note: The IP core does not support odd heights or widths
in 4:2:2 mode.
|
Maximum frame width | 32-8192, Default = 1920 | Specify the maximum frame width allowed by the IP core. |
Maximum frame height | 32-8192, Default = 1080 | Specify the maximum frame height allowed by the IP core. |
Input bits per pixel per color plane | 4-20, Default = 8 | Select the number of bits per color plane per pixel at the input. |
Enable input guard bands | On or Off | Turn on to limit the range for each input color plane. |
Lower input guard bands | 0– 2(input bits per
symbol)-1
Default = 0 |
Set the lower range limit to each input color plane. Values beneath this will be clipped to this limit. |
Upper input guard bands | 0– 2(input bits per
symbol)-1
Default = 255 |
Set the upper range limit to each input color plane. Values above this will be clipped to this limit. |
Output bits per pixel per color plane | 4–20, Default = 8 | Select the number of bits per color plane per pixel at the output. |
Enable output guard bands | On or Off | Turn on to limit the range for each output color plane. |
Lower output guard bands | 0– 2(input bits per
symbol)-1
Default = 0 |
Set the lower range limit to each output color plane. Values beneath this will be clipped to this limit. |
Upper output guard bands | 0– 2(input bits per
symbol)-1
Default = 255 |
Set the upper range limit to each output color plane. Values above this will be clipped to this limit. |
Filtering algorithm |
|
Select the preferred FIR mode. |
Enable edge data mirroring | On or Off | Turn on to enable full mirroring of data at frame/field edges. If you do not turn on this feature, the edge pixel will be duplicated to fill all filter taps that stray beyond the edge of the frame/field. |
Vertical filter taps | 1–16, Default = 8 | Select the number of vertical filter taps. |
Horizontal filter taps | 1–16, Default = 8 | Select the number of horizontal filter taps. |
Vertically symmetric coefficients | On or Off | Turn on to specify vertically symmetric coefficients. |
Horizontally symmetric coefficients | On or Off | Turn on to specify horizontally symmetric coefficients. |
Diagonally symmetric coefficients | On or Off | Turn on to specify diagonally symmetric coefficients. |
Blur search range | 1–3, Default = 1 | Select the number of pixels over which a blurred edge may be detected. This option is available only if you select EDGE_ADAPTIVE_SHARPEN. If you enable Run-time control, you may override this value using the Avalon-MM control slave interface at run time. |
Rounding method |
|
Select how fraction bits are treated
during rounding.
|
Use signed coefficients | On or Off | Turn on to use signed coefficient values. |
Coefficient integer bits | 0–16, Default = 1 | Select the number of integer bits for each coefficient value. |
Coefficient fraction bits | 0–24, Default = 7 | Select the number of fraction bits for each coefficient value. |
Move binary point right | –16 to +16, Default = 0 | Specify the number of places to move the binary point to the right prior to rounding and saturation. A negative value indicates a shift to the left. |
Run-time control | On or Off | Turn on to enable coefficient values to be updated at
run-time through the Avalon-MM control slave
interface. Note: When
you turn on this parameter, the Go
bit gets deasserted by default. When you turn off this parameter,
the Go is asserted by
default.
|
Fixed coefficients file (Unused if run-time updates of coefficients is enabled.) | User specified file (including full path to locate the file) | If you do not enable run-time control, you must specify a CSV containing a list of the fixed coefficient values. |
Default upper blur limit (per color plane) | 0– 2(input bits per
symbol)-1
Default = 0 |
Sets the default upper blur threshold for blurred edge
detection. This option is available only if you select EDGE_ADAPTIVE_SHARPEN. If you enable Run-time control, you may override this value using the Avalon-MM control slave interface at run time. |
Default lower blur limit (per color plane) | 0– 2(input bits per
symbol)-1
Default = 0 |
Sets the default lower blur threshold for blurred edge
detection. This option is available only if you select EDGE_ADAPTIVE_SHARPEN. If you enable Run-time control, you may override this value using the Avalon-MM control slave interface at run time. |
Reduced control register readback | On or Off | If you turn on this parameter, the
values written to register 3 and upwards cannot be read back through the
control slave interface. This option reduces ALM usage. If you do not turn on this parameter, the values of all the registers in the control slave interface can be read back after they are written. |
How user packets are handled |
|
|
Add extra pipelining registers | On or Off | Turn on to add extra pipeline stage
registers to the data path. You must to turn on this option to
achieve:
|
Video no blanking | On or Off | Turn on if the input video does not contain vertical blanking at its point of conversion to the Avalon-ST video protocol. |
8.8. 2D FIR Filter Control Registers
Address | Register | Description |
---|---|---|
0 | Control | Bit 0 of this register is the Go bit, all other bits are unused. Setting this bit to 0
causes the IP core to stop at the end of the next frame/field packet.
When you enable run-time control, the Go bit gets deasserted by default. If you do not enable run-time control, the Go is asserted by default. |
1 | Status | Bit 0 of this register is the Status bit, all other bits are unused. The IP core sets this address to 0 between frames. The IP core sets this address to 1 when it is processing data and cannot be stopped. |
2 | Interrupt | This bit cannot be used because the IP core does not generate any interrupts. |
3 | Blur search range | Set this register to 1, 2, or 3 to override the default parameter setting for the edge detection range in edge-adaptive sharpen mode. |
4 | Lower blur threshold | This register updates the value of the lower blur threshold used in edge detection in edge-adaptive sharpen mode. |
5 | Upper blur threshold | This register updates the value of the upper blur threshold used in edge detection in edge-adaptive sharpen mode. |
6 | Coefficient commit | Writing any value to this register causes the coefficients currently in addresses 7 to (6+T) to be applied from the start of the next input. |
7–(6+ T) | Coefficient data | Depending on the number of vertical taps, horizontal taps, and symmetry mode, T addresses are allocated to upload the T unique coefficient values required to fill the 2D coefficient array. |
9. Mixer II IP Core
The run-time control is partly provided by an Avalon-MM slave port with registers for the location, and on or off status of each foreground layer. The dimensions of each layer are then specified by Avalon-ST Video control packets.
- Each
foreground
layer
must be driven by a frame buffer or frame reader so that data can be provided at the
correct
time.
- If the Synchronize background to layer 0 parameter is enabled, the input connected to layer 0 is used as the background layer and does not have to be driven by a frame buffer or frame reader.
- If the Synchronize background to layer 0 parameter is disabled, all layers are treated as foreground layers and must be driven by a frame buffer or frame reader.
- Each layer must fit within the dimensions of the background layer.
To display the layers correctly:
- The rightmost edge of each layer (width + X offset) must fit within the dimensions of the background layer.
- The bottom edge of each layer (height + Y offset) must fit within the dimensions of the background layer.
- Supports picture-in-picture mixing and image blending with per-pixel and static value alpha support.
- Supports dynamic changing of location and size of each layer during run time.
- Supports dynamic changing of layers positioning during run time.
- Allows the individual layers to be switched on and off.
- Supports up to 8 pixels in parallel.
- Supports up to 20 inputs.
- Includes built in test pattern generator as background layer if required.
- Supports low-latency mode by using layer 0 as background layer.
The Mixer II IP core reads the control data in two steps at the start of each frame. The buffering happens inside the IP core so that the control data can be updated during the frame processing without unexpected side effects.
- disabled (0),
- active and displayed (1), or
- consumed but not displayed (2)
The IP core processes the non-image data packets of each active foreground layer, displayed or consumed, in a sequential order, layer 1 first. The IP core integrally transmits the non-image data packets from the background layer. The IP core treats the non-image data packets from the foreground layers differently depending on their type.
- Control packets (type 15)— processed to extract the width and height of each layer and are discarded on the fly.
- Other/user packets (types 1–14)—propagated unchanged.
The second step corresponds to the usual behavior of other Video and Image Processing IP cores that have an Avalon-MM slave interface. After the IP core has processed and/or propagated the non-image data packets from the background layer and the foreground layers, it waits for the Go bit to be set to 1 before reading the top left position of each layer.
go = 0; while (true) { status = 0; read_non_image_data_packet_from background_layer(); read_control_first_pass(); // Check layer status (disable/displayed/consumed) for_each_layer layer_id { // process non-image data packets for displayed or consumed layers if (layer_id is not disabled) { handle_non_image_packet_from_foreground_layer(layer_id); } } while (go != 1) wait; status = 1; read_control_second_pass(); // Copies top-left coordinates to internal registers send_image_data_header(); process_frame(); }
9.1. Alpha Blending
- Fixed opaque alpha value
- Static (run-time programmable) value (only when you select the Alpha Blending Enable parameter)
- Per-pixel streaming value (only when you select the InputN alpha channel parameter for InputN)
The valid range of alpha coefficients is 0 to 1, where 1 represents full translucence, and 0 represents fully opaque.
The Mixer II IP core determines the alpha value width based on your specification of the bits per pixel per color parameter. For n-bit alpha values, the coefficients range from 0 to 2 n –1. The model interprets (2 n – 1) as 1, and all other values as (Alpha value/2 n . For example, 8-bit alpha value 255>1, 254>254/256, 253>253/256, and so on.
The value of an output pixel O N , where N ranges from 1 to number of inputs minus 1, is derived from the following recursive formula:
O N = (1 – a N ) p N + a N O N – 1
O0 = (1 – a0) p0 + a0 pbackground ,
where p N is the input pixel for layer N, a N is the alpha value for layer N, and pbackground is the background pixel value.
The Mixer II IP core skips consumed and disabled layers.
9.2. Mixer II Parameter Settings
Parameter | Value | Description |
---|---|---|
Maximum output frame width | 32-8192, Default = 1920 | Specify the maximum image width for the layer background in pixels. |
Maximum output frame height | 32-8192, Default = 1080 | Specify the maximum image height for the layer background in pixels. |
Bits per color sample | 4-20, Default = 8 | Select the number of bits per pixel (per color plane). |
Number of pixels in parallel | 1, 2, 4, 8 | Select the number of pixels transmitted every clock cycle. |
Colorspace (used for background layer) |
|
Select the color space you want to use for the background test pattern layer. |
4:2:2 support | On or Off | Turn on to enable 4:2:2 sampling rate
format for the background test pattern layer.
Turn off to enable 4:4:4 sampling rate. Note: The IP core does not support odd heights or widths
in 4:2:2 mode.
|
Synchronize background to layer 0 | On or Off | Turn on to synchronize the background layer to layer 0
(low-latency mode). Turn off to use the internal Test Pattern Generator as the background layer. |
Layer Position Enable | On or Off | Turn on to enable the layer mapping. Turn off to disable the layer mapping functionality to save gates. |
Number of inputs | 1-20; Default = 4 | Specify the number of inputs to be mixed. |
Alpha Blending Enable (all layers) | On or Off | Turn on to allow the IP core to alpha blend using a run-time programmable register alpha value.. |
InputN alpha channel | On or Off | Turn on to allow the input streams to have an alpha channel. |
Pattern |
|
Select the pattern you want to use for the background test pattern layer. |
R or Y | Default = 0 | If you choose to use
uniform background pattern, specify the individual R'G'B' or Y'Cb'Cr'
values based on the color space you selected. The uniform values match the width of bits per pixel up to a maximum of 16 bits. Values beyond 16 bits are zero padded at the LSBs. |
G or Cb | Default = 0 | |
B or Cr | Default = 0 | |
Register Avalon-ST ready signals | On or Off | Turn on to add pipeline. Adding pipeline increases the fMAX value when required, at the expense of increased resource usage. |
Reduced control register readback | On or Off |
If you turn on this parameter, the values written to register 3 and upwards cannot be read back through the control slave interface. This option reduces ALM usage. If you do not turn on this parameter, the values of all the registers in the control slave interface can be read back after they are written. |
Add extra register stages to data pipeline | 1-20; Default = 0 |
Add extra register stages in the data pipeline to improve timing. Add one register stage every Nth data processing stage where N is the parameter value; setting a value of 0 disables this feature. There are as many data processing stages as there are inputs. |
How user packets are handled |
|
Select whether to allow user packets to be passed through the mixer. |
9.3. Mixer II Control Registers
For efficiency reasons, the Video and Image Processing Suite IP cores buffer a few samples from the input stream even if they are not immediately processed. This implies that the Avalon-ST inputs for foreground layers assert ready high, and buffer a few samples even if the corresponding layer has been deactivated.
Address | Register | Description |
---|---|---|
0 | Control | Bit 0 of this register is the Go bit, all other bits are unused. Setting this bit to 0 causes the IP core to stop the next time control information is read. |
1 | Status | Bit 0 of this register is the Status bit, all other bits are unused. |
2 | Reserved | Reserved for future use. |
3 | Background Width | Change the width of the background layer for the next
and all future frames.
Not available when the Synchronize background to layer 0 parameter is enabled. |
4 | Background Height | Changes the height of the background layer for the next
and all future frames.
Not available when the Synchronize background to layer 0 parameter is enabled. |
5 | Uniform background Red/Y | Specifies the value for R (RGB) or Y (YCbCr). If you
choose to use uniform background pattern, specify the individual R'G'B'
or Y'Cb'Cr' values based on the color space you selected. The uniform values match the width of bits per pixel up to a maximum of 16 bits. The IP core zero-pads values beyond 16 bits at the LSBs. |
6 | Uniform background Green/Cb | Specifies the value for G (RGB) or Cb (YCbCr). If you
choose to use uniform background pattern, specify the individual R'G'B'
or Y'Cb'Cr' values based on the color space you selected. The uniform values match the width of bits per pixel up to a maximum of 16 bits. The IP core zero-pads values beyond 16 bits at the LSBs. |
7 | Uniform background Blue/Cr | Specifies the value for B (RGB) or Cr (YCbCr). If you
choose to use uniform background pattern, specify the individual R'G'B'
or Y'Cb'Cr' values based on the color space you selected. The uniform values match the width of bits per pixel up to a maximum of 16 bits. The IP core zero-pads values beyond 16 bits at the LSBs. |
8+5n | Input X offset n | X offset in pixels from the left edge
of the background layer to the left edge of input n. Note:
n represents the input
number, for example input 0, input 1, and so on.
|
9+5n | Input Y offset n | Y offset in pixels from the top edge
of the background layer to the top edge of input n. Note:
n represents the input
number, for example input 0, input 1, and so on.
|
10+5n | Input control n |
Note:
n represents the input
number, for example input 0, input 1, and so on.
|
11+5n | Layer position n | Specifies the layer mapping
functionality for input n. Available only when
you turn on the Layer Position
Enable parameter. Note:
n represents the input
number, for example input 0, input 1, and so on.
|
12+5n | Static alpha n | Specifies the static alpha value for input n with bit width matching the bits per pixel per color plane
parameter. Available only when you turn on the Alpha Blending Enable parameter. Note:
n represents the input
number, for example input 0, input 1, and so on.
|
9.4. Layer Mapping
The layer positions determine whether an input is mixed in the background (layer 0) through to the foreground (layer N, where N is the number of inputs minus one) in the final output image.
Note: if there are any repeated values within the Layer Position registers (indicating that two inputs are mapped to the same layer), the input with the repeated layer position value will not be displayed and will be consumed.
If you turn off the Layer Position Enable parameter, the Mixer II IP core uses a direct mapping between the ordering of the inputs and the mixing layers. For example, Layer 0 will be mapped to Input 0, Layer 1 to Input 1, and so on.
9.5. Low-Latency Mode
In low-latency mode, the Mixer II IP core synchronizes its operations to the incoming video on layer 0. Each video frame received on layer 0 generates a frame at the IP core's output. The dimensions of the output video matches the dimensions of the input frame.
For layer mapping in low-latency mode, the Mixer II IP core functions in the following behavior:
- If you turn off the Layer Position Enable parameter when the IP core is in low-latency mode, the Mixer II IP core synchronizes its operation to input 0 (for this parameterization, input 0 will be mapped to layer 0).
- If you turn on the Layer Position Enable parameter when the IP core is in low-latency mode, the Mixer IP core synchronizes its operation to the input that is mapped to layer 0 by its Layer position n control register.
10. Clipper II IP Core
You can specify the active region by providing the offsets from each border or a point to be the top-left corner of the active region along with the region's width and height.
The Clipper II IP core handles changing input resolutions by reading Avalon-ST Video control packets. An optional Avalon-MM interface allows the clipping settings to be changed at run time.
10.1. Clipper II Parameter Settings
Parameter | Value | Description |
---|---|---|
Maximum input frame width | 32–8192, Default = 1920 | Specify the maximum frame width of the clipping rectangle for the input field (progressive or interlaced). |
Maximum input frame height | 32–8192, Default = 1080 | Specify the maximum height of the clipping rectangle for the input field (progressive or interlaced). |
Bits per pixel per color sample | 4–20, Default = 8 | Select the number of bits per color plane. |
Number of color planes | 1–4, Default = 2 | Select the number of color planes per pixel. |
Number of pixels in parallel | 1, 2, 4, 8 | Select the number of pixels in parallel. |
Color planes transmitted in parallel | On or Off | Select whether to send the color planes in parallel or serial. If you turn on this parameter, and set the number of color planes to 3, the IP core sends the R’G’B’s with every beat of data. |
Run-time control | On or Off | Turn on if you want to specify clipping offsets using
the Avalon-MM interface.
Note: When
you turn on this parameter, the Go
bit gets deasserted by default. When you turn off this parameter,
the Go is asserted by
default.
|
Clipping method |
|
Specify the clipping area as offsets from the edge of the input area or as a fixed rectangle. |
Left offset | 0–8192, Default = 0 | Specify the x
coordinate for the left edge of the clipping rectangle. 0 is the left
edge of the input area. Note: The left and right offset values must be less than
or equal to the input image width.
|
Top offset | 0–8192, Default = 0 | Specify the y
coordinate for the top edge of the clipping rectangle. 0 is the top edge
of the input area. Note: The top and bottom offset values must be less than
or equal to the input image height.
|
Right offset | 0–8192, Default = 0 | Specify the x
coordinate for the right edge of the clipping rectangle. 0 is the right
edge of the input area. Note: The left and right offset values must be less than
or equal to the input image width.
|
Bottom offset | 0–8192, Default = 0 | Specify the y
coordinate for the bottom edge of the clipping rectangle. 0 is the
bottom edge of the input area. Note: The top and bottom offset values must be less than
or equal to the input image height.
|
Width | 32–8192, Default = 32 | Specify the width of the clipping rectangle. The minimum output width is 32 pixels. |
Height | 32–8192, Default = 32 | Specify the height of the clipping rectangle. The minimum output height is 32 pixels. |
Add extra pipelining registers | On or Off | Turn on this parameter to add extra
pipeline stage registers to the data path. You must turn on this
parameter to achieve:
|
10.2. Clipper II Control Registers
Address | Register | Description |
---|---|---|
0 | Control | Bit 0 of this register is the Go bit, all other bits are unused. Setting this bit to 0
causes the IP core to stop the next time control information is read.
When you enable run-time control, the Go bit gets deasserted by default. If you do not enable run-time control, the Go is asserted by default. |
1 | Status | Bit 0 of this register is the Status bit, all other bits are unused. The Clipper IP core sets this address to 0 between frames. It is set to 1 while the IP core is processing data and cannot be stopped. |
2 | Interrupt | This bit is not used because the IP core does not generate any interrupts. |
3 | Left Offset | The left offset, in pixels, of the
clipping window/rectangle. Note: The left and right offset values must be less than
or equal to the input image width.
|
4 | Right Offset or Width | In clipping window mode, the right
offset of the window. In clipping rectangle mode, the width of the
rectangle. Note: The left and right offset values must be less than
or equal to the input image width.
|
5 | Top Offset | The top offset, in pixels, of the
clipping window/rectangle. Note: The top and bottom offset values must be less than
or equal to the input image height.
|
6 | Bottom Offset or Height | In clipping window mode, the bottom
offset of the window. In clipping rectangle mode, the height of the
rectangle. Note: The top and bottom offset values must be less than
or equal to the input image height.
|
11. Color Plane Sequencer II IP Core
A color pattern is a matrix that defines a pattern of color samples repeating over the length of an image.
- Splits or duplicates a single Avalon-ST Video stream into two or, conversely, combines two input streams into a single stream.
- Supports Avalon-ST Video streams with up to 4 pixels transmitted in parallel. A pixel may contain up to 4 color planes transmitted either in parallel or in sequence but not both
- The input/output color patterns to rearrange the Avalon-ST Video streams between the inputs and outputs may be defined over two pixels, which covers all common use-cases.
11.1. Combining Color Patterns
In this mode of operation, the IP core pulls in two input color patterns (one for each input stream) and arranges to the output stream color pattern in a user-defined way, in sequence or parallel, as long as it contains a valid combination of the input channels. In addition to this combination and rearrangement, color planes can also be dropped.
11.2. Rearranging Color Patterns
11.3. Splitting and Duplicating
In this mode of operation, the IP core arranges the color patterns of video data packets on the output streams in a user-defined way using any of the color planes of the input color pattern.
The color planes of the input color pattern are available for use on either, both, or neither of the outputs. This allows for splitting of video data packets, duplication of video data packets, or a mix of splitting and duplication. The output color patterns are independent of each other, so the arrangement of one output stream's color pattern places no limitation on the arrangement of the other output stream's color pattern.
11.4. Handling of Subsampled Data
- When specifying an input pattern over two pixels, the Color Plane Sequencer II IP core pulls two input pixels from the corresponding input before doing the rearrangement. Hence, you can configure the first pixel of the pattern with color planes "Y" and "Cb" and the second pixel of the pattern with color planes "Y" and "Cr".
- When specifying an output pattern over two pixels, each rearrangement operation produces two output pixels. You may specify different color planes for the first and second pixel of the pattern.
- When using a 2-pixel pattern for input stream 0, the IP core halves the width of the input control packets if the output is using a single-pixel pattern.
- When using a single pixel pattern for input stream 0, the IP doubles the width of the input control packets if the output is using a 2-pixel pattern.
- Control packet widths are not modified when using a single-pixel or a 2-pixel pattern on both sides.
11.5. Handling of Non-Image Avalon-ST Packets
- Avalon-ST Video control packets from input stream 1 are always dropped.
- Avalon-ST Video control packets from input stream 0 may be either propagated or dropped depending on the IP parameterization but the last control packet received before the image packet on input stream 0 is always propagated on all enabled outputs and its width may be altered.
- Input user packets can be dropped or forwarded to either or both outputs.
11.6. Color Plane Sequencer Parameter Settings
Parameter | Value | Description |
---|---|---|
How user packets are handled |
|
|
Add extra pipelining registers | On or Off | Turn on to add extra pipeline stage registers to the data path. |
Bits per color sample | 4-20, Default = 8 | Select the number of bits per color sample. |
Number of inputs | 1 or 2 | Select the number of inputs. |
Number of outputs | 1 or 2 | Select the number of outputs. |
din_n: Add input fifo | On or Off | Turn on if you want to add a FIFO at the input to smooth the throughput burstiness. |
din_n: Input fifo size | 1–128, Default = 8 | Specify the size (in powers of 2) of the input FIFO (in number of input beats). |
din_n: Number of color planes | 1–4, Default = 3 | Select the number of color planes per pixel. |
din_n: Color planes transmitted in parallel | On or Off | Select whether the color planes are in parallel or in sequence (serially). |
din_n: Number of pixels in parallel | 1, 2, 4 | Specify the number of pixels received in parallel (per clock cycle). |
din_n: Specify an input pattern over two pixels | On or Off | Turn on if you want to create an input color pattern using two consecutive input pixels instead of one. |
din_n: Input pattern for pixel 0 | — |
Select a unique symbol name for each color plane of pixel 0. Each symbol may appear only once and must not be reused for pixel 1, or when specifying the color pattern for the other input. |
din_n: Input pattern for pixel 1 | — | Select a unique symbol name for each color plane of pixel 1. This parameter is only available if you turn on Specify an input pattern over two pixels. |
dout_n: Add output fifo | On or Off | Turn on if you want to add a FIFO at the output to smooth the throughput burstiness. |
dout_n: Output fifo size | 1–128, Default = 8 | Specify the size (in powers of 2) of the output FIFO (in number of output beats). |
dout_n: Number of color planes | 1–4, Default = 3 | Select the number of color planes per pixel. |
dout_n: Color planes transmitted in parallel | On or Off | Select whether to transmit the color planes in parallel or in sequence (serially). |
dout_n: Number of pixels in parallel | 1, 2, 4 | Specify the number of pixels transmitted in parallel (per clock cycle). |
dout_n: Propagate user packets from input 0 | — | Select whether user packets from input 0 are propagated through output n. This parameter is only available if you turn on Pass all user packets through to the output(s). |
dout_n: Propagate user packets from input 1 | — | Select whether user packets from input 1 are propagated through output n. This parameter is only available if you turn on Pass all user packets through to the output(s) and Specify an input pattern over two pixels. |
dout_n: Specify an output pattern over two pixels | On or Off | Turn on if you want to create an output color pattern using two consecutive output pixel instead of one. |
dout_n: Output pattern for pixel 0 | — |
Select a valid symbol name for each color plane of pixel 0. The symbol must be defined on one of the input color patterns. |
dout_n: Output pattern for pixel 1 | — | Select a valid symbol name for each color plane of pixel 1. The symbol must be defined on one of the input color patterns. This parameter is only available if you turn on Specify an output pattern over two pixels. |
12. Color Space Converter II IP Core
You can configure this IP core to change conversion values at run time using an Avalon-MM slave interface.
- Provides a flexible and efficient means to convert image data from one color space to another.
- Supports a number of predefined conversions between standard color spaces.
- Allows the entry of custom coefficients to translate between any two three-valued color spaces.
- Supports up to 4 pixels per transmission.
A color space is a method for precisely specifying the display of color using a three-dimensional coordinate system. Different color spaces are best for different devices, such as R'G'B' (red-green-blue) for computer monitors or Y'CbCr (luminance-chrominance) for digital television.
Color space conversion is often necessary when transferring data between devices that use different color space models. For example, to transfer a television image to a computer monitor, you are required to convert the image from the Y'CbCr color space to the R'G'B' color space. Conversely, transferring an image from a computer display to a television may require a transformation from the R'G'B' color space to Y'CbCr.
Different conversions may be required for standard definition television (SDTV) and high definition television (HDTV). You may also want to convert to or from the Y'IQ (luminance-color) color model for National Television System Committee (NTSC) systems or the Y'UV (luminance-bandwidth-chrominance) color model for Phase Alternation Line (PAL) systems.
12.1. Input and Output Data Types
The guard bands specify ranges of values that must never be received by, or transmitted from the IP core. Using output guard bands allows the output to be constrained, such that it does not enter the guard bands.
12.2. Color Space Conversion
You convert between color spaces by providing an array of nine coefficients and three summands that relate the color spaces.
You can set these coefficients and summands at compile time, or you can enable the Avalon-MM slave interface to change them dynamically at run-time.
dout_0 = (A0 × din_0) + (B0 × din_1) + (C0 × din_2) + S0 dout_1 = (A1 × din_0) + (B1 × din_1) + (C1 × din_2) + S1 dout_2 = (A2 × din_0) + (B2 × din_1) + (C2 × din_2) + S2
- Computer B’G’R’ to CbCrY’: SDTV
- CbCrY’: SDTV to Computer B’G’R’
- Computer B’G’R’ to CbCrY’: HDTV
- CbCrY’: HDTV to Computer B’G’R’
- Studio B’G’R’ to CbCrY’: SDTV
- CbCrY’: SDTV to Studio B’G’R’
- Studio B’G’R’ to CbCrY’: HDTV
- CbCrY’: HDTV to Studio B’G’R’
- IQY' to Computer B'G'R'
- Computer B'G'R' to IQY'
- UVY' to Computer B'G'R'
- Computer B'G'R' to UVY'
The values are assigned in the order indicated by the conversion name. For example, if you select Computer B’G’R’ to CbCrY’: SDTV, din_0 = B’, din_1 = G’, din_2 = R’, dout_0 = Cb’, dout_1 = Cr, and dout_2 = Y’.
If the channels are in sequence, din_0 is first, then din_1, and din_2. If the channels are in parallel, din_0 occupies the least significant bits of the word, din_1 the middle bits, and din_2 the most significant bits. For example, if there are 8 bits per sample and one of the predefined conversions inputs B’G’R’, din_0 carries B’ in bits 0–7, din_1 carries G’ in bits 8–15, and din_2 carries R’ in bits 16–23.
12.2.1. Predefined Conversions
Predefined conversions only support unsigned input and output data.
If you select signed input or output data, the predefined conversion produces incorrect results. When using a predefined conversion, the precision of the coefficients and summands must still be defined.
Predefined conversions are only defined for input and output bits per pixel per color plane equal to 8, 10, and 12. You must manually scale the summands accordingly when using a different bits per color plane value. If you use different input and output bits per pixel per color plane, you must also shift the results by the correct number of binary places to compensate. For example, to convert from 10-bit CbCrY' to 8-bit Computer B'G'R', select the conversion preset for 10-bit CbCrY' to 10-bit computer B'G'R'. The summands are already scaled for a 10-bit input so they remain unchanged. Change the output bits per color plane value from 10 to 8 on the parameter editor and follow the instructions of the warning message to shift the results by the correct number of binary places (2 places to the left).
12.3. Result of Output Data Type Conversion
This conversion is performed in four stages, in the following order:
- Result scaling—You can
choose to scale up the results, increasing their range. This is useful to
quickly increase the color depth of the output.
- The available options are a shift of the binary point right –16 to +16 places.
- This is implemented as a simple shift operation so it does not require multipliers.
- Removal of fractional
bits—If any fractional bits exist, you can choose to remove them:
- Truncate to integer—Fractional bits are removed from the data. This is equivalent to rounding towards negative infinity.
- Round-half up—Round up to the nearest integer. If the fractional bits equal 0.5, rounding is towards positive infinity.
- Round-half even. Round to the nearest integer. If the fractional bits equal 0.5, rounding is towards the nearest even integer.
- Conversion from signed to
unsigned—If any negative numbers can exist in the results and the output type
is unsigned, you can choose how they are converted:
- Saturate to the minimum output value (constraining to range).
- Replace negative numbers with their absolute positive value.
- Constrain to range—logic that
saturates the results to the minimum and maximum output values is automatically
added:
- If any of the results are not within the minimum and maximum values allowed by the output bits per pixel
- If any of the results are beyond the range specified by the output Guard bands (optional)
12.4. Color Space Converter Parameter Settings
Parameter | Value | Description |
---|---|---|
General | ||
Color planes transmitted in parallel | On or Off | Turn on to transmit the color planes in parallel. |
Number of pixels in parallel | 1, 2, 4, or 8 | Specify the number of pixels transmitted or received in parallel. |
Input data type: Input bits per pixel per color plane | 4–20, Default = 8 | Specify the number of input bits per pixel (per color plane). |
Input data type: Signed | On or Off | Turn to specify the output as signed 2's complement. |
Input data type: Guard bands | On or Off | Turn to use a defined input range. |
Input data type: Max | -524288–1048575, Default = 255 |
Specify the input range maximum value. |
Input data type: Min | -524288–1048575, Default = 0 |
Specify the input range minimum value. |
Output data type: Bits per pixel per color plane | 4–20, Default = 8 | Select the number of output bits per pixel (per color plane). |
Output data type: Signed | On or Off | Turn to specify the output as signed 2's complement. |
Output data type: Guard bands | On or Off | Turn on to enable a defined output range. |
Output data type: Max | -524288–1048575, Default = 255 |
Specify the output range maximum value. |
Output data type: Min | -524288–1048575, Default = 0 |
Specify the output range minimum value. |
How user packets are handled |
|
If you design does not require the IP core to propagate user packets, then you may select to discard all user packets to reduce ALM usage. If your design guarantees there will never be any user packets in the input data stream, then you further reduce ALM usage by selecting No user packets allowed. In this case, the IP core may lock if it encounters a user packet. |
Conversion method | LSB or MSB |
This parameter is enabled when input and output bits per sample per color plane differ and when user packets are propagated. When the propagation of user packets requires padding or truncation,
the IP can do one of the following:
|
Run-time control |
On or Off |
Turn on to enable runtime control of the conversion values. |
Reduced control register readback | On or Off |
If you do not turn on this parameter, the values of all the registers in the control slave interface can be read back after they are written. If you turn on this parameter, the values written to registers 3 and upwards cannot be read back through the control slave interface. This option reduces ALM usage. |
Operands | ||
Coefficient and summand fractional bits | 0–31, Default = 8 | Specify the number of fraction bits for the fixed point type used to store the coefficients and summands. |
Coefficient precision: Signed | On or Off | Turn on to set the fixed point type used to store the constant coefficients as having a sign bit. |
Coefficient precision: Integer bits | 0–16, Default = 1 |
Specifies the number of integer bits for the fixed point type used to store the constant coefficients. |
Summand precision: Signed | On or Off | Turn on to set the fixed point type used to store the constant summands as having a sign bit. |
Summand precision: Integer bits | 0–22, Default = 10 |
Specifies the number of integer bits for the fixed point type used to store the constant summands. |
Coefficients and Summand Table A0, B0, C0, S0 A1, B1, C1, S1 A2, B2, C2, S2 |
12 fixed-point values | Each coefficient or summand is represented by a white cell with a gray cell underneath. The value in the white cell is the desired value, and is editable. The value in the gray cell is the actual value, determined by the fixed-point type specified. The gray cells are not editable. You can create a custom coefficient and summand set by specifying one fixed-point value for each entry. |
Move binary point right | -16 to +16, Default = 0 | Specify the number of places to move the binary point. |
Remove fraction bits by |
|
Select the method of discarding fraction bits resulting from the calculation. |
Convert from signed to unsigned by |
|
Select the method of signed to unsigned conversion for the results. |
12.5. Color Space Conversion Control Registers
The width of each register in the Color Space Conversion control register map is 32 bits. To convert from fractional values, simply move the binary point right by the number of fractional bits specified in the user interface.
The control data is read once at the start of each frame and is buffered inside the IP core, so the registers can be safely updated during the processing of a frame.
Address | Register | Description |
---|---|---|
0 | Control | Bit 0 of this register is the Go bit, all other bits are unused. Setting this bit to 0 causes the IP core to stop the next time control information is read. |
1 | Status | Bit 0 of this register is the Status bit, all other bits are unused. |
2 | Interrupts | Unused. |
3 | Coeff-commit | Writing a 1 to this location commits the writing of coefficient data. You must make this write to swap the coefficients currently in use with the latest set written to the register map. |
4 | Coefficient A0 | The coefficient and summand registers use integer, signed 2’s complement numbers. Refer to Color Space Conversion. |
5 | Coefficient B0 | |
6 | Coefficient C0 | |
7 | Coefficient A1 | |
8 | Coefficient B1 | |
9 | Coefficient C1 | |
10 | Coefficient A2 | |
11 | Coefficient B2 | |
12 | Coefficient C2 | |
13 | Summand S0 | |
14 | Summand S1 | |
15 | Summand S2 |
13. Chroma Resampler II IP Core
The human eye is more sensitive to brightness than tone. Taking advantage of this characteristic, video transmitted in the Y’CbCr color space often subsamples the color components (Cb and Cr) to save on data bandwidth.
The Chroma Resampler II IP core allows you to change between 4:4:4 and 4:2:2 sampling rates where:
- 4:4:4 specifies full resolution in planes 1, 2, and 3 (Y, Cb and Cr respectively)
- 4:2:2 specifies full resolution in plane 1 and half width resolution in planes 2 and 3 (Y, Cb and Cr respectively)
Sampling (4:2:2 to 4:4:4 | Algorithm | ||
---|---|---|---|
Nearest Neighbor | Bilinear | Filtered | |
Upsampling | Yes | Yes | Yes |
Downsampling | Yes | Yes | Yes |
Horizontal Resampling | Yes | No | No |
Vertical Resampling | Yes | No | No |
You can configure the Chroma Resampler II IP core to operate in one of two generalized modes: fixed mode and variable mode.
Fixed mode | Variable mode |
---|---|
|
|
The variable mode is mainly to be use with interface standards, such as HDMI 2.0, which allow color space and subsampling to vary at run time. Because most of the VIP IP cores support only a fixed subsampling (either 4:4:4 or 4:2:2), the Chroma Resampler II IP core is allows a variable-to-fixed conversion (Variable 3 color interface = INPUT) at the input to the processing pipeline, and a fixed-to-variable conversion (Variable 3 color interface = OUTPUT) at the output of the processing pipeline
13.1. Chroma Resampler Algorithms
The Chroma Resampler II IP core supports 3 different resampling algorithms.
- Nearest Neighbor
- Bilinear
- Filtered
13.1.1. Nearest Neighbor
Nearest neighbor is the lowest quality resampling algorithm, with the lowest device resource usage.
- For horizontal downsampling (4:4:4 to 4:2:2), it simply drops every other Cb and Cr sample.
- For horizontal upsampling (4:2:2 to 4:4:4), it simply repeats each Cb and Cr sample.
- For vertical downsampling (4:2:2 to 4:2:0) the chroma data from every other video line is discarded.
- For vertical upsampling (4:2:0 to 4:2:2) the chroma data is repeated for two lines of luma data.
13.1.2. Bilinear
The bilinear algorithm offers a middle point between visual image quality and device resource cost.
The figure and equations below show how the Chroma Resampler II IP core calculates the bilinear resampled chroma for both horizontal and vertical upsampling and downsampling. The bilinear algorithm uses center chroma siting for both the Cb and Cr samples in 4:2:2 format.
13.1.3. Filtered
The filtered algorithm is the most computationally expensive and device resource heavy algorithm, but it offers increased visual quality.
You can parameterize the filtered algorithm to use either left siting (co-siting) or center siting of the chroma data.
- For downsampling conversions (4:4:4 to 4:2:2), the filtered algorithm applies an 8-tap Lanczos-2 resampling filter to generate the downsampled data. Different phase shifts are applied to the Lanczos-2 function when generating the coefficients, depending on the siting selected and whether the pixel index is even or odd. For left chroma siting, phase shifts of 0 and 0.5 are applied to the Lanczos-2 coefficients for the,even and odd indexed chroma samples respectively. For center chroma siting, the phases shifts are –0.25 and +0.25.
- For upsampling conversions (4:2:2 to 4:4:4), the filtered algorithm applies a 4-tap Lanczos-2 resampling filter to generate the upsampled data. For left chroma siting phase shifts of 0 and 0.5 are applied to the Lanczos-2 coefficients for the even and odd indexed chroma samples respectively. For center chroma siting the phases shifts are -0.25 and +0.25.
You may also opt to enable luma adaption for upsampling conversions. This feature further increases device resource usage (and is the only chroma resampler mode to implement some logic in DSP blocks), but may reduce color bleed around edges when compared to the default filtered algorithm.
When you enable luma adaption, the differences between successive luma samples are computed and compared to an edge threshold to detect significant edges. In areas where edges with strong vertical components are detected the phase of the Lanczos-2 filter can be shifted by up to 0.25 to the left or right to weight the resulting chroma samples more heavily towards the more appropriate side of the edge.
13.2. Chroma Resampler Parameter Settings
Parameter | Value | Description |
---|---|---|
Horizontal resampling algorithm |
|
Select the horizontal resampling algorithm to be used. |
Horizontal chroma siting |
|
Select the
horizontal
chroma siting to be used. This option is only available for the filtered algorithm. The nearest neighbor algorithm forces left siting and bilinear algorithm forces center siting. |
Enable horizontal luma adaptive resampling | On or Off | Turn on to enable
horizontal
luma-adaptive resampling. The parameter is only available for filtered upsampling. |
Vertical resampling algorithm |
|
Select the vertical resampling algorithm to be used. |
Vertical chroma siting |
|
Select
the vertical chroma siting to be used. This option is only available for the filtered algorithm. The nearest neighbor algorithm forces top siting and bilinear algorithm forces center siting. |
Enable vertical luma adaptive resampling | On or Off | Turn on to enable vertical luma-adaptive resampling. The parameter is only available for filtered upsampling. |
Maximum frame width | 32–8192, Default = 1920 | Specify the maximum frame width allowed by the IP core. |
Maximum frame height | 32–8192, Default = 1080 | Specify the maximum frame height allowed by the IP core. |
How user packets are handled |
|
|
Add extra pipelining registers | On or Off | Turn on to add extra pipeline stage
registers to the data path. You must to turn on this
option to achieve:
|
Bits per color sample | 4–20, Default = 8 | Select the number of bits per color plane per pixel. |
Number of color planes | 1–4, Default = 2 | Select the number of color planes per pixel. |
Color planes transmitted in parallel | On or Off | Select whether to send the color planes in parallel or in sequence (serially). |
Input pixels in parallel | 1, 2, 4, 8, Default = 1 | Select the number of pixels transmitted per clock cycle on the input interface. |
Output pixels in parallel | 1, 2, 4, 8, Default = 1 | Select the number of pixels transmitted per clock cycle on the output interface. |
Variable 3 color interface |
|
Select which interface uses the variable subsampling 3 color interface. |
Enable 4:4:4 input | On or Off | Turn on to select 4:4:4 format input
data. Note: The input and output formats must be different. A
warning is issued when the same values are selected for both.
|
Enable 4:2:2 input | On or Off | Turn on to select 4:2:2 format input data. Note: The input and output formats must be different. A
warning is issued when the same values are selected for both. The IP
core does not support odd heights or widths in 4:2:2 mode.
|
Enable 4:2:0 input | On or Off | Turn on to select 4:2:0 format input data. Note: The input and output formats must be different. A
warning is issued when the same values are selected for both.
|
Enable 4:4:4 output | On or Off | Turn on to select 4:4:4 format output
data. Note: The input and output formats must be different. A
warning is issued when the same values are selected for both.
|
Enable 4:2:2 output | On or Off | Turn on to select 4:2:2 format output data. Note: The input and output formats must be different. A
warning is issued when the same values are selected for both. The IP
core does not support odd heights or widths in 4:2:2
mode.
|
Enable 4:2:0 output | On or Off | Turn on to select 4:2:0 format output data. Note: The input and output formats must be different. A
warning is issued when the same values are selected for both.
|
13.3. Chroma Resampler Control Registers
Address | Register | Description |
---|---|---|
0 | Control | Bit 0 of this register is the Go bit, all other bits are unused. Setting this bit to 0 causes the IP core to stop at the end of the next frame/field packet. |
1 | Status | Bit 0 of this register is the Status bit, all other bits are unused. The Chroma Resampler II IP core sets this address to 0 between frames. It is set to 1 while the IP core is processing data and cannot be stopped. |
2 | Interrupt | This bit is not used because the IP core does not generate any interrupts. |
3 | Selected subsampling | Control the selected subsampling format on either the input or output interface (whichever is variable). Write 0 to select 4:2:0, 1 for 4:2:2, and 2 for 4:4:4. |
14. Control Synchronizer IP Core
The Control Synchronizer IP core has the following ports:
- Avalon Video Streaming Input and Output port—passes through Avalon-ST Video data, and monitors the data for trigger events.
- Avalon Master port—writes data to the Avalon Slave control ports of other IP cores when the Control Synchronizer IP core detects a trigger event.
- Avalon Slave port—sets the data to be written and the addresses that the data must be written to when the IP core detects a trigger event.
- Avalon Slave Control port—disables or enables the trigger condition. You can configure the IP core before compilation to disable this port after every trigger event; disabling this port is useful if you want the IP core to trigger only on a single event.
The following events trigger the Control Synchronizer IP core:
- the start of a video data packet.
- a change in the width or height field of a control data packet that describes the next video data packet.
When the Control Synchronizer IP core detects a trigger event, the following sequence of events take place:
- The IP core immediately stalls the Avalon-ST video data flowing through the IP core.
- The stall freezes the state of other IP cores on the same video processing data path that do not have buffering in between.
- The IP core then writes the data stored in its Avalon Slave register map to the addresses that are also specified in the register map.
- After writing is complete, the IP core resumes the Avalon-ST video data flowing through it. This ensures that any cores after the Control Synchronizer IP core have their control data updated before the start of the video data packet to which the control data applies.
- When all the writes from a Control Synchronizer IP core trigger are complete, an interrupt is triggered or is initiated, which is the “completion of writes” interrupt.
14.1. Using the Control Synchronizer IP Core
In the following example, the Control Synchronizer IP Core is placed in a system containing the following IP cores:
- Test Pattern Generator II
- Frame Buffer II
- Scaler II
The Control Synchronizer IP core must synchronize a change of the width of the generated video packets with a change to the scaler output size in the following conditions:
- The scaler maintains a scaling ratio of 1:1 (no scaling)
- The frame buffer is configured to drop and repeat making it impossible to calculate packets streamed into the frame buffer and streamed out to the scaler.
- The scaler cannot be configured in advance of a certain video data packet.
The Control Synchronizer IP Core solves the problem through the following sequence of events:
- Sets up the change of video
width.
Figure 51. Change of Video Width
- The test pattern generator changes
the size of its Video Data Packet and Control Data Packet pairs to 320 width. It is
not known when this change will propagate through the frame buffer to the scaler.
Figure 52. Changing Video Width
- The Video Data Packet and Control
Data Packet pair with changed width of 320 propagates through the frame buffer. The
control synchronizer detects the change and triggers a write to the scaler. The
control synchronizer stalls the video processing pipeline while it performs the
write. Figure 53. Test Pattern Generator Change
- The scaler is reconfigured to output
width 320 frames. The control synchronizer resumes the video processing pipeline.
The scaling ratio maintains at 1:1. Figure 54. Reconfigured Scaler II
14.2. Control Synchronizer Parameter Settings
Parameter | Value | Description |
---|---|---|
Bits per pixel per color plane | 4-20, Default = 8 | Select the number of bits per pixel (per color plane). |
Number of color planes | 1–4, Default = 3 | Select the number of color planes that are sent over one data connection. For example, a value of 3 for R'G'B' R'G'B' R'G'B' in serial. |
Color planes are in parallel | On or Off |
|
Trigger on width change | On or Off | Turn on to start transfer of control data when there is a change in width value. |
Trigger on height change | On or Off | Turn on to start transfer of control data when there is a change in height value. |
Trigger on start of video data packet | On or Off | Turn on to start transfer of control data when the core receives the start of video data packet. |
Require trigger reset via control port | On or Off | Turn on to disable the trigger once triggered. If you turn on this parameter, you need to enable the trigger using the control port. |
Maximum number of control data entries | 1–10, Default = 3 | Specify the maximum number of control data entries that can be written to other cores. |
14.3. Control Synchronizer Control Registers
Address | Register | Description |
---|---|---|
0 | Control |
|
1 | Status | Bit 0 of this register is the Status bit, all other bits are unused. |
2 | Interrupt |
Bit 1 of this register is the completion of writes interrupt bit, all other bits are unused. Writing a 1 to bit 1 resets the completion of writes interrupt. |
3 | Disable Trigger |
|
4 | Number of writes | This register sets how many write operations, starting with address and word 0, are written when the control synchronizer triggers. |
5 | Address 0 | Address where word 0 must be written on trigger condition. |
6 | Word 0 | The word to write to address 0 on trigger condition. |
7 | Address 1 | Address where word 1 must be written on trigger condition. |
8 | Word 1 | The word to write to address 1 on trigger condition. |
9 | Address 2 | Address where word 2 must be written on trigger condition. |
10 | Word 2 | The word to write to address 2 on trigger condition. |
11 | Address 3 | Address where word 3 must be written on trigger condition. |
12 | Word 3 | The word to write to address 3 on trigger condition. |
13 | Address 4 | Address where word 4 must be written on trigger condition. |
14 | Word 4 | The word to write to address 4 on trigger condition. |
15 | Address 5 | Address where word 5 must be written on trigger condition. |
16 | Word 5 | The word to write to address 5 on trigger condition. |
17 | Address 6 | Address where word 6 must be written on trigger condition. |
18 | Word 6 | The word to write to address 6 on trigger condition. |
19 | Address 7 | Address where word 7 must be written on trigger condition. |
20 | Word 7 | The word to write to address 7 on trigger condition. |
21 | Address 8 | Address where word 8 must be written on trigger condition. |
22 | Word 8 | The word to write to address 8 on trigger condition. |
23 | Address 9 | Address where word 9 must be written on trigger condition. |
24 | Word 9 | The word to write to address 9 on trigger condition. |
15. Deinterlacer II IP Core
Interlaced video is commonly used in television standards such as phase alternation line (PAL) and national television system committee (NTSC), but progressive video is required by LCD displays and is often more useful for subsequent image processing functions.
- Run-time control and status registers to improve deinterlacing quality for mid-range motion-adaptive configurations
- Run-time control registers to allow run-time switching between bob, weave, and motion adaptive modes.
- Support for pass-through of progressive video at up to 4K resolutions and at a higher number of bits per pixel per color plane
- Integration of a stream cleaner core and embedded chroma resamplers where necessary
15.1. Deinterlacing Algorithm Options
Deinterlacing Algorithm | Quality | DDR Usage | Area | Latency | Film or Cadenced Content | Symbols in Sequence | Native 4K HDR/SDR Passthrough |
---|---|---|---|---|---|---|---|
Vertical Interpolation ("Bob") | Low | None | Low | 1 line | Not supported | Supported | Supported |
Field Weaving ("Weave") | Low | Low | Low | 1 field | Not supported | Supported | Supported |
Motion Adaptive | Medium | Medium | Low | 1 line | 3:2 and 2:2 detect and correct configurable | Not supported | Not supported |
Motion Adaptive High Quality | High | High | High | 1 field and 2 lines | 3:2 with video over film and 2:2 detect and correct configurable | Not supported | Supported |
- Low DDR usage—1 video field is read or written to DDR per output frame generated
- Medium DDR usage—approximately 4 fields of video is read or written to DDR per output frame generated
- High DDR usage—approximately 5 fields of video is read or written to DDR per output frame generated
- Low area—approximately 1–2K ALMs, ≤25 M10Ks, no DSP usage
- High area—approximately 15K ALMs, 44 DSPs
- Low—some blockiness, flickering, or weave artifacts may be seen, depending on the content
- Medium—most content perceived as artifact-free, but some high frequency artifacts will be visible
- High—some tuning and software control may be required using the register set available, and then all content should display well, with minimal artifacts
15.2. Deinterlacing Algorithms
The Deinterlacer II IP core provides four deinterlacing algorithms.
- Vertical Interpolation ("Bob")
- Field weaving ("Weave")
- Motion Adaptive
- Motion Adaptive High Quality (Sobel edge interpolation)
15.2.1. Vertical Interpolation (Bob)
The bob algorithm produces output frames by filling in the missing lines from the current field with the linear interpolation of the lines above and below them.
All color spaces and bits per pixel per color plane are supported.
At the top of an F1 field or the bottom of an F0 field there is only one line available so it is just duplicated. The function only uses the current field, therefore if the output frame rate is the same as the input frame rate, the function discards half of the input fields.
- Produce one frame for every field—interpolations are applied for each incoming field to create a new frame
- Produce one frame for every F0 field or Produce one frame for every F1 field—half the input field rate by producing fields on F0 or F1 according to the selection mode
15.2.2. Field Weaving (Weave)
Weave deinterlacing creates an output frame by filling all of the missing lines in the current field with lines from the previous field.
All color spaces and bits per pixel per color plane are supported.
This option gives good results for still parts of an image but unpleasant artifacts in moving parts. The weave algorithm requires external memory. This makes it significantly more expensive in external RAM bandwidth than the bob algorithms, if external buffering is not otherwise required. However, this option does not require any line buffering, making it the smallest deinterlacer configuration in terms of ALMs used.
15.2.3. Motion Adaptive
Motion Adaptive algorithm avoids the weaknesses of bob and weave algorithms by using bob deinterlacing for moving areas of the image and weave deinterlacing for still area.
All color spaces and bits per pixel per color plane are supported, although a YCbCr color space is used internally for high memory bandwidth configurations with video over film cadence detection.
If the motion computed from the current and the previous pixels is higher than the stored motion value, the stored motion value is irrelevant. The function uses the computed motion in the blending algorithm, which then becomes the next stored motion value. However, if the computed motion value is lower than the stored motion value, the following actions occur:
- The blending algorithm uses the stored motion value.
- The next stored motion value is an average of the computed motion and of the stored motion.
This computed motion means that the motion that the blending algorithm uses climbs up immediately, but takes about four or five frames to stabilize. The motion-adaptive algorithm fills in the rows that are missing in the current field by calculating a function of other pixels in the current field and the three preceding fields as shown in the following sequence:
- Pixels are collected from the
current field and the three preceding it (the X denotes the location of the desired output
pixel). Figure 55. Pixel Collection for the Motion-Adaptive Algorithm
- These pixels are assembled into
two 3×3 groups of pixels. Figure 15–3shows the minimum absolute difference of the two
groups. Figure 56. Pixel Assembly for the Motion-Adaptive Algorithm
- The minimum absolute difference value is normalized into the same range as the input pixel data. The function compares the motion value with a recorded motion value for the same location in the previous frame. If it is greater, the function keeps the new value; if the new value is less than the stored value, the function uses the motion value that is the mean of the two values. This action reduces unpleasant flickering artifacts.
- The function uses a weighted mean
of the interpolation pixels to calculate the output pixel and the equivalent to the output
pixel in the previous field with the following equation:
15.2.4. Motion Adaptive High Quality (Sobel Edge Interpolation)
Motion Adaptive High Quality (Sobel edge interpolation) is the highest quality algorithm, applying a merged bob and weave based upon the amount of motion detected, and in areas of high motion applying a Sobel-based edge detection algorithm to interpolate between two pixels.
- For the pixel being generated, P, in a missing line, N, from the current frame being generated, a kernel of 20 pixels is examined from lines N–3, N–1, N+1 and N+3.
- These 20 pixels are used to generate 7 smaller kernels over which Sobel transforms are performed (two of these are highlighted in yellow and red in the figure above).
- The Sobel transforms produce 7 motion vectors (as indicated by the arrows in the figure above), each comprised of a direction and magnitude.
- The deinterlacer uses this information to make the best possible
interpolation over a wide kernel of 34 pixels taken from lines N-1 and lines N+1.Figure 58. Sobel-based Edge Interpolation
15.3. Run-time Control
Enable run-time control if you require access to the register map.
If you do not select run-time control interface, the Deinterlacer II IP core starts deinterlacing as soon as it receives input video.
15.4. Pass-Through Mode for Progressive Frames
All configurations of the Deinterlacer II IP core support progressive passthrough of up to 1080p resolution. Some configurations support 4K progressive passthrough,
When progressive video passes through, there is no loss of precision or color space conversion internally.
15.5. Cadence Detection (Motion Adaptive Deinterlacing Only)
The Deinterlacer II handles such video sequence by detecting the cadence and reconstructing (reverse pulldown) the original film. This is achieved by comparing each field with the preceding field of the same type (3:2 detection) or detecting possible comb artifacts that occur when weaving two consecutive fields (2:2 detection).
The 3:2 cadence detector tries to detect matches separated by four mismatches. When the 3:2 cadence detector sees this pattern a configurable number of times, it locks. The 3:2 cadence detector unlocks after configurable number of successive mismatches. Locking and unlocking thresholds for the 2:2 cadence detector are similarly configurable.
Refer to the Deinterlacing Control Registers section for more information.
If the incoming video contains any cadenced video, enable the Cadence detection and reverse pulldown option. Then, select the cadence detection algorithm according to the type of content you are expecting. If the incoming video contains both 3:2 and 2:2 cadences, select 3:2 & 2:2 detector.
The cadence detection algorithms are also designed to be robust to false-lock scenarios—for example, features on adjacent fields may trick other detection schemes into detecting a cadence where there is none.
The Deinterlacer II IP core also provides 3:2 & 2:2 detector with video over film option. Select this option to deinterlace correctly the subtitles, credits, or other closed-caption contents that were added over the top of movies or other cadenced contents. Because this feature introduces a field of latency to allow weave operations to be performed either forwards or backwards, also set the Fields buffered prior to output to 1.
15.6. Avalon-MM Interface to Memory
The Deinterlacer II parameter editor calculates the top of the address space based on the configuration chosen.
15.7. Motion Adaptive Mode Bandwidth Requirements
- Image data:
For every pair of output lines produced there are two phases:
Phase 1: Read 2 lines = 1920 × 10 bits x 2 (YCbCr) × 2 = 76,800 bits per input line
Phase 2: Write 1 line, Read 1 line, = 1920 × 10 bits × 2 × 2 = 76,800 bits per input line
Phase 1 + phase 2 accesses = 153,600 bits of image data per input line
153600 × 540 lines = 82,944,000 bits per output frame
82944000 × 60 frames per second = 4,976,640,000 = 4.977 GBps of image data read/written
- Motion data:
Motion data is always 8 bits per pixel regardless of color space.
Read & Write motion = 1920 × 8 bits × 2 (one read and one write) = 30,720 bits per input line
30,720 × 540 lines = 16,588,800 bits per output frame
16,588,800 × 60 frames per second = 995,328,000 = 0.995 GBps of motion data written/read
- Video-over-film data:
Motion data is always 24 bits per pixel regardless of color space.
1920 × 24 bits × 2 (one read and one write per pixel) = 92,160 bits per input line
92,160 × 540 lines = 49,766,400 bits per output frame
49,766,400 × 60 frames per second = 2,985,984,000 = 2.985 GBps of video over film data written/read
Total bandwidth (without video over film cadence detection) = 4.977 + 0.995 = 5.972 GBps
Total bandwidth (with video over film cadence detection) = 5.972 + 2.985 = 8.957 GBps
15.8. Avalon-ST Video Support
Progressive content of all resolutions, including 4K content, will be passed through unchanged.
The Deinterlacer II always passes through user packets. The Deinterlacer II IP core contains an embedded Avalon-ST Stream Cleaner IP core for motion adaptive configurations, which you may disable. It is included to ensure that there is no possibility of malformed input packets locking up the deinterlacer.
You may disable the embedded stream cleaner but this is only recommended if a stream cleaner already exists in the system upstream of the deinterlacer or if you select one of the simpler algorithms (Vertical interpolation (“Bob”) or Field weaving (“Weave”), which have complete resilience to all possible malformed inputs.
15.9. 4K Video Passthrough Support
To determine the best approach for your deinterlacer configuration, refer to the table below.
Deinterlacing Algorithm | Cadence Detection Algorithm | Approach |
---|---|---|
Bob | Not applicable | None — 4K passthrough supported natively |
Weave | Not applicable | None — 4K passthrough supported natively |
Motion adaptive | Any settings | Approach B — 4K passthrough not supported natively; use two Switch II IP instances |
Motion adaptive high quality | 3:2 and 2:2 detector with video over film | Approach A — 4K passthrough supported natively but conversion for fMAX required |
Other settings | Approach B — 4K passthrough not supported natively; use two Switch II IP instances |
15.9.1. Approach A
- The Color Plane Sequencer II IP core converts between 2 and 4 pixels in parallel.
- Dual-clock FIFOs (Avalon-ST Dual Clock FIFO IP core) transfer data with a 50% duty cycle on the Avalon-ST valid signal in a 300MHz clock domain to 100% duty cycle in a 150MHz clock domain.
- The deinterlacer accepts pixels in parallel data and converts any interlaced content to 1 pixel in parallel for deinterlacing.
- Progressive content (and user packets) is maintained at the configured number of pixels in parallel and is unaffected by passing through the deinterlacer.
15.9.2. Approach B
For these configurations, you can use a pair of switches together with appropriate software control to ensure that any 4K content bypasses the deinterlacer.
The software control should operate in the following sequence:
- Upon start up, or on Clocked Video Input loss of lock, the software places
the mixer and the first switch into consume mode.Figure 65. Mixer and First Switch in Consume Mode
In this mode, the frame buffer continues to operate, absorbing any residual frames from the deinterlacer subsystem, and repeating the last valid output frame consumed by the mixer. The mixer produces its background layer. The first switch consumes any frames or fields, or parts of frames or fields from the Clocked Video Input II instance. Therefore, the deinterlacer does not observe any new frames or fields.
- The software continues to monitor the status of the Clocked Video Input II
instance. If the Clocked Video Input instance continues to detect and produce frames with
consistent resolution, the software removes the IP cores from consume mode. The software
then sets the two switches according to the resolution reported by the Clocked Video Input
instance or for 4K progressive video.Figure 66. Without Bypassing the DeinterlacerFigure 67. Bypassing the Deinterlacer for 4K Progressive Video
All Deinterlacer II variants support 1080p passthrough, so progressive resolutions of 1080p or less can either bypass the deinterlacer or not.
Approach B depends on the software control making the necessary switch CSR writes before any video packets reach the switch. The Clocked Video Input instance updates the resolution status registers at the end of the previous frame, so the software loop has a good portion of the vertical blanking interval to configure the video pipe. If little or no blanking is present, the software could insert a 1-line FIFO at the start of the video pipe to allow for the necessary time required. Intel recommends that you place an Avalon-ST Video Stream Cleaner instance after the Clocked Video Input instance.
You can use a software control code similar to the example below for Approach B. In this example, a down-scaler follows the second switch; in lines 66-67 and 91-92 the scaler's status bit detects when all video has been flushed from the pipe. If a scaler is not present, the software may use the status bit for whichever component that follows the second switch for this purpose.
In this code, the following const declarations are assumed:
- VIP_HDMI_CVI_BASE - Address of the Clocked Video Input II
- VIP_CLEANER_BASE - Address of the Avalon-ST Video Stream Cleaner
- VIP_SWI_0_BASE - Address of the first (upstream) Switch II
- VIP_DIL_BASE - Address of the Deinterlacer II
- VIP_SWI_1_BASE - Address of the downstream Switch II
- VIP_SCALE_DOWN_BASE - Address of the down Scaler II
- VIP_VFB_BASE - Address of the triple-buffering Frame Buffer II
- VIP_MIXER_BASE - Address of the Mixer II
Software Control Code
void start_cvi (unsigned int base) { unsigned int CVI_STAT=0; IOWR(base, 0, 1); // Starts the IP Core CVI_STAT=IORD(base, 1); // Read current status if ((CVI_STAT & 0x00000200)!=0) { // check the overflow IOWR(base, 1 , 0x00000200); // Reset the Overflow } } // read the current status of the video input unsigned int current_cvi_status (unsigned int base) { unsigned int current_status; current_status = IORD(base, 1); return current_status; struct image_config { int x; int y; bool interlace; color_info image_color; } //-- Read the current image_config of the video input image_config current_cvi_image_config (unsigned int cvi_base_addr) { image_config current_image_config; unsigned int current_status; unsigned int interlaced_input; unsigned int height_f1; int color_pattern_reg; current_image_config.y = IORD(cvi_base_addr, 5); //-- Using f0 height only current_image_config.x = IORD(cvi_base_addr, 4); current_status = current_cvi_status(cvi_base_addr); interlaced_input = ((current_status & 0x80)>>7); if (interlaced_input) { height_f1 = IORD(cvi_base_addr, 6); current_image_config.y = current_image_config.y + height_f1; // height is f0 + f1 } current_image_config.interlace = interlaced_input; color_pattern_reg = IORD(cvi_base_addr, 14); current_image_config.image_color.space = color_pattern_reg & 0x00FF; current_image_config.image_color.depth = (color_pattern_reg & 0xFF00)>>8; if ( current_image_config.image_color.space==Y420_COLOR_SPACE ) { current_image_config.x = current_image_config.x << 1; // width is halved for 4:2:0 } return current_image_config; } void start_vip_core (unsigned int base) { IOWR(base, 0, 1); } void configure_dil_out_of_pipe() { unsigned int status; status = IORD(VIP_SWI_0_BASE, 1); status = IORD(VIP_SWI_1_BASE, 1); status = IORD(VIP_DIL_BASE, 1); IOWR(VIP_SWI_1_BASE, 0, 0); //Stop SWI0 IOWR(VIP_SWI_0_BASE, 0, 0); //Stop SWI1 //Wait until STATUS reflects STOPPED in the scaler: status = 1; while (status == 1) { status = IORD(VIP_SCALE_DOWN_BASE, 1); } IOWR(VIP_SWI_0_BASE, 4, 1); //SWI0 Output 0 control - ON IOWR(VIP_SWI_0_BASE, 5, 0); //SWI0 Output 1 control - OFF IOWR(VIP_SWI_1_BASE, 4, 1); //SWI1 Output 0 control - outputs from input 0 (passthru) IOWR(VIP_SWI_1_BASE, 0, 1); //Start SWI1 IOWR(VIP_SWI_0_BASE, 0, 1); //Start SWI0 IOWR(VIP_DIL_BASE, 0, 0); //Stop dil } void configure_dil_into_pipe() { unsigned int status; IOWR(VIP_SWI_1_BASE, 0, 0); //Stop SWI0 IOWR(VIP_SWI_0_BASE, 0, 0); //Stop SWI1 //Wait until STATUS reflects STOPPED: status = 1; while (status == 1) { status = IORD(VIP_SCALE_DOWN_BASE, 1); } IOWR(VIP_SWI_0_BASE, 4, 0); //SWI0 Output 0 control - OFF IOWR(VIP_SWI_0_BASE, 5, 1); //SWI0 Output 1 control - ON IOWR(VIP_SWI_1_BASE, 4, 2); //SWI1 Output 0 control - outputs from input 1 (dil) IOWR(VIP_SWI_1_BASE, 0, 1); //Start SWI1 IOWR(VIP_DIL_BASE, 0, 1); //Start dil IOWR(VIP_SWI_0_BASE, 0, 1); //Start SWI0 } int main() { const int NUM_VFB_FRAMES_TO_ABSORB = 10; //Very safe,could be less int vip_pipe_active = 0; image_config prev_cvi_image_config; image_config cvi_image_config; image_config output_image_config; image_config requested_output_image_config; start_vip_core(VIP_HDMI_CVI_BASE); start_vip_core(VIP_CLEANER_BASE); start_vip_core(VIP_DIL_BASE); start_vip_core(VIP_VFB_BASE); start_vip_core(VIP_SCALE_DOWN_BASE); configure_dil_out_of_pipe(); int vfb_frame_counter_prev = 0; int vfb_frame_counter = 0; int vfb_frame_counter_orig = 0; int dil_configured = 0; int cleaned_frames_passed = 0; while(1) { // Always keep a frame count: vfb_frame_counter_prev = vfb_frame_counter; vfb_frame_counter = IORD(VIP_VFB_BASE, 3); prev_cvi_image_config = cvi_image_config; cvi_status = current_cvi_status(VIP_HDMI_CVI_BASE); cvi_image_config = current_cvi_image_config(VIP_HDMI_CVI_BASE); if ( ((cvi_status & 0x00000800)==0) || (cvi_image_config.x != prev_cvi_image_config.x) || (cvi_image_config.y != prev_cvi_image_config.y) || (cvi_image_config.x > UHD_DIM.x) || (cvi_image_config.y > UHD_DIM.y) || (cvi_image_config.image_color.space != prev_cvi_image_config.image_color.space) ) { // The CVI is unlocked or the incoming resolution has changed or resolution // is invalid. Put mixer's VIP pipe input in to consume so that output keeps // running and display is clean. if (vip_pipe_active) { IOWR(VIP_MIXER_BASE, 10, 2); // input 0 consumed // Need to put the first SWI into consume mode too, because we cannot allow any // resolutions >1080p into the dil: IOWR(VIP_SWI_0_BASE, 16, 1); vfb_frame_counter_orig = IORD(VIP_VFB_BASE, 3); } vip_pipe_active = 0; cleaned_frames_passed = 0; dil_configured = 0; } else if (((cvi_status & 0x00000C00) >> 10) == 3) {// CVI locked with valid resolution if (vip_pipe_active == 0) { // Before pipe is started, configure switches: if (!dil_configured) { cvi_image_config = current_cvi_image_config(VIP_HDMI_CVI_BASE); if (cvi_image_config.interlace) { configure_dil_into_pipe(); } else { configure_dil_out_of_pipe(); } // It is safe to take the switch out of consume mode now: IOWR(VIP_SWI_0_BASE, 16, 0); dil_configured = 1; } input_is_4k = (cvi_image_config.x==3840)?1:0; vip_pipe_active = 1; } if (cleaned_frames_passed == 0) { if (vfb_frame_counter != vfb_frame_counter_prev) { if ((vfb_frame_counter - vfb_frame_counter_orig) >= NUM_VFB_FRAMES_TO_ABSORB) { // Mixer path re-enabled after NUM_VFB_FRAMES_TO_ABSORB frames, as cleaned // frames should now be flushed through IOWR(VIP_MIXER_BASE, 10, 1); cleaned_frames_passed = 1; } } } } prev_cvi_image_config = cvi_image_config; } //-- while(1) return 0; }
15.10. Behavior When Unexpected Fields are Received
You can guarantee this behavior through the use of the integrated Avalon-ST Video Stream Cleaner or an external stream cleaner. Some video streams may not follow this rule, and the behavior of the deinterlacer is undefined in such cases.
15.11. Handling of Avalon-ST Video Control Packets
This packet contains the correct frame height and the proper interlace flag so that the following image data packet is interpreted correctly by the following IP cores.
15.12. Deinterlacer II Parameter Settings
Parameter | Value | Description |
---|---|---|
Maximum width of interlaced content | 32–2048, Default = 1920 | Specify the maximum frame width of any interlaced fields. The maximum frame width is the default width at start-up. |
Maximum height of the generated progressive output | 32–1080, Default = 1080 | Specify the maximum progressive frame height in pixels. The maximum frame height is the default progressive height at start-up. |
Disable embedded Avalon-ST Video stream cleaner | On or Off | Turn on this option only if your system can guarantee to always supply well-formed control and video packets of the correct length. |
Number of pixels in parallel | 1, 2, 4, or 8 | Select the number of pixels to be transmitted every clock cycle. |
Bits per color sample | 4–20 | Select the number of bits per pixel (per color plane). |
Number of color planes | 2 or 3 | Select the number of color planes per pixel. |
Color planes transmitted in parallel | On or Off | Select if the Avalon-ST symbols are being transmitted in parallel. |
YCbCr | On or Off | Turn on if you are using YCbCr 4:2:2 data format. |
4:2:2 | On or Off | Turn on if you are using 4:2:2 data
format. Note: 4:2:2 mode does not support odd frame widths and
heights.
|
Deinterlacing algorithm |
|
Select the deinterlacing algorithm you want to use. |
Vertical interpolation ("Bob") deinterlacing behavior |
|
Determines the rate at which frames
are produced and which incoming fields are used to produce them. Note: Only relevant if you set the deinterlacing
algorithm to Vertical interpolation
("Bob").
|
Run-time control | On or Off | Turn on to enable run-time control of
the deinterlacer. When you turn on this parameter, the Go bit gets deasserted by default. When
you turn off this parameter, the Go is
asserted by default. Note:
Intel
strongly recommends run-time control when in motion adaptive modes
with 3:2 & 2:2 detector with video
over film.
|
Cadence detection algorithm and reverse pulldown |
|
Select the cadence detection algorithm you want to use. |
Fields buffered prior to output | 0 or 1, Default = 1 | Either 0 or 1 field is buffered prior to output. You must select 1 field of buffering for video over film cadence detection modes. Other modes incur no fields of latency delay. |
Cadence detection and reverse pulldown | On or Off | Turn on to enable automatic cadence
detection and reverse pulldown. Note: Cadenced content originates from movies or TV
shows. Enable Cadence detection and
reverse pulldown only if this content type is
processed, otherwise disable this feature to save
resources.
|
Avalon-MM master(s) local ports width |
|
Specify the width of the Avalon-MM ports used to access external memory. It is recommended to match this width to the Avalon-MM width of your EMIF controller. |
Use separate clock for the Avalon-MM master interface(s) | On or Off | Turn on to add a separate clock signal for the Avalon-MM master interface(s) so that they can run at a different speed to the Avalon-ST processing. The separation decouples the memory speed from the speed of the data path. Intel expects most applications to use separate Avalon-MM and Avalon-ST clock rates, so make sure this parameter is turned on. |
Base address of storage space in memory | 0–0×7FFFFFFF, Default = 0×00000000 | Select a hexadecimal address of the frame buffers in external memory. |
Top of address space | 0×00ca8000 | For your information only. Top of the deinterlacer address space. Memory above this address is available for other components. |
FIFO depth Write Master | 8–512, Default = 64 | Select the FIFO depth of the Avalon-MM write master interface. |
Av-MM burst target Write Master | 2–256, Default = 32 | Select the burst target for the Avalon-MM write master interface. |
FIFO depth EDI Read Master | 8–512, Default = 64 | Select the FIFO depth of the edge-dependent interpolation (EDI) Avalon-MM read master interface. |
Av-MM burst target EDI Read Master | 2–256, Default = 32 | Select the burst target for EDI Avalon-MM read master interface. |
FIFO depth MA Read Master | 8–512, Default = 64 | Select the FIFO depth of the motion-adaptive (MA) Avalon-MM read master interface. |
Av-MM burst target MA Read Master | 2–256, Default = 32 | Select the burst target for MA Avalon-MM read master interface. |
FIFO depth Motion Write Master | 8–512, Default = 64 | Select the FIFO depth of the motion Avalon-MM write master interface. |
Av-MM burst target Motion Write Master | 2–256, Default = 32 | Select the burst target for the motion Avalon-MM write master interface. |
FIFO depth Motion Read Master | 8–512, Default = 64 | Select the FIFO depth of the motion Avalon-MM read master interface. |
Av-MM burst target Motion Read Master | 2–256, Default = 32 | Select the burst target for motion Avalon-MM read master interface. |
15.13. Deinterlacing Control Registers
Deinterlacer II Control Register Maps
The tables below describe the Deinterlacer II IP core control register map for run-time control. The Deinterlacer II reads the control data once at the start of each frame and buffers the data inside the IP core. The registers may safely update during the processing of a frame. Use these registers in software to obtain the best deinterlacing quality.
Address | Register | RO/RW | Description |
---|---|---|---|
0 | Control | RW | Bit 0 of this register is the
Go bit, all other bits are
unused. Setting this bit to 0 causes the Deinterlacer II IP core to stop the next time that control information is read. When you enable run-time control, the Go bit gets deasserted by default. If you do not enable run-time control, the Go is asserted by default. Power on value: 0 |
1 | Status | RO | Bit 0 of this register is the
Status bit, all other bits are
unused.
Power on value: 0 |
2 | Reserved | – | This register is reserved for future use. |
For motion-adaptive configurations, Intel recommends that you initially retain all values at their reset value, with the exception of the following:
- The Motion Shift and Motion Scale registers may require adjustments to correct for weave artifacts caused by insufficient motion sensitivity. Refer to Tuning Motion Shift and Motion Scale Registers for more information.
- The cadence-related registers in Set A (primarily registers 8 and 9) may require adjustments to correct undetected cadences.
The tables below detail the run-time control registers for the motion adaptive configurations of the Deinterlacer II IP core. Configurations with video-over-film mode enabled use Set B registers, all other configurations use Set A registers.
Address | Register | RO/RW/WO | Width | Description |
---|---|---|---|---|
0 | Go | RW | 32 |
Setting this bit to 0 causes the Deinterlacer II IP core to stop the next time that control information is read. When you enable run-time control, the Go bit gets deasserted by default. If you do not enable run-time control, the Go is asserted by default. Power on value: 0 |
1 | Status | RO | 32 |
Power on value: 0 |
2 | Reserved | – | – | This register is reserved for future use. |
3 | Unused | – | – | Unused |
4 | 3:2 Cadence Diff Count | WO | 8 |
If the IP core could not detect 3:2 cadences, poll this register to facilitate the tuning of 3:2 detection. For
example:
while(1){ pollCount++; if (pollCount%350 == 0) { diffCount = IORD(VIP_DIL_BASE, 4); printf ("Dil diffCount = %0d\n", diffCount);} The register returns the number of lines in the
current field for which a difference is detected compared to the
preceding field. A successfully detected 3:2 cadence generates
output such as the
following:
Dil diffCount = 253 Dil diffCount = 253 Dil diffCount = 0 Dil diffCount = 248 Dil diffCount = 249 Dil diffCount = 244 Dil diffCount = 245 Dil diffCount = 0 Dil diffCount = 240 Dil diffCount = 241 Dil diffCount = 237 Dil diffCount = 239 Dil diffCount = 0 Dil diffCount = 236 Dil diffCount = 235 Dil diffCount = 233 You are required to experiment with the polling rate to poll at a rate of approximately once per field. |
5 | 3:2 Cadence Lock Threshold | WO | 8 |
The higher the threshold value, the more stringent the requirements for the deinterlacer to start performing reverse telecine deinterlacing. You may set lower threshold values for greater sensitivity to cadenced sequences. The default value is 6. |
6 | 3:2 Cadence Unlock Threshold | WO | 8 |
Set this register lower than the 3:2 Cadence Lock Threshold register. The closer the value is to the 3:2 Cadence Lock Threshold register, the less stringent the requirements for the deinterlacer to lose lock and stop performing reverse telecine deinterlacing. The default value is 4. |
7 | 3:2 Cadence Diff Threshold | WO | 8 |
The 3:2 Cadence Diff Count register increments when the “score” from the cadence detector for a line is equal or more than the 3:2 Cadence Diff Threshold register. The default value is 16. |
8 | 3:2 Cadence Diff Line Ratio | WO | 8 |
This register affects the proportion of lines within a field that are required to exhibit a cadence before a 3:2 cadence lock can be achieved. Shift the number of lines using this value: Lines >> 3:2 Cadence Diff ThresholdThe default value is 4. |
9 | 3:2 Cadence Diff Noise Suppresion | WO | 8 |
Use this register to shift the result of difference calculation logic which is used to determine whether a line is being repeated: Diff result >> 3:2 Cadence Diff Noice SuppresionThe default value is 5 to allow resilience against noise in the LSBs masking a cadence relationship. |
10 | 2:2 Cadence Lock Threshold | WO | 4 |
The higher the threshold value, the more stringent the requirements for the deinterlacer to start performing reverse telecine deinterlacing. |
11 | 2:2 Cadence Unlock Threshold | WO | 4 |
Set this register lower than the 2:2 Cadence Lock Threshold register. The closer the value is to the 2:2 Cadence Lock Threshold register, the less stringent the requirements for the deinterlacer to lose lock and stop performing reverse telecine deinterlacing. The default value is 4. |
12 | 2:2 Cadence Comb Threshold | WO | 8 |
A "comb count" for a field increments when the "score" from the 2:2 cadence detector for a line is ≥ 2:2 Cadence Comb Threshold. Its reset value is 16. Decrease this value to increase the deinterlacer's sensitivity to 22 cadences. |
13 | Unused | – | – | Unused |
14 | Motion Shift | WO | 8 |
Specifies the amount of raw motion (SAD) data that is right-shifted. Shifting is used to reduce sensitivity to noise when calculating motion (SAD) data for both "bob" and "weave" decisions and cadence detection. Note: It is very important to set this register
correctly for good deinterlacing performance.
Tune this register in conjunction with the motion visualization feature. Higher values decrease sensitivity to noise when calculating motion, but may start to introduce weave artifacts if the value used is too high. |
15 | Unused | – | – | Unused |
16 | Visualize Motion Values | WO | 3 |
|
Address | Register | RO/RW/WO | Width | Description |
---|---|---|---|---|
0 | Control | RW | 32 |
Bit 0 of this register is the Go bit, all other bits are unused. Setting this bit to 0 causes the Deinterlacer II IP core to stop the next time that control information is read. When you enable run-time control, the Go bit gets deasserted by default. If you do not enable run-time control, the Go is asserted by default. Power on value: 0 |
1 | Status | RO | 32 |
Bit 0 of this register is the Status bit, all other bits are unused.
Power on va |