UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Visitor travagli
Visitor
9,190 Views
Registered: ‎02-19-2010

Problem with phase detector on Spartan 6

Hello,

I'm having problems on implementing a high-speed data deserialization , using the design described in xapp 1064.

 

I designed a 1-to-12 deserialization, with 780 MHz bit rate and the incoming clock is DDR.

Referring to the examples in the xapp I followed the design as in Case 2 (pag.2) using a PLL in order to multiply the incoming clock by a factor two.

For data deserialization I implemented the "serdes_1_to_n_data_diff" VHDL module, also using the phase detector logic.

 

My problem arises when trying to perform a post-route simulation (bot with ISim (ISE 12.1) and ModelSim SE 6.5c):

after the initial calibration phase, when using VALID and INCDEC signals from the MASTER ISERDES2, I get two different behaviour depending on the phase between clock and data (at the input Pads) that I set in the stimulus file.

 

1) when clock arrives later than data ( > 500 ps with respect to a ~1.3 ns bit period),  a given amount of decreasing steps (valid =1 , incdec = 0) are asserted from Iserdes (and then re-tx to the iodelay). Finally , a stable sampling point is correctly found and data are correctly sampled.

 

2) when clock arrives early than data (< 500 ps and > 1100 ps) , steps asserted from Iserdes are increasing. I trasmit these signals correctly ( as described in AR #34617) to the iodelay but the found sampling point is not correct.

In fact, when INCDEC is 1 data are correct, but with the following INCDEC = 0 data are shifted by one bit.

I tried both with Iodelay set in "wraparound" and "stay_at_limit".

 

I found this statement in the Spartan6-SelectIO  User' Guide :

"

The delay line has two limitations. First, it should only be used to delay signals by a
maximum of one bit period, because bit errors can occur beyond this limit.

 

The delay line has two limitations. First, it should only be used to delay signals by amaximum of one bit period, because bit errors can occur beyond this limit." (pag 64)

 

It could be that, by increasing the delay and reaching the maximum number of steps (of one bit period), the phase deskew mechanism into the iserdes find a wrong point?

Is this problem related only to the simulation (behavioural sim isn't affected) or do I have to be worried and try to implement some solution ?

 

Thank you,

Riccardo 

 

 

0 Kudos
18 Replies
Adventurer
Adventurer
9,058 Views
Registered: ‎06-12-2008

Re: Problem with phase detector on Spartan 6

Hello travagli,

 

Did you find a solution to your problem?

 

I am about to design something similar and I am therefore very interrested.

 

regards, Klaus

0 Kudos
Visitor travagli
Visitor
8,982 Views
Registered: ‎02-19-2010

Re: Problem with phase detector on Spartan 6

Hello Klaus,

I implemented a workaround, so that the post-layout simulation works correctly.

 

Basically, I put the Slave Iodelay2 on the clock module with "variable_from_zero" and "wraparound" attributes.

Then I load a fixed number of steps from configuration registers and I used this number to increase the delay on the clock input by using INC and CE ports.

The right number will be found experimentally on the hardware, but, in the simulation, I tried several phase delays between clock and data and I found all the time a good value (allowing the data be sampled correctly).

 

So far I didn't finish to implement my setup, but I hope in the near future to test this solution also in hardware.

 

best regards,

Riccardo

0 Kudos
Xilinx Employee
Xilinx Employee
8,927 Views
Registered: ‎11-03-2008

Re: Problem with phase detector on Spartan 6

Hi Riccardo,

The assumption with XAPP1064 is that the clock and data will be aligned within 0.25 UI, so around 325 nS in your case. The reason is that at the 0.5 UI point the master delay will wraparound, and as the phase detector logic will always be either incrementting  or decrementing, it can then immediately wrap back again. This will cause data loss. The difference between the theoretical 0.5 UI and the 0.25 UI we quote is to account for jitter and signal distorion plus some margin.

 

Putting in some fixed clock delay can change the point where this effect happens, but as the delays are uncompensated they can in theory vary widely from one part to another, so determining values from experimentation isnt a good solution.

 

So, if your clock and data are nominally aligned, the xapp should well for you. If the relationship is unknown, or beyond 0.25 UI then you may well lose data in reception.

 

Regards

Nick

0 Kudos
Visitor icosgmbh
Visitor
8,459 Views
Registered: ‎10-07-2011

Re: Problem with phase detector on Spartan 6

Hi,

 

I have a case where there is NO known relationship between data and clock phase, 8:1 DDR differential input,

known training pattern sent to adjust sampling, 624 Mbps.

Do I interpret the discussion correctly: phase-detector cannot be used without possible loss of data ?

I attempt to use the phase_detector.vhd as provided by the SerialIO Wizard. It works correctly in the

majority of cases, but for some few relative phases of clock and data it runs havoc, in very few cases

hard reproducible so.

Is that the expected behavior ????

 

Thanks and regards

John

0 Kudos
Xilinx Employee
Xilinx Employee
8,450 Views
Registered: ‎11-03-2008

Re: Problem with phase detector on Spartan 6

Hello John,

Yes, this is to be expected. If the realtionship between the sampling clock and data is around 180 degrees then wraparound and data loss will occur.

Regards

Nick

0 Kudos
Highlighted
Observer alvaro.navarro
Observer
8,417 Views
Registered: ‎03-22-2010

Re: Problem with phase detector on Spartan 6

Ok, the simple design proposed in xapp 1064 cannot be used, but let's look forward.

 

Does someone know of a way to implement serial data reception in Spartan 6 with a source-synchronous clock and  unknown phase relationship?

Tags (1)
0 Kudos
Observer alvaro.navarro
Observer
8,269 Views
Registered: ‎03-22-2010

Re: Problem with phase detector on Spartan 6

I found the application note 495, in which the receiver has exactly this problem. The delays are simply configured as "STAY_AT_LIMIT" so that no bits are duplicated or lost. The only problem I see with this design is that when eye and edge are off by ~0.5 UI, the tap count will not be able to follow skew variations in one direction, and thus bit errors may arise due to improper sampling time. Anyway, it's much better than the problem with the wraparound.

 

Copy-pasted text:

 

In Case 4and Case 5, because the master IDELAY settles either at ZERO or MAX, its
IODELAY2 attribute COUNTER_WRAPAROUND must be set to STAY_AT_LIMIT to prevent
the IDELAY from underflow or overflow. This is important because the clock and data jitter
cause the phase detector to issue extra decrement or increment commands.

 

This usage is different from that described in Source-Synchronous Serialization and
Deserialization (up to 1050 Mb/s) [Ref 8], where WRAP_AROUND is suggested when clock
and data are roughly pre-aligned. For the cases with unknown initial clock to data phase
described in this application note, the use of WRAP_AROUND leads the master sampling
window to accidently draft one bit and subsequently cause bit errors.

0 Kudos
Visitor icosgmbh
Visitor
8,261 Views
Registered: ‎10-07-2011

Re: Problem with phase detector on Spartan 6

Hello,

 

I have resolved the problem several months ago, and a number of systems runs fine with that solution.

Basic idea: phase variance is SYSTEM and possibly LONG TIME dependent, and not SHORT TIME dependent. Therefore,

it is sufficient to calibrate phases on startup of the system. I use fixed phase delays, and adjust each and every

of the serial input delays to center-of-eye on startup, using a training pattern and the delay increment signal,

and I have established a fully automatic software phase/delay calibration procedure.

That works well for ANY relative phase between clock and data.

 

That this works well is possibly connected to good voltage and temperature stabilization.

 

John

0 Kudos
Observer alvaro.navarro
Observer
8,250 Views
Registered: ‎03-22-2010

Re: Problem with phase detector on Spartan 6

Thanks for the update.

 

I think I'll start with the STAY_AT_LIMIT solution, because in most situations it'll still be able to adapt the phases dynamically, and in case it hits the limits (at the initial calibration or during operation), it'll simply remain there and not move in one direction, just as if it had been fixed after a calibration.

0 Kudos
Visitor jonpry
Visitor
7,217 Views
Registered: ‎06-04-2012

Re: Problem with phase detector on Spartan 6

 

I'm having the same problem. I haven't tried to implement it yet, but I was wondering if something could be done because we essentially know when the sampleing edge will get flipped from min<->max. So if the output of the iserdes went to something like a 3 deep fifo. And there was a machine that would select which pipeline stage to use based on the min<->max action. Would it be possible to recover the missing bits and maintain interruption free data flow? I suspect this would only work for max->min and not min<-max because the latter would leave a bit not sampled at all. However there are 2 iserdes at work here (master and slave. So maybe a more complicated scheme could ensure no loss of bits.

 

0 Kudos
Observer alvaro.navarro
Observer
7,208 Views
Registered: ‎03-22-2010

Re: Problem with phase detector on Spartan 6

I think the problem with that is that there is no way of knowing exactly when the delay has shifted, since it depends on the number of transitions. By counthing the number of times the phase detector states machine issues inc/dec signals, you can know that a max <--> min transition is going to take place, but you can't know exactly when.

0 Kudos
Visitor jonpry
Visitor
7,196 Views
Registered: ‎06-04-2012

Re: Problem with phase detector on Spartan 6

   You raise an interesting point but I think it's not the end of the world. Suppose that the serdes factor is limited 4 so that we can use both iserdes blocks. The the parallel outputs of both the master and slave iserdes should match at the beginning of inc/dec command and as the delay adjustment takes place a discrepency will emerge. Potentially showing the shift and the missing bit.

0 Kudos
Observer alvaro.navarro
Observer
7,176 Views
Registered: ‎03-22-2010

Re: Problem with phase detector on Spartan 6

I don't think that would work. The data in the second ISERDES is no different that the bits that have been sampled by the first FF in the Master ISERDES, and then are shifted through the chain of 4 FF in the Master ISERDES, and then shifted out to the slave. The problem is that when you transition from MAX to 0 delay, the serial stream reaching that 1st FF is missing one of the bits. So this bit is never captured or seen by any of the two ISERDES. In the case of 0  -> MAX transition, as you said, you have a bit that is duplicated but you have no means of knowing which one it is.

 

I'm no expert, but this is what my understanding of the delay-deser tells me.

0 Kudos
Visitor jonpry
Visitor
7,156 Views
Registered: ‎06-04-2012

Re: Problem with phase detector on Spartan 6

  I'm not 100% sure that the simulation models of ISERDES match the real hardware behavior. But the theory is that if you limit the serdes factor to 4, then its possible to have the slave ISERDES not get its data from the master but rather the other IODELAY. So you end up having parallel data that can be analyzed at reasonable speed. 

 

   XAPP585 has some interesting stuff. It appears they have implemented this technique somehow on 7 series devices. It's a little weird because 7-series has a maximum SERDES factor of 16 and who knows what other differences. I'm somewhat hopeful that the XAPP code can simply be adapted to the smaller factor and run on Spartan 6. 

0 Kudos
Scholar samcossais
Scholar
7,004 Views
Registered: ‎12-07-2009

Re: Problem with phase detector on Spartan 6


jonpry wrote:

   XAPP585 has some interesting stuff. It appears they have implemented this technique somehow on 7 series devices. It's a little weird because 7-series has a maximum SERDES factor of 16 and who knows what other differences. I'm somewhat hopeful that the XAPP code can simply be adapted to the smaller factor and run on Spartan 6. 


Yes I'm thinking the same for Virtex-6 actually. I'm pretty sure it can be adapted easily.

0 Kudos
Xilinx Employee
Xilinx Employee
7,000 Views
Registered: ‎11-03-2008

Re: Problem with phase detector on Spartan 6

Hi,

The XAPP585 code for 7 series cant be used with spartan6 as it relies on knowing when to wrap the delay line around, and thats something the spartan 6 delays dont tell you. The basic deskew mechanism in the xapp is however based on what the spartan6 does automatically, but extended to cases where wraparound can occur.

Regards

Nick

0 Kudos
Scholar samcossais
Scholar
6,993 Views
Registered: ‎12-07-2009

Re: Problem with phase detector on Spartan 6

Thank you Nick. I also got your reply about V6 and it sounds good.

0 Kudos
Observer alvaro.navarro
Observer
6,863 Views
Registered: ‎03-22-2010

Re: Problem with phase detector on Spartan 6

Hi, just wanted to share my final design configuration and findings on its behaviour.

 

Since the problem with wraparound in the master iodelay seems unavoidable, I configured it as stay_at_limit. The slave iodelay, however, is set as wraparound, as it is not used for actual data, but only for edge detection purposes. That way the master iodelay can move throughout the tap interval that covers 1 bit duration, and the slave is guaranteed to provide a half-bit-difference sample to feed the phase detector.

 

Depending on the initial phase, you have a margin of X fraction of a bit to adapt to changes of phase in one direction, and (1-X) in the other one until the master iodelay hits the limit. I can't know in advance what that initial phase condition X will be, so I investigated the effects of pushing the phase difference beyond that limit. When that happens, further ind/dec commands do not modify the master's delay, which stays pinned at the same tap value, and thus not perfectly centered in the eye anymore. The slave's iodelay, however, receives that command and increments/decrements, keeping the phase detector stable for as long as the master's sampling point is close enough to the center of the eye so as not to cause too many detection errors. In my design, with an 800 Mbps optical link, errors began approximately 1/8 of a bit past the limit. At this point, since you're having a lot of errors anyway, you can assume issuing a new CAL+RST to the master. Note that once you go beyond the limit, the half-bit distance between master and delay is broken and is not recovered by going back to a "valid" phase; it only recovers after a CAL to the slave. Although past this 1/8 of a bit the link is practically unusable, if you go past this point eventually the master's sampling point goes so close to the edge (to the slave's position) that the phase detector is no longer stable and "trips" a whole bit.

0 Kudos