Solutions Products Support  

Help Sign In

This board  Search all content

Community Forums  Forums  Hardware Development  Versal and UltraScale Architecture™  Zynq Ultrascale+ LVDS in native mode or component ...

xu58
Visitor

03-25-2021 09:17 AM

1,225 Views
Registered: 02-03-2021

Zynq Ultrascale+ LVDS in native mode or component mode

Hi everyone,

I want to connect an acquisition board (model AFE5808) to the Zynq Ultrascale+ board (xczu6c) via FMC connector.
The AFE5808 board consists of 8 channels, 8 ADC's with 14 bits resolution and 40MHz sampling frequency.

The data is received by LVDS. I receive two differential pairs for each channel and four differential pairs of clock, two for frame clock and two for bit clock.

Data is received in DDR mode. The bit clock is aligned to the center of the data.

Well, I have a frame clock frequency of 40MHz, bit clock of 280MHz and a data rate of 560Mbps.

Data goes to HP banks 65 and 66, frame clock to HP bank 65 to GC pins and bit clock to HP bank 66 to GC pins.

The application notes for Ultrascale+ do not have examples of this case. Xapp1315 only uses one clock, however xapp524 is similar but is not for
Ultrascale+.

I have many doubts about how to start my project.

Do you recommend me to use the two clock signals coming from the ADC or to use only one and use a MMCM/PLL?

Do you recommend me to use component mode or native mode?

If you need more information I can offer it to you.

Thanks in advance.

Regards.

 0 Kudos  Share Reply

All forum topics  Previous Topic Next Topic 

7 Replies

[email protected]
Guide

03-26-2021 05:51 PM - edited 03-26-2021 05:54 PM

1,159 Views
Registered: 01-22-2015


@xu58

Data exchange between the FPGA and the AFE5808 is called DDR source synchronous input, because the AFE5808 is forwarding both LVDS data
(DATIP, DATIN) and LVDS bit-clock (DCLKP, DCLKN) to the FPGA.

The AFE5808 is also forwarding a LVDS frame-clock (FCLKP, FCLKN) to the FPGA which should be captured as data (ie. do not treat it as a clock).

The good news is that I think this interface will pass static timing analysis. That is, you probably don’t need the complicated dynamic-capture method
described in XAPP524. Further, the 280MHz clock is not too fast to use in the FPGA fabric.

So, try implementing the architecture shown below. The bit-clock should enter the FPGA on a clock-capable (GC) LVDS pin pair in an HP bank. The data
and the frame-clock can enter the FPGA on any LVDS pin pair in the HP bank. Note that the IDDRE1 is used to capture data. That is, we are using
UltraScale component mode instead of native mode - because component mode is easier to use and is sufficient. The bit-clock is routed to an MMCM
(which I called clkgen) that is configured so that input and output clocks are both 280MHz and specified to be “phase aligned”.

The following template shows the format of timing constraints for this interface. Note that the constraints use setup and hold specifications for the AFE5808
interface which are shown in the AFE5808 datasheet. The datasheet explains that setup and hold are the same for the data and the frame-clock.

# AFE5808 at 40MHz sampling, bit-clock = 280MHz, DDR interface

set t_su 0.55; #AFE5808 output minumum setup time(ns)
set t_hd 0.73; #AFE5808 output minimum hold time(ns)
set t_hp 1.785; #half-period(ns) of 280MHz DDR clock
set min_delay [expr $t_hd]
set max_delay [expr $t_hp - $t_su]
#
set DDR_Clock [get_clocks -of_objects [get_ports DCLKP]]
#
set_input_delay -clock $DDR_Clock -min $min_delay [get_ports DATIP]
set_input_delay -clock $DDR_Clock -max $max_delay [get_ports DATIP]
set_input_delay -clock $DDR_Clock -min $min_delay [get_ports DATIP] -clock_fall -add_delay
set_input_delay -clock $DDR_Clock -max $max_delay [get_ports DATIP] -clock_fall -add_delay
#
set_input_delay -clock $DDR_Clock -min $min_delay [get_ports FCLKP]
set_input_delay -clock $DDR_Clock -max $max_delay [get_ports FCLKP]
set_input_delay -clock $DDR_Clock -min $min_delay [get_ports FCLKP] -clock_fall -add_delay
set_input_delay -clock $DDR_Clock -max $max_delay [get_ports FCLKP] -clock_fall -add_delay
#
set_property PHASESHIFT_MODE LATENCY [get_cells {CG1/inst/mmcme4_adv_inst}]

