elodg

Members
  • Content count

    35
  • Joined

  • Last visited

  • Days Won

    4

elodg last won the day on April 22

elodg had the most liked content!

About elodg

  • Rank
    Advanced User

Recent Profile Visitors

533 profile views
  1. Bank 33 is a 1.5V-powered bank. Make sure sysclk is input, because only LVDS inputs without internal termination are compatible with any bank supply voltage. For more information, see ug471 from Xilinx.
  2. Hi @BeamPower, This might be relevant: https://smallshire.org.uk/sufficientlysmall/2013/10/31/arduino-avr-gcc-eclipse-and-windows-8-1/ Open the Xilinx Software Command Line Tool for your SDK version from the Start menu. Cd into your SDK project's Debug or Release folder and try running make clean and make from there. See if it errors out. The link above describes a similar issue with the Windows build of GNU make. In any case, this is a Xilinx tool issue.
  3. Hello @Lakshmi morla, The PHY address is in the ref manual: https://reference.digilentinc.com/reference/programmable-logic/genesys-2/reference-manual#ethernet_phy The I/O standard compatibility errors are due to incorrect LOC constraints. Figure 7 in our reference manual shows incorrect locations for Ethernet pins. Please use the XDC file instead that has all the pins and their correct locations. Depending on your application you might need to change the I/O standards for Pmod and FMC signals. Other on-board peripherals should have the correct I/O standard specified and are wired to FPGA banks with compatibility in mind.
  4. @zygot, Standards that specify layers from mechanical all the way up to protocol like HDMI, USB, SATA are strict and do not leave much wiggle room. VITA.57 (FMC) is an interconnect standard that makes little effort to specify anything other than the mechanical layer. The electrical requirements are intentionally open-ended. The protocol layer is not even mentioned. It makes sense, since it is heavily geared towards FPGA. The interconnect needs to stay flexible to cover the wide range of applications (including data rates possible). Every effort was made for the Genesys 2 to be VITA.57-compliant. Differential impedance is 100ohm and pair mismatch is < 1ps. Unfortunately, @dlgeng's request is outside the scope of the standard and requires a separate validation effort. Thank you both for your input and we will strive to provide better specifications in the future.
  5. Hello @dlgeng, The Genesys 2 manufacturing test runs the Aurora protocol @5Gbps on the ten FMC DP lanes through a loopback board. By design the lanes should be able to reach 10Gbps. We do not sell any mezzanine cards that actually use GT lanes, so we have not validated it for specific applications like 10GbE. It may be cynical, but we simply cannot cover all use cases with a development board. Contact sales to see if they are willing to lend you a board for short-term testing.
  6. Hi @RisinT96, As you observed, the AD7873ARUZ is not loaded on the FMC-HMI. Section 1.5 of the reference manual states: "The AMS header is there to provide support for the XADC feature of seven-series system boards. Operators can use the AMS header signals to bias the touch panel by selecting the analog MUX inputs and carrying the differential analog signal to the FPGA pins for measurement." You can learn about 4-wire resistive touch screens here: https://www.sparkfun.com/datasheets/LCD/HOW DOES IT WORK.pdf http://www.ti.com/lit/an/slaa384a/slaa384a.pdf The idea is to use [X|Y]D[+|-] (drive) pins in the AMS header to bias two electrodes and use the ADG709CRUZ analog multiplexer to switch the [X|Y]S[+|-] (sense) lines to VP/VN pins of the AMS header. The drive pins in the AMS header are digital and are expected to be controlled from a 3.3V FPGA bank. Just output '1' and '0' conform the biasing scheme. The sense lines that need to be measured can be selected with A0 and A1, which are also in the AMS header. Finally, VP/VN is the dedicated input to the XADC primitive that needs to be used to digitize the measurement. The coordinate can be calculated from there.
  7. Yes, in the test bench tx is assigned to rx. However, the example design is also implementable, and has the constraints for the transceiver channels. Isn't that what you were looking for?
  8. See the example project for the IP generated by the Transceiver Wizard to see how these should be handled. The wizard should generate all the necessary constraints and the pins I believe should just be made external. This is what I get in the example design: ##---------- Set placement for gt0_gtp_wrapper_i/GTPE2_CHANNEL ------ set_property LOC GTPE2_CHANNEL_X0Y4 [get_cells gtwizard_0_support_i/gtwizard_0_init_i/inst/gtwizard_0_i/gt0_gtwizard_0_i/gtpe2_i] ##---------- Set placement for gt1_gtp_wrapper_i/GTPE2_CHANNEL ------ set_property LOC GTPE2_CHANNEL_X0Y5 [get_cells gtwizard_0_support_i/gtwizard_0_init_i/inst/gtwizard_0_i/gt1_gtwizard_0_i/gtpe2_i]
  9. There are two relevant docs in the Adept SDK package: Digilent Parallel Transfer Interface (DPTI).pdf and DPTI Programmer's Reference Manual.pdf There is a sample for both FPGA and C++ in the samples folder of the same package. Our Vivado library has a new IP called AXI DPTI: https://github.com/Digilent/vivado-library/tree/master/ip/AXI_DPTI_1.0 It pairs neatly with a demo project that has both PC software and hardware for the Nexys Video board: https://github.com/Digilent/NexysVideo/tree/master/Projects/dpti Go have fun with it!
  10. See ug482 for information on GTP transceivers. The user guide has a whole section dedicated to the 7-series FPGA Transceiver Wizard, which is how you are expected to use the transceivers. The placement of the primitives is also done through that wizard. Each channel and clocking primitive is identified by an XY coordinate rather than pin designators. If you do not wish to use the wizard, create the XDC manually and look up the pin designators in the schematic as @jpeyron showed above.
  11. Hello Regis, There is indeed a bug in our firmware that causes certain scan codes not being sent with the extension prefix. As soon as get my mental stamina up to work with Microchip tools, I will fix it and post an update.
  12. First, the AD8195 buffer on port 2 only supports up to 2.25 Gbps. Second, high rise/fall times (<250ps) in current-driven I/O standards have real issues with the high pin capacitance of FPGA user I/O pins. There is nothing really that can be done about this. However, if the carrier board follows reasonable FMC routing guidelines, it will be functional at lower resolutions. We validated the FMC-HDMI with the Zedboard and was able to do 720p@60Hz (742.5MHz) on port 2. Even 1080p@60Hz (1485MHz) worked on the limited number of boards we tested it with. Furthermore, the carrier card also needs to support 3.3V on VADJ for the TMDS_33 I/O standard for port 2 to work.
  13. @faescobar85, when you say detected by the computer, do you mean Windows showing a secondary screen called Digilent DVI? Detection should happen over the DDC bus by reading the EDID and has nothing to do with aPixelClkLckd. Only after extending/duplicating the desktop will the video link come up and the dvi2rgb core lock onto it. The latter is the aPixelClkLckd signal. I recommend Vivado hardware debugging on: aPixelClkLckd, PhaseAlign/pAligned, PhaseAlign/pEyeSize, PhaseAlign/pError, ChannelBond/pMeRdy for all three channels.
  14. If one has the time, give kUseFastAlgorithm a try. This is a generic parameter in the PhaseAlign module that is set to false for now. One could make this parameter accessible from the IP wizard and should result in faster lock times in some cases. It is an untested feature, however.
  15. This is an old thread, but maybe it will help someone having the same issue. The minimum limit of 40MHz for pixel clock comes from the phase alignment implementation on 7-series FPGA, as @mikeanthonywild noticed it. There are 32 steps available for delaying each data channel independently. Each step adds an additional delay of 78ps. The maximum amount of delay possible is roughly 2.5ns. For low pixel clock frequencies this does not span the whole bit period, so phase alignment might not be possible. That being said, back in Jan 2016 I changed the phase alignment algorithm to lock once a wide enough valid data eye is found, even if the whole bit period cannot be searched for the data eye boundaries. I believe pixel clock frequencies lower than 40MHz should work with the current core version. Anyone still having issues, please file a bug report.