elodg

Digilent Staff
  • Content Count

    113
  • Joined

  • Last visited

  • Days Won

    8

Everything posted by elodg

  1. This seems relevant: The same goes for GTX transceivers on the G2. Either use the wizard for your IP and do the lane mapping there, or instantiate it as GTX primitives and write a LOC constraint for the channel primitive. Since the channel primitive is fixed to its pins and there is no IOSTANDARD to specify, you do not need to constrain the pins at all. This is what I see in the JESD wizard.
  2. Assuming you instantiated with the default generics kGenerateSerialClk : boolean := true; kClkPrimitive : string := "PLL"; , you do not have to provide SerialClk to the module. The error message is complaining about CLKIN1 of the PLL generating SerialClk internally. CLKIN1 is actually PixelClk, so check where it is coming from and if it is a valid signal.
  3. Since you took the sources out the packaged IP and instantiated them as a module, please provide the generic parameters you instantiated with.
  4. From the IP documentation: Optional, if you enable the internal generation option in IP customization. If not, it must be generated external to the IP and provided on the pin.
  5. @Jonathan.O, I am seeing SPI signals in the code, not SD native. I though the whole point of this exercise is to have the interface with the lowest latency. In any case you have to get the init sequence right first. Either use ILA and Vivado Hardware Manager to debug the sequence, or switch back to Microblaze and software for easy debugging. Honestly I would do Microblaze just to have file system support. The init sequence is complicated with several modes and states the SD card can be in, wait times, status polls which are not easy got get right, especially in VHDL. Also confirm the clock speed is in the init range until the card is able to accept the maximum frequency.
  6. elodg

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

    Vivado sysnthesis fail..Pcam

    The error is due to IPs and sub-IPs not being upgraded to the new version. I just posted a new release of the project which aligns the format with the digilent-vivado-scripts flow and upgrades everything to 2018.2. See here. Notice anything amiss? Post on issue on GitHub. It cannot be said often enough that Digilent only supports the Vivado version the project was released for. Furthermore, for a healthy dose of mental sanity, only one version is supported per year. For the year 2018 it is 2018.2, and not 2018.3 as @Ciprian said.
  9. 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.
  10. Behavior confirmed. Will be looked at.
  11. Just to confirm, are we talking about Zybo or Zybo Z7?
  12. 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.
  13. @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.
  14. 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.
  15. 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.
  16. elodg

    Nexys Video "Feet"

    https://www.fastenal.com/products/details/0146057 https://www.fastenal.com/products/details/28783
  17. @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.
  18. In block design, this is the way to do it. Other than writing it in VHDL and adding it as module.
  19. 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.
  20. There you go: https://reference.digilentinc.com/reference/programmable-logic/zybo-z7/reference-manual#hardware_errata
  21. @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.
  22. 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!
  23. 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.
  24. Check your internet connection, it works for me.
  25. 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.