Technical Forum Moderator
  • Content Count

  • Joined

  • Last visited

  • Days Won


artvvb last won the day on September 8

artvvb had the most liked content!


About artvvb

Profile Information

  • Gender

Recent Profile Visitors

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

  1. Welcome to the Forums! The critical warnings about not being able to find the Pmod interface are likely to be causing the issue. The vivado-library folder contains two main subfolders, "ip" and "if". The Pmod IP is contained in the former, while the itnerface is contained in the latter. Make sure that you picked the root "vivado-library" folder when adding the IP repository to your project (first image, below). When the IP's Pmod interface is successfully connected to the board interface, you should see the connection show up in the board tab and in the block diagram (second image, below). Unrelated to your question, but take care to make sure that the block memory that Microblaze is connected to is big enough to fit you application. The drivers we provide are quite large - minimum 385 KB as noted by the Pmod IP guide's compatibility table. Unfortunately this won't fit in the Basys 3's BRAM without some work to reduce their size, or to find some other solution. -Arthur
  2. Welcome to the Forums! The "bitstream is not compatible with the target" error means that the part selected when you created the project does not match the part that the hardware manager found on the Pynq. You can change the part or board through the first page of the project's Settings dialog. Make sure that the part matches "xc7z020clg400-1". All communication with the Pmod CAN from the host board goes through a SPI bus. The Pmod IP core and its drivers wrap a Xilinx Quad SPI IP core and xspi drivers, so the actual SPI protocol is mostly abstracted away when you are writing your code. Thanks, Arthur
  3. Hi @asmi You can launch Vitis through the Tools > Launch Vitis menu option in Vivado. I briefly cover the steps required to create a new application project in this other thread. Edit (link didn't work): Go to, click on Documents, search for "create a sample application", and click the first link. Thanks, Arthur
  4. Hi @Arty7_Lover Unfortunately the Arty Z7 does not yet officially support Vitis. That said, you can still use the Arty Z7 with Vivado 2019.2 and Vitis. The workflow for creating a basic embedded application has not changed much from previous version of Vivado with Xilinx SDK, described here. In order to create a application project, you must have a hardware specification (.xsa file) that targets the board. This hardware specification is exported from a Vivado project (File > Export > Export Hardware). I have attached both a project and specification for the Arty Z7-20 to this post. The project only uses the GPIOs and Zynq preset from our board files. Once you have a specification, you can launch Vitis. In the new application project dialog in the image you posted, if you click on the + button at the top left, you can choose a custom specification for your project. This can be any XSA file that supports the Arty Z7-20, whether you are using mine, or exported your own. If you keep clicking next through the dialog, you are able to choose an application template. This works the same as it did in Xilinx SDK. I have attached a zipped Vitis workspace with a hardware platform and a slightly modified Hello World application. The Arty can then be programmed from Vitis through the Xilinx > Program FPGA dialog, provided that the XSA included a bitstream. The application can be run by right clicking on the system project or application project and clicking Run As > Launch on Hardware. I hope that this provided a decent starting point. Thanks, Arthur arty_z7_20_base.xsa
  5. artvvb

    Custom IP interrupt

    Hi @HasanWAVE The address range assigned to the custom IP's AXI_INTR interface can be found in IPI's Address Editor and manually brought into SDK. To bring the base address into SDK automatically, you will need to add C_S_AXI_INTR_BASEADDR (and possibly C_S_AXI_INTR_HIGHADDR) to the list of parameters found in the TCL script in the IP's Software Driver file group. Offsets from the base address for particular registers are typically manually defined in SDK through the use of macros. The code blocks below show the changes to the IP's sources I would suggest as a starting point. I am working with the template with no other changes, and have not tested this to make sure that it works. EDIT: Note that I am using Vivado 2019.1, there may be some differences in the AXI IP template between versions. File Groups -> Advanced -> Software Driver -> myip.tcl proc generate {drv_handle} { xdefine_include_file $drv_handle "xparameters.h" "myip" "NUM_INSTANCES" "DEVICE_ID" "C_S00_AXI_BASEADDR" "C_S00_AXI_HIGHADDR" "C_S_AXI_INTR_BASEADDR" "C_S_AXI_INTR_HIGHADDR" } File Groups -> Advanced -> Software Driver -> myip.h <...> /****************** Include Files ********************/ #include "xil_types.h" #include "xstatus.h" #define MYIP_S00_AXI_SLV_REG0_OFFSET 0 #define MYIP_S00_AXI_SLV_REG1_OFFSET 4 #define MYIP_S00_AXI_SLV_REG2_OFFSET 8 #define MYIP_S00_AXI_SLV_REG3_OFFSET 12 #define MYIP_S_AXI_INTR_REG_GLOBAL_INTR_EN_OFFSET 0 #define MYIP_S_AXI_INTR_REG_INTR_EN_OFFSET 4 #define MYIP_S_AXI_INTR_REG_INTR_STS_OFFSET 8 #define MYIP_S_AXI_INTR_REG_INTR_ACK_OFFSET 12 #define MYIP_S_AXI_INTR_REG_INTR_PENDING_OFFSET 16 <...> Thanks, Arthur
  6. Hi @Mosi_513 Simulating your design will help a lot in debugging the issues with it. For example, it looks like your clock_divide process is actually dividing the clock by 12, not by 5. The counter counts from 0 to 5, and on 5 (the 6th iteration), it toggles the clkdiv signal. Doing a toggle like this doubles the period of the enable strobe, so the main process only actually activates every 12 cycles. See the attached screenshot. I have also attached the testbench I used, which should help to get you started. There are likely other issues that I haven't spotted yet, but using the simulator will take you a long way. Thanks, Arthur testbench.vhd
  7. @johnsan1 I'm not sure w/ regards to tera term, but there are some other options. Assuming you aren't running up against the baud rate as a speed limit, you could add a Xilinx AXI Timer/Counter IP to your block design, that could be used to fairly precisely time how long your code takes to execute. The time values captured from the counter, either raw or formatted however you want could then be printed over serial, along with your data. Adding in extra bytes to the serial transfers would slow the system down, but you could either increase the data density of the transfers by reducing the number of bytes (stripping out the leading "Pin V" substring for example), or try to increase the baud rate, or something else. -Arthur
  8. Hi @youngpark Looks like the AXI GPIO (axi_gpio_0) connected to the module's key input is set to input only. This should be changed to output only. the connection between led and axi_gpio_1 is also a potential issue. When you connect only some pins of an interface to a module, it disables the board interface's version of those pins. What this means in your design is that clock_divider_0's output is not going to be reflected on the LEDs. From the point of view of the processor, when it reads from the GPIO, it will see the clock_divider module's output, and when it writes, it writes directly to the board's LEDs. If the intended behavior is to have the counter output to the LEDs and for the processor to be able to read the state of the LEDs, then you would probably need to use a port that is not from the board file and an XDC file to constrain it. See the images below (microblaze etc. not included). EDIT: I missed that the push buttons were also connected. They also have the same issue that the LEDs do. I have changed my screenshots to reflect how to solve the issue for both. Thanks -Arthur
  9. We've used XIT scripts to apply additional constraints. Example from the PmodAD5, which handles hooking the IP's interface to the board file interface. I've pasted the contents of the "xitscript.tcl" script we use to add this file to the IP packager below: set imp_fg [ipx::add_file_group -type {xilinx_implementation} xilinx_implementation [ipx::current_core]] ipx::add_file {utils/board/board.xit} $imp_fg set_property type {{xit}} [ipx::get_file utils/board/board.xit $imp_fg] set_property used_in {{implementation} {board}} [ipx::get_file utils/board/board.xit $imp_fg] -Arthur
  10. artvvb

    Unspecified IO standard

    Hi @dmeads_10 The error message is telling you that the port names you use in your XDC do not match the ones that are at the top level of the design (the HDL wrapper file). The issue appears to be that the block diagram's ports are interface ports as opposed to just ports. Since interface ports could contain multiple buses (_tri_i, _tri_o, and _tri_t for example), they typically have an extra suffix tacked on when Vivado generates the HDL wrapper. There are a couple of solutions: 1. You could make the individual ports of the interfaces external, as opposed to the interfaces themselves. The names of non-interface ports are preserved in the wrapper file. 2. Open the HDL wrapper and review its port map to get the actual names of the ports as they are now, then use those names in the XDC. Thanks, Arthur
  11. Hi @krjdev The "Connect Board Component" flow requires modifications at least to the generated xgui.tcl, and to the parameters of the Pmod interface port, within the IP. You can see how we added board file support in the existing IPs. Internally, we typically create new Pmod IPs by modifying an existing one that is known to be good. You can also connect custom IP to the interfaces of the Pmod Bridge, but this will likely not be doable through connection automation. Thanks, Arthur
  12. Welcome to the forum! Those clocks should be fine. As mic hardware and line hardware are different, an amplifier is required. This why computers use two ports. The converter you linked only splits the cable, and does not appear to do any kind of amplification. Mic to line amplifiers are available for purchase online, but I do not have any specific ones to recommend. -Arthur
  13. Hi @Rodrigo_Montero I don't think the issue is with the clock or with the XADC core, as you are seeing data on the LEDs, and the data on the LED line is synchronous to the clock. The issue is likely due to the control signals for the SPI core and Pmod DA3. First, If you look at the Pmod DA3 Reference Manual and AD5541A Datasheet, you can see that the MISO pin is replaced by an "LDAC" input to the chip. Data transferred over SPI is not actually output by the DA3 until this LDAC pin is brought low by the FPGA. Since your block design's MISO port is an input, you don't currently have any control over this. The default state of that pin might be low, so it might not be the cause of the issue, but controlling the pin is still important. Replacing the MISO port with an output of a const IP configured to output "0" should be sufficient. Second, it is not clear how you are setting the external signals that control the SPI core. The ChipKit reset button looks like it will work as intended. I am less clear on the i_tx_start_0 signal. It looks like it should work fine as long as the Arty's JB2 pin is wired to VDD. (Though you may want to eventually expose the XADCdemo's ready_pe_strobe flag and data register to get more precise control over when SPI words are sent.) Thanks, Arthur
  14. artvvb

    Nexys 4 DDR - UART ERROR

    Hi @AvaTRm Simulating your design is a very good approach to debugging stuff. I ran your file against a simple testbench (written in Verilog and pasted below) in Vivado's simulator. It looks like, (1.) you are not sending a start bit, and (2.), the r_data_indis counter is rolling over before you send the last few bits of your byte (this is why those "1"s are showing up). See the timing diagram below. // uart_sim.v `timescale 1ns / 1ps module uart_sim; reg clk = 0; initial begin #5; forever #5 clk = ~clk; end reg reset = 1; initial begin #20 reset <= 0; end reg [7:0] data_tx = 8'h00; reg tx_start = 0; initial begin #40 tx_start <= 1; #50 tx_start <= 0; end wire tx_out; wire [7:0] led; UARTtx #( .CLK_FREKANS(100000000), .BAUDRATE(115200) ) dut ( .i_clk(clk), .i_reset(reset), .i_data_tx(data_tx), .i_tx_start(tx_start), .o_tx_out(tx_out), .LED(led) ); endmodule Hope this helps, Arthur
  15. Apologies for the late response. From the hardware's point of view, BRAM is placed within the PL itself, and reading from it is both fast and consistent. DDR is also fast, but located off-chip, and the bus to it is shared by PS. This means that if the PS is doing some kind of memory-intensive operation, bandwidth from DDR to PL may be limited. Typically in Zynq applications, DDR memory is dumped to PL BRAMs in bursts, through a DMA controller. When DMAing data, BRAM-based FIFOs are used to ensure that data can be read at the time it is needed. This means that the two approaches could be summarized as BRAM or DDR+BRAM. To do the "BRAM only" approach pretty much requires you to create a custom AXI4-Lite slave. There are various examples around, including a number of threads here on the forum. Here's an example. To do the DMA approach means that you would be using Xilinx's AXI DMA IP, with a custom DAC controller that pulls data from the DMA through an AXI Stream Interface. The DMA Audio Demo for the Zybo Z7 is a decent example of how this approach can be used. Thanks! Arthur