The purpose of the “PHASESHIFT_MODE LATENCY” latency constraint shown above is to make it easy for you to add positive or negative delay to the bit-
clock by simply using +/- phase settings for the output clock of the MMCM. So, the final tuning of the interface consists of trying different values of output-
clock-phase for the MMCM until you find one that makes the interface pass timing analysis.

Finally, you’ll need to write some HDL that looks at samples of the frame-clock captured in registers DATO(2) and DATO(3) and uses these values to order
the data samples captured by registers DATO(0) and DATO(1) into the 14-bit values being collected by the AFE5808 ADC.

Cheers,
Mark

Tags: ADC frame clock AFE5808 interface DDR src sync input wframe clock

 1 Kudo  Share Reply

xu58
Visitor

03-27-2021 05:47 AM

1,117 Views
Registered: 02-03-2021


[email protected]

Nice to meet you Mark.

Thank you very much for your answer.

Very good description of the DDR source synchronous (FPGA-AFE5808).

1. The AFE5808 is also forwarding a LVDS frame-clock (FCLKP, FCLKN) to the FPGA which should be captured as data (ie. do not treat it as a clock).

Ok, I will treat it as data. (My idea was to treat it as clock signal just like bitclock). Thanks

2. The good news is that I think this interface will pass static timing analysis. That is, you probably don’t need the complicated dynamic-capture method
described in XAPP524.

Does this mean I don't have to use a Gearbox for data nor a calibration state machine for bitclock as in the Xapp1315 application note?

https://www.xilinx.com/support/documentation/application_notes/xapp1315-lvds-source-synch-serdes-clock-multiplication.pdf

Do I also not need to use IDELAYE3 or ISERDESE3 for my application? I had understood that it was necessary to use ISERDESE3 to deserialize the ADC
data.

I was think to mix ideas from the xapp1315 and xapp524 application notes because of the information I had read on the forum and in the application notes.

3. The data and the frame-clock can enter the FPGA on any LVDS pin pair in the HP bank.

The frame clock enters the FPGA via the FMC connector pins which are GC pins, Is this a problem?, Could I disable the GC function of the pins?

The rest of the information I think I understand.

I will check it out and if I have any more questions I will write it here.

Again, thank you very much Mark for your answer and your knowledge.

Regards.

 0 Kudos  Share Reply

[email protected]
Guide

03-27-2021 05:37 PM

1,070 Views
Registered: 01-22-2015

@xu58

Does this mean I don't have to use a Gearbox for data nor a calibration state machine for bitclock as in the Xapp1315 application note?

Yes, when static capture of the data is possible then you don't need the gearbox and you also don't need many other things described in XAPP1315 and
XAPP524.

The dynamic capture methods described in XAPP1315 and XAPP524 are needed when you have a small (typ < 1ns) data eye. The data eye for AFE5808
DDR interface starts out with a width equal to 1.786ns, which is half the period of the 280MHz interface clock. From this, we must subtract (max_delay -
min_delay = 0.5ns), where max_delay and min_delay are shown in the constraints I gave you. The resulting data eye width of (1.786 - 0.5 = 1.286ns) is
greater than 1ns which is the rule-of-thumb value where static capture of the data is just possible.

