elodg

Digilent Staff
  • Content Count

    117
  • Joined

  • Last visited

  • Days Won

    9

Reputation Activity

  1. Like
    elodg got a reaction from mescobar2014 in Error [DRC PDRC-34] when trying to use dvi2rgb on Vivado 2017.4   
    Upgraded dvi2rgb to 2.0 and pushed the changes of Nexys-Video-HDMI to GitHub. If you take that and change the TMDS Clock frequency constraint in the xdc and the dvi2rgb clock range, it should meet timing.
  2. Like
    elodg got a reaction from mescobar2014 in Error [DRC PDRC-34] when trying to use dvi2rgb on Vivado 2017.4   
    Writing to confirm that there are indeed timing errors in the reference project that will take some time to fix. There is an XDC in dvi2rgb that is getting synthesized by mistake (lost property during an update) and the locked signal not being synchronous to PixelClk as the reset module is expecting.
  3. Like
    elodg got a reaction from cj01 in Arty adjustable clock with Microblaze and Vivado SDK   
    @Weevil,
    The error is due to an invalid connection. PXL_CLK_5X_O uses a BUFIO internally that cannot be routed to an external pin, which is what you are trying to achieve. To make it work, leave it unconnected and use PXL_CLK_O for internally clocking your DDS Compiler instance. These are particularities of the axi_dynclk IP due to it being meant for video applications. If you cannot make it work, see other options below.
    For dynamic clock generation, you have two IP options: Xilinx Clocking Wizard with AXI-Lite interface or the Digilent axi_dynclk.
    Advantages of Clocking Wizard: clock buffer options more suitable for non-video applications, documentation
    Advantages of axi_dynclk: clock buffer options (BUFIO, BUFR) suitable for video applications, driver with VCO parameter calculation.
    The Digilent axi_dynclk in the master branch of vivado-library does not have a standalone driver nor documentation. It does have a linux driver though. See issue https://github.com/Digilent/vivado-library/issues/14
    However, there is a new  version of axi_dynclk with a standalone driver on a different branch: https://github.com/Digilent/vivado-library/tree/feature/axi_dynclk_driver
  4. Like
    elodg got a reaction from Esti.A in Vivado sysnthesis fail..Pcam   
    @Esti.A,
    1. The timing error is localized to the DPHY input. The Digilent MIPI D-PHY IP is functional, but not optimized. Feel free to replace it with Xilinx's offering.

    2. Just did a clean clone and re-did what the readme steps. Fixed the readme to ask for C++ instead of C, which I already told you in the issue you raised on Github. The workspace should look like this:

    3. There is little we can do about SDK application crashes.
  5. Like
    elodg got a reaction from jpeyron in Support with the Pmod SD and Pmod AMP2   
    Hello @Jonathan.O,
    SD cards usually only guarantee write bandwidth through class specifications. Usually we can extrapolate read performance too. However, all the performance levels are specified for SD native interface, not SPI. Since you mentioned library code, I suspect you are using the SPI-based IP from here: https://github.com/Digilent/vivado-library/tree/master/ip/Pmods/PmodSD_v1_0.
    Try an SD controller IP from OpenCores, see if it works better.
  6. Like
    elodg got a reaction from Michael P in Hdmi out from zybo   
    I believe the behavior is due to the Zybo Z7 Petalinux BSP wrongly using 400kHz on the DDC bus to read out the EDID. Nexys Video does not provide an intelligible answer in this case.
    If you are in a hurry, try lowering the I2C0 speed to 100kHz. We will get around to fixing this eventually.
  7. Like
    elodg got a reaction from Suavek in Pcam 5C camera module interfacing   
    Hello @Suavek,
    I gave our SDSoC reVISION platform a try, because it is Linux-based and supports Pcam 5C. Booting the platform I get the following:
    root@Zybo-Z7-20:~# v4l2-ctl -d /dev/video0 --verbose --list-formats-ext VIDIOC_QUERYCAP: ok ioctl: VIDIOC_ENUM_FMT Index : 0 Type : Video Capture Multiplanar Pixel Format: 'YUYV' Name : YUYV 4:2:2 Index : 1 Type : Video Capture Multiplanar Pixel Format: 'UYVY' Name : UYVY 4:2:2 Index : 2 Type : Video Capture Multiplanar Pixel Format: 'NM16' Name : Y/CbCr 4:2:2 (N-C) Index : 3 Type : Video Capture Multiplanar Pixel Format: 'NV16' Name : Y/CbCr 4:2:2 Looking at the Petalinux BSP project that is used in our SDSoC reVISION platform too, v4l2 support for the Pcam5C is coming from Xilinx Petalinux recipes for the MIPI CSI2 Rx Subsystem and Video Processing Subsystem IPs: https://github.com/Digilent/Petalinux-Zybo-Z7-20/commit/59be69aa92699cc26083c2ece87c28e2991151b3
    Unfortunately, both IPs require a license (either separate or included in the SDSoC license), if you are re-creating the hardware platform, but you can use it as reference.
    Build a new Petalinux project using our BSP and compare devicetrees.
  8. Like
    elodg got a reaction from Peter Phillips in Nexys Video "Feet"   
    https://www.fastenal.com/products/details/0146057
    https://www.fastenal.com/products/details/28783
  9. Like
    elodg got a reaction from Bianca in Nexys Video "Feet"   
    https://www.fastenal.com/products/details/0146057
    https://www.fastenal.com/products/details/28783
  10. Like
    elodg reacted to JColvin in Zedboard 3.3V Aux   
    Hi @JeffL,
    For the Rev D version of the board, this pin (D32 on the FMC) will also be a VCC 3.3V supply, much like it is for @zygot's Rev C. From the specification for VITA 57.1, this pin is "a 3.3V auxiliary power supple available for IO Mezzanine module use and is not intended to provide primary power to the module but rather to accommodate system management functionality which might need to operate even if the onboard power conversion circuitry fails." Based on rule 5.101 though, we (Digilent) have chosen to service this pin by using the main 3.3V line.
    So, the short answer to your question is that the pin specifically on the Zedboard is a 3.3V source, though from my understanding this auxiliary supply should not be connected with any 3.3V primary paths on the mezzanine side.
    Thank you,
    JColvin
  11. Like
    elodg got a reaction from thobie in Zybo Z7 PS preset/board file and Out-of-Box Demo out-of-date!   
    @thobie, the bare-metal purchase option for the Zybo was done to enable a lower price point for those who do not require the accessories. For the rest of our customers, adding the Accessory Kit is recommended during the purchase process.
    You are not the first and the last to complain about version compatibility. It is economically unfeasible for us to update all support projects, IP and support packages provided for free four times per year for each Vivado version. Instead we made a commitment to consider the last Vivado release in each year stable and do a once-a-year update cycle. In that regard, 2017.4 is the version we are upgrading projects to. There is a question whether OOB designs should be updated at all, or kept at the version which generated the binary image shipped with the board.
    The board presets are not versioned for Vivado (no version-specific releases in our git repo), because these should be forward-compatible with Vivado versions. The critical warning itself related to CK-to-DQS delays being negative appears starting with 2017.4. The negative values are due to CK trace being shorter than any of the four DQS traces.
    In the early days of Zynq board design negative values where listed as sub-optimal, but not erroneous. Tree topology instead of fly-by was also among the routing recommendations for DDR3 layouts. So the Zybo was designed with this sub-optimal layout due to space constraints. During Write Leveling calibration, 0 is used as an initial value instead of the negative preset delays. After calibration, if the skew is still too low, the clock is inverted. See ug585 pg 316 for more details. All Zybos shipped to customers are functionally tested and pass the DDR3 calibration process.
    Xilinx recommendations changed in the mean time, both in terms of routing topology and delay values. A trace of this can be found here: https://www.xilinx.com/support/answers/53039.html. The > 0ns requirement was introduced to be in line with non-Zynq MIG-based designs, where negative delays were never permitted.
    Since these delays are board-dependent, we would need to re-design the board to make the delay positive. This is impossible with the current form-factor.
    Another option would be modifying the board preset file and forcing a zero value instead of the actual delay. The tools seem to be using zero anyway for calibration. This will have to be thoroughly verified first.
     
     
  12. Like
    elodg got a reaction from JColvin in Zybo Z7 PS preset/board file and Out-of-Box Demo out-of-date!   
    @thobie, the bare-metal purchase option for the Zybo was done to enable a lower price point for those who do not require the accessories. For the rest of our customers, adding the Accessory Kit is recommended during the purchase process.
    You are not the first and the last to complain about version compatibility. It is economically unfeasible for us to update all support projects, IP and support packages provided for free four times per year for each Vivado version. Instead we made a commitment to consider the last Vivado release in each year stable and do a once-a-year update cycle. In that regard, 2017.4 is the version we are upgrading projects to. There is a question whether OOB designs should be updated at all, or kept at the version which generated the binary image shipped with the board.
    The board presets are not versioned for Vivado (no version-specific releases in our git repo), because these should be forward-compatible with Vivado versions. The critical warning itself related to CK-to-DQS delays being negative appears starting with 2017.4. The negative values are due to CK trace being shorter than any of the four DQS traces.
    In the early days of Zynq board design negative values where listed as sub-optimal, but not erroneous. Tree topology instead of fly-by was also among the routing recommendations for DDR3 layouts. So the Zybo was designed with this sub-optimal layout due to space constraints. During Write Leveling calibration, 0 is used as an initial value instead of the negative preset delays. After calibration, if the skew is still too low, the clock is inverted. See ug585 pg 316 for more details. All Zybos shipped to customers are functionally tested and pass the DDR3 calibration process.
    Xilinx recommendations changed in the mean time, both in terms of routing topology and delay values. A trace of this can be found here: https://www.xilinx.com/support/answers/53039.html. The > 0ns requirement was introduced to be in line with non-Zynq MIG-based designs, where negative delays were never permitted.
    Since these delays are board-dependent, we would need to re-design the board to make the delay positive. This is impossible with the current form-factor.
    Another option would be modifying the board preset file and forcing a zero value instead of the actual delay. The tools seem to be using zero anyway for calibration. This will have to be thoroughly verified first.
     
     
  13. Like
    elodg got a reaction from jpeyron in Zybo Z7 PS preset/board file and Out-of-Box Demo out-of-date!   
    @thobie, the bare-metal purchase option for the Zybo was done to enable a lower price point for those who do not require the accessories. For the rest of our customers, adding the Accessory Kit is recommended during the purchase process.
    You are not the first and the last to complain about version compatibility. It is economically unfeasible for us to update all support projects, IP and support packages provided for free four times per year for each Vivado version. Instead we made a commitment to consider the last Vivado release in each year stable and do a once-a-year update cycle. In that regard, 2017.4 is the version we are upgrading projects to. There is a question whether OOB designs should be updated at all, or kept at the version which generated the binary image shipped with the board.
    The board presets are not versioned for Vivado (no version-specific releases in our git repo), because these should be forward-compatible with Vivado versions. The critical warning itself related to CK-to-DQS delays being negative appears starting with 2017.4. The negative values are due to CK trace being shorter than any of the four DQS traces.
    In the early days of Zynq board design negative values where listed as sub-optimal, but not erroneous. Tree topology instead of fly-by was also among the routing recommendations for DDR3 layouts. So the Zybo was designed with this sub-optimal layout due to space constraints. During Write Leveling calibration, 0 is used as an initial value instead of the negative preset delays. After calibration, if the skew is still too low, the clock is inverted. See ug585 pg 316 for more details. All Zybos shipped to customers are functionally tested and pass the DDR3 calibration process.
    Xilinx recommendations changed in the mean time, both in terms of routing topology and delay values. A trace of this can be found here: https://www.xilinx.com/support/answers/53039.html. The > 0ns requirement was introduced to be in line with non-Zynq MIG-based designs, where negative delays were never permitted.
    Since these delays are board-dependent, we would need to re-design the board to make the delay positive. This is impossible with the current form-factor.
    Another option would be modifying the board preset file and forcing a zero value instead of the actual delay. The tools seem to be using zero anyway for calibration. This will have to be thoroughly verified first.
     
     
  14. Like
    elodg got a reaction from Bert_ALSE in FMC & SFP+ link (Aurora) on Nexys Video   
    @Bert_ALSE, to work around the JTAG issue on the FMC adapter, you can try either
    shunting FMC_TDI to FMC_TDO on the FMC adapter OR
    interrupting the PRSNT_M2C_L connection to GND by pulling the pin from the FMC connector, for example. It is not for the faint-hearted, in any case.

    You mention Aurora and gigabit, so I assume you wish to use the GTP transceivers in the Artix-7 on the the Nexys Video. VADJ has absolutely no effect on the GTP transceivers. Just make sure you set it appropriately for any other control pins or interfaces using regular user I/O (non-GT) pins.
    You also mention VC707, which has GTX (GTZ?) transceivers. The data rates supported are obviously different, but there might be other functional differences as well. Make sure all the pre-emphasis and voltage swing settings are correct.

    DPx and GBTCLK pins go directly to the FPGA. The PCB traces are length-matched and designed for 100-ohm characteristic impedance. Via stub elimination was not considered necessary. The GT power supplies are within spec. The interface was validated using IBERT with an FMC loopback board at the maximum data rate supported by the FPGA.

  15. Like
    elodg got a reaction from jpeyron in Anvyl board HID/PS2Keyboard interface   
    @pbaran,
    I did some edits to the relevant sections of the Anvyl Reference Manual. To summarize:
    The microcontrollers are USB embedded hosts supporting keyboards and mice implementing the USB HID boot protocol. The rule of thumb is if it works in a BIOS setting, it should work with our boards too. Devices with USB/PS/2 dual functionality are still used in USB mode.
    The whole set of PS/2 commands are implemented, even keyboard output commands. I could not find the contradictions you mentioned with respect to PS/2 specs. The device (microcontroller) always drives the clock pulses, but the host can pull the line low in certain conditions.
    There is a programming header, so you can write your own firmware and program it with Microchip tools. The firmware source code is not public. State your case in an e-mail to support and we might give it to you provided certain legal requirements are met.
  16. Like
    elodg got a reaction from cassini in HDMI Customization   
    DVI/HDMI is not easy. Which is the reason why we provide both an input and an output ip over at https://github.com/Digilent/vivado-library . You may re-use them without the need to understand the exact implementation. Or you can look at the source files, since we do provide the VHDL. A user guide is also available at the same location.
    To understand the protocol itself, read the specs. For example: http://www.cs.unc.edu/~stc/FAQs/Video/dvi_spec-V1_0.pdf
    I do admit that our DVI IPs are missing testbenches, so I cannot help with simulations. However, dvi2rgb has an ILA debug module option that can help you to look at signals.
     
     
     
  17. Like
    elodg got a reaction from Bianca in Anvyl Spartan-6 FPGA Trainer Board   
    Indeed, the project included in the workspace does not work. But if you create a new "lwip echo server" example project in SDK along with a new BSP, that works. Make sure any software firewall is off or allows ping packets.

  18. Like
    elodg got a reaction from amkichu in Anvyl Spartan-6 FPGA Trainer Board   
    What are you talking about? I opened 10.Anvyl_Ethernet_Demo in XPS 14.7, and upgraded the project to the latest version along with IPs. There are no IPs missing, but there is an error message upon bitstream generation that is answered here: https://www.xilinx.com/support/answers/62380.html
    Just double-click on axi_ethernetlite_0 and uncheck Include PHY I/O constraints, as described in the AR. Then, the bitstream gets generated successfully.
    Exporting to SDK works, but BSP needs to be regenerated to upgrade to the latest library version. Then the application compiles as well. I don't have a board at hand, but you can try it yourself using the upgraded project I attached.
    10.Anvyl_Ethernet_Demo.zip
  19. Like
    elodg got a reaction from dummyC in How to program the Nexys 3 using a USB memory stick?   
    @dummyC,
    The Nexys3 came with an older version of the firmware that did not support flash drives announcing high power requirement. Please try with an older pen drive, one that does not require more than 100mA of current. Device Manager in Windows 7 shows this info for the root hub the pen drive is connected to.
    There is an update for the Nexys3 firmware, but it needs to be loaded from an already working pen drive. This update should extend the range of supported pen drives.
    I will send the update in a PM.

  20. Like
    elodg got a reaction from vic in Running XAPP1079 on Zybo   
    I have never tried this app note. I will, when I get the chance, but no promises.
  21. Like
    elodg got a reaction from Bianca in UART Interrupt in zybo queries   
    The examples assume that you are using either axi_intc (Microblaze) or scugic (Zynq). You are mixing the two in your project only you know why. Theoretically it should work, but there are two interrupt controllers to initialize and setup handlers for. Scugic needs to enable the first F2P interrupt ID and set its handler to XIntc_InterruptHandler (or something like that). XIntc needs to enable the peripheral interrupts and set the appropriate handlers for each. Add probes to interrupt lines and check with the logic analyzer to confirm the propagation of the interrupt signals. Add software breakpoints to handlers to confirm that the proper ones are called.
    Honestly, if the type and polarity of the peripheral interrupts are compatible with Scugic, removing axi_intc from the design is probably easier. Then, all interrupt-based examples should work.
  22. Like
    elodg got a reaction from RisinT96 in [Solved] FMC-HMI Touch display operating voltages   
    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.
  23. Like
    elodg got a reaction from jpeyron in [Solved] FMC-HMI Touch display operating voltages   
    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.
  24. Like
    elodg got a reaction from Bianca in FMC HDMI port 2   
    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.
  25. Like
    elodg got a reaction from jpeyron in Generating Zybo project hdmi_in from Digilent's github in Vivado v2016.3   
    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.