I want to provide some feedback on the new the axi_jesd_gt.v library HDL, where it is split into axi_jesd_gt.v and util_jesd_gt.v for the hdl_2015_r2 and dev HDL github branches.
For a custom design where a the number of RX and TX lanes is not equal the new axi_jesd_gt.v does not appear to correctly tie off the unused RX or TX lanes going out to the GT transceivers. HDL lines 1463 to 1558 in new axi_jesd_gt.v that tie off unused lanes only looks at the total number of lanes used in the generate statement. The early all in one axi_jesd_gt.v that is in hdl_2015_r1 and master had separate generate statements for RX and TX both in form of a else statement that looked at total number of lanes against number of TX or RX lanes used, which does correctly tie off the unused TX or RX lanes out to the transceivers for the cases where TX and RX are not equal.
Not such a good idea..in terms of splitting the axi_jesd_gt.v into two sections of HDL. It does make logical sense to split axi_jesd_gt.v up adding the util_jesdgt.v HDL. Yet the upper level TCL scripting that does the pin mapping for each is making the library builds take for ever. I don't see a good way around this, for my needs I went back and made a custom library based on the earlier all in one axi_jesd_gt.v which builds in a few seconds.
More of a comment; I have quite a custom design going, pulse generation with digital marker out, in which I needed to get deterministic latency from the JESD204 out to the DAC, in my case a AD9144 or AD9136 FMC card. The core FMC sysref clocking for the DAQ2 FMC board is done same way.
The FMC board clock generator is generating the FPGA 500MHz JESD, DAC, and sysref clock signals. First to get this syncing topology to work the adi,sysref-external-enable entry must be put in the driver devictree tx link for the jesd GT. The main problem is this only gets to a 2ns deterministic latency in the JESD interface because the 250MHz core clock does not come from the external clock generator but rather the JESD 0 PLL output, buffered tx_clk_g. Since the sysref and sync are all re-synced in FPGA with the 250MHz which is divided from the 500MHz reference there is no control over the clock generators sysref clock phase and that of the FPGA generated 250MHz clock phase on power up; hence the 2ns jumping in the JESD to DAC latency on power cycles.
What I found did work for at least a simple single DAC design was to green wire the FMC card such that the internal FPGA sysref clock is brought out of it and sent over to the DAC as it's sysref clock. Using the FPGA internal generated sysref going out to DAC now on power cycles my digital marker is always aligned with the pulsed waveform being sent to the DAC.
If only the FMC board clock generator also feed the 250MHz core clock into the FPGA this would not be a issue.
In regards to this the DAQ2 WIKI introduction page docs kind of says subclass 1 JESD204B, but between the HDL and current board clock generation used that is not quite true.I hope that the ADI team might add some section into the WIKI site about deterministic latency and the requirements for true subclass 1 JESD204B support, or at least note the basic board design does not fully support it.
Last, I am very grateful to say the least for all the great support coming from the ADI team in regards to providing HDL and Linux drivers for their devices. Without the base platform provided in the HDL library,board builds, and underling ADI TCL scripts I would become quite lost in things like Vivado.