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: 
3,332 Views
Registered: ‎08-08-2017

Receiving data at 2.8GHz DDR (5.6GB/s line rate) and storing it in memory to be transmitted out to be evaluated in matlab

Hey guys so I am working on a project that is proving to have some road bumps. My partner may have posted on the forum, so you may see a similar problem discussed. First, the FPGA I am using is the Virtex-7 VC7215. So here is the explanation of what I am doing followed by what I need to accomplish. A company made an ADC that spits data out at 5.6GB/s on 6 lines. Once I successfully receive the data in, I need to analyze the waveform to see if the ADC correctly sampled the data. Therefore, I need a way to store the data and then somehow export it to matlab to reconfigure the data. With that being said, I am trying to find a way to do this. Does this seem feasible to anyone? I don't believe the fabric of the FPGA would allow me to simply receive 5.6GB/s of data and store it into any memory element. Maybe I am wrong or there could be another way? Any suggestions or ideas would be appreciated. 

 

0 Kudos
8 Replies
Historian
Historian
3,328 Views
Registered: ‎01-23-2009

Re: Receiving data at 2.8GHz DDR (5.6GB/s line rate) and storing it in memory to be transmitted out to be evaluated in matlab

You need to give more information.

 

You say 2.8GHz DDR. DDR implies that there is a clock associated with the data. If that is the case, then forget it - FPGAs can't even get anywhere NEAR this frequency with a synchronous interface.

 

However, if the data is being sent over a high speed serial link using JESD204B protocol, then this is not a problem. Xilinx has a JESD204B core that can receive the high speed serial stream and convert it to a parallel interface at significantly lower clock rates.

 

After the JESD204B core, you can then process the data as you need store it either in on-chip of off-chip memory. From there captured data can be transferred to a PC over a number of different protocol; PCIe or Ethernet would probably be desirable for this amount of data (although the VC7215 doesn't appear to have external memory, PCIe or Ethernet connectors...)

 

So the answer depends completely on the protocol from the ADC.

 

Avrum

0 Kudos
3,325 Views
Registered: ‎08-08-2017

Re: Receiving data at 2.8GHz DDR (5.6GB/s line rate) and storing it in memory to be transmitted out to be evaluated in matlab

You are correct in assuming there is a clock. The ADC has 6 outputs and a clock all synchronous to each other. This is not a typical problem which will require problem solving and we will be using a clock divider on the synchronous clock to bring it up to 2.8GHz on the board via 2 quads, 6 transceivers, and their CPLLs. The data comes out of the ADC with no communication protocol associated with it. 

0 Kudos
Historian
Historian
3,313 Views
Registered: ‎01-23-2009

Re: Receiving data at 2.8GHz DDR (5.6GB/s line rate) and storing it in memory to be transmitted out to be evaluated in matlab

You are correct in assuming there is a clock. The ADC has 6 outputs and a clock all synchronous to each other. This is not a typical problem which will require problem solving and we will be using a clock divider on the synchronous clock to bring it up to 2.8GHz on the board via 2 quads, 6 transceivers, and their CPLLs. The data comes out of the ADC with no communication protocol associated with it. 

 

I don't understand what you are saying here. If this is a 5.6Gb/s 6 line interface with a clock and no protocol then this is just impossible to handle. However, I find it hard to believe that anyone would produce a device with an interface like this; even in the ASIC world, this would be (at least close to) impossible to deal with.

 

Why don't you tell us what ADC you are working with.

 

Avrum

Tags (1)
0 Kudos
3,225 Views
Registered: ‎08-08-2017

Re: Receiving data at 2.8GHz DDR (5.6GB/s line rate) and storing it in memory to be transmitted out to be evaluated in matlab

The ADC is actually a new technology that we are testing and I currently am not even allowed to know the name of it. However, what you just said is something I have been concerned with for quite awhile now. We actually have an ASIC that was build as a rate converter for this ADC; however, before the ASIC is to be paired with the ADC, we wanted to test the ADC - from our conversation you can see that with no encoding scheme, NRZ data, and 5.6GB/s there is almost no way to receive the data at that speed. Can you elaborate on why the FPGA can not operate at these frequencies even with a synchronous clock?

 

 

0 Kudos
Highlighted
Historian
Historian
3,197 Views
Registered: ‎01-23-2009

Re: Receiving data at 2.8GHz DDR (5.6GB/s line rate) and storing it in memory to be transmitted out to be evaluated in matlab

At this rate, the Unit Interval (length of a bit) is 179ps. When you take into account other factors like duty cycle distortion, signal integrity, clock to data skew, board routing mismatch, the width of the data eye is going to be smaller than this (maybe even non-existant - designing channels at 5.6Gbps requires all kinds of fancy analog stuff like equalization, pre-emphasis, etc...)

 

To statically capture data with a synchronous clock in conventional I/O, a MUCH larger data eye is required - more like 1ns to 1.5ns in width. So clearly this isn't an option.

 

Even with "perfect" dynamic calibration, with the best capture mechanism with the fastest speed grade the smallest data eye that can be captured is specified as Tsamp in the datasheet, which is 300ps (Kintex-7 in a -3 speed grade). So clearly this isn't an option.

 

So that leaves working with the high speed transceivers. These do not use a synchronous clock, but rely on clock/data recovery (CDR). For CDR to operate, you need some mechanism of ensuring maximum run length and DC balance, performing framing, performing channel bonding, etc... These are all done using a protocol designed for these - things like 8b/10b, 64b/66b or 64b/67b encoding. Without these, you cannot extract the data.

 

So, without protocol, you cannot use the high speed receivers, and at these rates you cannot use conventional receivers. Therefore, you cannot receive this stream in an FPGA.

 

While ASICs are much faster, if this interface is going over a board from the ADC to an ASIC, you are going to face many of the same problems - this interface may well be impossible. (Of course if the ADC and the data converter are on the same die, then that is a different story).

 

Avrum

Tags (2)
0 Kudos
3,182 Views
Registered: ‎08-08-2017

Re: Receiving data at 2.8GHz DDR (5.6GB/s line rate) and storing it in memory to be transmitted out to be evaluated in matlab

Here is the interesting part regarding your comment about the clock/data recovery. We have total control of the sine wave the enters the ADC for testing, so we can create one such that we toggle 10101010 on all 6 lines which would be DC balanced and therefore give us a possibility for recovery. Does this seem feasible and then route the data to the dual port BRAMs?

0 Kudos
Historian
Historian
3,160 Views
Registered: ‎01-23-2009

Re: Receiving data at 2.8GHz DDR (5.6GB/s line rate) and storing it in memory to be transmitted out to be evaluated in matlab

Here is the interesting part regarding your comment about the clock/data recovery. We have total control of the sine wave the enters the ADC for testing, so we can create one such that we toggle 10101010 on all 6 lines which would be DC balanced and therefore give us a possibility for recovery. Does this seem feasible and then route the data to the dual port BRAMs?

 

No. The protocol must be used on all data, not just on link initialization. While you might be able to solve some of the issues (like framing and channel bonding) at link initialization time, the DC balancing and (most importantly) the maximum run length must be maintained at all times that the link is up. You simply cannot pass non-protocol data through a CDR link.

 

Avrum

Tags (2)
0 Kudos
3,149 Views
Registered: ‎08-08-2017

Re: Receiving data at 2.8GHz DDR (5.6GB/s line rate) and storing it in memory to be transmitted out to be evaluated in matlab

You have been a great help. Thank you for this information. 

0 Kudos