elodg

Digilent Staff
  • Content Count

    102
  • Joined

  • Last visited

  • Days Won

    8

Everything posted by elodg

  1. elodg

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

    Genesys2 Display Port

    @MateoConLechuga, what I meant is that the OOB demo that the board is programmed with in factory correctly drives DisplayPort. Indeed, none of the source files we provide on Github work. Thanks for publishing your project.
  3. elodg

    Genesys2 Display Port

    The out-of-box demo in the flash memory drives the DisplayPort out and you should see it working. The source files for the project are here, where Jon linked to. The issue with the DP IP in the demo was that it requires a license to generate a bitstream, so it was removed and re-published here. I am glad you made it work, I know the feeling of satisfaction when that happens. I am eager to find out what was actually wrong with what you were trying.
  4. Hello Blake, Sincere apologies for the process taking so long. I will have to ask for your patience again. @BogdanVanca will send you a test project for the Zedboard + FMC-HDMI combo and instructions on how to execute the tests that are also used in manufacturing. I have to commend you for the clear description of the problem and all the debug work you already did. The message quoted above is expected for the first run on a new FMC-HDMI. It is unrelated to your issue. Let's wait for the test project and see the results before we go further.
  5. elodg

    Nexys Video "Feet"

    https://www.fastenal.com/products/details/0146057 https://www.fastenal.com/products/details/28783
  6. elodg

    ZedBoard XADC Header Dedicated Inputs

    @mehmetdemirtas89, The picture only shows that you can connect an input signal that has a DC component of maximum 0.5V and an AC component of maximum 0.5V. So the +-0.5V AC can have and offset between 0-0.5V. This is a signal between -0.5V and +0.5V or between 0V and 1V at the extremes.
  7. elodg

    On and off-chip connections with EMIO GPIO

    In block design, this is the way to do it. Other than writing it in VHDL and adding it as module.
  8. elodg

    Facing error in the rgb2dvi IP

    The error message complains about the internal frequency of the MMCM in rgb2dvi being too high. There are two things that influence the error message: the input clock frequency, and the parameters of the clock primitive. The input clock frequency is propagated from dvi2rgb and is originally coming from the TMDS_rx_i_clk_p port. The parameters of the clock primitive are exposed in the rgb2dvi IP wizard as the expected resolution/clock frequency. Your project seems to have the latter set to expect a low resolution/frequency, hence the 15x multiplication factor. However the input clock is timed for the highest DVI frequency possible at 165MHz (6.06ns). In a synthesized design you can execute the write_xdc command to dump all constraints to a file. Then look for the erroneous clock definition to find where it is coming from.
  9. There you go: https://reference.digilentinc.com/reference/programmable-logic/zybo-z7/reference-manual#hardware_errata
  10. @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.
  11. elodg

    MIPI to Digilent board, transfer rate, which boards work?

    MIPI CSI-2 cameras use MIPI D-PHY for the physical transport layer. The D-PHY I/O standard is only supported by UltraScale+ I/O pins. Any other architecture needs some form of adaptation. The compliant solution is the Meticom D-PHY-LVDS translator. A compatible solution with a passive termination network is described in https://www.xilinx.com/support/documentation/application_notes/xapp894-d-phy-solutions.pdf The compatible solution is in use on our Zybo-Z7 board's Pcam connector, which allows connecting one Pcam 5C camera module. It works up to the maximum data rate supported by the Pcam 5C, 672Mbps per lane, or 1344Mbps total. Your data rate is a bit high. Check the per lane data rate, which will tell you whether the passive termination suffices or your will need an active level translator. In any case, getting those high data rates into the FPGA requires high-speed connectors, like the purpose-made Pcam or the generic FMC connector. FPGA datasheets will tell you the maximum data rate supported by LVDS transmitter/receiver depending on speed grades. Some of our upcoming products will feature more than one Pcam connector. Check back for updates!
  12. HDMI_TX_HPD is input, HDMI_RX_HPD is output. See https://reference.digilentinc.com/reference/programmable-logic/zybo-z7/reference-manual#hdmi Leave HDMI_TX_HPD unconnected, if not used. Why don't you look at a demo we have on our Github: https://github.com/Digilent/Zybo-Z7-10-HDMI? Debug your design by tying signals to LEDs or ILA modules. The flow is the following: Sink (Zybo Z7) asserts Hot-Plug Detect -> confirm that HDMI_RX_HPD is tied high. 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 dvi2rgb/aPixelClkLckd goes high. Video is decoded -> confirm dvi2rgb/VSync, HSync and VDE are toggling. Video appears on output -> confirm hsync and vsync are correctly timed for the expected resolution.
  13. elodg

    Nexys 4 DDR with a new DDR2 chip

    Check your internet connection, it works for me.
  14. elodg

    NexysVideo PHY-MAC routed delay path

    It was left off from the capture, but those values are trace lengths in mm. C23 is reserved there for EMC purposes, it has nothing to do with the delays you are looking for.
  15. elodg

    NexysVideo PHY-MAC routed delay path

    The skew demanded by the RGMII specs between clock and data groups has not been implemented on the PCB. See the trace lengths below (unit mm) for delay matching inside the signal groups. This implies that the skew must be implemented in the MAC and/or PHY. The PHY has internal delays that are configurable by pull resistors on pins 32 and 16: R88/83 and R72/79. The board is shipping with no PHY delays enabled as written in the reference manual: You may change these on your board. The reason for no delay matching by default is because of the flexibility in MAC implementation in the FPGA. Check the exact MAC IP for delay matching. If it is not readily configurable, enable it in the PHY instead.
  16. elodg

    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.
  17. 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.
  18. 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.
  19. 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.
  20. 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.
  21. @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.
  22. 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.
  23. 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.
  24. 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.
  25. 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.