GPU -> FPGA via DisplayPort Video Interface

[cat416b]

Hi, I am new to FPGAs and looking at sending GPU-generated video data to a FPGA through a DisplayPort video interface. I would like it to eventually support transfer rates of up to 25 Gbits/sec. Any suggestions about FPGA types and add-on cards needed to do this would be greatly appreciated. Ideally, I would like the FPGA to define an EDID so that it essentially acts as a monitor allowing the GPU to be connected directly to it.

Thanks and any information that helps me get started on this project would be great.

[JColvin]

Hi @cat416b,

Digilent does not have any devices with a DisplayPort sink. (The Genesys 2 does have a DisplayPort sink, but the DisplayPort IP since 2015 or so now requires a particular piece of hardware which the Genesys 2 does not have so I would not recommend using the board in this instance) Any development help will be beyond the scope of what the Digilent staff provide here on our Forum.

I would recommend looking for a board that is dedicated towards video applications and supports DisplayPort 1.3 or later (since Wikipedia tells me that is the oldest revision that supports a total data rate of at least 25 Gbit/sec) and ensuring that whatever high speed transceiver data lines that port is connected to can support the appropriate rate.

I do not know if you are intending to use a vendor provided IP or develop your own solution (I imagine you're intending to further process the GPU data on the FPGA/SoC), but this will not be an easy process. It's certainly possible, as one of the primary features of an FPGA is that you can reconfigure it's hardware to suit your needs, high speed applications require precise hardware design to ensure an accurate and stable system (especially one that has a standardized protocol).

Thanks,
JColvin

[zygot]

2 hours ago, JColvin said:

The Genesys 2 does have a DisplayPort sink, but the DisplayPort IP since 2015 or so now requires a particular piece of hardware which the Genesys 2 does not have so I would not recommend using the board in this instance

Could you be more specific? What IP are you referring to? What hardware are you referring to?

The idea of looking for a platform that specifically supports the DisplayPort spec that your GPU supports is a good one. As JColvin hinted at, don't assume that any tool version supports any interface standard for any particular device. Sometimes, IP is used to help sell a new device family or board and then the IP gets depreciated in later tool versions. This happens quite a lot with all programmable logic vendors. The original TRD for the ZCU106 might serves as a good example of this. As far as free FPGA IP goes, "beware of Greeks ( FPGA vendors ) bearing gifts. There's always the 3rd party IP for a price.

Sounds like an interesting project but there are a lot of details that might derail your plans. In general FPGA transceivers are general purpose and IP support for specific standards generally lag with respect to other current hardware. Determining how well such IP supports standard specifications for interfaces like DisplayPort isn't always easy to do.

The Kintex part on the Genesys2 has GTX transceivers capable of 10 Gbps line rates. The DP_IN and DP_OUT each support 4 lanes of transceivers. That doesn't mean that the board is a good platform for implementing a specific display standard for any custom video transport application.

Edited August 4, 2022 by zygot

[JColvin]

On 8/4/2022 at 2:47 PM, zygot said:

Could you be more specific? What IP are you referring to? What hardware are you referring to?

I am referring to Xilinx's DisplayPort Rx Subsystem IP.

As I understand it, when Digilent originally used this IP back in Vivado 2014.4, no retimer (either a TI DP159 Retimer or a  MCDP6000 Retimer based on this Xilinx support thread, though the current IP guide, https://docs.xilinx.com/v/u/en-US/pg233-displayport-rx-subsystem, does not mention the latter option) was required. There was a reference design from Xilinx at one point that did not use TI's Retimer, based on this Forum thread, https://forum.digilent.com/topic/16947-displayport-subsystem-ip-21-on-genesys-2/, though the link to the reference design no longer works as Xilinx no longer supports it and removed the design (https://support.xilinx.com/s/question/0D52E00007FSatySAD/xapp1178-link-to-download?language=en_US).

Thanks,
JColvin

 

[annijonn]

On 8/4/2022 at 10:51 PM, cat416b said:

Hi, I am new to FPGAs and looking at sending GPU-generated video data to a FPGA through a DisplayPort video interface. I would like it to eventually support transfer rates of up to 25 Gbits/sec. Any suggestions about FPGA types and add-on cards needed to do this would be greatly appreciated. Ideally, I would like the FPGA to define an EDID so that it essentially acts as a monitor allowing the GPU to be connected directly to it.

Thanks and any information that helps me get started on this project would be great.

So, you can choose the other option of it, then it will be helpful for you. Sometime when you trying to display video but it create some errors but you can easily fix them

[engi]

On 8/8/2022 at 9:03 PM, JColvin said:

the link to the reference design no longer works as Xilinx no longer supports it and removed the design

Wasn't there an issue with the Transceivers' PLLs and stability in the A7?  I have something in mind like that. Generally DP works with Kintex e.g. (proved)

[zygot]

I've used the 4-lane transceivers connected to mDP ports on an Artix 50T on the Mimas-A7 from Numato Labs for an Aurora interface at 1.35 GHz per lane with no issues. One thing to note is that Xilinx has decided to make connecting certain transceiver applications on Artix incompatible with Kintex versions. I haven't used the mDP transceivers on the Nexys Video but have no reason to doubt that they work.

FPGA vendors offer and then remove IP all the time when it has nothing to do with device functionality or errata.

Edited December 17, 2022 by zygot

[engi]

However strange. Display Port is a valueable thing because free of charge. Maybe this is the reason for removing it? XI offers the HDMI for purchase :-)

 

[zygot]

I've been dealing with programmable logic vendors for a long time. The following is speculation, but perhaps informed speculation. FPGA vendors don't give anything away for free. The first thing that they don't want to do is let customers think that they can use a smaller part or part from a cheaper family to accomplish their goals. So, when they are nice, they just make it hard to use certain device features with cheap parts by either restricting documentation and application notes or making it hard to use their IP with cheaper parts. When they don't feel like being nice, they disable the capability to use a feature in the tools. One example of this is using transceivers for Cyclone V JESD204 applications. They advertise transceivers in Cyclone that can do JESD204. They advertise JESD204 for Cyclone. But I'd be interested if anyone has found a way to actually implement a JESD204 design for Cyclone V using the free IP that comes with Quartus; the tools say nah Stratix only. Transceivers have historically been a feature used to sell more expensive devices. Every Artix device sold has at least 1 transceiver in it. You wouldn't notice reading AMD/Xilinx Application Notes and White Papers.

Besides now wanting a cheap family to undercut sales of expensive devices, vendors really don't want customers thinking that they can port designs to a device from a competitor. That's why FPGA vendors put so much energy into proprietary soft-core processors and SDK tools. You simply can't port them to a competitor's tools. Better yet, you can make customers reliant on soft-core IP to do things like Ethernet connectivity. If an FPGA vendor thought that a particular market sector application was important enough to take away sales from a competitor you can be sure that they will provide the IP to do so. Xilinx, in particular like to restrict some IP, like video., to AXI buss implementations that might make sense for ZYNQ and are required by MicroBlaze because it uses more memory and is more complicated than the average customer wants to invest time in.

Of course, down the chain are "partnerships" with IP and hardware vendors. There's a certain amount of loyalty to those loose agreements; similar to the phrase "loyalty among thieves", depending on the marketing aims of the moment.

You don't necessarily have to buy HDMI IP. While difficult, you can do video applications without it. Long time, but recently absent, user hamster has done valiant work in this arena.

In the end programmable logic vendors are businesses ( though 80% of the FPGA market is now property of CPU vendors with their own agendas ) and businesses have to make money, so I'm not sure that reasons for why they do things are all that important to their users.

As an aside, I've recent read that Intel is going to go to a marketing scheme where a customer can purchase functionality, for a price, that can be "enabled" in their CPU devices on live end-user products. That's where the world is headed, whether you like it or not. The age where companies competed for customer sales by providing a better product, or better service has been dead and buried for a while now. Edited December 18, 2022 by zygot