Technical Forum Moderator
  • Content Count

  • Joined

  • Last visited

1 Follower

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. Here's the mentioned example, connecting the Pmod OLED to the Cmod A7 through the Pmod port. Notably, the project uses the Pmod bridge IP to connect the QSPI to a board interface. Drivers are pulled from the IP core for the Pmod OLED. The Vitis workspace can be opened by importing projects from the file. Some screenshots of the section of interest of the block design and IP configurations are also attached, in case the tool version doesn't allow the project to be opened. -Arthur
  2. Hi @Elisheva The result port in your VHDL design is 24 bits wide, and should not be directly connected to the UART pin. You need to add a UART transmitter to the hardware design that can produce the correct wave to send those three frames through the single pin. The individual result bus ports do not currently have location constraints. If you mapped each of them to a physical pin (probably Pmod ports), you might be able to put data out through those pins to meaningfully read the data (whether with LEDs or something else). Fundamentally, you need to figure out how you want
  3. If the Zynq sample uses the AXI QSPI IP core, the software sources should nearly work as-is on Microblaze (typically with some additional calls to enable/disable caches if you are using them). If it's using the PS SPI instead, then that's different. For a relatively simple case of using the AXI QSPI, you can take a look at the drivers for the Pmod AD5 IP:
  4. Hi @helloworld1029 Currently your hardware design can only handle output. The Pmod IPs need to use tristate buffers. This is why each of the Pmod pins has an "_i", "_o", and "_t" port in the interface. Typically, the Pmod IP will handle this for you when working with the whole interface. Unfortunately, it looks like merely making the rest of the pins on the half of the interface you are working with external won't cause the buffers to be added. This means that you need to add the buffers manually. You can edit the HDL wrapper for your project, or you can try to work around it in the block
  5. Hi @RichardV Could you clarify what you mean by "the QSPI port"? You can create your own SPI controller and have it use any of the Cmod's IO pins - constraining the pins with an XDC instead of through the board files. The AXI QSPI IP can similarly be connected to various external pins, on the Pmod port, breadboard connector, pretty much wherever (but should be used with a Microblaze processor). You can configure the AXI QSPI to work in standard SPI mode (SPI Options: Mode = Standard instead of Quad). Thanks, Arthur
  6. Hi @PoroCYon, welcome to the forums! An option that resembles the first you proposed: you can create an AXI peripheral with its ports either grouped into a GPIO interface or just on four-bit _i, _o, and _t buses, then use the Pmod Bridge IP from our vivado-library repo (latest released download here) to handle the constraints, connecting your IP to the bridge in a block design. I've attached a screenshot of how this could be wired up in the block design below (it uses an RTL module where your AXI IP would fit in). Connecting a Pmod interface to a board-flow port requires some additio
  7. Hi @vivekmishra01 Which version of the tools are you using? I haven't managed to reproduce the issue in 2018.2 (and don't have 2016.4 installed), but assuming that you are using the 2016.4-2 release, there's some possibility that adding the following line to the demo.h file might help: #define DDR_BASE_ADDR XPAR_PS7_DDR_0_S_AXI_BASEADDR Alternatively, you can try this version: Thanks, Arthur
  8. The Cora example was intended to show that you can set up the same or a similar circuit with the Zybo, using appropriate resistors. The AXI and DRP interfaces are two different ways of getting data out of the XADC core, and, I believe, are mutually exclusive. If you want to use the XADC data in the Zynq PS, I'd recommend setting it up with the AXI interface instead of DRP. That said, UG480 has information on the timing of the DRP interface in chapter 5.
  9. Hi @helloworld1029 Another Zynq board, the Cora Z7, uses a circuit similar to what you describe in order to support up to 3.3V into some of its analog inputs. You can find the circuit in question on sheet 2 of the board's schematic: Additional information can be found in the appropriate reference manual section: The Vitis code will need to use one of the drivers built
  10. Hi @rob2018t, Assuming you've cloned the vivado-library repo, could you indicate which commit and branch is checked out? Otherwise, if you downloaded a zip, the name of the zip before extraction would help me narrow down which version you have. It's possible you have a version of the IPs that does not include support for the Artix 7 family. Thanks, Arthur
  11. Hi @jungle AXI lite and full are memory-mapped interfaces, while the AXI stream interface is not. As such, you won't find the streams in the address editor. DMA is a good way to connect an AXI stream to one of these memory mapped interfaces. To send data to this stream, you should then be using the xaxidma drivers to set up and trigger the transfer. The DMA IP acts as an intermediary: for simple transfers, the processor hands it an address and a transaction length, and it reads each word of data out of that region of RAM, and sends it down the AXI stream. Can also note that the DMA I
  12. 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,
  13. @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
  14. 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
  15. 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