tido
-
Posts
7 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Gallery
Posts posted by tido
-
-
Once again, thank you so much for the hints and the food for thought, zygot! This is much appreciated.
I, too, assume that TxVOCM and TxVOD in the Xilinx article refer to the Tx=transmitter VO=voltage output for CM=common mode ("bias") and D=differential. After all, they make statements about what their (Xilinx') hardware is able to handle. Furthermore, this seems reasonable due to the way they define the limit on the input voltage and the criterion for rebiasing.
I agree that the over-/undershoot conditions and the AC nature of the signal make this more involved than comparing static voltage levels. However, I think those assumptions are reasonable given the "low" speed at which I operate the link: ~100MHz, cf. my earlier posting. Over-/undershoot can only happen when Tx and Rx are separated by a transmission line, i.e. when you have a substantial phase delay between the two. The given configuration (cable and operating frequency) resembles more of a DC than high-speed digital.. 😉
Looking at the datasheet again, I have to correct myself. The information on VCCO=3.3V is given in Table 1 right below the line that you refer to: the upper limit for VIN is 2.625V. Strictly speaking, this puts the device at risk of being damaged if the FIN1108 would output its maximum 3.3...3.6V. However, the nominal maximum output is --as you say-- only 1.6V with up to 1.825V still being covered by its specification. So no damage under practical (and reasonably to assume) operating conditions.
Last but not least, I was able to tweak the design and run part of it with the DIFF_TERM=TRUE. I have yet to confirm full function, but: the clock seems quite stable. (I compare the input clock with an internally generated clock of the same frequency.) It looks like the cable is not the culprit, but rather it was the missing termination.
-
4 hours ago, zygot said:
I looked at the FIN1108 datasheet. It's a 3.3V device and not ( probably as I haven't looked into the details ) directly compatible with programmable logic differential IOSTANDARDs.
Following up on this for the sake of completeness and in case anyone else runs into this: Xilinx' flow chart [1] illustrates the requirement for AC coupling and DC rebiasing. In essence, you will need to rebias if the absolute maximum output voltage from the external circuit could be higher than what the FPGA input can handle.
In case of the FIN1108, this means common mode voltage + 50% of differential voltage swing = 1.375V + 450mV = 1.825V.
On the other hand, the Kintex7 HR input pins can handle VCCO+0.55V = 3.3V+0.55V = 3.85V [2]. The flow chart is more restrictive and requests VCCO+0.2V=3.5V. Either way, this is higher than the FIN1108's output, so no AC coupling is required. In addition, the supply voltage of the FIN1108 is recommended to be set to VCC=3.3-3.6V. Given that I am supplying 3.3V, this does not exceed the Kintex7's input rating either.That said, an external termination as shown in Fig 1-70 of Xilinx SelectIO Resource Guide [3] is still worthwhile to be used. (Thanks pointing this out, zygot!) Notably, these are not in place on the FMC that I am dealing with. I am beginning to think that this could be the actual issue for the flaky clock that I witness.
The cable might make things worse, but could be indifferent for two reasons:
- The cable does not act as a fully developed transmission line here: I am running the LVDS near 100MHz. i.e. free-space wavelength/2=1.5m or approx. 75cm in the cable. Hence, the cable is 1/6 of a wavelength in length. This is good as it prevent reflections from building up.
- The fact that the cable's phase delay is less than a full period means that it does not attenuate the signal much, if at all. Hence, reflections from the FPGA input pin return to and impact the transmitter.
The latter aspect leads me to consider the missing termination to be the dominant cause for the observed misbehaviour.
[1] https://support.xilinx.com/s/article/43989?language=en_US
[2] https://docs.xilinx.com/v/u/en-US/ds182_Kintex_7_Data_Sheet
[3] https://docs.xilinx.com/v/u/en-US/ug471_7Series_SelectIO -
5 hours ago, zygot said:
There's no 3.3V LVDS IOSTANDARD so make sure that the IO banks receiving your clocks are set to Vccio = 2.5V. On the Genesis2 this is determined by jumpers on JP6. The Genesys2 reference manual has a good write-up about the power supplies. On devices like FPGA, that support a wide range of logic standards, it's necessary to limit certain standards to specific IO bank power supply voltages. There are plenty of 3.3V LVDS logic devices that are not compatible with direct connection to FPGA pins without adding additional passive components. Now that I think about it, this is the 2nd thing to check once you've found the terminator resistors.
ACK. This is indeed a problem when wanting to transmit from the Genesys2 to a FMC. To my understanding, using LVDS_25 is permitted for a Genesys2's Kintex7 at Vccio=2.5V as well as Vccio=3.3V, if it is used as an input pin, i.e. receive, cf. https://support.xilinx.com/s/article/43989?language=en_US.
Thank you for the extensive advice. I will be sure to consult all of it!
-
Thank you zygot. It is really helpful that you confirm my concerns regarding the cable! I have joined a project mid-way and have not designed the original FMC. There are several things that I feel have not been taken into account before... hence no opposition to any sort of changes on my end. 😉 The cable is not there to stay, but was a workaround to swap pin pairs and use the available hardware sample for as much testing as possible.
The LVDS lines are driven by FIN1108 [1] fairly close to the FMC connector. I take it, that no additional termination would make sense on the end of the FMC card, right?
I find that a lack of information on PCB and cable materials (insert loss, return loss) makes simulation a challenge in this case. I have several years of experience in EM simulation for high-speed interconnects and am able to come up with models for the segments. I am certain that I would be able to extract data to illustrate the detrimental effect of the cable. However, this doesn't give me much new information to work with. In other words, I already know that I do not want the cable between FMC card and Genesys2. 🙃
-
I am working with a custom-made FMC (HPC) that attaches to a Genesys2 board with VADJ=3.3V. Among various signals, I have two LVDS_25 clock inputs on the pairs L25/K25 (FMC pins K4/K5) and F12/E13 (FMC pins K28/K29):
set_property -dict {PACKAGE_PIN L25 IOSTANDARD LVDS_25} [get_ports clk0_p]; #IO_L12P_T1_MRCC_AD5P_15 Sch=fmc_clk_p[2] set_property -dict {PACKAGE_PIN K25 IOSTANDARD LVDS_25} [get_ports clk0_n]; #IO_L12N_T1_MRCC_AD5N_15 Sch=fmc_clk_n[2] create_clock -period 9.523 -name clk0_105mhz [get_ports clk0_p]; set_property -dict {PACKAGE_PIN F12 IOSTANDARD LVDS_25} [get_ports clk1_p]; #IO_L14P_T2_SRCC_18 Sch=fmc_hb_p[06] set_property -dict {PACKAGE_PIN E13 IOSTANDARD LVDS_25} [get_ports clk1_n]; #IO_L14N_T2_SRCC_18 Sch=fmc_hb_n[06] create_clock -period 9.523 -name clk1_105mhz [get_ports clk1_p];To my understanding, both pin pairs are clock-capable and Vivado synthesizes/implements without issues. The HB bank is powered by an external voltage of 3.3V from the FMC card.
For sanity checking, I pass both clocks through IBUFGDSs...
wire w_clk0_ibufg; IBUFGDS clk0_ibufgds_inst (.I(clk0_p), .IB(clk0_n), .O(w_clk0_ibufg)); wire w_clk1_ibufg; IBUFGDS clk1_ibufgds_inst (.I(clk1_p), .IB(clk1_n), .O(w_clk1_ibufg));
...divide the clock and power a couple of LEDs to confirm signal availability:
reg [25:0] r_clk0div = 0; reg [25:0] r_clk1div = 0; assign led[0] = r_clk0div[25]; assign led[1] = r_clk1div[25]; always @(posedge w_clk0_ibufg) begin r_clk0div <= r_clk0div + 1; end always @(posedge w_clk1_ibufg) begin r_clk1div <= r_clk1div + 1; end
To my surprise, I see only led[0] blinking (with irregularities), but not led[1]. I see a LVDS signal on the FMC connector pins of both clock inputs. The signals are somewhat distorted (oscilloscope struggles to trigger at the proper period) and led[0] blinks irregularly at times.
Due to reasons, the FMC is connected to the Genesys2 board by an 250mm cable [1]. My guess is that the additional connector introduces reflections and the cable attenuates the clock signals to a degree that the FPGA does not detect a LVDS signal. Is it really this "simple", or am I missing something?
Genesys 2 not detected in Vivado Hardware Manager
in FPGA
Posted · Edited by tido
I'd like to follow up on this topic, since I am experiencing a similar issue with a previously programmed Genesys2 board. I am using Vivado 2020.2.
I don't get the error messages shown above, but instead
Using openFPGALoader, I am able to confirm that the JTAG interface works, but no device seems to be found on the bus. How can I recover the Genesys2 board (a fairly new one, too, which has seen only 2-3 programming cycles to the SPIflash until now. To this point, the board loads the most recently programmed bitstream from the SPIflash without fault. Selecting JTAG as source for the bitstream will cause the FPGA to idle and wait for a bitstream to be provided via JTAG.
I am using Debian Linux (bookworm/12) and have had no issues flashing several boards an estimated total amount of 5000-10000 times in the last three years. This is the first board.
Update: after selecting JTAG programming mode via the jumper next to J16 and reinstalling the "drivers" (udev rules), the hardware manager in Vivado now returns a similar error as shown below. The USB cable is new out of the (Digilent Genesys2) box and this phenomenon has been observed on multiple computers with different USB cables.