03-09-2020 03:13 PM
I have been using a ZC706 Rev 2.0 evaluation board for the past year or so to develop a firmware/software interface to communicate with a proprietary board. The firmware has been working since last September, or so, with this proprietary board but seems to have suddenly stopped working. The functionality seems to have stopped mid-test and has replicated to another ZC706 board that we had in the lab. I have tried to program the eval boards via JTAG and booting from an SD card, changing the eval boards, changing the power supplies, removing the eval board from a housing that we had it in for testing purposes, making minor changes in the firmware and reloaded the hdf file and bitstream, as well as some other changes but nothing seems to be helping.
I have probed the pins that should be outputting an LVDS 2.5 clock, and I no longer see a common mode voltage on either of the pins. These are the H4 and H5 pins are connected to the FMC HPC connector, CLK0_M2C_P and CLK0_M2C_N respectively. I have previous read that these pins are meant to be used as an input from the mezzanine to the FPGA when connected to a daughter card, but have been using them for months now to output a clock. There have been no functional changes to the firmware that we have been running, and definitely no changes to the constraints file.
As another test, I wrote a firmware only project that relays a button's state to an OBUFDS module whose output is tied to CLK0_M2C_P and CLK0_M2C_N . When I press the button I see the images that were attached below. You can see the repeated button presses throughout the time frame, this looks like an LVCMOS2.5 IO standard signal on the O-scope. I have double checked the Implemented design to ensure that the IO standard was correct and rerouted the pins to the FMC HPC pins G6 and G7, LA00_P_CC and LA00_N_CC respectively, and got the other O-scope capture. This is the expected LVDS 2.5 output I am looking for, but no longer see on CLK0_M2C_P and CLK0_M2C_N.
Is there any idea out there why something like this would be happening?
03-09-2020 03:34 PM
Would you try BIST to investigate the route cause on ZC706 ?
Refer the following, if you want to get BIST application and know the detail.
03-09-2020 05:44 PM
...some things to check:
1) The LVDS outputs (CLK0_M2C_P and CLK0_M2C_N) are coming from bank 11 of the FPGA - and this bank has VCCO = VADJ_FPGA. Check that VADJ_FPGA is nominally 2.5V and does not exceed 2.85V, at which point the LVDS outputs will be in high-Z state (see footnote 2, Table 1-55 of UG471).
2) Ensure that you have not lost/damaged the termination resistor across the LVDS outputs.
3) If your firmware is using IOBUFDS instead of OBUFDS then check datasheet for switching time between input and output, which can sometimes be slow.
03-10-2020 09:41 AM
I have checked to make sure that the VADJ_FPGA is at 2.5V, by looking at the implemented design. I also took a voltage reading across C245 and got 2.5V.
The termination resistance is set digitally by a proprietary board that I am communicating with, but I will go dig up a 100Ohm resistor and get an o-scope reading with that if I can't find a differential probe laying around. I have capture the LVDS reading that I attached by using a 1Mohm terminated probe referenced to the board ground on each leg of the LVDS lines though.
I also thought of that delay, we did not have timing issues with that bus turn around time before. But just in case, I had created a wrapper that instantiates a OBUFDS module and nothing else. This module takes in a clock and should be outputting it along the pin of interest, but I see no signal coming out.
03-11-2020 05:34 PM
The firmware has been working since last September, or so, with this proprietary board but seems to have suddenly stopped working.
As another test, I wrote a firmware only project that relays a button's state to an OBUFDS module whose output is tied to CLK0_M2C_P and CLK0_M2C_N .
So, you have firmware#1 that does not toggle the LVDS outputs reliably and you have firmware#2 that does toggle the outputs reliably - on the same board. Is that right?
If so, then this means the LVDS pins are not damaged and that you have properly terminated the LVDS outputs with a 100ohm resistor.
That fact that firmware#1 was working and then stopped working suggests timing problems.
You say that the LVDS outputs are part of a "firmware/software interface to communicate with a proprietary board". Can you tell us more about this interface and about the part of firmware#1 that drives the LVDS outputs?
03-12-2020 07:26 AM
Yes, you are correct in that Firmware #1 toggle the LVDS lines reliably. You are also correct that Firmware #2, the test firmware that maps a button press to drive some OBUFDS modules to the same pins as used in Firmware #1, toggle outputs reliably. An issue that I'm seeing is that Firmware #2 seems to be driving an LVCMOS signal out of the CLK0_M2C_P and CLK0_M2C_N pins on the button press, as shown in the attachment.
The summary of the interface in Firmware #1 is that there are several modules that make up a chain of communication that ends with a module that is essentially a wrapper for two instances of IOBUFDS modules, and one OBUFDS module. When I look at the Design Timing Summary of the Implemented Design it shows positive margins for Setup, Hold, and Pulse Width metrics.
03-12-2020 10:35 AM
An issue that I'm seeing is that Firmware #2 seems to be driving an LVCMOS signal out of the CLK0_M2C_P and CLK0_M2C_N pins ...
Aha - I missed that clue before.
...a chain of communication that ends with a module that is essentially a wrapper for two instances of IOBUFDS modules, and one OBUFDS module.
Sometimes with wrappers for IOBUFDS, I don't get the implemented design that I want. Now, I always instantiate (and never infer) IOBUFDS, OBUFDS and IBUFDS and I always do this in the top-level of my design.
Clues are suggesting that implementation of the design is not what you want.
I see that you previously checked the implemented design, but maybe again open the implemented design and see what is connected to the pins in bank-11 of the FPGA that are driving the LVDS lines on the HPC connector. Do you agree that these FPGA pins are AE22 and AF22?
03-12-2020 03:46 PM
Instantiating the buffers at the top level is a good idea, I'll keep that in mind for the future. The reason we used the wrapper methodology was that we were using the Block Diagram interface to ease use with the PS on the Zynq.
I have attached implementation screenshots, and it seems as though everything is in check.
An interesting thing that just happened was that I just grabbed a Rev 1.2, ZC706 board, and ran the firmware/software correctly. I was seeing the LVDS signals out of the pins I was expecting. I was booting off of an SD card, so I transferred that SD card around to the 3 different Rev 2.0 boards I have in the lab and did not see the behavior replicated.
03-26-2020 05:33 AM
moved this here so we could get some other experts to look at it.
I don't know why the OBUFDS would somehow lose it's ability to provide a proper common mode unless there was some damage to the IO or if something on the receiver side was doing this.
Can you look at any other pins in the bank?
Can you show a diagram of what is connected here?