cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
nfrancque1
Visitor
Visitor
831 Views
Registered: ‎09-24-2020

Asynchronous Oversampling

Jump to solution

Hello,

I have a single ended data input coming into an xc7z015clg485-1 that has been clocked down to 50MHz for the time being, but ideally would like to go faster up to over 100MHz.  The 50MHz satisfies requirements for now, but is probably not the long term solution.  Any incremental improvements are desirable. The clock is in my control, the phase at which the data is received is not.

I see the guide https://www.xilinx.com/support/documentation/application_notes/xapp1294-4x-oversampling-async-dru.pdf from 2017 specifies that it will work with single ended inputs, with the limitation that it will only achieve 4 samples - so probably a higher than desired error rate.  I I understand correctly, no encoding of the data is required to achieve this.  Is all that correct?

If so, what I would like to know is if the above guide is the current best practice for this scenario.  I see this example https://www.xilinx.com/support/documentation/application_notes/xapp861.pdf requires that the data be LVDS, but it's from 2007 so perhaps the 7 series can get around this limitation somehow.

And if not, and I am able to keep my clock at 50Mhz, could simple modifications be made to the 4x single ended DRU to support 8x at 50Mbps?  Or am I misunderstanding the DRU state machine, and more samples are not necessarily needed?

Please let me know if more information is needed.

Thanks

 

0 Kudos
1 Solution

Accepted Solutions
nfrancque1
Visitor
Visitor
587 Views
Registered: ‎09-24-2020

@dgisselq Thanks for the detailed reply.  I ended up using the DRU oversampling defined in XAPP1294.  For anyone who stumbles upon this post later, the reference design worked for me without any changes, but the speed configuration vector did not work.  As long as the clock ratios were kept the same as recommended, that approach recovered the data successfully.  Closing this question now.

View solution in original post

0 Kudos
8 Replies
beandigital
Scholar
Scholar
819 Views
Registered: ‎04-27-2010
Hi
I implemented a receiver for a MADI signal some years ago. That was using a Spartan 6. If I recall the frequency was 125MHz, so it is definitely possible to do. I used one of the Xilinx app notes as a basis for the design. Cant remember the exact one. I will try and find the code and may be able to give more info.
0 Kudos
klumsde
Moderator
Moderator
809 Views
Registered: ‎04-18-2011

Hi @beandigital @nfrancque1 

I think this is the XAPP you want for Asynchronous capture of LVDS data in 7-series

https://www.xilinx.com/support/documentation/application_notes/xapp523-lvds-4x-asynchronous-oversampling.pdf

 

Keith 

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
nfrancque1
Visitor
Visitor
802 Views
Registered: ‎09-24-2020

@klumsde Please take another look at description above, data is not LVDS.  That is mostly what I am wondering about, how to apply the guide you linked for single ended data.

0 Kudos
nfrancque1
Visitor
Visitor
797 Views
Registered: ‎09-24-2020

I think the question is similar https://forums.xilinx.com/t5/Other-FPGA-Architecture/Connecting-a-single-ended-input-to-two-ISERDES2/td-p/1085367, which it looks like you also replied to.  Looking for the best way to recover a minimum 50 Mbps single ended signal that works up to ~120Mbps in an ideal world, where the clock is always known but the phase is not, on a 7 series.

0 Kudos
klumsde
Moderator
Moderator
789 Views
Registered: ‎04-18-2011

I don't think it can be done by just replacing the input buffer or taking its output to the adjacent ISERDES and its inversion path. 

In this case likely that you will have to build this yourself in fabric somehow 

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
beandigital
Scholar
Scholar
726 Views
Registered: ‎04-27-2010
I think I used xapp224 when I did it. But probably you can use some of the newer app notes for 7 series.
0 Kudos
dgisselq
Scholar
Scholar
714 Views
Registered: ‎05-21-2015

@nfrancque1 ,

So ... you have an incoming signal at 50MHz (will be higher eventually), clocked from an uncontrolled source, that you want to reclock properly into your FPGA.  Did I get that right?

So ... the steps to doing this would be:

  1. Sample the signal on input at a higher rate.  2x is too slow.  4x is commonly used.  3x may be good enough, but ppl like power-of-two math
  2. Recreate the clock from that incoming signal.
  3. Resample in the middle of the eye of this incoming clock.  Beware, the incoming signal may be either slower *or* *faster* than your (nominal) 50MHz clock,

How to recover a clock from an incoming signal?  Some mechanisms use an 8b10b encoding, some a 64b66b encoding method to guarantee sufficient transitions.  My personal favorite method is to ensure sufficient randomness in the incoming signal.  If the incoming bits are sufficiently random (i.e. no long runs of zeros or ones) then the (mathematically optimal) way of doing this is:

  1. Run the incoming signal through a matched filter.  (If you are 4x oversampled, then add 4 samples together.  In general, a '1' is added as though it were -1, and a '0' as though it were a '1'--this just makes the GF two math work out better, although you can usually map the bits as you wish.  This will give you numbers in the range of { -4, -2, 0, -2, 4 }.
  2. Square the result.  This should give you a stream, at 4x oversampled, of numbers from the set of { 0, 4, 16 }.  You can simplify this to { 0, 1, 4 } if you like.  Beware that, in the case of a constant input, you'll get a long stream of 16's that you can't do much with.
  3. Average these numbers over time on a cycle of 4 (or whatever your oversample rate is).  This helps to get rid of the runs of ones or zeros, so your averaging time will need to be longer than the longest run you expect.  If you don't have a sufficient number of averages, then the "optimal" location will get washed out amid other possibilities.
  4. Look for the point in the cycle with the maximum value after averaging
  5. That will be the location where you need to sample.

If you build this method, you should be able to run nicely at much higher speeds.

Hope this helps,

Dan

Tags (1)
nfrancque1
Visitor
Visitor
588 Views
Registered: ‎09-24-2020

@dgisselq Thanks for the detailed reply.  I ended up using the DRU oversampling defined in XAPP1294.  For anyone who stumbles upon this post later, the reference design worked for me without any changes, but the speed configuration vector did not work.  As long as the clock ratios were kept the same as recommended, that approach recovered the data successfully.  Closing this question now.

View solution in original post

0 Kudos