elodg

Digilent Staff
  • Content count

    68
  • Joined

  • Last visited

  • Days Won

    6

elodg last won the day on August 7 2017

elodg had the most liked content!

About elodg

  • Rank
    Frequent Visitor

Recent Profile Visitors

1127 profile views
  1. 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.
  2. @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.
  3. 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
  4. 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.
  5. Anvyl Spartan-6 FPGA Trainer Board

    See what the terminal says on the USB/UART port of the Anvyl. Does the lwip server bind successfully to the IP?
  6. Anvyl Spartan-6 FPGA Trainer Board

    What are you talking about? I opened 10.Anvyl_Ethernet_Demo in XPS 14.7, and upgraded the project to the latest version along with IPs. There are no IPs missing, but there is an error message upon bitstream generation that is answered here: https://www.xilinx.com/support/answers/62380.html Just double-click on axi_ethernetlite_0 and uncheck Include PHY I/O constraints, as described in the AR. Then, the bitstream gets generated successfully. Exporting to SDK works, but BSP needs to be regenerated to upgrade to the latest library version. Then the application compiles as well. I don't have a board at hand, but you can try it yourself using the upgraded project I attached. 10.Anvyl_Ethernet_Demo.zip
  7. FMC Configuration for PMOD ADC input

    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.
  8. @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.
  9. DDR3 mig 7 traffic control example on nexys video board

    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]]
  10. DDR3 mig 7 traffic control example on nexys video board

    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
  11. Use Smartphone MHL(TV-Out) output as ZYBO HDMI INPUT

    @faescobar85, when you say detected by the computer, do you mean Windows showing a secondary screen called Digilent DVI? Detection should happen over the DDC bus by reading the EDID and has nothing to do with aPixelClkLckd. Only after extending/duplicating the desktop will the video link come up and the dvi2rgb core lock onto it. The latter is the aPixelClkLckd signal. I recommend Vivado hardware debugging on: aPixelClkLckd, PhaseAlign/pAligned, PhaseAlign/pEyeSize, PhaseAlign/pError, ChannelBond/pMeRdy for all three channels.
  12. If one has the time, give kUseFastAlgorithm a try. This is a generic parameter in the PhaseAlign module that is set to false for now. One could make this parameter accessible from the IP wizard and should result in faster lock times in some cases. It is an untested feature, however.
  13. Problems with dvi2rgb at low resolutions

    This is an old thread, but maybe it will help someone having the same issue. The minimum limit of 40MHz for pixel clock comes from the phase alignment implementation on 7-series FPGA, as @mikeanthonywild noticed it. There are 32 steps available for delaying each data channel independently. Each step adds an additional delay of 78ps. The maximum amount of delay possible is roughly 2.5ns. For low pixel clock frequencies this does not span the whole bit period, so phase alignment might not be possible. That being said, back in Jan 2016 I changed the phase alignment algorithm to lock once a wide enough valid data eye is found, even if the whole bit period cannot be searched for the data eye boundaries. I believe pixel clock frequencies lower than 40MHz should work with the current core version. Anyone still having issues, please file a bug report.
  14. Pull the latest changes from https://github.com/Digilent/vivado-library My latest commits should fix all incompatibilities of dvi2rgb with 2016.x versions of Vivado.
  15. FMC FRU is empty?

    I cannot promise an exact date for the new batch of FMC-HDMI with the fix applied. We will create an upgrade project and publish it somewhere.