cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
t-koyama
Visitor
Visitor
482 Views
Registered: ‎05-18-2018

Multiple implementation about Displayport 1.4

I have four Displayport Subsystem 1.4 implemented on my XCKUP15.

I'm using four, BANK227,229,231,233 Reference Clock is taken from BANK229,233.

Reference Clock confirms that 270Mhz is included. The problem is that QPLL1 does not LOCK.

Therefore, the subsequent processing cannot work at all. When mounted on BANK227,229 and mounted two, QPLL lock could be confirmed only for BANK227.

BANK229 could not be locked.

 

Do you know anything with this much information?

There is a problem with the addressing of the PHY, or the PHY currently has a 128K address space. Is this a problem?

Also, can I use this Displayport IP when updating a program with Tandem PCIe with field update?

0 Kudos
10 Replies
florentw
Moderator
Moderator
400 Views
Registered: ‎11-09-2015

HI @t-koyama 

I would suggest to do everything step by step:

Did you try with a single video phy on Bank 229 with Reference Clock from BANK229? Is this working?

PS. I have no idea about Tandem PCIe with field update, you might want to ask on the PCIe board for this


Florent
Product Application Engineer - Xilinx Technical Support EMEA
**~ Don't forget to reply, give kudos, and accept as solution.~**
0 Kudos
t-koyama
Visitor
Visitor
377 Views
Registered: ‎05-18-2018

Thank you for reply
Certainly, I think it's better to go in order.
The device I'm using is XCKU15P-1760FFVA.

First, the Reference clock is connected to Bank 229 from the outside.
This clock is working properly.
And if VID_PHY_CONTROLLER with Displayport setting is implemented in Bank229, QPLL1 will not be locked.
However, when implemented in Bank230, QPLL1 appears to be locked.
The input of Reference clock is still Bank229.
The status of QPLL1 confirms the status of Adress 0x0018 of VID_PHY_CONTROLLER.
I know that resetting QPLL1 is important, so I set it to reset 0x0014.

I'm using Vivado 2019.2.
And use Xilnx's Displayport 1.4 tx subsystem v2.1
I am using it.

To start, the following data is written in VID_PHY_CONTROLLER (write only)

