Forum Managers
  • Content count

  • Joined

  • Last visited

  • Days Won


sbobrowicz last won the day on October 17

sbobrowicz had the most liked content!


About sbobrowicz

  • Rank
    Prolific Poster

Profile Information

  • Gender
  • Location
    Pullman, WA

Recent Profile Visitors

3,265 profile views
  1. Issue with MIG for Arty S7-50 on Vivado 2017.2

    @jpeyron @Abdoulaye BERTHE I am unable to replicate this in Windows 7 or Ubuntu 16.04. What is your operating system? Can you also provide your system specs (RAM, CPU, etc.)? Also, are you able to click "run block automation", or does that cause the same error? Does it only occur when you double click the MIG IP core? One thing that is different in my setup vs. yours, is that I install the board files by creating a file called init.tcl and placing it in C:\Users\<WindowsUserName>\AppData\Roaming\Xilinx\Vivado The file just needs the following line (and should also have some newlines at the end to be safe): set_param board.repoPaths [list "C:/sam_work/git/digilent/vivado-boards/new/board_files"] You should replace the path with a path to where you have downloaded our vivado-boards package. This is the safer way to install our board files, and is convenient because you don't need to install them again every time you install a new version of Vivado. We still need to update our documentation to use this new method. Bonus convenience points if you use git to download the vivado-boards package, because then it only takes a simple "git pull" to get the most recent changes, and we are constantly making fixes/improvements.
  2. Making SDSoC platform for Arty Z7

    You found my secret notes... that project has been under heavy development while I try to put together our official SDSoC/reVISION platform for the Arty Z7-20. I'm betting that guide is broken. Current timeline is end of october for first release of this platform. That project is a good sdsoc platform project to build on, but I would not trust anything in that folder for using it to create your SDSoC platform. You should just use the Vivado project with UG1146 to create your platform. You will find some useful tips in that guide (like how to make sure the Arty Z7 board files can be used), but following it to the letter is not going to work. If it works with your schedule, you could also wait for our platform.
  3. DVI to RGB IP Core - problems with resolutions above 720p

    I've got some places you could start looking: 1) Are you providing refclk as 200MHz? 2) Are kIDLY_TapValuePs and kIDLY_TapWidth being left as default values? I've never seen them before so I'm assuming they should be left as defaults. 3) You could try registering the sync signals and data signals right before they are sent to the VGA. This could clean them up a bit. Probably won't affect quality so much though. 4) Is your design meeting timing? 5) You could try using kClkRange=1. 6) Try a different monitor and see if this changes the quality. This can help determine if the issue is on the decode side or the output side. You can also try messing with the monitor's timing settings to see if that affects quality. 7) Try a different input source. Some input sources work better than others with this IP core. If none of these things seem to help, please provide more information about how the quality is degrading. Is it blurry edges? jittery? Using test patterns on the input can help determine what is degrading exactly.
  4. Arty Z7-20 HDMI pass through

    Couple of possibilities: 1) Are you meeting intraclock timing? 200 MHz is kinda fast for an AXI stream bus, you might be going faster than the fabric can handle. You can try to clock the axi stream bus directly from the pixel clock, or from a slower clock (but faster than the pixel clock) generated from the clocking wizard. 2) Make sure the buffers in the converter cores are at least as wide as the maximum resolution's width (2048 will do it if you are doing 1080p). 3) Is your stream-2-video core in master or slave mode? Maybe try whichever one you are not doing. I believe if you are in master mode you need to use the vtg_ce signal to pause the vtiming bus. This might mean that a processor and a VTC core would be necessary. Checkout the stream-2-video IP core product guide for more info on this.
  5. Clocking changing as a function of programming method on cmod-s6

    @apailes Sounds like an interesting problem... your guess is probably on the right track. Very strange behavior though. Check out the DCM_SP section here, it recommends also looping back a DCM STATUS bit and the LOCKED signal to the DCM reset in order to properly handle when an input clock goes out of spec: Also check the Spartan 6 datasheet to make sure the oscillator is in spec: I'll also mention that I think your clocking scheme is a bit of a violation.Usually you want to drive the DCMs directly from a GCLK input, not from the global clock network. Also, you are only supposed to drive a single DCM with a single GCLK input. I may be wrong here and getting my 7-series architecture mixed up with the 6-series, so check me on this. If I'm right, you could try connecting your oscillator to two different GCLK inputs, assuming it has the drive strength to handle the additional capacitance. That would be cleaner. One more tip: Try enabling bitstream compression to decrease Flash programming time.
  6. Using Videotiming controller for static image display

    What is the resolution you need? You can just modify the following line in SysCon.vhd file: res <= R1600_900P; The following values are valid for "res": R640_480P R720_480P R1280_720P R1600_900P Details of the resolutions are directly below the line where res is defined. If you need a different output resolution, you will need to calculate the necessary DCM M and D values to generate the valid pixel clock, and also modify remote_sources/_/lib/digilent/Video.vhd to add the desired resolution's timing parameters.
  7. NetFPGA 1G CML

    I'll provide a short answer: It will require work on your part. Probably several weeks, depending on your expertise. You can compile your HDL (assuming verilog or VHDL is used) in the equivalent Xilinx tools, but any references to primitives or IP Cores will need to be ported over to the Xilinx equivalents. The good news is that these two companies follow each other very closely from a feature perspective, so I would bet that you will be able to track down fairly similar equivalents in most cases. If you want to go down this road you can expect to receive some help here on the forum, but you will need to keep your questions scoped to reasonable size. Nobody is going to do this entire project for you (for free, there are contractors available out there). I'll also warn what Jon mentioned above: the NetFPGA boards (the 1G CML and SUME) are not "general use" FPGA platforms and were created specifically to be used with the NetFPGA project software. This means they don't have general purpose support content from Digilent, so you won't get a lot of out of box support either. You could avoid this if you went with a platform that is Digilent supported, such as the nexys video or Genesys 2.
  8. ARTY S7 microblaze

    Little correction, no PS (Zynq processing system) in the Arty S7. It will help them with microblaze and the MIG If I had to guess, I would bet that this has to do with a bug in the new "AXI Smart connect" ip that Xilinx is now instantiating when using autoconnect. For now, I would recommend using the Arty-S7-50-base-rt project that Jon linked to above as a starting point for your design. If you don't want to bother with git, you can download it from the "releases" tab in github (just be sure not to download it using the "Download ZIP" button, that will not work).
  9. Linux_BD wrapper for arty z7-20 hdmi issue

    Since the memory bus on the Arty Z7 is actually 16-bits wide, the memory throughput is: 1050 * 16 = 16.800 Gb/s = 2.1 GB/s Note the Arty Z7 bus only operates at 1050 MT/s, because of the oscillator used. Your calculations regarding video bandwidth are correct, you just forgot to take into account the DDR bus width when calculating the max theoretical bandwidth.
  10. Honestly, it could be a number of things. Everything has to be perfect and setup a specific way: the vivado project needs to have the VDMA and other video pipeline IP cores correctly configured, the device tree needs to have very specific nodes and properties, and the kernel needs to include proper versions of the Xilinx DRM drivers and our clock and DRM driver. I know it is a pain to install another version of Petalinux/Vivado, but I'd recommend jumping to 2017.2 and using the project I linked above (I recently updated it to 2017.2). It is documented and nearly released (the only remaining tasks are listed in the TODO section of the README). If you start with that project and just make changes as needed your life is going to be much easier. If you need to modify the block diagram, it is available here: Just download it (you have to use git clone --recursive in order to get the vivado-library submodule) and then make the changes as needed and export the HDF. You can then import the HDF with "petalinux-config --get-hw-description".
  11. As far as I know, allocating physically contiguous memory from User space is not easily done, and usually requires a hack or to tie into a specific subsystem for what you are trying to accomplish (for example, using the DRM frame work to allocate framebuffer memory). If you are trying to allocate memory for a video framebuffer, I would highly recommend this guide for learning to do so: . If you are looking for just a general purpose way of allocating memory, I think you can do it from the device tree:
  12. Are you powering from USB or from the Wall? Does the Done LED become unilluminated when it crashed while booting from SD? Looking at your log, it looks like you started with the Arty Z7 HDMI project. Can you verify this is the case (and that you didn't start from, say, the Zybo HDMI input project)? Also, please let me know if you are using the Arty Z7-10 or Arty Z7-20.
  13. My noobish questions on Atlys HDMI demo

    Wow, its been a long time since working with the MPMC, I forgot how much differently that works than the more modern MIG+VDMA solution. You are right, the 0xD1000000 Address is not the register map address assigned by EDK. It is the Physical address of the DDR that the MPMC will write the video data to. I forgot that this had to be set in EDK before building the bitstream (VDMA lets you set it in software from SDK). So here is the magic part: since the MPMC knows that there is only 128 MB, it seems to be automatically masking out any unnecessary bits. So it is effectively only looking at bits (26 downto 7), and 0xD1000000 turns into 0x01000000. Note that providing 0x49000000 would also get masked down to 0x01000000 which is why the software works. So you can effectively think of the value that you provide to FRAME_BASE_ADDR as a relative address within the DDR physical address space. Note that the above explanation heavily relies on the base address of the MPMC being 128MB aligned (so bits 26 downto 0 are all '0'). In this design, the MPMC is given address 0x48000000, which satisfies this requirement. I honestly have no idea how the FRAME_BASE_ADDR value will be interpreted if the MPMC were assigned a base address that is not aligned to 128 MB. I have no idea why the project sets the FRAME_BASE_ADDR to 0xD1000000 instead of 0x49000000, or even 0x01000000. My bet is that an earlier version of the project had the MPMC base address set to 0xD1000000, but this was changed when it got updated at some point. Since nothing broke, it slipped through unnoticed.
  14. cannot configure ethernet in linux4.9 | ZYBO

    I think you might need to make some changes to your device tree to work with the newer kernel. Checkout the device tree here for reference: Note the gem0 node is instantiated in the zynq-7000 file and modified in the pcw, system-top, and system-conf files. I think you might also need to make changes to the USB device tree node as well, I think I remember there being changes to that too.
  15. My noobish questions on Atlys HDMI demo

    0x48000000 is the start of the DDR2 memory address. The next 128 MB of address space are the entire contents of the DDR2 memory on the Atlys. The program (hdmi_demo) is actually executing from the front of the DDR2 (0x48000000). So, assuming the program is not larger than 16MB, 0x49000000 is a safe physical address within the DDR2 that should not overlap with the program's memory. This was poor style to assign the address this way for many reasons. It would have been better to just declare an array of bytes big enough to contain the frame buffer, and then dereference the array to get the physical address. 0xD1000000 is the base address of the hdmi_out core's register map for controlling that IP core