Technical Forum Moderator
  • Content Count

  • Joined

  • Last visited

  • Days Won


artvvb last won the day on March 24 2018

artvvb had the most liked content!


About artvvb

  • Rank
    Prolific Poster

Profile Information

  • Gender

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Hi @Rickdegier, Welcome to the Digilent forums! I am not the most confident on this topic, but I have used the DMA some. The most important facet here is to make sure that your buffer is actually contained in the DDR memory. Different parts of the program can be placed in different memories using the linker script in your application project's src folder (lscript.ld). You should check that file to make sure that your global arrays are placed in the DDR. Second, if the data cache is enabled (likely), you should make sure to flush and invalidate the buffer memory area around your SimpleTransfer calls (functions to do this are in xil_cache.h). Lastly, I personally have had more success using malloc to create my buffers than using global or local arrays - I'm not sure why this is, from a cursory google search, it looks like the DMA will allow transfers into program memory when you aren't careful. You may want to reach out to Xilinx on their forums. Thanks, Arthur
  2. It looks like you have vivado-library included correctly. For vivado-boards, please go to Settings -> Project Settings -> General -> Project Device. "Zedboard" should show up in this field. Click the "...", when the "Select Device" wizard shows up, it should have the Zedboard selected. Could you confirm that the "vendor" column shows "", not "". If it shows avnet, select the digilent version instead, if the digilent version doesn't show up at all, please refer to the link in my previous comment. I suspect that you installed the digilent board files, but did not update the board file being used in your project. Thanks, Arthur
  3. Hi @jackn, Apologies for the slow response. I have a few questions: What version of Vivado are you using? Are you using Avnet's board files for the Zedboard? In order to use the Pmod CAN IP core, you will need to use our board files. Installation instructions can be found on our wiki, at this link. How did you add the Pmod CAN IP core to your project? Did you follow this tutorial? If so, which release did you download? It is somewhat strange that Vivado can find the Pmod CAN IP core, but cannot find the Pmod interface (located in the if/ subdirectory of the release). These errors could be caused by adding only the ip/ subdirectory of vivado-library to your project, rather than the vivado-library/ directory itself. Since the pmod bridge IP (another required dependency of the CAN IP) also was not found, I'd guess that you added only the Pmod CAN itself to Vivado's IP repositories page in the Settings GUI. If you are using our board files and the vivado-library, you should not need to manually constrain the Pmod_out interface's ports. Vivado IPI will do this for you. Thanks, Arthur
  4. @BYTEMAN My only major concern with the your current flow is that it is still relatively difficult to gain access to any control signals you might want to use. The Language Template GUI (which you can find in the Project Manager section of the Flow Navigator) has some boilerplate code for an AXI port map with customized parameters that you can add to your custom module. THis doesn't come with the actual AXI control template, but combining the syntax for the portmap with the IP you've created, you should be able to create the same design with only a single added module. AFAIK, added modules don't play as nicely with Connection Automation as actual AXI IP, but it may warrant some investigation. I am currently away from a PC with Vivado installed, so I am unfortunately unable to be more specific on where in the Language Templates you can find this... I'd suggest you try the above, but another method that can be useful to move data between Microblaze and HDL would be to use an AXI Stream interface (which is MUCH simpler than full AXI, there's some info in Xilinx UG761, starting at page 45) in your HDL module that connects to the transmit stream of an AXI4-Stream FIFO Controller (Xilinx PG080). I've been playing around with this a bit recently, and it seems like it works pretty well. This method is more useful for "bursty" data streams (Xilinx uses this for Ethernet communications), rather than "set and forget" registers (like LEDs or something), either on the processor or module side, but it's worth pointing out. Thanks, -Arthur
  5. artvvb

    HDMI in for ARTY-Z7-20

    In SDK, that error can be resolved by right clicking on the BSP and re-generating BSP sources, as shown below. Please provide screenshots of your errors in the Vivado flow.
  6. artvvb

    HDMI in for ARTY-Z7-20

    @Mahesh I don't see anything obvious that you are doing wrong. The project that that error message is referring to is the hdmi_in_wrapper_hw_platform_0 project, seen in the first screenshot below. This directory was missing from a previous release, but is there in the 2016.4-4 release. The second screenshot shows the Import Projects screen. All three of the subdirectories of the sdk/ folder should show up and be checked when importing. Thanks, Arthur
  7. artvvb

    HDMI in for ARTY-Z7-20

    @Mahesh You are correct that you do not need to export to open in SDK, I am just trying to get a feel for the route you ware trying to take. The release archive contains the stuff for two different workflows. First, importing the SDK application project, BSP, and hardware platform directly in SDK. Second, going through Vivado to generate the hardware platform, then exporting it to SDK and importing the BSP and application project. Using the SDK-only flow, you should confirm that all three projects (hdmi_in, hdmi_in_bsp, and the hw_platform) are imported. There might be something weird going on with the create_project script where it messes with the /sdk folder, though I have not confirmed this - I'd suggest you try this flow with a clean download of the v2016.4-4 release archive. I am not clear on what is going wrong with the Vivado flow, I'll look into it and update here. (FYI, Username "Arthur" is a different person, my username is "Artvvb". This is relevant since the '@' feature sends a notification.) Thanks, Arthur
  8. artvvb

    HDMI in for ARTY-Z7-20

    @Mahesh I just uploaded a release to Github with the sdk hardware platform in it. Looking back through this thread, I'd like to confirm, you were able to generate a bitstream, but then saw the "missing hardware platform" error when you launched SDK? Did you launch SDK directly, or did you, in Vivado, use File>Export>Export Hardware followed by File>Launch SDK? EDIT: Let me also note that you will need to right click on the BSP and select "Re-generate BSP sources" when you get the SDK projects imported. Sorry for the delay, Arthur
  9. artvvb

    Input pins GPIO

    @liwerfm Please provide your block design, either as screenshots of the design pane and customization GUI for the AXI GPIO controller, or by attaching the TCL script created when you select File>Export>Export Block Design in the top tool bar of Vivado. Thanks, Arthur
  10. artvvb

    Microblaze inputs

    Welcome to the forum! How you do this depends on the internal logic you want to read. Could you explain a little more about your project? There are two primary ways for MicroBlaze to interact with internal logic: First, via an interrupt controller. This is only used to trigger MicroBlaze to do something based on a single bit flag. Second, via an AXI interface. This is likely what you will need. There are a couple of ways to do this, but my suggestion, at least to start with, would be to connect your internal signals to the gpio_io_i port of an AXI GPIO controller. Note that if your signals change frequently, or you can't just poll the signals, then you will likely need a proper AXI interface. Thanks! Arthur
  11. artvvb

    Pmod SSD

    It is also possible to create an IP or an HDL module that can sit between the AXI GPIO controller and the PmodSSD port. Creating a module is significantly easier. The following is a portmap for a module with a slave GPIO interface that can be connected to an output-only 8-bit AXI GPIO controller. module pmodssd ( // clock interface (* X_INTERFACE_INFO = " clk CLK" *) (* X_INTERFACE_PARAMETER = "FREQ_HZ 100000000" *) input clk, // 8-bit slave GPIO interface (master should be configured 8-bit output-only) (* X_INTERFACE_INFO = " GPIO_I TRI_I" *) input [7:0] gpio_i, // Pmod seven-segment display ports output [6:0] seg, output an ); //Add user code here endmodule If this code is placed into a verilog source file in the project, it can be added into the block diagram by right clicking on some empty space in the diagram and selecting "Add Module". The interfaces and output ports need to be manually connected to some output ports constrained by the XDC, and the appropriate GPIO interface and clock source. The "user code" mentioned in the module can be pretty much whatever you want, it could decode two 4-bit numbers into segment codes, and toggle between the two digits, for example. Cheers, Arthur
  12. artvvb

    Pmod SSD

    Quoting the Reference Manual: Thanks, Arthur
  13. @dgottesm Check out the Using Digilent Github Demos tutorial, which explains how to run these demos. The "Projects Supported by this Tutorial" dropdown table contains links to the front-end pages for each demo. For a little bit more specifics about the directory structure: For the most part these folders separate sources that get used at different stages from the rest of the source. What I mean by this is that they are just organizational, so you don't really do anything with them yourself. The hw_handoff folder contains a file that can be used to open the project directly in Vivado SDK, skipping Vivado entirely. The sdk folder contains the C/C++ projects and source code that are needed for microblaze/zynq demos. The proj folder contains the create_project script that takes the sources in the rest of the directories and turns them into a proper Vivado project. The src folder contains Vivado source files. The repo folder contains IP source files that may be from a different Github repository. Thanks, Arthur
  14. artvvb

    Pmod SSD

    @mbo Unfortunately, we don't currently have an IP for the Pmod SSD. If you are designing for it in a Microblaze or Zynq project, I'd recommend that you use the AXI GPIO IP core. The attached screenshots show where I would start for creating the hardware, note that the two Pmod headers of the SSD should be on the same GPIO channel so that setting each of the cathode pins and the digit select pin use the same XGpio_DiscreteWrite call in SDK. The process I went through here was to add an AXI GPIO, configured it as below, right clicked on the output port of the GPIO interface and select "Make External". I then added a constraint file to constrain the output port to JA and JB of, in my case, the Arty.
  15. @Mahdi I'd recommend that you connect the flag pin to an AXI GPIO controller and the normal SPI signals to your AXI Quad SPI IP. If you want to get fancy, you can add an interrupt controller and configure the GPIO controller for interrupts so that when the flag pin goes high, the CPU can drop whatever else it's doing to respond. A bit of a side note, but you might be able to use our Pmod Bridge IP core (configured for top-row SPI and bottom row GPIO) to connect both of the AXI controllers to a Pmod port. Most of the SPI Pmod IP cores are just wrappers for these three IP. Thanks, Arthur