2.5.3. Top-Level Common Blocks

F-Tile HDMI Intel® FPGA IP Design Example User Guide

Download PDF

ID 709314

Date 6/06/2024

Version

Public

Visible to Intel only — GUID: yvm1637648246690

Ixiasoft

2.5.3. Top-Level Common Blocks

The top-level common blocks include the transceiver arbiter, the RX-TX link components, and the CPU subsystem.

Table 14. Top-Level Common Blocks
Module	Description
RX-TX Link	The video data output and synchronization signals from HDMI RX core loop through a DCFIFO across the RX and TX video clock domains. The auxiliary data port of the HDMI TX core controls the auxiliary data that flow through the DCFIFO through backpressure. The backpressure ensures there is no incomplete auxiliary packet on the auxiliary data port. This block also performs external filtering: Filters the audio data and audio clock regeneration packet from the auxiliary data stream before transmitting to the HDMI TX core auxiliary data port. Filters the High Dynamic Range (HDR) InfoFrame from the HDMI RX auxiliary data and inserts an example HDR InfoFrame to the auxiliary data of the HDMI TX through the Avalon® streaming multiplexer.
CPU Subsystem	The CPU subsystem functions as SCDC and DDC controllers, and source reconfiguration controller. The source SCDC controller contains the I²C master controller. The I²C master controller transfers the SCDC data structure from the FPGA source to the external sink for HDMI 2.0 operation. For example, if the outgoing data stream is 6,000 Mbps, the Nios® V processor commands the I²C master controller to update the `TMDS_BIT_CLOCK_RATIO` and `SCRAMBLER_ENABLE` bits of the sink TMDS configuration register to 1. The same I²C master also transfers the DDC data structure (E-EDID) between the HDMI source and external sink. The Nios® V CPU acts as the reconfiguration controller for the HDMI source. The CPU relies on the periodic rate detection from the RX Reconfiguration Management module to determine if the TX requires reconfiguration. The Avalon® memory-mapped slave translator provides the interface between the Nios® V processor Avalon® memory-mapped master interface and the Avalon® memory-mapped slave interfaces of the externally instantiated HDMI source’s IOPLL and TX PMA Direct PHY. Perform link training through I²C master interface with external sink
IOPLL (vid_clk)	The IOPLL performs the following: Generates the video clock. The reference clock to this IOPLL is 100 MHz clock. Provides fix clock frequency which is 225 MHz.
F-Tile Reference and System PLL Clock	This IP connects the System PLL output clock as well as the Tx PLL and Rx CDR reference clock to the F-tile PMA/FEC Direct PHY IP. System PLL clock output shall always set to run at a higher clock frequency than the native PMA recovered clock. For this design, the clock frequency is 900 MHz. In F-Tile HDMI Intel FPGA IP Design Example, F-Tile Reference and System PLL Clock IP is configured to enable out_coreclk_1 which is driven by Refclk #1 for FGT PMA. The F-Tile Reference and System PLL Clock IP configuration for the reference clock routed to the core feature in this design example is limited only for the HDMI application. For more information about the supported mode and configuration of the IP, refer to the Implementing the F-Tile Reference and System PLL Clocks Intel FPGA IP section of the F-Tile Architecture and PMA and FEC Direct PHY IP User Guide.
Transceiver Reconfig Arbiter	This generic functional block prevents transceivers from simultaneous reconfiguration when either RX or TX transceivers within the same physical channel require reconfiguration. The simultaneous reconfiguration impacts applications where RX and TX transceivers within the same channel are assigned to independent IP implementations. This transceiver arbiter is an extension to the resolution recommended for merging simplex TX and simplex RX into the same physical channel. This transceiver arbiter also assists in merging and arbitrating the Avalon® memory- mapped RX and TX reconfiguration requests targeting simplex RX and TX transceivers within a channel as the dynamic reconfiguration IP can only be accessed sequentially. The interface connection between the transceiver arbiter and dynamic reconfiguration IP in this design example demonstrates a generic mode that applies for any IP combination using the transceiver arbiter. The transceiver arbiter is not required when only either RX or TX transceiver is used in a design. The transceiver arbiter identifies the requester of a reconfiguration through its Avalon® memory-mapped reconfiguration interfaces and ensures that the corresponding reconfig_en[NUM_DR_CH-1:0] is gated accordingly. NUM_DR_CH refers to the number of reconfiguration requesters in the design.
Dynamic Reconfig IP	Dynamic Reconfiguration (DR) IP is facilitated by NIOS. This includes inter-protocol switching or intra protocol link characteristic change such as link width or data rate switching. For these use cases, DR can be triggered by either user application or Quartus NIOS utility. NIOS shall then perform the low level configuration register programming for various functional blocks. HDMI example design using Dynamic Reconfiguration (DR) IP to reconfigure dynamically is a subset of the transceiver channels to operate in different modes (e.g. data rates) without impacting the adjacent active channels.