cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
accxsupport
Observer
Observer
13,475 Views
Registered: ‎06-21-2012

Kintex 7 GTX CDR Problems

Jump to solution

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.

 

TrainingPattern1.jpg

 

Mark.

0 Kudos
1 Solution

Accepted Solutions
venkata
Moderator
Moderator
17,985 Views
Registered: ‎02-16-2010
If you are finding problems when consecutive 0101010 pattern, I think the AR#56894 could help
http://www.xilinx.com/support/answers/56894.htm
------------------------------------------------------------------------------
Don't forget to reply, give kudo and accept as solution
------------------------------------------------------------------------------

View solution in original post

18 Replies
accxsupport
Observer
Observer
13,462 Views
Registered: ‎06-21-2012

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?

 

TrainingPattern1-1.jpg

 

Thanks,

Mark.

0 Kudos
muravin
Scholar
Scholar
13,382 Views
Registered: ‎11-21-2013

Hi Mark,

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.

Best regards

Vlad

Vladislav Muravin
0 Kudos
accxsupport
Observer
Observer
13,361 Views
Registered: ‎06-21-2012
Hi Vlad,

CDR is only failing during training phase 1. This was also with v3.2 under ISE14.4. Just be careful with the mgt parameters as some of them are wrong depending on which version of ISE you are using. Specifically CPLL_FBDIV and CPLL_FBDIV_45 are wrong, also RXELECIDLE mode should be "11" or you won't get symbol lock.

Following on CDR seems ok for all other phases, apart from training pattern 1, as when I get the core to pass training phase1, I can get the link up and running.

Please let me know if you have any success.

Thanks,
Mark.
0 Kudos
venkata
Moderator
Moderator
17,986 Views
Registered: ‎02-16-2010
If you are finding problems when consecutive 0101010 pattern, I think the AR#56894 could help
http://www.xilinx.com/support/answers/56894.htm
------------------------------------------------------------------------------
Don't forget to reply, give kudo and accept as solution
------------------------------------------------------------------------------

View solution in original post

muravin
Scholar
Scholar
13,345 Views
Registered: ‎11-21-2013

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.

 

Vlad

 

Vladislav Muravin
0 Kudos
accxsupport
Observer
Observer
13,335 Views
Registered: ‎06-21-2012
Hi,

I had not seen this AR but it is essentially what I have been trying to do. The training pattern in displayport is many thousand cycles of 0101 repeated. It is not exactly clear what *HOLD ports (H2-H5) they are referring to in the AR, I tried it with RXCDRHOLD.

Thanks,
Mark.
0 Kudos
muravin
Scholar
Scholar
13,306 Views
Registered: ‎11-21-2013

Hi Mark,

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.

Thanks Vlad

Vladislav Muravin
0 Kudos
venkata
Moderator
Moderator
13,285 Views
Registered: ‎02-16-2010
Hi,

The AR is referring to the following *HOLD ports of DFE.
RXDFEUTHOLD
RXDFETAP2HOLD
RXDFETAP3HOLD
RXDFETAP4HOLD
RXDFETAP5HOLD
------------------------------------------------------------------------------
Don't forget to reply, give kudo and accept as solution
------------------------------------------------------------------------------
0 Kudos
accxsupport
Observer
Observer
13,281 Views
Registered: ‎06-21-2012
Hi,

As per AR56894 as soon as I see the tp1 on the bus for 3000 cycles of 0101, I assert the above hold registers. You also MUST set RXDFEXYDEN = 1. Under these conditions the link passes both tp1 and tp2.

There is one remaining issue. It seems that when the incoming data signal transitions from non-scrambled training data to scrambled link data the DFE takes quite some time to adapt and it loses symbol lock, showing numerous symbol and disparity errors, due to the DFE losing lock the CDR also loses lock. It does eventually adapt, the issue is the TX checks the status of the link during this period, sees that it has lost lock and forces retraining to occur, and we end up going around in circles.

After a number of training cycles like this the link usually comes up, more out of luck I guess, with the TX checking the status at an opportune moment, or the RX adapting better.

I am not sure if this is the exact issue, for even a common phenomenon to see the DFE take time to adapt when the input changes from non-scrambled predictable pattern to scrambled random data.

Any thoughts on the matter much appreciated.

Thanks,
Mark
0 Kudos
accxsupport
Observer
Observer
11,783 Views
Registered: ‎06-21-2012
I was being fooled by not asserting the *HOLD signals on all 4 gtx channels. Once I did this I was able to reliably train and establish my link, at least at RBR of 1.62Gbps.

I don't think the DFE config is perfect, but it is working, at least with the TX I am using.

Thanks,
Mark.
0 Kudos
vtesanovic
Visitor
Visitor
11,741 Views
Registered: ‎12-05-2013

Hi Mark,

 

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.

 

Thanks 

Vladimir

 

0 Kudos
accxsupport
Observer
Observer
11,714 Views
Registered: ‎06-21-2012
Hi Vlad,

We were told by Xilinx not to use the 4.0 core, the 4.1 core has a number of changes. That said as of yet we can't get either the 4.0 or 4.1 core to work properly. With 4.1, the hot plug detect line is not even asserted (brought low for 1ms) when the link is enabled and so the TX does not initiate aux communications!

That is why we went back to v3.2 core, the only changes made were those listed in these posts. The biggest issue was the DFE not being able to adapt properly during the training phase. Whilst not perfect we have the link consistently training by asserting the hold signals on the DFE.

What is really needed is a working reference design from Xilinx that demonstrates RBR, HBR, and HBR2 operation on a standard platform, e.g, KC705, the spartan 6 reference design works well, so I presume the issue is with the GTX transceivers.

Using 3.2 core and simple fsm policy maker you should be able to train the link.
- make sure the GTX is rest properly and the cplls are locked.
- then enable the link, which you should then see aux traffic from TX, you can decode this to see how training is going
- then use chipscope to monitor phy signals and status, you should see when the TX is putting tp1 on the link and from the aux channel or config registers you can monitor how training is going.

If you see a particular problem let me know and I may be able to offer more pertinent advice.

Mark.
0 Kudos
vtesanovic
Visitor
Visitor
11,662 Views
Registered: ‎12-05-2013

Hi Mark,

 

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  

 

snapshot2.png

 

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.

 

snapshot1.png 

 

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.

 

Thanks 

Vladimir

0 Kudos
muravin
Scholar
Scholar
11,623 Views
Registered: ‎11-21-2013

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:

- RXDFEUTHOLD

- 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.

Vladislav Muravin
0 Kudos
muravin
Scholar
Scholar
11,621 Views
Registered: ‎11-21-2013

And here is the 3,000 cycles attempt. You can see that the DFE Hold is asserted after the stability period of the lane's data, so CDR locked keeps jittering.

BR

Vlad

 

Vladislav Muravin
0 Kudos
simonyang
Adventurer
Adventurer
11,353 Views
Registered: ‎05-16-2011
Have you resolved the issue? Which attribute setting should be modified?
0 Kudos
muravin
Scholar
Scholar
11,339 Views
Registered: ‎11-21-2013

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.

Vladislav Muravin
0 Kudos
kalana1989
Newbie
Newbie
9,709 Views
Registered: ‎09-23-2014

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.

 

Regards,

Kalana

 

 

0 Kudos