04-30-2020 07:44 AM
maybe there are some DisplayPort1.2 experts out there, who have some experiences with compliance testing, and who can help me answering the following question:
"Does the DP1.2 Rx Subsystem support the DP1.2 CES compliance test, which shall be executed with the following Tektronix calibration and test setup?"
Link to Tektronix document:
Today I learned, that the Bit-Error Rate will be measured inside the DP-Rx device (according to the DP specification), and the BER result will be stored in DPCD registers, which in turn can be read out from the AUX-Controller via the DP AUX-channel.
Does any body know, if the DP1.2 Rx Subsystem does support the corresponding BER measurement circuit and the corresponding DPCD registers, so that a compliance test can be perfromed with the Tektronix setup displayed above?
04-30-2020 08:57 AM
I believe this will work. The main thing that you need to be aware is the PHY test automation is not supported. You have to do each testing individually.
This is because errors have to be monitored manually at DP159 interface and also special programming of DP159 is needed for multi-lane testing.
Some example design have the code used for compliance. Refer for example to the KC705 example application. You need to enable the COMPLIANCE switch to enable it
05-04-2020 12:20 AM
thank you for this information. Last week I learned from Tektronix, that the Phy test consist of more than 500 single tests (different lanes, differen link speeds, different voltage levels & preemp levels, etc.). So if you have to do all the tests by hand, this can become a big job.
05-05-2020 01:51 AM
I am not sure how the Tektronix equipment work. You might be able to automate some testing but not all can be fully automated
05-05-2020 02:09 AM
do you know somebody at Xilinx who can help me clarifying this question?
As far as I can remember, Xilinx performed a compliance test for the DP1.2 Rx subsystem, with the DP1.2 FMC-Card from Inrevium.
So there must be actually somebody at Xilinx, who has probably gathered some experiences with this stuff.
Do you think it is possible to get in contact with those people?
05-05-2020 03:25 AM
If you have specific questions I can answer.
As I mentioned, the example designs for the KC705 and ZCU102 have the code used for compliance. The UART menu should have the options required.
Multiple customers were able to go through compliance with this
05-12-2020 01:34 AM
thank you for this answer. One thing is not clear to me. Will automatic testing be supported with the Tektronix setup when I set the define COMPLIANCE, or do I still have to do the tests manually?
05-12-2020 03:13 AM
I have no experience with the use of the Tektronix. But my understanding is that some tests might fails as you need to read the values from the DP159.
I would say do the tests and let me know if you are facing issues
06-03-2020 03:21 AM
In my experience the code does not fully support everything that is needed to achieve compliance. There are a couple of #defines in the code but there is much more code required in order to get it to pass. I got the general feeling that someone got the KC705 etc through compliance with lots of peeking/poking of the DP159 and IP and didn't keep detailed notes. As I said this was just my experience and this may have changed since I last tried a year or 2 ago.
In particular the testing of the individual lanes requires some very specific setup of DP159 etc and lane 0 must have a clock on it. The code itself does not do this automatically (at least as far as I could find) and I struggled getting the help from Xilinx. I managed to get lanes 0 and 1 through most of the phy testing but could not get past lanes 2 and 3. Every time I thought I'd got everything in the IP/DP159 set correctly there would be one last change that would cause the link to drop. I think there is a very precise set of steps required. I'm sure some people have done it but Xilinx were very light on notes/procedures/code requried to do it, so good luck. Project got canned in the end as we could not get compliance in a reasonable time. Design worked fine with all sources we threw at it, just couldn't get compliance.
06-17-2020 05:00 AM
I just thought I'm the only one which is too stupid to understand how the compliance test shall be perfromed
Florent Werbrouk from Xilinx mentoined, that there are plenty of customers which have already performed the compliance test successfully. But so far, I didn't found someone who made some positive experiences, and xilinx is not in the condition to give you clear instructions.
Well, Xilinx did not understood so far, that a DisplayPort IP-core is worthless, if you cannot perform a compliance test with it. We are in the medical business, and our customers are big system intergrators, where you need a certificate, which tells them that you DP device is complinat according the DP-spec. Otherwise you will loose the race, independent how godd you design will work.
It is a pitty that your project was canned !!! But it can be that we run into the same sitaution one day...
By the way, I do not touch the DP159 anymore. We got already our fight with TI regarding bugs inside this chip. The DP159 does not behave as you would expect, and it is buggy (as confirmed by TI). After a lot of conversations with TI, I have the feeling, that even TI has sometimes no glue, how this chip shall behave.
But Simon as you know, Xilinx is now totally busy with the two big letters "AI".
Such ordinary things like a "simple displayport interface" are out of focus.
06-17-2020 06:34 AM
I have to say I was beginning to think it was just me!
The biggest problem we had was that I think I was expecting it to work "out of the box" without any special hand-holding or peeking/poking. It didn't help that the only test houses were either US or Taiwan and we are in UK and the company couldn't afford to ship me over to work on the kit for an indefinite period while it was there. Shipping the test unit backwards and forwards was also too expensive, especially as we couldn't afford the Tektronix kit to use in the office either. I'd have thought that if you advertise it as compliant, some info as to how you achieved compliance would be useful for your customers, but obviously we weren't buying enough chips...
I'd have loved to achieve compliance with it, just so I could have "completed" the project. Oh well. We'd already changed from the DP130 to the DP159 (under Xilinx's recommendation) as we were told it wouldn't meet compliance. The whole experience has made me want to steer clear of DP for a looooong time. I have nightmares about sales people/management asking for DP1.4.
As you say, it all seems AI and Big Data Accelerators now, you'd think the smaller stuff would sell more chips.
Good luck with it! If you ever do manage to get it through I would love to hear what you needed to do, even if it's only for a learning experience.
06-17-2020 08:25 AM
There are still video use in many AI Application so you would still need to have Video Connectivity.
The thing I can say here is that DP1.4 (and the retimer from Megachip) will not use to look into the retimer to get data for compliance. So you should be able to run test automation. There is no need to have a specific application as for DP1.2 with DP159.
I know the DP1.4 IP is not the ideal solution for everybody as you would need to use at least UltraScale which is more expensive than 7-Series. But that might be a discussion to have with your FAE.
@stgateizo I sent you the steps we have internally in private. If you are still not able to make it work then get in contact with your FAE. There might be customer who were not able to do the compliance test but at least I know we had multiple customers going through compliance successfully through official VESA test house (but I agree you need to be able to travel)).
06-18-2020 01:53 AM - edited 06-18-2020 01:57 AM
this is actually a good reason to transition to DP1.4. The problem is that as far as I can remember the Kintex Ultrascale is crictical regarding timing closure issues in vivado, and the smallest Kintex UltraScale+ device is much more expensive than our Kintex7 (we already had contact regarding pricing with our FAE). Therefore, I don't think that DP1.4 can be cheaply implemented in a Xilinx device.
At the moment Xilinx can not offer a cheap DP1.4 Rx/Tx Subsystem solution based on FPGAs. The cheapest chip costs around 300€, which is far away from what we can spent to stay competitive, or did I missed something?
06-18-2020 03:47 AM
There is an intermediate solution if you separate DP1.4 specification and the Xilinx DP1.4 IP.
Yes, this is a bit harder to meet timing with DP1.4 rates (i.e. 8.1 Gbps) on kintex Ultrascale. With that said this is a bit less true since the core is out, the solution has been improved. If you refer to table-1, it is only mentioned that 8.1 Gbps with HDCP is not supported on US devices (you need to limit the rate to 5.4Gbps).
And if the goal is to change the retimer solution but you are fine with only supporting DP1.2, then you can use the DP1.4 IP for DP1.2 by limiting the maximum line rate to 5.4Gbps so you will no timing issue (unless you design is very full as it would be the case for any IP).
And you can always start with a DP1.2 solution and see later if you design is fine to move to DP1.4
06-18-2020 04:37 AM
your suggestion is mostlikely possible and it would be indeed an option to bring the cost a bit down, but even if you would decide to use the smallest Kintex Ultrascale device without the plus, the costs are still 4-5 times higher, compaired to the current Kintex 7 solution. I do not see a big advantage from the costs view.
06-18-2020 05:29 AM
Kindly note that I have no idea of the pricing for each device. From your message, I understood that you were saying that Kintex Ultrascale could be a reasonable pricing not Ultrascale+ this is the reason why I gave the previous suggestion.
06-18-2020 06:29 AM
The price difference between Kintex Ultrascale and Ultrascale+ is not so big, when you compare the smallest chips of each familly. In contrast to those devices, the Kintex7 is 4-6 times cheaper. That is, simply said, the reason why DP1.4 is an expensive solution. Ultrascale and Ultrascale+ FPGAs make only sense when you add additional video processing functionality, where the customer is willing to pay for.
06-24-2020 03:44 AM
Is your issue resolved? If so, could you mark the solution that helped you the most as an 'accepted solution'? If not, could you update the community on your current issue?