Jump to content

coldfiremc

Members
  • Posts

    18
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

coldfiremc's Achievements

Member

Member (2/4)

1

Reputation

  1. I have 2 pull requests, pls check 🙂
  2. I can make a support case, I have enterprise support
  3. Thanks @zygot. I have two nexys video boards and a Nexys A7 among other fancy RFSoC boards. I would like to follow this test designs. I have a Xilinx enterprise license, so I can open cases, and I use this MIG ip's too much in kind of critical applications to let nasty bugs to appear this way. If you can narrow those bugs, I would get some sort of official answer with Xilinx. One of the causes of the limited clocks for MIG is the fact that MIG generates inside its refclock and max PLL clock and divider options get very limited this way. Better designs use 2 clocks: one for data, and one for reference, coming from external oscillators. It would be neat to have more boards designed with 2 differential oscillators (can be cheap oscillators, there's no need to get oven controlled PLL's in domestic boards like digilent's)
  4. I learned how to edit those xml files. Can I push a new version to the digilent repo?. Can you after that push them to the xilinx board store?
  5. Some News https://support.xilinx.com/s/feed/0D52E00006wQfP7SAK?language=en_US There's some little details in the IP and interface definitions. I tweaked a little the Board file also, to fix clocks and not matching of the TMDS interface names. HDMI input has the same problem probably, so it's time to check it
  6. Check logs and implemented design to see if the block is optimized/deleted in some way
  7. I finally managed to interface this device. I used lots of documentation, but the most informative was the altera AN433 Application note, that details how to write and derive constraints to modify the STA behavior to time this type of devices properly. Thanks @zygot
  8. Ok I found something Interesting Despite the board file has the I/O pins defined for this interface (and an associated IP), Implementation fails because i/o pins are not fixed. This is very strange considering that to assign a pin explicitly is enough to fix the I/O mapping. This is the error (The ISERDES needs an explicit and fixed mapping) Here's the "anomaly" I will check this further, digging in the Board File. Probably it needs a little fix Greetings
  9. After developing a project with this board I noticed that this problem is not only affecting the DVI input IP, but also the clock wizards. Apparently the board file has some inconsistent names. Also the constraints for this IP are a little "Weak" and with a minimum modification, are not applied correctly. Please update the board files. A workaround for this is write constraints manually, but this is not always easy for block designs. Also there's other problem with rgb to DVI, input frequency is not updated accordingly, so this error appears [BD 41-927] Following properties on pin /rgb2dvi_0/PixelClk have been updated from connected ip, but BD cell '/rgb2dvi_0' does not accept parameter changes, so they may not be synchronized with cell properties: FREQ_HZ = 75000000 Please resolve any mismatches by directly setting properties on BD cell </rgb2dvi_0> to completely resolve these warnings. Also incorporating the clock generator inside the ip limit the IP seriously. I think that the integrated clock generator must be discarded to simplify design and allow proper clock settings.
  10. Hi I'm trying to use the RGB to DVI ip to acquire video, and I'm getting placement errors. if I unpackage IP, I, can't find any "conflictive" setting related to placement, in the sense that there isn't any physical pin reference at all and ISERDES instances look good. I'm providing the 200mhz ref clock to properly drive input delays and I'm not using any external constraint file. How can I fix or check that there isn't anything wrong? The board (and related configuration) being used is a nexys Video, and compiling with Vivado 2021.1. The rest of the design has a microblaze, some buttons and leds and the DDR3 memory controller. I'm using the latest IP version from the Digilent IP Repo. Thanks
  11. RGB to DVI is just about the physical interface and not the video signal itself. AXI4-to-video IP in fact supports interlaced video. The important part is to calculate properly the timings and setting a proper serial clock for HDMI with an external clock manager. You have to check if your FPGA has enough resources to do this, knowing that HDMI serial clock is a little high.
  12. Hi I have to interface an ADC for a project, and this ADC(ADS4225) fits the requirements. I'm planning to buy the development board and the needed adapter to connect it to the FMC port of a Nexys Video. However, I never interfaced a high speed DDR LVDS device before, and this device (and all of its class) need some signal adjustments to get the data links properly aligned. Can I get some guidance to implement input delays and DDR clock calibration? Thanks
  13. coldfiremc

    Nexys Video HDMI

    I think that this could be a better approach. However, if you want a more clean board you can buy one of those Trenz Electronik SOM's and snap it in a sort of motherboard for your application. With nexys video you can develop the inner parts of the system and then go for the final model with some of those SOM's. This is in the pricey side, but you will end with a more professional "workflow" and a cleaner product. Also SOM's are cheaper than development boards because the absence of connectors and peripherals.
  14. coldfiremc

    Nexys Video HDMI

    It's clear that this cannot be "sufficiently safe" for a commercial design, even considering that the high clock is going into the OSERDESE2. It would be great to hear an "official" answer from Digilent. It's also obvious that clocks in this board are some sort of limited by size/cost/application.Also It's worth to note that the OSERDESE2 implementation is using DDR, that's a pretty neat trick to get the objective frequencies, especially considering the serial clock. Most of this pricepoint boards can't even get 720p running with standard timings. This board struggles to get it, bug it gets, and for most developers it's just enough to develop the rest of the system. This is a good enough board for the price, and does not rely in jerry-rigged designs or obscure files. I have did lots of high bandwidth stuff just with RTL and board files are quite simple. I'm cleaning the bd to get it on github to upload it and discuss it.
×
×
  • Create New...