elodg

Digilent Staff
  • Content Count

    112
  • Joined

  • Last visited

  • Days Won

    8

Everything posted by elodg

  1. According to ug190 pg. 297 a LVPECL-compliant transmitter needs a three-resistor output termination circuit that is not present on the Genesys. A further requirement from pg. 299 is the 2.5V bank supply voltage, which is available in bank 3, 12 and selectable on 11, 13. Banks 11 and 13 are the ones wired to the VHDCI connectors and your best bet is creating a custom board or using something like http://store.digilentinc.com/all-products/modules-add-on-boards/vmod-vhdci-expansion-modules/ to get your signal out of the board and add the termination resistor. It is not ideal, because it won't be near-end anymore, but it might work.
  2. elodg

    MGT on Nexys Video

    Well, "failed timing" is like saying the sky is blue. You got to tell us more if you want help with that. Google Xilinx timing closure for more info. Here is one link that is a good starting point: https://www.xilinx.com/support/documentation-navigation/design-hubs/dh0006-vivado-design-analysis-and-timing-closure-hub.html
  3. 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.
  4. 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.
  5. 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.
  6. @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.
  7. 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.
  8. 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.
  9. elodg

    MGT on Nexys Video

    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?
  10. elodg

    MGT on Nexys Video

    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]
  11. 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!
  12. elodg

    MGT on Nexys Video

    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.
  13. 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.
  14. 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.
  15. @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.
  16. 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.
  17. 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.
  18. Pull the latest changes from https://github.com/Digilent/vivado-library My latest commits should fix all incompatibilities of dvi2rgb with 2016.x versions of Vivado.
  19. elodg

    FMC FRU is empty?

    I cannot promise an exact date for the new batch of FMC-HDMI with the fix applied. We will create an upgrade project and publish it somewhere.
  20. elodg

    FMC FRU is empty?

    Hello Antti, The FMC-HDMI IPMI EEPROM is programmed during manufacturing, so the blank EEPROM sounds implausible. However, there is a known issue in our FRU record relating to voltages. According to the documentation, the VCU108 can be forced to set a particular VADJ voltage for the FMC connector, which is the workaround I recommend on the short-term. See https://www.xilinx.com/support/documentation/boards_and_kits/vcu108/ug1066-vcu108-eval-bd.pdf#M6.9.84194.Heading2.FMC.Menu.Options If the customer is willing, we can provide a new EEPROM image for the FMC-HDMI, that can be programmed in the field. We could design the programmer for the VCU108, or any other board (preferably from Digilent) available.
  21. Hi @Goutham Why do you want to use Microblaze on the Zedboard? Similarly, why do you want to use PmodNIC100 when there is a 1G Ethernet PHY on-board? On the Zedboard the 1G PHY is indeed connected to PS pins, so not directly accessible by PL. However, a Microblaze in the PL could access the PS MAC through the S_GP0 and DDR through the HP ports. Or, if you really want to ignore the PS and can fit the Microblaze application in BRAM, you can indeed use PMODNIC100 with a SPI master controller implemented in PL. You will have to write the lwIP adaptor layer though. However, I am not sure you can fit an lwIP application in BRAM alone.
  22. elodg

    DDR3 Termination

    Although this is an old post, I would like to clarify the situation. @Nebruda, I see no reason to prefer DDR3 on a certain side from the user's point-of-view. Both topologies are technically sound and functionally the same. They present advantages and disadvantages for the board designer only. The tree topology on the Zybo allowed us to save a power supply, resulting in a more compact board. However, compared to the fly-by topology it is harder to route and validate.
  23. Have you tried with another USB pen drive? As a first guess, it could be indeed the insufficient capacitance at fault, if the pen drive has large load variations under stress. However, this should have been solved by the cap you loaded. Is there some other debug log of the USB controller we could look at? If you scope VBUS there should be no large voltage drops when under stress with the large cap loaded. The device lock-up might be due to something else.
  24. Hello Troy, It depends what is the nature of the data you are transferring. The Zynq Ethernet MAC works with Ethernet packets. If you are using point-to-point connection with the PC, Ethernet packets might be enough. You only need to make sure that the correct MAC address is used when sending and receiving the packets. If you want higher protocol-level support, you need IP. On top of IP you choose TCP, if you need guaranteed packet delivery, or UDP, if not. Both TCP/UDP and IP are implemented by lwIP. On top of that you either implement your own application protocol, or choose an existing one: TFTP if file transfer is that you are after, or SMTP if you want to send e-mails and so on. I believe none are implemented by lwIP, but there are open-source examples all over the Web.
  25. Hello Andrew, We don't have any such examples. We do test SD and USB in our manufacturing tests, but it does not go as far as knowing anything about files. For both SD and USB Mass-storage you will need file system support. FatFs is a good open-source example. The lower-level drivers are the ones provided by Xilinx and we use them ourselves. For example, reading the first data block on an SD is as simple as: #include "sdps.h" /// Initialize the read buffer memset(arrbyReadBuff, 0, kwBlockSizeBytes); /// Initialize SDIO controller psSdConfig = XSdPs_LookupConfig(XPAR_PS7_SD_0_DEVICE_ID); if (XSdPs_CfgInitialize(&sSdPs, psSdConfig, psSdConfig->BaseAddress) != XST_SUCCESS) { VERBOSE("%s (line %d) error", __func__, __LINE__); FAIL_AND_RETURN; } /// Initialize SD card if (XSdPs_CardInitialize(&sSdPs) != XST_SUCCESS) { VERBOSE("%s (line %d) error", __func__, __LINE__); FAIL_AND_RETURN; } /// Change bus width to 4-bit if (XSdPs_Change_BusWidth(&sSdPs) != XST_SUCCESS) { VERBOSE("%s (line %d) error", __func__, __LINE__); FAIL_AND_RETURN; } /// Issue a read of the first block (boot block) XSdPs_ReadPolled(&sSdPs, 0, 1, arrbyReadBuff);