Viktor Nikolov

Do you mean that you didn't see any output on a terminal connected to the appropriate COM port? Have you tried debugging the program? If you are able to step over commands in the program, then the PS works, and the board is not kaput. Occasionally, I have problems seeing UART output from PS programs on my Windows 11. It's usually an intermittent problem and I wasn't able to pinpoint the root cause. Try PuTTY. For me, it's usually the most reliable terminal app.

I did the test with recv_buffer able to hold up to 4M words (still way below the theoretical limit of the DMA 26-bit max.). When I tried a single packet of words_per_packet==2,000,000 , only the first 1,805,843 words were transferred correctly. Then 16,248 zeroes followed, and then the correct values continued (although I did not check the very end of the 2M buffer; it's possible it was corrupted the way you experienced). I was surprised to see the very same behavior with packets==2, words_per_packet==1,000,000 , and with packets==4, words_per_packet==500,000. With packets==1, words_per_packet==1,805,843 , everything was transferred correctly. I did this test as part of my research for a project in which I want to try sampling a long series of data from Zynq 1 Msps XDAC. It seems, 1.8 seconds is the limit when using Xilinx AXI DMA IP.

You can use the output of XADC Wizard IP in the PL when you enable the "Enable AXI4Stream" option. Recently, I created HW design following this tutorial: Signal Processing with XADC and PYNQ - Hackster.io (I used only the HW design from that tutorial.) The XADC Wizard IP can output measurement data as an AXI Stream, which is a pretty simple protocol. In the HW design I mention here, the AXI stream is fed into the AXI-Stream Subset Converter IP (to divide the stream into chunks of 128 records by setting the tlast signal) and then into AXI DMA IP to load it into memory accessible by Zynq ARM core. Nevertheless, you can process the AXI Stream coming from the XADC Wizard IP using any PL logic you want. I have attached the PS code I used in my experiment. It doesn't communicate with the XADC Wizard IP in any way. It only calls routines working with the AXI DMA IP. The "magic" of getting data into AXI DMA IP happens solely on the PL level. main.c

My understanding is that you need to use the XADC Wizard IP to access the ADC of the Zynq. Digilent provides Cora Z7 XADC Demo project. I used it recently, and it worked pretty well. I opened the 2021.1 version available for download in Vivado 2023.1 and was able to upgrade it and generate outputs without issues.

I tried HW design and SW code from @artvvb (big thanks, Arthur, for both!) in Vivado and Vitis 2023.1 I was able to successfully transfer by the DMA exactly 1,805,843 words (i.e., 6.89 MB of data). After the 1,805,843rd word follows 16,248 zeroes, and then the correct values continue. The strange thing is that I observed the same behavior even when trying to split data transfer to multiple calls of XAxiDma_SimpleTransfer(). E.g., setting in the main() variable words_per_packet=500000 and packets=4. Calling XAxiDma_SimpleTransfer() once or multiple times always correctly transfers only 1,805,843 words. I can only speculate that this is a bug in AXI DMA IP.

I'm not sure I understand. When I download the https://github.com/Digilent/digilent-xdc/archive/master.zip and uncompressed it to a folder on my computer, it does contain the file Nexys-A7-100T-Master.xdc . You need to add this single file as constraints file to you HW project in Vitis.

I'm afraid you missed a step in the tutorial to rename CLK100MHZ to sys_clk_i in the constraints file (as shown on this picture from the tutorial). Names of ports in the constraints file and in the diagram must match. The error about conflicting voltages is probably caused by an issue I described in an article here. Add BUFG buffer between sys_clk_i and MIG.sys_clk_i, that should solve the problem (you can find the guidance in the article). Using DDR memory (i.e., the MIG) with MicroBlaze is an advanced HW design. For the first proof of concept I suggest that you use the MicroBlaze only with the block memory within the FPGA itself. It makes the HW design much more simple. You can add the DDR at later stage of HW design evolution.

Good start for beginners is this guide provided by Digilent. It explains, among other things, how to create constraints file and how to get constraints file template for the board you are using.

I suggest you share the content of your Nexys-A7-100-Master.xdc file and a screenshot of your diagram. That would help the audience of this forum to understand possible sources of critical warnings and errors.

My first guess is that you don't have a constraints file (.xdc) defined in your HW design. Or you do, but you do not set IOSTANDARD attribute for the ports.

The Arty A7 board file comes with the configuration for MIG. For instructions on setting up the MIG on Arty A7, you can refer to the first chapter of this tutorial. The tutorial is focused on MicroBlaze; nevertheless, setting up the MIG is the same for both MicroBlaze and PL logic.

Just to add for clarity: You configured UART 1 to use MIO pins 8 and 9. However, almost all MIO pins are connected to some peripherals on the Arty Z7 board itself (e.g., flash, Ethernet). See the table in this chapter of the Reference Manual and check what MIO pins 8 and 9 are connected to. According to that table, UART 0 has to be configured on MIO pins 14 and 15! If you want to use UART 1, you need to set it to use EMIO. Then, it would appear as a signal on the Zynq IP and could be routed to I/O ports

What is your motivation for enabling UART1? The Arty Z7 reference manual says that USB-UART bridge is to be used with UART 0. It is wired to UART 0 Zynq IC pins. How do your Board Support Package (BSP) settings look like in Vitis? I attached a screenshot of the BSP settings of a functional Zynq project. stdin and stdout need to be configured to UART 0 because your HW design doesn't expose UART 1 pins to PL and output ports, and thus, you can't access UART 1 in any way. Viktor

I think you need to wait one cycle between the busy signal going down and you setting ready_2 high. I see in the source code of uart_tx that it reacts to i_Tx_DV (i.e., ready_2) going high only when uart_tx is in the state s_IDLE. However, after setting o_Tx_Active low, uart_tx waits one cycle before going to state s_IDLE. This is to keep o_Tx_Done high exactly for one cycle. However, during this one cycle, you advance to the next state and set ready_2 to low. So, the uart_tx doesn't catch it. I would introduce an intermediate state between the bytes, waiting for o_Tx_Done to go high. Viktor

If this is of any help: On my Windows 11 I can normally use Cora Z7-07S in both Vivado and Vitis 2023.1. Windows shows that a driver from FTDI is being used. Have you tried to install a driver published here?: https://ftdichip.com/drivers/vcp-drivers/ Viktor