About Design Limitations and Known Issues
In the "GTS SDI II IP User Guide", section 8. Design Limitations and Known Issues states a known issue: "High bit error rates are observed in recovered data." It also states that there is no workaround in the current version of Quartus, but are there any plans to address this issue? https://www.intel.com/content/www/us/en/docs/programmable/823539/25-3/design-limitations-and-known-issues.htmlAbout Dual Simplex for Agilex 3
In the" GTS Transceiver Dual Simplex Interfaces User Guide: Agilex™ 3 and Agilex™ 5 FPGAs and SoCs", Note 3 in Table 2, Section 2. Overview, states the following: "DS mode is not currently supported for Agilex™ 3 FPGAs for this protocol." Which future version of Quartus Prime will support Agilex 3 ？ https://www.intel.com/content/www/us/en/docs/programmable/825853/25-1/overview.html
Please let me know how to get a GTS license for Agilex 5.
I have already some licenses, for example, IP-SDI-II, IP-DP, IP-HDMI and so on. I want to use these IP on Agilex 5. However, Ordering Code is not match the IPs I have when I searched the IP User Guide. SDI => IP-GTS-SDI-II Display Port => IP-GTS-DP Is it possible to get a License of IP-GTS-xxx, if I regenerate in my SSLC ? Or, Need I buy the new licenses for GTS Transceiver? Thanks.
DisplayPort TX IP Core Link Training Abort
Hi All, we are using the Intel DisplayPort TX IP core on Cyclone 10 GX FPGA and we see link training failures with a certain sink (monitor) of our customer. Using a DP aux channel analyzer, we see that during the test of voltage levels and pre-emphasis, the DP TX core aborts the link training process instantly after about 60 ms. This is caused due to a delay behavior of the sink: Each time, after the DP TX core writes training pattern sets (0x102) or training lane sets (0x103), the sink answers the next 8 source status reads each with AUX_DEFER, until finally providing the requested status. This results in a long duration of the whole link training process, which is aborted by the DP TX core after about 60 ms. Tests of the monitor at a commercial GPUs shows that the link training process takes more than a second until finally succeeds. We have no link training problems with other commercial monitors. Questions: Why does the link training process not complete? We expect that there is some kind of internal timeout within the DP TX core and ask of how we can change this value. We knew that within the sink (monitor) works a Xilinx DP RX IP core, so probably there are pre-known incompatibilities between Intel and Xilinx DisplayPort cores? Note: We use dp tx core version v20.0.1, config without support for DP 1.4 We use quartus pro version 22.3 I attached two aux channel analyzer logs, where the AUX-DEFER packets and the DP TX abort can be seen. I had to compress them to zip due to the forum upload restrictions. Thank you in advance! Stefan
