artvvb

Technical Forum Moderator
  • Content Count

    303
  • Joined

  • Last visited

1 Follower

About artvvb

  • Rank
    Prolific Poster

Profile Information

  • Gender
    Male

Recent Profile Visitors

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

  1. Hi @rt54321 AXI GPIO only supports enabling/disabling interrupts per channel. I'd suggest, in software, tracking the state of the channel containing your GPIO, and only performing the interrupt action when the bit corresponding to DP6 goes high. You can place your XGpio instance and a u32 inside of a struct, and pass the pointer to that struct to your interrupt handler (or just use global variables). The interrupt handler would read out the new state, compare to the old value, potentially perform its action, and store the new value in the struct before returning. Alternatively,
  2. @Zzingoh Assuming that you are doing a baremetal design, you can find the heap size (and stack size) in the application project's linker script file, lscript.ld. Thanks, Arthur
  3. artvvb

    Basys 3 Constraints

    Hi @JuanL Welcome to the forums! Adding the curly brackets to the lines that don't have them won't cause problems. XDC syntax is effectively a subset of the TCL scripting language used in Vivado's console. In this language, square brackets execute a command inline. Taking the set_property lines as an example, get_ports is called first, and the result is passed to set_property. Note that the indices for the seven segments and some other pins require that square brackets be used in the signal name. In TCL curly brackets escape out of the string placed in the brackets. This means t
  4. Hi @Kharade, welcome to the forums! There is a mismatch between the frequencies used in the create_clock constraints in the master XDC file and in the XDC automatically generated by the Clocking Wizard IP core - 83.33 versus 83.333. You can resolve the issue either by editing the master XDC to match, or by commenting the line back out (note the package_pin and iostandard constraints are still necessary), as the wizard is handling it for you. Critical warnings in the methodology tab in implementation tipped me off: "TIMING-8 Critical Warning The clocks clk_out1_clk_wiz_0_1 and clk_out
  5. Welcome to the forums! `[email protected](negedge sclk0 & send == 1)` is likely to be causing problems. First, you are already preventing the process's logic from happening by wrapping the contents of the process in an `if (send == 1)`, making the `send==1` redundant. Additionally, I'm not positive what the `&` ends up actually representing. Avoid mixing clocks and other signals in sensitivity lists. Second, sclk0 is generated in logic, and cannot be routed on the dedicated clock lines of the FPGA. I'd recommend using the `posedge clock` here, with an additional flag to enable the
  6. Hi Dave, The board files lock in the some of the IP settings. The number of slaves can't be changed when using the board files to constrain the SPI bus, since the board.xml interface and the part0_pins.xml constraints only specify a single chip select pin. I'd recommend using Make External on the relevant pins of the AXI Quad SPI's SPI port, and constraining them all yourself. For what its worth, it looks like clearing the interface selection to Custom in the IP's Board tab will preserve all of the other settings. It may also be necessary to manually add IO buffers into the design (
  7. Hi @davec I don't see anything wrong with your hardware design or the board files. So I spun up a similar design with port J6, working from the polled_example (Vivado/Vitis 2020.1 and version 4.6 of the xspi drivers). Debugging the modifications showed a problem where XSpi_Transfer was silently failing when checking if a slave was selected in the driver, and finding none. Make sure you are calling XSpi_SetSlaveSelect. See my main.c, below. #include "xspi.h" #include "xparameters.h" #include "xil_printf.h" #include "sleep.h" int main() { xil_printf("Hello World!\r\n"); XSpi device;
  8. I am nearly certain that the DRCs are caused by the incorrect settings. It's likely that opening the configuration wizard and following until the end with default settings to regenerate the core would create issues. A MIG for which the configuration wizard has not been stepped through appears to keep its settings from the board file. Looks like you have the correct file. According to appropriate documentation, linked below, you are correct. That said, I am fairly certain that have seen the MIG work when using the default BUFG global clock buffer selection. Recommended MIG set
  9. Hi @Erick In order for the processor to be able to read data from a module, the module needs to have a memory mapped interface connected to the processor, so that the processor can read or write register data through the addresses that have been assigned to the module's interface. For microblaze, this would (usually) be an AXI interface. This guide should be able to get you started, but is fairly out-of-date, and only handles data written from a processor to an IP. Fair warning, this is a pretty broad topic, and you can find plenty of posts on this forum, and elsewhere on the web, about d
  10. Hi @okonomiyonda Some MIG configuration wizard settings terminology: The "Clock Period" setting is the period of the actual clock for the DDR interface. "Input Clock Period" is the period of the clock connected to sys_clk_i. There may be some issues with importing the board file MIG project in 2020.1, the MIG project file specifies 166.667 for Arty A7, while the configuration wizard shows a default of 333.333 (Plus, when selecting the MIG clock pins in IPI, 100MHz frequencies are shown). I can confirm that implementation can be completed with a MIG with default settings, changing
  11. Hi Tim, Some more info, I've been working on getting the Pmod IPs updated to 2020.1. A working branch is available on GitHub here: https://github.com/timothystotts/vivado-library/tree/feature/pmod_update. So far, I've updated most of the Makefiles on this branch, but have not yet updated the software drivers. Thanks, Arthur
  12. @bobsmith The Arty Z7's Reference Manual (Basic I/O and Shield Connector sections) and Schematic (sheets 1, 2, and 9) have information on how these components are connected. All four buttons are connected to pins on FPGA Bank 35 with resistors to pull down the pin while the button is open, and protect the FPGA pin from the voltage rail while the button is closed. IO pins 0-13 are connected to FPGA Bank 34 via current limiting resistors. The buttons can be noisy, so it may be worthwhile to debounce their signals, if you are not doing so already. Checking the debouncer output on a
  13. artvvb

    Eclypse Z7 Repository

    @mgberry Thanks for pointing this out. This also affects several nested dependencies of the hw directory (vivado-library and digilent-vivado-scripts). Using git submodule update --init --recursive in the root Eclypse-Z7 directory (instead of submodule init then submodule update) will pick up all of the nested dependencies. I'm looking into getting the appropriate documentation revised. -Arthur
  14. Hi @edge30 Using Vivado/SDK 2019.1, I tested out the Xilinx interrupt mode example for xuartps using a Zybo Z7-20 (I'm working from home, and don't have all of the hardware I would normally have access to). The Zynq PS on this board is functionally the same as the one on the Cora Z7-10. Note that this is the same example project used by the original poster in this thread, and is available through the system.mss file in a compatible project. My block design contains only the Zynq PS with the default configuration from the board files, with AXI GP0 and FCLK 0 disabled. The PL is not used wh
  15. @Paul Chang I can confirm that you are using the correct flow to get the project. There aren't any licensing concerns around either the smartconnect or fifo generator IPs. I may be able to get some more information from the errors in the third image (Windows 10), if you expand the [IP Flow 19-167] error, or if you upload a log file for that project. However, since each of the errors that show up in your screenshots appear to be related to files inside of the Xilinx installation directory, I'd recommend that you reach out to them on their Forums. Apologies, Arthur