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

1307 profile views
  1. 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.
  2. 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.
  3. 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
  4. 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.
  5. 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.
  6. 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
  7. 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.
  8. 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.
  9. Error [DRC PDRC-34] when trying to use dvi2rgb on Vivado 2017.4

    What makes you think the culprit is RefClk? I will add a debugging section to the documentation to make recognizing the error message easier.
  10. Error customizing/repackaging dvi2rgb IP

    Hello @tbrowning, Error 1 is due to the fact that each dvi2rgb instantiates its own IDELAYCTRL, which really aren't that many of in the FPGA. The solution would be what Xilinx IP do, having an option for instantiating shared logic externally. Or having an IP customization option for instantiating IDELAYCTRL. If you do implement that, please contribute back. Error 2 must be some new Vivado sh!@$$&#&$. I have not seen this in earlier versions. Maybe try creating a new IP and importing sources.
  11. Error [DRC PDRC-34] when trying to use dvi2rgb on Vivado 2017.4

    Translation of the error message: The MMCM primitive in dvi2rgb is getting a 165MHz input clock, which it multiplies by 10 and divides by 1, resulting 1650 MHz internal VCO frequency. This is outside its operating range as per the Zynq datasheet. The problem is that the DVI implementation needs a serialization clock five times the frequency of the input clock. There are several sets of multiplier and divider values possible to achieve this, but not all result in a valid VCO frequency and no single set covers the whole range of pixel frequencies (video resolutions). Adjust the IP settings to higher expected resolutions: >120 MHz (1080p). BTW all this is already described in the dvi2rgb user guide.
  12. Using 10Gb/Sec SFP board with Genesys2

    For sure they are not pin compatible, but adhere to the common VITA.57 spec. You will need to change the XDC location constraints, but otherwise the same features are available in the G2 FMC connector as on the Xilinx ones. If anything the Digilent board has more pins wired, the G2 FMC connector is a fully-bonded High Pin-Count connector. The only place where you can wire into the GTX transceivers are shown on pg 14 of the schematic: DisplayPort and FMC DPx pins. DisplayPort connectors have not been tested with >5.4 Gbps, nor they are certified for those rates. This leaves you with the option of designing an FMC mezzanine card for yourself that have the ADC, DAC and SFP+ cage on it. For I2C you may use any of the User I/O pins of the FMC: LAx, HAx... Or even Pmods. Pay attention to I/O voltages.
  13. @aytli, There are two behaviors you are questioning: initialization upon reset and caching. Initialization has both a hardware and a software component to it. By RAM I assume you are referring to DDR3. The content of DDR3 memories are undefined after a power-down event. It could be random data or Mona Lisa, with the latter having a negligible chance. The software component in this case is governed by the specifications of the C language referring to initialization of variables. For example: If an object that has automatic storage duration is not initialized explicitly, its value is indeterminate. If an object that has static storage duration is not initialized explicitly , then: —if it's as pointer type, it is initialized to a null pointer; —if it's an arithmetic type, it is initialized to (positive or unsigned) zero; —if it is an aggregate, every member is initialized (recursively) according to these rules; —if it is a union, the first named member is initialized (recursively) according to these rules. Your digits variable has static storage duration so it is initialized to zero by the loader or the C runtime. According to your debugger this was implemented. Your issues must stem from a caching behavior. You have two masters accessing the memory: processor and video DMA. The processor goes through a D-cache, while the DMA has direct access. This means that the two master's view of the memory is not the same: the DMA is not seeing what you are writing in software, because data is held in the cache instead of written out to memory. Do a D-cache flush after writing the frame buffer from software to commit the new values to the memory. The header xil_cache.h has a Xil_DCacheFlush function declared in it.
  14. Arty adjustable clock with Microblaze and Vivado SDK

    @Weevil, The error is due to an invalid connection. PXL_CLK_5X_O uses a BUFIO internally that cannot be routed to an external pin, which is what you are trying to achieve. To make it work, leave it unconnected and use PXL_CLK_O for internally clocking your DDS Compiler instance. These are particularities of the axi_dynclk IP due to it being meant for video applications. If you cannot make it work, see other options below. For dynamic clock generation, you have two IP options: Xilinx Clocking Wizard with AXI-Lite interface or the Digilent axi_dynclk. Advantages of Clocking Wizard: clock buffer options more suitable for non-video applications, documentation Advantages of axi_dynclk: clock buffer options (BUFIO, BUFR) suitable for video applications, driver with VCO parameter calculation. The Digilent axi_dynclk in the master branch of vivado-library does not have a standalone driver nor documentation. It does have a linux driver though. See issue https://github.com/Digilent/vivado-library/issues/14 However, there is a new version of axi_dynclk with a standalone driver on a different branch: https://github.com/Digilent/vivado-library/tree/feature/axi_dynclk_driver
  15. Anvyl Spartan-6 FPGA Trainer Board

    Indeed, the project included in the workspace does not work. But if you create a new "lwip echo server" example project in SDK along with a new BSP, that works. Make sure any software firewall is off or allows ping packets.