[DOUDA debug] PHY Write Addr = 0114 [Value = 00000001]
[DOUDA debug] PHY Write Addr = 0114 [Value = 00000002]
[DOUDA debug] PHY Write Addr = 0114 [Value = 00000004]
[DOUDA debug] PHY Write Addr = 0114 [Value = 00000008]
[DOUDA debug] PHY Write Addr = 0114 [Value = 00000020]
[DOUDA debug] PHY Write Addr = 0114 [Value = 00000010]
[DOUDA debug] PHY Write Addr = 0114 [Value = 00000040]
[DOUDA debug] PHY Write Addr = 0114 [Value = 00000080]
[DOUDA debug] PHY Write Addr = 0114 [Value = 40000000]
[DOUDA debug] PHY Write Addr = 0114 [Value = 80000000]
[DOUDA debug] PHY Write Addr = 007C [Value = 00000006]
[DOUDA debug] PHY Write Addr = 007C [Value = 00060006]
[DOUDA debug] PHY Write Addr = 0080 [Value = 00000006]
[DOUDA debug] PHY Write Addr = 0080 [Value = 00060006]
[DOUDA debug] PHY Write Addr = 007C [Value = 00060006]
[DOUDA debug] PHY Write Addr = 007C [Value = 00060006]
[DOUDA debug] PHY Write Addr = 0080 [Value = 00060006]
[DOUDA debug] PHY Write Addr = 0080 [Value = 00060006]
[DOUDA debug] PHY Write Addr = 0070 [Value = 010110101]
[DOUDA debug] PHY Write Addr = 0100 [Value = 02020202]
[DOUDA debug] PHY Write Addr = 0108 [Value = 010110101]
[DOUDA debug] PHY Write Addr = 001C [Value = 08080808]
[DOUDA debug] PHY Write Addr = 0024 [Value = 40404040]
[DOUDA debug] PHY Write Addr = 0010 [Value = 8C000111]
[DOUDA debug] PHY Write Addr = 0040 [Value = 0000107A]
[DOUDA debug] PHY Write Addr = 0040 [Value = 3003307A]
[DOUDA debug] PHY Write Addr = 0044 [Value = 3003307A]
[DOUDA debug] PHY Write Addr = 0048 [Value = 3003307A]
[DOUDA debug] PHY Write Addr = 004C [Value = 3003307A]
[DOUDA debug] PHY Write Addr = 0040 [Value = 00001085]
[DOUDA debug] PHY Write Addr = 0040 [Value = 017C3085]
[DOUDA debug] PHY Write Addr = 0044 [Value = 017C3085]
[DOUDA debug] PHY Write Addr = 0048 [Value = 017C3085]
[DOUDA debug] PHY Write Addr = 004C [Value = 017C3085]
[DOUDA debug] PHY Write Addr = 0134 [Value = 00000000]
[DOUDA debug] PHY Write Addr = 0010 [Value = 8C000111]
[DOUDA debug] PHY Write Addr = 0060 [Value = 00001094]
[DOUDA debug] PHY Write Addr = 0060 [Value = 00263094]
[DOUDA debug] PHY Write Addr = 0060 [Value = 00001098]
[DOUDA debug] PHY Write Addr = 0060 [Value = 08203098]
[DOUDA debug] PHY Write Addr = 0040 [Value = 0000107C]
[DOUDA debug] PHY Write Addr = 0040 [Value = 01E0307C]
[DOUDA debug] PHY Write Addr = 0044 [Value = 0000107C]
[DOUDA debug] PHY Write Addr = 0044 [Value = 01E0307C]
[DOUDA debug] PHY Write Addr = 0048 [Value = 0000107C]
[DOUDA debug] PHY Write Addr = 0048 [Value = 01E0307C]
[DOUDA debug] PHY Write Addr = 004C [Value = 0000107C]
[DOUDA debug] PHY Write Addr = 004C [Value = 01E0307C]
[DOUDA debug] PHY Write Addr = 0060 [Value = 0000107A]
[DOUDA debug] PHY Write Addr = 0060 [Value = 5000307A]
[DOUDA debug] PHY Write Addr = 0014 [Value = 00000007]
[DOUDA debug] PHY Write Addr = 0014 [Value = 00000000]
[DOUDA debug] PHY Write Addr = 001C [Value = 88888888]
[DOUDA debug] PHY Write Addr = 001C [Value = 08080808]
[DOUDA debug] PHY Write Addr = 007C [Value = 00070007]
[DOUDA debug] PHY Write Addr = 0080 [Value = 00070007]

0 Kudos
florentw
Moderator
Moderator
370 Views
Registered: ‎11-09-2015

HI @t-koyama 

There are still some things that you are not fully mentioning.

I assume you are aware that the GT ref clock connection will be different depending if the clock is coming from the same GT quad or if this is coming from a different GT quad.

Can you share a screenshot of the connection in the vivado design depending on both cases?

Same it seems that you are aware that the clock selection (QPLL1REFCLKSEL) is different in the application but can you share the different programming depending on if this is in the same quad or not?

Also, did you try with the Displayport 1.4 example application first? There might be one piece that you are missing

 


Florent
Product Application Engineer - Xilinx Technical Support EMEA
**~ Don't forget to reply, give kudos, and accept as solution.~**
0 Kudos
t-koyama
Visitor
Visitor
336 Views
Registered: ‎05-18-2018

First of all, I'm sorry I couldn't give you reliable information.

1.The sample model is an experiment using KCU105, and the image is  displayed on the monitor.

2. Next, we made our own design based on the sample design. At this time, I confirmed the operation of displaying the image on the monitor with the prototype board I designed.

The FPGA used was the XCU15P-1170-FFVA.


3.In this prototype design, we took in REFCLK from BANK233, used QUAD of BANK234, and confirmed that it was connected to the monitor and operated.