Static capture of the data means that once the architecture in your FPGA is built and initially-adjusted to work properly, then no more adjustment is needed
to make it work properly when Process (another FPGA with same part#), Voltage, and Temperature (PVT) change within specifications.

When the data eye is too small, then PVT variations can cause data capture to occur outside the safe window of the data eye. Then, dynamic capture
methods are needed to continuously move the time of data capture so that it stays in the window of the data eye.

Do I also not need to use IDELAYE3 or ISERDESE3 for my application? I had understood that it was necessary to use ISERDESE3 to deserialize
the ADC data.

You can use IDELAYE3 instead of the MMCM if you want. However, when it is possible to use the MMCM then you should because the MMCM can both
delay and advance the clock. IDELAYE3 can only delay the clock. The IDDRE1 is actually an ISERDESE3 with a deserialization of 1:2. Higher
deserialization (eg. 1:8) is used when the interface clock is too fast to be operated in the FPGA fabric. However, the 280MHz frequency of AFE5808
interface is not too fast for the FPGA fabric. So, the 1:2 deserialization of the IDDRE1 is all you need.

The frame clock enters the FPGA via the FMC connector pins which are GC pins, Is this a problem?, Could I disable the GC function of the pins?
It is not a problem that the frame clock enters the FPGA on GC pins.

 1 Kudo  Share Reply

avrumw
Expert

03-27-2021 09:09 PM

1,050 Views
Registered: 01-23-2009

I kind of need to disagree with [email protected] ...

A data window of <1.3ns is unlikely to be big enough for static capture. In the 7 series you needed at least a bit more than this and potentially as much as
1.75ns (depending on how much phase adjustment was needed).

Unfortunately, UltraScale/UltraScale+ are slower than 7 series when it comes to component mode I/O; you can only get really fast interfaces in native mode.

But, for native mode, your clocks need to be on *BC pins (DBC/QBC) - not on GC pins. So since the clocks from the FMC are on GC pins, you must use
component mode.

There is no harm in trying the constraints that [email protected] suggested, but I suspect that you will not get them to pass...

One more word of warning

IDELAYE3 can only delay the clock.

It is not recommended to use the IDELAYE3 on a clock (it is even stated in the User Guide). The technology of the IDELAYE3 is different than the IDELAYE2
on the 7 series; in the 7 series, you could (and it was even recommended to) use the IDELAYE2 on a clock. The IDELAYE3 should only be used to delay
data (not clock).

Avrum

 1 Kudo  Share Reply

[email protected]
Guide

03-28-2021 04:32 AM

1,008 Views
Registered: 01-22-2015

In Vivado v2020.2 for an XCKU5P and with a suitable phase setting for the MMCM output clock, the methods I describe allow the AFE5808 interface to pass
timing analysis with setup and hold slacks of +0.3ns and +0.2ns.

 1 Kudo  Share Reply

xu58
Visitor

04-09-2021 03:05 AM - edited 04-09-2021 03:14 AM

818 Views
Registered: 02-03-2021


Ok. Thank you for your answer.

I decided to implement the design proposed by Mark. In order to implement the design, I had to connect the registers outputs to unused pins, otherwise
Vivado would give an error, it said: empty project.

After fixing this error, the design didn't pass static timing analysis. With an MMCM setting, +90degs phase, I have WNS = 0.236ns y WHS = 0.26ns. Now, I'm
pass the static timing analysis.

Well, now I want to see if I can receive data in the fpga. I want to connect the AFE5808 board via the FMC connector to the fpga and observe if I receive data
over the pins. I haven't written any HDL code yet, I just have the following interface implemented:

Question 1:

I have read about ILA (integrated logic analyzer) do I have to use ILA to visualize the results as I said? What do I connect to "clk"?, my input clock "dclk"?
DCLK has a frequency of 280MHz and ILA only supports 100MHz, Can that "clk" signal be removed?

Can ILA instantiation affect the static timing analysis? Do I have to add any constraints?

Other options? Any recommendations?

Thanks in advance.

Regards.

 0 Kudos  Share Reply

[email protected]
Guide

04-09-2021 04:32 PM

785 Views
Registered: 01-22-2015


@xu58

I suggest that you learn to save the data output from registers, (FDRE_DATA_a, FDRE_DATA_b, FDRE_FCLK_a, FDRE_FCLK_b) to simple-dual-port block-
RAM (SDP-BRAM). This will help with your testing and is something you will probably want to do in your final design.

You can setup SDP-BRAM using the Xilinx IP called the Block Memory Generator. See document, PG058 for details. I think you will prefer using the “Native
Interface” rather than the “AXI Interface” to SDP-BRAM. UG573 gives you timing diagrams for writing and reading SDP-BRAM.

You will find that SDP-BRAM has both a write-clock, CLKA, and a read-clock, CLKB. You should connect CLKA to the clock output of your DCLK_MMCM.
However, CLKB can be any clock in your design – it can even be a clock that is much slower than CLKA and unrelated to CLKA. A nice feature of SDP-
BRAM is that it automatically handles the interface between the CLKA domain and the CLKB domain. That is, you do not need to write constraints or create
synchronizers for the data crossing between the two clock domains. Although, you must be careful not to simultaneously write and read from the same
address in SDP-BRAM.

So, for your testing, you could collect (say) a 1000-sample burst of data from the AFE5808 interface and store it in SDP-BRAM. Then, you could read the
data from SDP-BRAM using a slow CLKB and send it out of the FPGA via whatever interface you have available (RS232, ethernet, etc). You could also use
the ILA to sample data that you are clocking out of the SDP-BRAM and sending to some unused pins on the FPGA.

 0 Kudos  Share Reply

© 2021 Xilinx Privacy | Legal | Supply Chain Transparency | Contact  ENGLISH      