11-14-2013 06:20 PM
Hi All, I have displayport receiver and transmitter connections to a Kintex 7. The transmitter works fine as per xapp1178. However I am having trouble with the receiver.
The issue seems to be the recovered clock (CDR) from the data stream. I have a 135MHz reference clock, which the CPLL locks to 1.62GHz. The link is trained by the transmitter initially placing 8B10B D10.2 symbols on the link. When training commences, I reset the GTX and hence the CDR. The CDR locks based on the incoming data. As expected the locked RXCLK output is 81MHz, however there seems to be a degree of wander. When I look at the received data pattern with chipscope which is supposed to be (0xA4) recovered from the D10.2 10B symbol, The D10.2 pattern seems to be wandering as I get 0xA4 and 0xB5, which is the D21.5 symbol (one bit shift of D10.2).
Is there a way to tune the CDR better? There seems to be some discrepancy between the RXCDR_CFG values for each release of the displayport core, and when I change between these different values, the recovered clock changes.
I've attached the waveform I see. It shows the CDR locking, followed by RESET_DONE going high and then the data being output on rxdata. chipscope is clocked by the recovered clock and if working correctly I would expect to just receive D10.2 symbols, decoded as 0xA4.
The reference clock is 135MHz connected directly to the Quad being used and AC coupled, I have tried both 10 nF and 100 nF.
Any help or ideas would be much appreciated.
11-22-2013 05:05 AM
11-14-2013 08:48 PM
Hi All, further to the above the CDR actually begins to lose lock whilst this training pattern is being received. The pattern on the wire is supposed to be 0101010101 repeated. As the CDR loses lock the RXCDRLOCK output from the GTX begins oscillating and not unsurprisingly the recovered data becomes less stable.
Should the CDR be able to lock onto this repetitive pattern and regenerate the link clock?
11-21-2013 10:56 AM
We believe we are having similar issue. Previously, we had a version 2.3 running on Virtex-6 and this one was working just fine. We are using 3.2 version of the DisplayPort core now on Kintex-7 and the CDR fails. We are just about to start chipscoping the surroundings of the GTX transceivers, and also trying a different clocking/GTX settings to see if this makes things better.
11-22-2013 03:26 AM
11-22-2013 05:05 AM
11-22-2013 01:08 PM
Thanks for propmt response. Well, we are not yet at the point you were. We cannot even see the CDR lock going up AT ALL, but I am going to follow your suggestion.
We are using 14.6, and I have tried also generating DP core from VIVADO, then exporting the RXCDR CFG word onto the GTX instance, and this was not successful. The PLL does not even lock up.
11-22-2013 04:46 PM
11-25-2013 08:08 AM
We have got to the point of your screenshots, i.e. CDR locked goes up and down.
I believe the settings of the CPLL dividers were simply used for 108 MHz clock and not 135 MHz, whch is btw the same the rev 2.3 of the DP core was configured. Were you able to bypass or force the CDR 1st phase to pass? Which mode then worked, LPM or DFE? We are about to try both and see which one works.
11-25-2013 11:40 PM
11-26-2013 01:53 AM
11-28-2013 04:07 AM
12-05-2013 06:19 AM
We are hving similar problems with DisplayPort Sink on Kintex 7.
We are useing Displayport 4.0 core. 4.0 core is all the time in LPM mode (it only goes to DFE moad during training on 5.4G RBR), AR56894 says that no action is needed in LPM mode still we can't pass trainig patern 1.
Which core you where useing when you have established link? What changes have you to make so your sink started passing training? I asume that you had to make changes in displayport_v4_0_rx_phy.v and GTX wizard files. Have you needed to add some steps to initilaization squence that where not described in the datasheet?
I would be grateful for any info.
12-06-2013 02:27 AM
12-13-2013 10:34 AM
I tried folowing your instruction from this forum and AR56894, and I havent been able to pass training pattern 1.
I am useing ISE 14.3 and Inrevium TB-7K-325T-IMG referent board and DisplayPort v3.2 (as you have sugested).
Here is what I see
I am also observing A4A4 and 5B5B on data lines similar like you have at the begining, but form me asserting DFEHOLD signals didn't change anything. I also tried aserting RXCRDHOLD signal but without any luck.
It seams to me that I have problem with CRD setings. Have you change any od CRD setings on your end when you pass test pattern 1. Also if you have any ideas what could be problem I would be realy greatfull.
12-18-2013 04:46 PM
Hi Mark, Vladimir.
I meant to respond earlier but we were busy preparing demo for our customers... you know how it is.
Now I am back to trying to bring up the DisplayPort, and I believe I am at exactly the same point as Vladimir is.
To re-iterate, our settings are:
- XPS 14.6
- DisplayPort 3.2
- We need HBR, 2.7 Gbps link rate on 4 lanes
- We only have SINK core (i.e. RX), the TX is sourced by a video card
I did follow up all the guidelines listed at that AR and also what you've suggested, i.e.
- RXDFEXYDEN = 1
- RXELECIDLEMODE = 11
- RX_DFE_VP_CFG = 0x00F00
Furthermore, trying to catch 3,000 repetitions of that pattern is a no-go; at least, this is what I "thought" I understood. There is a wandering pattern between 0x4a4a and 0xb5b5 that looks like "eye diagram" as it is wandering. I did attach a chipscope screenshot. That is, I can see the recovered data being STABLE for something like 1,000 cycles of the recovered clock, and counting 3,000 cycles of this puts the CDR into the wandering area, and CDR locked jitters afterwards. So, I reduced the count to 750 so that it will fall somewhat in the stable window, and then asserted the hold on the following lines:
- RXDFETAP2HOLD to RXDFETAP5HOLD
- RXCDRHOLD // I know this was not listed on that AR but it makes sense to do so
Now I am at the point where Vladimir is, i.e. TP1 cannot pass, but the CDR is locked, no jittering on it. Re-reading the AR# 56894, it talks about 3,000 bits, so perhaps this was my misunderstanding.
There is something that goes wrong and the link goes back to 1.62 Gbps where we do see a symbol lock on the lane 0, but we need 2.7 Gbps at 4 lanes. And after that, we will need 5,4 Gbps as well.
I will keep looking at the registers and see if there is anything I can catch, and any advice/suggestion/etc is very much appreciated.
12-18-2013 04:49 PM
02-25-2014 07:53 AM
Well, the answer is not simple.
First of all, DisplayPort does have problems, and the problems are somewhere between DisplayPort core and the GTX, most likely the GTX, or its tolerance to the jitter on the DisplayPort line. While this jitter could still be within the spec of the GTX, the GTX CDR loop simply cannot handle it.
So, what do we do? Well...
1. Call your local FAE, talk about the solution that smoothens the jitter (DisplayPort jitter re-clocker, there is a little chip from TI that does it).
2. Try a different video card if your source is a video card; this is a long shot but worth trying.
3. If your system is still at a stage you could redesign it, put a DisplayPort PHY in it and hook the FPGA to this PHY.
I also would like to share with everyone that we are designing our own high-speed serial receiver for V by 1 standard. This V by 1 thing is like DisplayPort but no AUX channel. Basically, we have a design that runs on 2.97 Gbps line rate and the clock training phase works for about 30% of the time if we are using LPM, but if we use DFE, we never fail clock trianing even if we do not follow the AR# 56894. Simply transmititng the clock training pattern for the maximum locking period (3.7E6) does the job very well !!!
I wish my answer would be more helpful, but this is what I can offer.
09-23-2014 05:48 AM
Hi Vladislav and Mark,
Sorry for drifting off the topic here. But I'm new to this and you guys seem to know a lot about the displayport design.
I'm trying to implement a Displayport transmitter on a Zynq ZC706 platform using the Avnet DVI I/O FMC module which has a displayport TX interface (as used in XAPP493).
I first implemented the example project in XAPP493 on a Virtex 6 ML605 platform with the Avnet DVI I/O FMC module and that works fine (this project uses Displayport source core v2.3). So the hardware is working. Then I tried implementing a source core on the ZC706 board which is my target (core v4.2 in Vivado which supports Zynq). I tried using the simple example hardware state machine based design generated by xilinx but that doesn't work. So I modified that RTL after reading the Displayport spec and now managed to get it passed link training. I know this because clock recovery, equalization and lane alignment bits are set in DPCD of the sink display (an HD monitor). But I still don't see any video even after configuring all the main stream attributes. Is there anything that I could be missing here? I know this is a tough question to answer but I can't be more specific cause I have no idea where and why its going wrong.
And I further tried porting the XAPP1178 design to the ZC706 board (I don't have a Kintex 7 board) but that didn't work out. If any of you have done a hardware based link policy maker which I can take a look to get an idea that will be very helpful. I'll be happy to share my RTL if you like to take a look.
Any suggessions to make a Displayport transmitter work on the Zynq ZC706 board would be greatly appreciated. I prefer to use a hardware state machine based link policy maker but I'm open to other options.