4.With this extension, I created an application that implements four DP + PHYs.

The connection at this time will be 4Dp_connection.png.

5. In this state, it was found that all four QPLL1s were not locked.

6. REFCLK is set to 270Mhz, and it is confirmed that it is operating normally.

7.The design implements 4 Dp_subsysytem and 4 vid_phy_controller. REFCLK is shared by the two PHYs.

8. Remember that the BANK position has changed from the first design I tried.

9. I simply implemented one DP + PHY and confirmed it. as a result

 REFCLK BANK233  PHY BANK234   QPLL1 LOCK OK
 REFCLK BANK233  PHY BANK233   QPLL1 LOCK NG
 REFCLK BANK233  PHY BANK232   QPLL1 LOCK NG
 REFCLK BANK233  PHY BANK231   QPLL1 LOCK NG

 REFCLK BANK229  PHY BANK231   QPLL1 LOCK OK
 REFCLK BANK229  PHY BANK230   QPLL1 LOCK OK
 REFCLK BANK229  PHY BANK229   QPLL1 LOCK NG
 REFCLK BANK229  PHY BANK228   QPLL1 LOCK NG
 REFCLK BANK229  PHY BANK227   QPLL1 LOCK NG

This is the result.
At this time, the wiring of the Block design was not changed, only the PHY bank setting was changed. attached DP_block.png.
The state of Reference Clock Select is in all cases.

Address 0x0010 = "8C000111".

 

As for the problematic part
① The wiring of the block design is wrong
② The setting to Phy is wrong, especially Reference Clock SELECT
③ Factors such as Clock Jitter on our board
④ Refrence Clock can only be used for the above BANK.

I'm thinking about things like that, but do you know what the factors are?

I would appreciate any advice.

 

 

 

0 Kudos
florentw
Moderator
Moderator
316 Views
Registered: ‎11-09-2015

Hi @t-koyama 

Ok we are starting to see the issue.

