elodg

Digilent Staff
  • Content count

    61
  • Joined

  • Last visited

  • Days Won

    6

elodg last won the day on August 7

elodg had the most liked content!

About elodg

  • Rank
    Frequent Visitor

Recent Profile Visitors

886 profile views
  1. @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.
  2. 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]]
  3. 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
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. FMC FRU is empty?

    Hello Antti, The FMC-HDMI IPMI EEPROM is programmed during manufacturing, so the blank EEPROM sounds implausible. However, there is a known issue in our FRU record relating to voltages. According to the documentation, the VCU108 can be forced to set a particular VADJ voltage for the FMC connector, which is the workaround I recommend on the short-term. See https://www.xilinx.com/support/documentation/boards_and_kits/vcu108/ug1066-vcu108-eval-bd.pdf#M6.9.84194.Heading2.FMC.Menu.Options If the customer is willing, we can provide a new EEPROM image for the FMC-HDMI, that can be programmed in the field. We could design the programmer for the VCU108, or any other board (preferably from Digilent) available.
  10. Does Zedboard support PmodWIfi

    Hi @Goutham Why do you want to use Microblaze on the Zedboard? Similarly, why do you want to use PmodNIC100 when there is a 1G Ethernet PHY on-board? On the Zedboard the 1G PHY is indeed connected to PS pins, so not directly accessible by PL. However, a Microblaze in the PL could access the PS MAC through the S_GP0 and DDR through the HP ports. Or, if you really want to ignore the PS and can fit the Microblaze application in BRAM, you can indeed use PMODNIC100 with a SPI master controller implemented in PL. You will have to write the lwIP adaptor layer though. However, I am not sure you can fit an lwIP application in BRAM alone.
  11. DDR3 Termination

    Although this is an old post, I would like to clarify the situation. @Nebruda, I see no reason to prefer DDR3 on a certain side from the user's point-of-view. Both topologies are technically sound and functionally the same. They present advantages and disadvantages for the board designer only. The tree topology on the Zybo allowed us to save a power supply, resulting in a more compact board. However, compared to the fly-by topology it is harder to route and validate.
  12. Zybo Host USB "Device offlined" ...

    Have you tried with another USB pen drive? As a first guess, it could be indeed the insufficient capacitance at fault, if the pen drive has large load variations under stress. However, this should have been solved by the cap you loaded. Is there some other debug log of the USB controller we could look at? If you scope VBUS there should be no large voltage drops when under stress with the large cap loaded. The device lock-up might be due to something else.
  13. Communicating with Zybo via Ethernet

    Hello Troy, It depends what is the nature of the data you are transferring. The Zynq Ethernet MAC works with Ethernet packets. If you are using point-to-point connection with the PC, Ethernet packets might be enough. You only need to make sure that the correct MAC address is used when sending and receiving the packets. If you want higher protocol-level support, you need IP. On top of IP you choose TCP, if you need guaranteed packet delivery, or UDP, if not. Both TCP/UDP and IP are implemented by lwIP. On top of that you either implement your own application protocol, or choose an existing one: TFTP if file transfer is that you are after, or SMTP if you want to send e-mails and so on. I believe none are implemented by lwIP, but there are open-source examples all over the Web.
  14. zybo/zedboard standalone USB mass storage example

    Hello Andrew, We don't have any such examples. We do test SD and USB in our manufacturing tests, but it does not go as far as knowing anything about files. For both SD and USB Mass-storage you will need file system support. FatFs is a good open-source example. The lower-level drivers are the ones provided by Xilinx and we use them ourselves. For example, reading the first data block on an SD is as simple as: #include "sdps.h" /// Initialize the read buffer memset(arrbyReadBuff, 0, kwBlockSizeBytes); /// Initialize SDIO controller psSdConfig = XSdPs_LookupConfig(XPAR_PS7_SD_0_DEVICE_ID); if (XSdPs_CfgInitialize(&sSdPs, psSdConfig, psSdConfig->BaseAddress) != XST_SUCCESS) { VERBOSE("%s (line %d) error", __func__, __LINE__); FAIL_AND_RETURN; } /// Initialize SD card if (XSdPs_CardInitialize(&sSdPs) != XST_SUCCESS) { VERBOSE("%s (line %d) error", __func__, __LINE__); FAIL_AND_RETURN; } /// Change bus width to 4-bit if (XSdPs_Change_BusWidth(&sSdPs) != XST_SUCCESS) { VERBOSE("%s (line %d) error", __func__, __LINE__); FAIL_AND_RETURN; } /// Issue a read of the first block (boot block) XSdPs_ReadPolled(&sSdPs, 0, 1, arrbyReadBuff);
  15. It is possible that HPD is not implemented as a software interrupt, in which case input video might not re-initialize on-the-fly. Do you program an EDID into the ADV7611? How do you know, you are receiving video from the input? Is it the resolution and color format you are expecting? Are you configuring the output (ADV7511) with the same settings? You need to provide more information, if you want a more helpful answer. Generally, I suggest using logic analyzer to scope signals of interest. You should be able to see where does the video stream get blocked. Reading the status registers of both the encoder and decoder also helps.