elodg

Digilent Staff
  • Content Count

    120
  • Joined

  • Last visited

  • Days Won

    9

elodg last won the day on October 10

elodg had the most liked content!

About elodg

  • Rank
    Prolific Poster

Recent Profile Visitors

2274 profile views
  1. elodg

    Digilent FMC implementations

    The short answer is no, Digilent is neither testing nor certifying 3rd party mezzanine cards. The long answer is that the role of the VITA.57 standard is to guarantee compatibility to a certain extent between carrier and mezzanine cards. Mechanical and power-wise the spec has ways to ensure this. In other matters, it is deliberately left open-ended. We are working on ways to better document those areas for our carrier cards. BTW, ADI has example projects for the Zedboard and their own ADC/DAC mezzanine cards.
  2. We do not recommend wiring the Pcam 5C to Pmod connectors of any kind. There is the mechanical issue of converting from the FFC connector to the Pmod, the electrical issue of terminating and adapting the D-PHY signals to LVCMOS and LVDS in a 3.3V bank and the issue of transmission losses of Pmod traces. Out of all the great things we could be working on this is the least desired.
  3. Hello @wooky, TL;DR No, the FMC Pcam Adapter is not compatible with the ZCU106. We will be releasing FMC Pcam Adapter+ next year that will improve compatibility. Even with that, however, the ZCU106 pin-out limits the number of Pcams to 3. As the reference manual states "the UltraScale architecture in particular has a very restrictive clock/strobe propagation mechanism". This means that once you try mapping more than one source-synchronous interfaces (like MIPI CSI-2) the propagation mechanism will quickly create conflicts between the interfaces. Again quoting from the manual, "the VITA 57.1 specs are not granular enough for the requirements of today's high-speed I/O architectures", so the best bet is creating a pin-out the supports the target number of interfaces on some specific carrier cards. The next upgrade to the FMC Pcam Adapter board will cover some Digilent, Xilinx and Avnet boards with varying number of interfaces supported. The other issue is IP-related. UltraScale+ brings I/O support for D-PHY, whereas previous architectures require some level translating solution. The FMC Pcam Adapter features such level translators, but the Xilinx D-PHY IP defaults to direct I/O support on UltraScale+ architectures. This means that the IP need manual editing to force the right I/O logic.
  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.
  5. 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.
  6. elodg

    Ethernet on Genesys 2 board

    Indeed, the Realtek PHY support is only present in their PS MAC code. Since your issue PHY and not MAC-specificity, you can try porting the PHY init code to the AXI Ethernet MAC functions. Apart from porting, you have other options as well: go back to the OOB demo version of the lwIP library or disable auto-negotiation and set a fixed link speed in BSP lwIP settings. Fixed link speed should work because I noticed that the auto-negotiated link speed query fails with the generic PHY init code. Let us know your results.
  7. elodg

    Ethernet on Genesys 2 board

    Hello @asmi, At least the OOB design works, which is a good starting point. The delay is due to how often the lwIP stack is polled in the demo among other tasks, and is expected. PHY support is not in the scope of lwIP, so Xilinx contributes PHY and MAC-specific initialization code and re-packages it as a BSP library. Basic PHYs functionality is controlled by common registers, but advanced functionality is in manufacturer-specific registers. The library (very correctly) warns you that Marvell or TI-specific registers were not written, because the PHY is different. Please take a look at the latest commits to the embeddedsw repo, because there seems to be Realtek support now: https://github.com/Xilinx/embeddedsw/blob/master/ThirdParty/sw_services/lwip211/src/contrib/ports/xilinx/netif/xemacpsif_physpeed.c The 2019.1 tag shows Realtek support present in the source code, so I expect it to be packaged with SDK. If it isn't, you can always take the latest source code, add it as a repository to SDK and it will appear as an option to add to BSP. BTW, this is also the route to go on, if you want to edit source code: make a copy of the library, rename it, add it as a repo and it will be pulled in during the Regenerate BSP Sources step of building the BSP.
  8. 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.
  9. 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.
  10. Since you took the sources out the packaged IP and instantiated them as a module, please provide the generic parameters you instantiated with.
  11. 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.
  12. @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.
  13. 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.
  14. 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.
  15. 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.