So when you use a clock from the same bank, you need to use GTREFCLK0 and/or GTREFCLK1 (refer to UG576

 

 

 

This connection has to be done correctly for each video PHY in Vivado.

Then for each video phy, you need to have the correct selection for QPLL1REFCLKSEL in reg 0x010 (it will not be the same for all):

GT3.JPG

 


Florent
Product Application Engineer - Xilinx Technical Support EMEA
**~ Don't forget to reply, give kudos, and accept as solution.~**
0 Kudos
t-koyama
Visitor
Visitor
309 Views
Registered: ‎05-18-2018

First of all, I realized that the Block Design wiring needs to be changed for each block.
I didn't understand that, so I was connecting to mgtrefclk0_in on the PHY_controller on all four PHYs.
However, if you check the actual Implemented design, when the Reference Clock wired from Bank233 is wired to Bank234
I'm not aware of this, but it seemed to be automatically wired to GTNORTHREFCLK01.
This means that Vivado is wiring automatically, should the block design be wired correctly?
.
For this, make sure that all wiring is routed correctly.
.
Because the four DP connections we sent you earlier are what we want
.
.4DP_connection.PNG
.
.
In the case of BANK229, is it correct to connect the Reference Clock to mgtrefclk0in?
BANK227 has
gtsouthrefclk0 in
gtsouthrefclk1 in
gtsouthrefclk00 in
gtsouthrefclk01 in
gtsouthrefclk10 in
gtsouthrefclk11_in?
Is it correct to connect the Reference Clock to them ?
.
Is it the same for Bank233 and Bank230?
.
.
.
Next, consider QPLL1REFCLKSEL in reg 0x010. I'm also curious about this setting
Our application originally set 0x0010 = "8C000111" on all PHYs.
I noticed that this is different from this description, QPLL1REFCLKSEL, so experimentally in our application
I tried to change the selection, but because this selection change did not change the state of QPLL1
I was wondering if it was fixed inside Vivado or somewhere else.


The basis is
In our confirmation, we got the following results
REFCLK BANK233 PHY BANK234 QPLL1 LOCK OK
.
In this case as well, 0x0010 = "8C000111" is set, so when you actually check the Implemented status, gtnorthrefclk
Is connected, and in the case of this selection, REFCLK is not connected to QPLL1 and LOCK becomes NG.
I was wondering if there was one, but in reality this BANK is LOCK OK.
Is this the correct phenomenon?

First of all, as advised, block design wiring and reg0x010 Try to separate the settings for each PHY.

I'm sorry I wrote it for a long time
Please give me any advice.

0 Kudos
florentw
Moderator
Moderator
299 Views
Registered: ‎11-09-2015

HI @t-koyama 

First of all, I realized that the Block Design wiring needs to be changed for each block.
I didn't understand that, so I was connecting to mgtrefclk0_in on the PHY_controller on all four PHYs.
However, if you check the actual Implemented design, when the Reference Clock wired from Bank233 is wired to Bank234
I'm not aware of this, but it seemed to be automatically wired to GTNORTHREFCLK01.
This means that Vivado is wiring automatically, should the block design be wired correctly?

This is possible that Vivado is doing the connection correctly. It seems possible looking at UG576:

florentw_0-1606483192302.png

But then I am not sure what is the correct selection you have to do in the Video PHY. And I am not sure if the Video Phy is designed correctly for this use case.

Next, consider QPLL1REFCLKSEL in reg 0x010. I'm also curious about this setting
Our application originally set 0x0010 = "8C000111" on all PHYs.
I noticed that this is different from this description, QPLL1REFCLKSEL, so experimentally in our application
I tried to change the selection, but because this selection change did not change the state of QPLL1
I was wondering if it was fixed inside Vivado or somewhere else.

I do not think this is fixed. But maybe vivado tool change something which is not planned by the Video PHY

In this case as well, 0x0010 = "8C000111" is set, so when you actually check the Implemented status, gtnorthrefclk
Is connected, and in the case of this selection, REFCLK is not connected to QPLL1 and LOCK becomes NG.
I was wondering if there was one, but in reality this BANK is LOCK OK.
Is this the correct phenomenon?

This is not what I would expect. But as with previous comment, maybe with the connection done automatically by vivado, the control from the Video phy does not work anymore.

I would suggest connecting the Video PHY as suggested (using the NORTH/SOUTH reflclk when appropriate)


Florent
Product Application Engineer - Xilinx Technical Support EMEA
**~ Don't forget to reply, give kudos, and accept as solution.~**
0 Kudos
t-koyama
Visitor
Visitor
248 Views
Registered: ‎05-18-2018


Thank you very much for the detailed explanation

The GTREFCLOCK connection diagram is what we especially want Q (n), Q (n-1).

Let me check only one point in this figure
Isn't the part marked with a red circle connected? Or is it a mistake in the figure?

gtref_clk.PNG

0 Kudos
t-koyama
Visitor
Visitor
173 Views
Registered: ‎05-18-2018

Before implementing multiple VID_PHYs, simply implement and verify one VID_PHY.

When I took in the Reference Clock from Bank233 and checked whether QPLL1 of the Quad of Bank233 was locked, QPLL1 was not locked either.

Reference Clock connection to VID_PHY is connected to mgtrefclk0_in in Block Design. The result is the same in Advanced Clock Mode and not, is there any reason why QPLL1 does not lock with this simple connection?

VID_PHY status as belows

reg 0x0010 ="8C000111"   Write

reg 0x0018 ="00000000"   Read

reg 0x0020 ="04040404"   Read

reg 0x0078 ="00000000"   Read

Do I need to be careful about how to apply RESET?

0 Kudos
florentw
Moderator
Moderator
156 Views
Registered: ‎11-09-2015

Hi @t-koyama 

Aren't you using the drivers for this?

There is an example design for the Displayport 1.4 can you refer to it? This is doing the correct sequence to set up the video phy


Florent
Product Application Engineer - Xilinx Technical Support EMEA
**~ Don't forget to reply, give kudos, and accept as solution.~**
0 Kudos