08-08-2019 06:10 PM
I'm a student working on a research project. I'm having a bit questions regarding the VC707 datasheet, and really appreciated if I could find solution from this forum.
Backgrond: I am currently designing a customized ADC Eval-Board that can interface with Xilinx FPGA Board for DSP via FMC connectors, so effectively, I think I'm building a FMC daughter card for the FPGA. We are currently investigating the possibility to choose VC707 as our DSP board, and find out whether the FPGA board is fast enough to handle all the data coming from FMC ports.
The ADC Eval-Board I'm building contains 16 ADC chips operate in interleaving. Each ADC chip outputs 4-bit wide (D0~D3), twos complement, signal data rate, LVDS data at 640 MSPS, plus a differential Data-Clock-Output (DCO+/-) signal to provide latch timing with receiving logic. There is also a Overrange (OR+/-) condition signal output, but it should be at a much lower frequency if the over range condition doesn't occur.
I'm planning to use 2 FMC (HPC) ports to interface all the outputs from 16 ADC chips. So, each FMC port will handle 48 pairs of differential signals (34 LA pairs + 14 HA pairs).
1. On page 60 of the VC707 User Guide (v1.8), I found the signaling speed ratings, which says "(Differential) Optimal Vertical: 9GHz, Optimal Horizontal: 16GHz, High Density Vertical 7GHz" Could anyone help specify what does "vertical", "horizontal", and "high density vertical" means?
2. How should I calculate and check whether the FPGA board is fast enough to handle all the signals from these 2 FMC ports?
Thank you very much for your time and help!
08-09-2019 09:29 AM - edited 08-09-2019 10:22 AM
Could anyone help specify what does "vertical", "horizontal", and "high density vertical" means?
These terms are from test reports provided by the manufacturer, Samtec, of the FMC connectors on the VC707. These terms refer to orientation/location of LVDS signal pairs in the FMC connector. You will find more information about these terms in Samrec test reports .
How should I calculate and check whether the FPGA board is fast enough to handle all the signals from these 2 FMC ports?
This question can be broken into a group of questions that fall into the categories of acquiring, storing, and retrieving-from-FPGA the data generated by the ADCs. The Virtex-7 on the VC707 (and all FPGAs) can perform many tasks in parallel. That is, acquiring and storing data from each ADC can be done by the Virtex-7 independently of the other 15 ADCs. Retrieving the ADC data stored in the FPGA will probably be done in a serial (rather than parallel) manner. Hence, the Virtex-7 will probably acquire bursts of data from the 16 ADC. These data burst periods last until available memory in the Virtex-7 is full. Then, data acquisition will probably need to be paused while data is retrieved from the Virtex-7 (eg. via LAN connection).
Lets's focus on data acquisition/storing (ie. tasks that can be done in parallel). Then, to answer your question about “fast enough” for all 16 ADC, it is sufficient to answer the question for just one ADC channel. Here is a group of question that help you determine if the Virtex-7 is “fast enough”. The answer to each question is a value for allowable maximum clock frequency, FMAX.
1) FMC connector and cable limitations? From UG885(v1.8) page 60, FMAX=9GHz.
2) Virtex-7 data acquire/capture limitations? It appears that your ADCs produce serial streams of data. Further, FMC connections on the VC707 use standard IO of the Virtex-7. So, you will want to use the serial-to-parallel (ISERDES) feature of the Virtex-7 which is described by documents, UG471(v1.10) and XAPP1017(v1.10). From these documents and Table 1 of XAPP1017, we find the FMAX of the BUFIO clock buffer will limit ISERDES operation to FMAX=800MHz. You will also find FMAX for the BUFIO in Table 36 of the Virtex-7 datasheet, DS183(v1.28),
3) Virtex-7 clocking limitations? Clock generation and distribution inside the Virtex-7 uses the MMCM clock management tile and BUFG clock buffers. From DS183, we find that FMAX for these components is 1066MHz and 741MHz, respectively from tables 40 and 35.
4) Virtex-7 data storage limitations? You will probably use the block-RAM, BRAM, storage found in the Virtex-7 because of its speed (it can store a 4-bit data value from the ADC in 1 clock cycle). From table 33 of DS183 we find FMAX=601MHz.
In summary, I understand that each of your ADCs is 4-bit and is operating at 640MSPS, which is a data rate of 4*640=2560MB/s and equivalent to FMAX=2560/2=1280MHz when using a double-data-rate (DDR) interface. So, to meet your requirements, the FMAX for questions 1) and 2) must be at least 1280MHz – and you can see that the FMAX-answer to question 2) falls far short. If the Virtex-7 could have acquired the data, then the data needs to be clocked through the FPGA and saved at your sampling rate of 640MHz. Here again, the FMAX-answer to question 4) falls short. So, it appears that the VC707 board cannot meet your requirements.
For your homework 😊, you can investigate boards that use the Xilinx UltraScale FPGAs, which are a newer and faster alternative to 7-Series FPGAs. That is, for a Virtex UltraScale FPGA , find documents that like the ones I have referenced above for the Virtex-7 and find the associated values of FMAX.
08-10-2019 04:00 PM
Thank you very much for your reply! I've been studying your response, and have a few follow-up questions:
Background: The ADC I'm planning to use is AD9267 from Analog Devices, which is a 16-bit resolution Sigma-Delta ADC, outputs twos complement, single data rate, LVDS data at 640 MSPS. The output is four bits wide per channel.
1. About your "2) Virtex-7 data acquire/capture limitations?", why do I have to use the SERDES feature from the FPGA? If I don't need to use the SERDES, I think FMAX = 800 MHz for the I/O buffers is enough for acquiring the ADC data. Am I understand this correct, did I miss someting?
2. If I'm planning to let 8 interleaved ADCs to share 1 FMC port (the whole project is a 16 ADC interleaving, and I'm planning to use 2 FMC connectors to interface all the ADCs data into FPGA, so each FMC will be shared by 8 ADC chips), wouldn't the data rate become 640*4*8=20.48GB/s? If so in that case, not even the FMC connector will be fast enough to handle the total data rate. Did I understand this wrong? Is it 640*4*8=20.48GB/s, or 640*4=2.56GB/s? But why would it be 640*4=2.56GB/s if these 8 ADC chips are interleaved?
Thank you very much for your time and help!
08-10-2019 06:34 PM
You are welcome. This is a very interesting and unusual design challenge!
Before addressing your new questions, let’s talk about the AD9267 digitizer you have selected. The manufacturer, Analog Devices, does not recommend this part for new designs. Further, with an analog input bandwidth of 10MHz and a sampling rate of 640MSPS, the AD9267 is sampling at 32x the Nyquist rate. Please confirm that this unusually high sampling rate is needed and please explain why you need it.
What are your other reasons for choosing the AD9267?
08-10-2019 07:22 PM
The requirements for my project are follow:
1. must be a Sigma-Delta ADC (this is a must)
2. we want to achieve a very wide input bandwidth Sigma-Delta ADC, hence why we decided to interleave 16 ADC chips. So the higher the input bandwidth of each individual ADC, the less number of ADC chips there are. And AD9267 has the widest input bandwidth from what I found, hence I chose it.
08-11-2019 03:20 AM
I understand that Sigma-Delta ADCs use a low-bit, high-speed digitizer followed by a demodulator (averaging and decimation) to achieve a higher number of bits - but not higher analog bandwidth.
The AD9267 has an analog input bandwidth of 10MHz. Please explain the interleave method you plan to use and how it gives an input bandwidth greater than 10MHz.
08-11-2019 12:25 PM
In short, (time domain) interleaving ADCs is to present only a slice of input signal into each individual ADC (called a "channel"), and effectively achieve higher Nyquest bandwidth. To achieve this, it will also require a very fast sampling front-end (or "MUX") that can multiplexing the input signal into the parallel array of identical ADCs. This sampling front-end, however, is not included in my project (at least for now...). So the premise of my questions is from the ADC array till the DSP FPGA-Board, and right now I'm struggling with figure out how to interface between the parallel ADC array and the FPGA-Board.
Here is an article from Analog Devices explaining the interleaving ADCs: https://www.analog.com/en/analog-dialogue/articles/interleaving-adcs.html
08-11-2019 04:53 PM
Thanks for the article explaining the interleave method. So that others reading this thread can follow along, I have copied the following figure from the article.
As the caption to the figure says, the interleave method allows us to achieve a signal sample rate of fs by using M digitizers, each sample at a rate of fs/M.
According to Nyquist, if a signal has bandwidth, B=fs/2, then we can capture all the information in the signal by sampling it at a rate of 2B=fs. The AD9267 has an analog input bandwidth is 10MHz, which means that a signal entering this ADC will have no more than 10MHz bandwidth. Thus, according to Nyquist, we could use the AD9267 to capture all information in a signal with a bandwidth of 5MHz, by sampling it at 10MHz (10MSPS). From a signal-bandwidth viewpoint, there is no reason to collect samples from the AD9267 at a rate faster than 10MSPS. This 10MSPS rate is very different from the current fixed output rate of 640MSPS for the AD9267. Being able to work at 10MSPS would greatly simplify your design – and allow each of your eight digitizers to run at 10/16=0.625MSPS.
If the above arguments make sense to you, then consider choosing another sigma-delta ADC with an adjustable sampling frequency and wide analog input bandwidth.
08-11-2019 07:07 PM
Thank you for your reply! However, I'm afraid that I might not elaborate my task. To reply to your post:
1. The reason for AD9267 to output higher rate than the Nyquest rate is that AD9267 is a Sigma-Delta ADC. The Sigma-Delta architecture uses oversampling to lower the quantization noise within the Nyquest band in order to achieve higher resolution. Hence this ADC outpus 16-bit resolution. In this case of AD9267, it oversamples the input signal by 32 times (input bandwidth=10MHz makes the Nyquest frequency=10x2=20MHz, whereas the sampling frequency=640MHz, hence 640/20=32 over-sample-rate "OSR").
If we somehow lower its sampling rate, it will degrade the resolution, which I would like to avoid. Also, notice that this AD9267 chip doesn't have built-in decimation filter, hence its output rate equals its sampling rate.
2. Back to the Figure 1 you cited from the article, what I meant is AD9267 will be used as each individual ADC in each channel. So, I'm interleaving 16 AD9267 chips to achieve effectively 10MHz x 16 = 160MHz input bandwitdh.
I hope these will help clarify my task. Again, thank you for your time and help!
08-12-2019 05:22 AM
So, I'm interleaving 16 AD9267 chips to achieve effectively 10MHz x 16 = 160MHz input bandwitdh.
The 10MHz bandwidth of the AD9267 is an analog input bandwidth. That is, frequency spectral content above 10MHz is filtered off (or at least highly attenuated) from any signal being sent to the AD9267 before it reaches the digitizer. No amount of tricky signal processing can recover this filtered-off spectral content and give you more than 10MHz bandwidth.
…this AD9267 chip doesn't have built-in decimation filter
This fact is making life so much harder for you. The paper from Manganaro and Robertson does not say that the interleave method must be applied before use of the Sigma-Delta ADC decimation filter. In fact, the paper does not even specify the type of ADC. So, I again suggest that you find another Sigma-Delta ADC with a decimation filter. Then, the data-rate coming out of the ADC will be the Nyquist rate, which is much slower than the data-rate going into the decimation filter. –and your life will be much easier.
08-12-2019 05:31 PM
"The 10MHz bandwidth of the AD9267 is an analog input bandwidth. That is, frequency spectral content above 10MHz is filtered off (or at least highly attenuated) from any signal being sent to the AD9267 before it reaches the digitizer."
I think this 10MHz bandwidth means the effective bandwidth of the integrator (inside Sigma-Delta modulator). That is, the noise-shaping resulted from the Sigma-Delta modulator can only push the quatization noise away up to 10MHz. You can check this in the AD9267 datasheet P13 Section "Theory of Operation". There is no "filter off" action inside the Sigma-Delta modulator, and all signal power (input signal + quantization noise) is sampled up to the sampling frequency. The only affect is that as frequency goes higher, the quantization noise component increase and input signal component decrease (i.e.: the out-of-band, > 10MHz, power spectrum density is dominated by quantization noise with very little input signal. Hence the out-of-band spectrum is effectively useless. Hence the datasheet specify that the effective input bandwidth of this ADC is 10MHz). Here is an article talking about the Sigma-Delta modulator: https://www.analog.com/media/en/training-seminars/tutorials/MT-022.pdf
Cited from the article above, a diagram of 1st-order Sigma-Delta ADC:
"No amount of tricky signal processing can recover this filtered-off spectral content and give you more than 10MHz bandwidth."
Interleaving M identical ADCs can effectively increase the Nyquest bandwidth by M times. For example, AD9267 has (effective) input bandwitdh = 10MHz, which makes the Nyquest bandwidth = 20MHz. The sampling frequency = 640MHz, makes the over-sample-ratio (OSR) = 32. This OSR is needed for noise-shaping of the Sigma-Delta modulator in order to achieve 16-bit resolution. So, if I interleave 16 of AD9267 chips, the overall system would still have OSR=32 (hence still delivering 16-bit resolution), and the Nyquest bandwidth will become 10 x 16 = 160MHz, hence the overall system becomes a wideband input bandwidth ADC.
08-13-2019 03:46 AM
Thanks for your detailed thoughts on bandwidth. However, I find the AD9267 data sheet to be unclear on this issue. Please discuss this with your project advisor before continuing. Your interleave project requires that the AD9267 have 160MHz of input analog bandwidth.
So, what about my 2nd point? That is, why are you sending data to the FPGA before sending it through decimation? If you send the data before decimation then the data rate from each AD9267 is 640MSPS. If you send the data after decimation then the data rate from each AD9267 is only 10MSPS.
08-14-2019 02:16 PM
Thank you for your reply, and your suggestions of using lower data rate ADC.
Meanwhile, I'd very appreciate if you could help clarify a few questions I posted before, i.e:
1. In your reply about "2) Virtex-7 data acquire/capture limitations?", why do you suggest to use the SERDES feature from the FPGA? Because the AD9267 datasheet states that the output data rate is 640MSPS (4-bit, Single-Data-Rate). Also, the Timing Diagram from AD9267 datasheet shows:
According to this picture, it seems the AD9267 is outputing 4-bit outputs in parallel at rate of 640MSPS. Since you also said that the data acquisition of each ADC is done in parallel, isn't it means that I should look for FMAX of I/O Blocks to be only greater than 640MHz? If that's the case, then 800MHz should be sufficient.
2. This 2nd question is related with the 1st question above. In your reply, you pointed me to "Table 1 of XAPP1017", and concluded that because FMAX of the BUFIO clock buffer of ISERDES can only operates up to 800MHz, the 7-Series Virtex FPGA is not useable. However, in document XAPP1017, I found this:
It seems that "BUFIO" is only used in SERDES features. Again, if I won't use the SERDES feature, then this FMAX=800MHz should not be a concern. In that case, should I looking for the FMAX of I/O Blocks? Do you know where I can find the FMAX of the receiving I/O Blocks?
3. There is one conclusion in your reply that I'm not quite understand, which is:
"In summary, I understand that each of your ADCs is 4-bit and is operating at 640MSPS, which is a data rate of 4*640=2560MB/s and equivalent to FMAX=2560/2=1280MHz when using a double-data-rate (DDR) interface."
If each FMC connector is shared by 8 ADCs, what is the total data rate? Is it still 640*4=2.56Gb/s? Or 640*4*8=20.48Gb/s? If it is 20.48 Gb/s, then not even the FMC connector will be fast enough to handle the total data rate...... :-(
08-14-2019 06:00 PM - edited 08-14-2019 06:01 PM
Thanks for continuing the discussion.
Some of my early statements were given before I fully understood the AD9267 interface.
why do you suggest to use the SERDES feature from the FPGA?
SERDES is used for serial-data interfaces, converting them to a parallel-data interface with slower clocking. Since the AD9267 interface is already a parallel-data interface, then you would not normally use SERDES.
it means that I should look for FMAX of I/O Blocks to be only greater than 640MHz? …. 800MHz should be sufficient.
You are correct.
Do you know where I can find the FMAX of the receiving I/O Blocks?
FMAX specifications are given in the FPGA datasheets (eg. see Xilinx document DS183 for datasheet of Virtex-7).
There is one conclusion in your reply that I'm not quite understand, which is: "In summary, I understand that each of your ADCs is 4-bit and is operating at 640MSPS, which is a data rate of 4*640=2560MB/s and equivalent to FMAX=2560/2=1280MHz when using a double-data-rate (DDR) interface."
This conclusion assumed a serial-data interface with the AD9267. You can now ignore this conclusion.
The AD9267-to-FPGA interface is called a source-synchronous-input interface to the FPGA. The parallel data bits, D0-D3, and the data clock, DCO, will all be routed into the FPGA. In a Virtex-7, DCO would be routed to a BUFIO (FMAX=800MHz) clock buffer. Each of D0-D3 would be routed through an IDELAY (FMAX=800MHz) and into an IOB register which is part of the IDDR. The clock output from the BUFIO will clock the IOB register and the IDELAY is used to delay the data (if necessary) to place the clock capture edge in the middle of the data-eye. However, with DCO=640MHz, the data-eye is only 1.56ns wide (one period of DCO) and not wide enough when we take into account Process-Voltage-Temperature (PVT) variations within the FPGA. I am quite sure that you cannot make this source-synchronous-interface work on any Xilinx FPGA. Depending on characteristics of the ADC you choose, a DCO frequency below 250MHz is probably needed to get reliable data transfer from the ADC to the FPGA using a source-synchronous-interface. For more details see comments of avrumw in the following threads.
08-15-2019 05:35 PM
Thank you very much for your helps! I felt I'm learning more and more about the FPGAs :-)
I have a follow-up question and very appreciate if you could clarify. There is one conclusion from you reply that I don't understand:
"However, with DCO=640MHz, the data-eye is only 1.56ns wide (one period of DCO) and not wide enough when we take into account Process-Voltage-Temperature (PVT) variations within the FPGA. I am quite sure that you cannot make this source-synchronous-interface work on any Xilinx FPGA. Depending on characteristics of the ADC you choose, a DCO frequency below 250MHz is probably needed to get reliable data transfer from the ADC to the FPGA using a source-synchronous-interface."
Could you help elaborate how did you come up with 1.56nS of data-eye-window is too short? And where could I find information to verify this? I've been searching in 7-series' datasheets and I can't find this information...
Thank you very much for your time and help!
08-16-2019 05:33 AM
Could you help elaborate how did you come up with 1.56nS of data-eye-window is too short? And where could I find information to verify this?
This refers to limitations of the IOB register used to capture data coming from the ADC. This register has specifications called setup and hold, which refer to the fact that the data input to the register must be stable for a short time both before and after the register receives a clock rising-edge. As shown in the figure below, we ideally want the clock rising-edge to be located halfway between the data-change times (ie. we want the rising-edge in the middle of the data-eye). Note that the width of the data-eye in an SDR interface is equal to the period of the interface clock.
The problem with FPGA IO (like the source-synchronous interface to your ADC) is that clock and data signals get delayed as they pass through components in the FPGA. Further, these delays change as temperature and voltage inside the FPGA change (called PVT variations). So, even though we initially adjust things so that the rising-edge (aka capture-edge) of the clock is in the middle of the data-eye, PVT changes will cause the position of the rising-edge to move within the data-eye. If the clock capture-edge position moves too close to the data-change times then you have violated setup and hold for the IOB register and the data will not be received properly.
The Xilinx Vivado tools can be used to completely model the FPGA-to-ADC interface and to determine whether PVT changes will cause setup and hold violations at the IOB register.
However, a rule-of-thumb calculation can be done as follows (using numbers from datasheet DS183 for the Virtex-7). Setup and hold times for the IOB register are small (a few tenths of nanoseconds (ns)). Clock delay for your FPGA-to-ADC interface can be computed roughly as the BUFIO delay (1.04ns, Table 36) plus the LVCMOS33 buffer delay (1.40ns, Table 19) for a total of 2.44ns. Further, we can expect this total delay to vary 3:1 over PVT (ie. from about 1.22ns to 3.66ns). This variation, (3.66-1.22=2.44ns), needs to be smaller than the width of the data-eye minus the setup and hold times if the clock capture-edge is to remain in the data-eye over PVT. So, if we use a data-eye width of about 3.0ns, then this equates to a clock-period of 3.0ns and a clock-frequency of 333MHz. However, the ADC also has PVT variations in the way it outputs clock and data, which means we should further widen the data-eye and lower the interface clock frequency – to say about 250MHz.
08-19-2019 03:21 PM
Thank you for your reply and helps!
I have a few follow-up questions and really appreciate if you could help:
1. Do you know where could I find the range of the IDELAY that I can tune to compensate for the process corners in the Virtex-7 datasheet? what is the name of such parameter in the datasheet?
2. Do you know where I can find the recommended data rate of LVDS from Xilinx?
Thank you very much for your time and help!
08-19-2019 05:14 PM
The parameter for tuning IDELAY is IDELAY_VALUE shown in Table 2-5 of UG471(v1.10). It has 32 values, each value representing a step/resolution, T(IDELAYRESOLUTION) = 1/(32 x 2 x FREF) us, as shown in Table 28 of DS183(v1.28). The parameter, FREF, is the Reference Clock frequency described on page-124 of UG471.
I don’t think you’ll find a Xilinx recommended data rate for LVDS, since the other things inside the FPGA that we have talked about will limit data-rate before LVDS.