I am using the AD9164-FMC-EBZ Eval board in conjunction with the VCU108 development board. I have created a vivado project that contains the JESD IP, a MicroBlaze, an RTL block that allows gpio to interface with an AXI peripheral, and an RTL block that allows gpio to interface with a SPI peripheral. My MicroBlaze is connected to the AXI and SPI interface blocks, which allows me to control the AXI and SPI functions from custom C code. Currently, control of the AD9164 via SPI has been disabled in favor of letting ACE control it.
These are the parameters given in ACE. My JESD IP has been configured to match these. Subclass0, LaneRate=12.5Gbps, L=8, M=1, F=1, S=4, K=32, N=16, NP=16. Via the JESD IP AXI interface, I am also setting CS=0, CF=0, HD=1, SCR=1, ILA Multiframes=4. These changes occur on startup and the JESD IP is reset afterwards, per the pg066-jesd204.pdf manual.
I am having trouble establishing the JESD link. The ACE GUI tells me that Good Checksum for lanes 0-3 is reliably set correctly, but nothing else seems to work as it should. CGS for lanes 0-3 passes randomly, Frame Sync for lanes 0-3 passes randomly, and ILAS for lanes 0-3 has passed a couple times but not often. Lanes 4-7 are almost never successfully set in any category. I have been debugging for many days now and can't seem to make any progress. What could I be doing wrong?
I would like to first refer you to this post under the EngineerZone:
The user is reporting a similar issue with a slightly different setup. Based on this case, please try to answer the following questions:
- Have you considered inverting JESD pins in order to match both transmitter and receiver sides' polarity?
- have you used crossbar switch to map the physical JESD lanes?
- what is the status of PLL and DLL of the DAC? Are they both locked?
Thank you for that link. My problems *almost, see edited below* ended up being solved by two things:
1) I had to change the mapping of lanes 4-7 with the crossbar switch and lane inversion registers to the same as described at this link in the section entitled "JESD Lane Mapping and..": https://wiki.analog.com/resources/eval/dpg/ad916x-fmcx-ebz
2) Changing any JESD settings seems to only work following a power cycle. Other than that, it seems to 'get confused' and then never be able to sync properly even though the link is being reset on both sides. A complete power cycle, followed by my desired setup, then establishment of the link, seems to work as it should.
This solution worked for exactly one build. Now, I am seeing lane 2 fail consistently. See Screenshots below:
Upon looking into the memory map at the checksum registers, I see this:
What would cause only lane 2 to fail? I am relatively new to Xilinx tools and so I am not sure how timing constraints are applied with Xilinx IPs. Could this be a timing issue, as it worked for one build but then stopped working for builds thereafter (changes were made to other modules that aren't relevant to this, but would effect how things are routed)?
I'm now leaning toward this being a timing issue on the FGPA side unless someone can tell me different. I simply removed all the debug nets from my firmware design and am now getting the following errors:
I believe it's a timing issue because I'm literally not changing anything about how I set up the link and it is the reliably the same error until I change something minuscule in my firmware project and rebuild, at which point the error may change to a different lane and be slightly different (refer to above screenshots of ACE SERDES Status GUI). I've looked through the .xdc files associated with the IP and the only constraints I see are for creating generated clocks. Does the IP not constrain setup and hold times for the pins attached to it? If not, why can't I find anyone else mentioning this?
This tells me you still have clock issue with your setup. Could you please check the QPLL on the FPGA side to make sure it stays in lock state all the time.
I had CPLL selected in the JESD IP at first, but then changed to QPLL0. That exposed the QPLL lock signal you are referring to which then appears to never lose its lock. Using the CPLL instead of QPLL0 might have been my problem, however. The intermittent lane failures seem to have stopped for now.