elodg

Digilent Staff
  • Content Count

    112
  • Joined

  • Last visited

  • Days Won

    8

Everything posted by elodg

  1. Your best bet is looking in the XDC file or schematic. Also, the VITA.57 spec for FMC connectors is helpful. There is nothing really to it. All the pins listed there are differential-capable pins routed straight to an FPGA bank powered from VADJ. When you are designing your FMC mezzanine module just choose some (preferably lower order) of the LA signals. Clock inputs should go on CC pins and source synchronous interfaces should be grouped into LA halfs (banks). If you have only single-ended signals and you are concerned about crosstalk between _P and _N, just choose one side for your signals and tie its pair to ground. Look at other FMC modules for examples, like our FMC-HDMI. There are some auxiliary signals that need to be tied in a certain way, which is spelled out in the VITA spec.
  2. @tuan, Fix the async group timing issues by adding clock-domain crossing circuits with false path constraints. That alone might solve the intra-clock issues. I imagine the Clocking Wizard has 74.25 for input and outputting 1x and 5x. Make sure the clock constraints are correctly generated. I don't know how the SelectIO interface wizard works, but DVI input requires phase delay calibration, which needs IDELAYCTRL, which needs a 200MHz reference clock. I don't see that anywhere. Try our IP offering (https://github.com/Digilent/vivado-library/tree/master/ip/dvi2rgb), see if it works any better. Our IP has an internal register (eye_count) that you can debug with ILA to see the results of the phase delay calibration for each channel. Blue having a shorter eye width might explain the issues you are seeing.
  3. Keep in mind that: "The input system clock cannot be generated internally." -quote from ug586. In other words, you should not be cascading MMCM/PLL for MIG purposes. So sys_clk must come from a CCIO pin, either in the memory controller bank, or in this case from another bank in the column through the clock backbone (SYSCLK is in bank 34, just below DDR3 bank 35. MIG will instantiate a PLL and an MMCM in the clock region of bank 35. If you do not want to re-use that MMCM to generate the 200MHz clock, you need to instantiate another MMCM in the clock region of bank 34, getting input from the same SYSCLK routed on the backbone. Configure MIG for 100MHz sysclk, No Buffer. In the example project, configure a new Clocking Wizard for 100MHz input, No Buffer, synthesizing 200Mhz. Add to example_top: IBUFG_inst : IBUFG generic map ( IBUF_LOW_PWR => FALSE, -- Low power (TRUE) vs. performance (FALSE) setting for referenced I/O standards IOSTANDARD => "DEFAULT") port map ( O => sys_clk_ibufg, -- Buffer output I => sys_clk_i -- Buffer input (connect directly to top-level port) ); RefClkGen: clk_wiz_0 port map ( -- Clock in ports clk_in1 => sys_clk_ibufg, -- Clock out ports clk_out1 => clk_ref, -- Status and control signals reset => '0', locked => open ); Then, wire the clocks to the mig core instance in example_top: -- System Clock Ports sys_clk_i => sys_clk_ibufg, -- Reference Clock Ports clk_ref_i => clk_ref, -- System Clock Ports sys_clk_i => sys_clk_ibufg, -- Reference Clock Ports clk_ref_i => clk_ref, Also add the following to your XDC file: set_property CLOCK_DEDICATED_ROUTE BACKBONE [get_nets -of_objects [get_ports sys_clk_i]]
  4. As D@n said earlier ref_clk must be 200MHz. This is clearly stated in UG586. If the system clock was in range, it could be used a reference clock too. However, on the Nexys Video this is not the case so the only other option is generating it internally ("No Buffer"), as allowed by UG586. You have three options: The easiest is to use block design and instantiate MIG with AXI, which will allow you to specify additional clocks to be generated, set one of them to 200MHz and loop it back to the clk_ref pin. The other two options require manual changes. In a project where you instantiate MIG (either yours or the example design) you mark the MIG as "User-managed IP": https://www.xilinx.com/support/answers/57546.html. Then, you are free to edit the MIG-generated files. You need to go down two levels and look for the instantiation of mig_7series_v2_1_infrastructure. You need to set the following addition parameters: UI_EXTRA_CLOCKS => "TRUE", MMCM_CLKOUT0_EN => "TRUE", MMCM_CLKOUT0_DIVIDE=> 4 CLKOUT0_DIVIDE needs to be calculated though. CLKOUT0_DIVIDE = Fsys_clk / DIVCLK_DIVIDE * CLKFBOUT_MULT / 200M. Then the port ui_addn_clk_0 will have your 200MHz reference clock that you need to wire to clk_ref. I attached a MIG example project done in 2014.4 that has the modifications. No guarantees that it actually works, use it as reference only. The third option leaves the MIG IP alone and modifies the hosting project instantiating another MMCM sharing sys_clk as an input with MIG. Set the extra MMCM to generate 200MHz and wire it to clk_ref. mig_800_example.xpr.zip
  5. Write your own UART controller and implement a command-based protocol on top of it. If you have a microblaze-based design, add the Uartlite IP and implement your command-protocol in software. This is an example of UART command processing written in software for the Zybo: https://github.com/Digilent/Zybo-hdmi-out/blob/master/sdk/displaydemo/src/display_demo.c
  6. You are missing IP definitions because you did not check out sub-modules. When cloning, do it recursively. Or, do a submodule update on an already cloned repo. More info here: https://stackoverflow.com/questions/3796927/how-to-git-clone-including-submodules The properly cloned repo should have vivado-library in the repo/ folder. You are seeing IP revision change for other locked IPs because the project was created in 2016.4. Upgrade is hard and fought with blood. We provide no support for it, outside our regular upgrade cycle. Use 2016.4 and see if you still have issues. If not and the project works, you can embark on a version upgrade, if absolutely needed.
  7. elodg

    Pynq Heating Issues

    Open the XADC graph in Vivado Hardware Manager to see the FPGA die temperature. Make sure boot mode is set to JTAG. It is normal for the board to get warm.
  8. @dummyC, The Nexys3 came with an older version of the firmware that did not support flash drives announcing high power requirement. Please try with an older pen drive, one that does not require more than 100mA of current. Device Manager in Windows 7 shows this info for the root hub the pen drive is connected to. There is an update for the Nexys3 firmware, but it needs to be loaded from an already working pen drive. This update should extend the range of supported pen drives. I will send the update in a PM.
  9. @pawel.pawelec Try the attached core version, see if it works. I believe GoPro requires CEA extension block in the EDID for it to work. dvi2rgb_v1_6.zip
  10. It is impossible to support all the I/O standards with the recommended terminations schemes on a generic connector. Pmod is for LVCMOS33 mainly. XADC Pmod is for analog differential mainly. Provided that you are willing to give up warranty and do some hacking, you can try to make it work. For LVDS output you will need VCCO=2.5V which the Nexys Video is capable of. The other end will need the standard 100ohm differential termination. If you leave the two 100 ohm series resistors there, the voltage swing will be the third of the nominal value. It might be enough if the receiver has wide operating range. Short the resistors for larger swing. For inputs, VCCO=2.5V will give you internal terminations. The series resistors will have the same effect as above. If you have only 3.3V available, you will have to load a parallel termination resistor. For the Pmod XADC on the Nexys Video you can do that on the capacitor footprint in the anti-alias filter. All the above concerns voltage levels only. Impedance mismatches will cause considerable signal degradation if the signal edges are steep enough. Other than slowing down the signal, there is nothing more you can do. Safe hacking!
  11. Make sure the whole DDC bus is connected to the external port directly. The I/O buffer should be automatically inferred and the only external ports you should see are ddc_scl_io, ddc_sda_io. I edited the table in the reference manual to make it clearer that the pins are grouped by connector. You will need either the Sink or the Source column. Regarding the SDK error messages, try re-creating the hardware platform by importing the hand-off file, and the BSP by creating a new one and overwriting the mss file with the old one.
  12. elodg

    Running XAPP1079 on Zybo

    I could not yet find the time to try those application notes. Digilent does not provide bare-metal demos for dual-core operation. I am wondering whether the Xilinx forum would not be more appropriate.
  13. I will refrain from the socio-political aspects of this question. Purely from the technical perspective, I am thinking replacing that manual labour step with cameras and image recognition. I cannot think of anything else that is easier to implement and close to impossible to cheat.
  14. elodg

    Running XAPP1093 on Zybo

    How is this question different than ? Possible duplicate.
  15. Looking at the block design and the interrupt handlers here is what is happening in the example design: when an HDMI clock is detected, the GPIO interrupt is triggered and gets handled by GpioIsr. This in turn enables the vtc (Video Timing Controller) interrupt. If a known resolution is detected on the timing signals, the vtc interrupt is triggered and gets handled by VtcIsr. This reads in the detected timing information (videoPtr->timing) and calls VideoStart. You either need to tie all camera sync signals (not just v_sync) to vtc, if the camera outputs at a VESA standard timing, or replace the timing detection mechanism altogether. A quick and easy way is to hard-code the timing information, since it is you who is configuring the camera to a set resolution. In this case, remove the interrupts altogether and call VideoStart when the camera is transmitting. Mismatch in number of pixels and lines between the camera and VDMA might cause errors or lock-up. Use Vivado to insert logic analyzer probes and follow the video stream as it flows from the camera to the VDMA. Since the pattern is shown I expect the output stream (from the VDMA to the VGA) to be working.
  16. elodg

    Running XAPP1079 on Zybo

    I have never tried this app note. I will, when I get the chance, but no promises.
  17. elodg

    Running XAPP1079 on Zybo

    https://reference.digilentinc.com/reference/software/vivado/board-files?redirect=1 This will install board definition files for the ZYBO. Then, in your project settings you can choose the board and not the Xilinx part. Finally, instantiating the PS IP and running block automation will give you the option to apply board preset to the processor. In your case, in an existing project it is probably better to import a preset to the Zynq Processing system only. I don't know why we haven't published this before, but I added it to our ZYBO repo: https://github.com/Digilent/ZYBO/tree/master/Resources/Preset Just go to Presets -> Apply Configuration and choose the tcl file from above.
  18. elodg

    Arty-Z7 GPIO0 access

    Read the GPIO section of ug585. The XGpioPs driver maps MIO and EMIO into different GPIO banks and uses sequential designators mixing the two. You most probably should not be reading bank 0 or pin 0.
  19. The easiest way is getting that version, running the scripts to generate the hardware project and then opening it in your new version, where an upgrade will be performed. The hard route is going into build_bd_design.tcl and manually editing it to deactivate the version warning and modify all IP versions to their current version in "create_bd_cell" commands. Then trial-and-error until the project gets generated without errors. Depending on the IP changelogs there might be interface differences, but those are rare.
  20. All the example projects on our Github page that use the PL-to-PS interrupt: https://github.com/search?utf8=✓&q=org%3ADigilent+IRQ_F2P++extension%3Atcl&type=Code&ref=advsearch&l=&l= In 2016.4 at least I am getting the correct defines in xparameters.h: #define XPAR_FABRIC_XADC_WIZ_0_IP2INTC_IRPT_INTR 61 #define XPAR_FABRIC_AXI_DMA_0_MM2S_INTROUT_INTR 62
  21. The examples assume that you are using either axi_intc (Microblaze) or scugic (Zynq). You are mixing the two in your project only you know why. Theoretically it should work, but there are two interrupt controllers to initialize and setup handlers for. Scugic needs to enable the first F2P interrupt ID and set its handler to XIntc_InterruptHandler (or something like that). XIntc needs to enable the peripheral interrupts and set the appropriate handlers for each. Add probes to interrupt lines and check with the logic analyzer to confirm the propagation of the interrupt signals. Add software breakpoints to handlers to confirm that the proper ones are called. Honestly, if the type and polarity of the peripheral interrupts are compatible with Scugic, removing axi_intc from the design is probably easier. Then, all interrupt-based examples should work.
  22. First, open the synthesized design netlist in the IP project and see if anything got optimized due to bad HDL. Then, do the same in the project that instantiates your IP and ties the AXI bus to a master. Watch for warnings related to nonexistent objects, inputs hard-wired to constants or unused signals.
  23. elodg

    Running XAPP1079 on Zybo

    For sure you will need to apply the correct preset to the board. Input clock frequency, DDR3 parameters and MIO mapping most probably differ between the two boards. After you apply the Zybo preset check the differences between the two preset, stuff like which UART controller should be used for stdout. Also, you were saying it does not show anything after booting from SD. Define FSBL_DEBUG and confirm that it actually boots your application. Also try launching over JTAG from SDK.
  24. Jumpers J1 should be left on all the time. If the DA/DB pins of the mux show a different voltage than the A-dependent SxA/SxB pins, the mux is broken and you can try claiming warranty. If the mux works fine and the XADC measures a negative differential voltage with floating inputs, but none of the pins is negative w.r.t. GND, it is working as expected. You can avoid floating inputs by doing a touch presence measurement first. Glad you got it working.
  25. Just to be clear, you are digitally driving '1' to XD+ and '0' to XD-, resulting in a drive of 2.5V. The rest should be HiZ. Just for the kick of it, using a voltmeter measure between XS+ and XS-. This is the voltage across the X panel put in series between the 1K and 150ohm resistors on-board forming a resistive divider. This is independent of touch and is caused by the characteristic resistance of the panel. To measure actual touch coordinate, you need to measure between YS+ and XS-. XS- is a point in the resistive divider, close to 0V and YS+ is floating, if there is no touch. If there is touch, YS+ is too inserted in this resistive divider and you should measure a voltage that is between 0V and 1V. Measuring floating inputs should not result in stable negative measurements. Read http://www.ti.com/lit/an/slaa384a/slaa384a.pdf again and draw a schematic for better understanding.