Digilent Staff
  • Content count

  • Joined

  • Last visited

  • Days Won


elodg last won the day on August 7 2017

elodg had the most liked content!

About elodg

  • Rank
    Frequent Visitor

Recent Profile Visitors

1423 profile views
  1. elodg

    Zybo-Z7-20-pcam-5c many include files missing

    @qwaserdf, you are wrongly assuming that Vivado 2016.4 without SDK installed will work with SDK 2018.1. Because it does not, Vivado is giving you an error during project creation: "couldn't execute xsct...". Since that fails, you are left with an old hardware handoff (.hdf) in the sdk workspace. You are importing the same old hdf when creating a new hardware platform in the workspace. That explains why it is looking for an nonexistent DDYNCLK variable, which is for an IP that does not exist in the hardware project anymore. The rest of the SDK errors are due to the wrong SDK version. You can try importing the hdf from hw_handoff instead and go through with manually re-creating the BSP for 2018, but do yourself a favor and install SDK 2016.4 instead.
  2. elodg

    Nexys Video DMA Audio Demo is broken

    @bklopp, you are getting version errors as expected. Use the Vivado version the project was published in and tested for. If you still want to do the upgrade yourself, this particular SDK error can be fixed by manually updating each driver and OS version to the current one, or re-creating the BSP and manually importing all the settings from the old one.
  3. The connection flow is the following: Sink (Zybo) asserts Hot-Plug Detect -> confirm that HDMI_HPD is tied high and HDMI_OUT_EN is unused or tied low. Source (whatever you have connected) queries the capabilities over DDC -> confirm that Digilent DVI appears as a secondary monitor on a PC for example. Source begins transmitting video -> confirm that the Source actually enables the secondary monitor and drives a compatible resolution. Sink locks onto the signal -> confirm that clk_wiz is locked and aPixelClkLckd goes high. v_vid_in_axi4s splits video data into timing and AXI-Stream -> confirm with ILA that tvalid goes high and timing signals fit your resolution. v_tc matches the timing signal to a known resolution and, if configured, re-generates the same timing on its output -> confirm with ILA. v_axi4s_video_out waits for Start-of-Frame (tuser) and enables the generator in v_tc -> confirm vtg_ce and locked go high. Video appears on VGA -> confirm hsync and vsync are correctly timed for the expected resolution.
  4. I just ran implementation on the Zybo-Z7-10-HDMI project and it completed bitstream generation. Don't throw me off the scent here! So the implementation error is given for the PLL in rgb2dvi being out-of-range, because it is driven by a 165MHz PixelClk and it multiplies it by 10 internally, which is outside the 1600MHz maximum for PLL. PixelClk needs to be constrained properly for your maximum resolution. For 1080p, you are shooting for 148.5MHz. In a pass-through design this clock is coming from dvi2rgb, so you want to make sure that the TMDS input clock is constrained. Add create_clock -period 6.734 -waveform {0 3.367} [get_ports { hdmi_in_clk_p }]; to your top-level XDC.
  5. @joaBaur, I don't think this is related to the IP rev, but rather default settings for the expected TMDS clock frequency. From the documentation: Also, 165MHz TMDS clock is way outside the Artix-7 FPGA's BUFIO/BUFR capabilities. You might want to lower that.
  6. We don't have a Z7 board, but we do have Arty Z7 and Zybo Z7. Check the HDMI section of the Zybo Z7 reference manual for auxiliary signals. Everything you described is sound, it is just missing HPD. Hot plug detect needs to be driven by RX high, so that your laptop can read the DDC and detect a display. Also, if the board has buffers, muxes on the data path, there might be an enable signal needed too.
  7. elodg

    HDMI In to VGA out on Zybo

    @cgarry, I recommend ug949 chapter 5 for instructions on how to achieve timing closure. You have to click on each failing category in the timing summary and see the failing paths on the right. For example, if you check the Pulse Width constraint, it is due to driving the BUFR primitive with a frequency too high for an Artix-7 FPGA. You may ignore this warning, or specify a larger period constraint for the HDMI input clock (hdmi_clk_p) and using a lower resolution. The rest of the timing categories have to be analyzed path-by-path. Solve Inter-Clock first, which are most of the time due to incorrect clock-domain crossings. Intra-Clock should be solved by reducing congestion, trying different implementation strategies or lowering clock frequencies.
  8. elodg

    FPGA with really much RAM

    Hello Matthias, When you move from a software prototype to embedded hardware, you first need to think about how the implementation changes. Embedded systems have different performance/latency profiles and data access patterns are very important. See if you really need 8GB of memory for your algorithm. If yes, an FPGA board with SODIMM slot is your only viable choice. High-Bandwidth Memory is still expensive. I would start by researching the feasibility of your algorithm in hardware. Get to know FPGA architecture and write prototypes either in VHDL or HLS. The interfaces are secondary to algorithm. For Ethernet you will need a MAC and a microprocessor running an IP stack inside the FPGA. See if the latency of a Microblaze+lwIP combo is acceptable. Otherwise, you are left with implementing the IP stack in hardware that extracts the image data and spews it into memory. Similarly, for USB you will need a host controller. You either license an IP for FPGA or go with one of the ARM+FPGA hybrids (Zynq). The Zynq has both Ethernet MAC and USB controller included as hard cores, so you would only need to implement your processing algorithm in FPGA.
  9. elodg

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

    pHSync, pVSync, and pVDE on rgb2dvi IP

    On how to use the IP, check the countless examples available on our Github page, even if not specifically made for your board: https://github.com/search?q=org%3ADigilent+rgb2dvi&type=Code You can look at the block design and see where those signals are coming from. These are the synchronization signals adopted by DVI and HDMI from the analog world of television and VGA: http://www.cs.unc.edu/~stc/FAQs/Video/dvi_spec-V1_0.pdf The sync signals can be generated by the Xilinx IP Video Timing Controller. The actual timing parameters are defined in VESA and CEA specs, which are not free, but a quick web search will turn up something for sure. Also, here is a primer on VGA: https://learn.digilentinc.com/Documents/269
  11. elodg

    CMOS signals on Nexys Video FMC

    Deciding which signals could share coupled traces is I/O interface dependent. For example, if it is a source-synchronous parallel interface, crosstalk is not an issue between bits of the same data bus. All bits that change rise or fall in the same time, momentarily inducing change on coupled bits too. It all stabilizes quickly by the time the sampling clock edge arrives. However clock is essential to be monotonic and not have spurious edges. So in this case I would make sure clock (if single-ended) is coupled with a GND trace.
  12. elodg

    CMOS signals on Nexys Video FMC

    All Digilent FMC Carrier boards have User I/O pairs routed differentially, 100-ohm coupled. Artix-7 has HR banks, supporting LVDS_25 and many other differential standards. You may use single-ended standards too, like LVCMOS25. In this case, _P and _N traces will have crosstalk between them. Stronger coupling benefits differential noise rejection, but causes higher crosstalk between single-ended traces. In single-ended applications, depending on signal rise times, this might cause issues. In such cases use either _P or _N side for the useful signal and drive the other side with constant 0 or 1. It wastes pins, but helps with crosstalk. As always, check the schematic, reference manual and SelectIO user guide. The latter for verifying different I/O standard compatibility in the same bank, supply and termination requirements.
  13. elodg

    Error customizing/repackaging dvi2rgb IP

    Look for Vivado_init.tcl in: https://www.xilinx.com/support/documentation/sw_manuals/xilinx2017_4/ug835-vivado-tcl-commands.pdf https://www.xilinx.com/support/documentation/sw_manuals/xilinx2017_4/ug895-vivado-system-level-design-entry.pdf
  14. elodg

    Error customizing/repackaging dvi2rgb IP

    I just opened a project originally created in 2016.4 in Vivado 2017.4, updated all the IP, edited dvi2rgb by adding whitespace to one of the files, repackaged the IP, upgraded the IP in block design and successfully built it. Functional test passes too. Editing the IP the second time still does not show the xit file you mentioned. Are you getting error messages related to board definition files? I needed to created a Vivado_init.tcl with path to our vivado-boards repo so that I wouldn't get errors related to board interfaces.
  15. elodg

    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.