Agilex‑7 F‑Tile Dynamic Reconfiguration Conflict Between HDMI and SDI RX

Hi etienne_cf ,

To be honest , your setting is little bit customize, I never try this implementation before.
BUT, This does not look like a DR transport/arbiter failure. Based on your symptoms: 

• HDMI works when both are present 
• SDI reconfiguration completes with no reported errors 
• SDI cycles through profiles but never locks 

the most likely issue is a shared F-Tile resource/configuration conflict, not a failure of the DR state machine itself. In other words, the DR writes are probably succeeding, but the resulting shared transceiver/common-resource state is valid for HDMI and not valid for SDI.

From your .qsf
set_global_assignment -name IP_RECONFIG_GROUP_TYPE "VIDEOINPUT0_DR:EXCLUSIVE:SHARED_SIP:CLK_MASTER"
set_global_assignment -name IP_RECONFIG_GROUP_TYPE "VIDEOINPUT1_DR:EXCLUSIVE:CLK_MASTER"

That asymmetry is suspicious if both RXs are truly sharing the same F-Tile resources. 
If HDMI is defined as participating in a shared-SIP topology, but SDI is not, Quartus may allow the build and the DR database may still be generated correctly, yet the tile-level shared resource ownership can still end up inconsistent at runtime.

From what you shows me, i suspect that HDMI and SDI are sharing one F-Tile DR block and common resources, but the QSF does not describe them as one valid, consistent shared-resource topology. because the shared analog/common/clock state is effectively owned or configured in a way that is incompatible with SDI after HDMI initialization.

Please check back 

• mismatched instance path for HDMI IP_COLOCATE
• inconsistent SHARED_SIP usage
• two independent CLK_MASTER groups on one tile

It just my suggestion, I hope it able to help you to narrow down the issue.

Regards,

Wincent_Altera