ivansavy

Hello, I am using Vivado and Vitis 2020.2 to build a MicroBlaze application for the Arty S7-50. I'd like to load my executable from flash and run it directly on the FPGA without external memory. My .elf is 215 kB (after optimization and no debugger). The 7 Series FPGAs Memory Resources User Guide states that the S7-50 has 75 x 36 kb = 2700 kb = 337.5 kB BRAM. However, when I allocate 256 kB for local memory in the address editor, I receive the implementation error: [DRC UTLZ-1] Resource utilization: RAMB18 and RAMB36/FIFO over-utilized in Top Level Design (This design requires more RAMB18 and RAMB36/FIFO cells than are available in the target device. This design requires 165 of such cell types but only 150 compatible sites are available in the target device. Please analyze your synthesis results and constraints to ensure the design is mapped to Xilinx primitives as expected. If so, please consider targeting a larger device.) the meaning of which is self-explanatory. I can successfully allocate 128 kB, though that is not enough to store my executable. I tried reducing the range of my other IPs in the address editor, but I still receive the error saying the design requires 165 cells but only 150 were given, so it doesn't look like reducing their sizes achieves anything. Is it possible to modify the design in Vivado to increase the available BRAM for storing an executable? I understand FPGAs are memory-limited, but the user guide says I could possibly have 337 kB BRAM and 256 kB would be just enough for my executable. Thank you.

The solution is to call XSpi_IntrGlobalDisable(&XSpiInstance) after XSpi_Start(&XSpiInstance).

@zygot Thank you for the info. It seems like a baud rate of 921600 is already sufficiently high so I will just use this setting in my design.

Updates: I deleted and re-added the QSPI IP to my design, configured the Board Interface to be Custom, disabled the STARTUP primitive, and constrained the relevant signals in the .xdc files just as above, but when I ran my MicroBlaze application I still did not see the SPI signals on the I/O pins I selected in my .xdc file. I also deleted and re-added the QSPI IP with the J7 board interface enabled and STARTUP primitive disabled, but again I was again not able to see any output on the scope when I launched my MicroBlaze application.

Update: The sck_io signal is unavailable because I had the STARTUP Primitive enabled, which routed the slave clock to STARTUP_IO_cfgmclk_io. As stated in the AXI Quad SPI v3.2 LogiCORE IP Product Guide section Enable STARTUPE2 Primitive Parameter: "This primitive has a dedicated clock pin that can be used to provide the SPI clock to the slave memory" and in Table 2-2: "Free-running clock from on-chip oscillator. Nominally 50 MHz but is not characterized or specified in a data sheet."

Updates: In the Board tab of the IP, you can select the Board Interface to be Custom, spi, or qspi flash. I had this selected as spi, which I think routed my SPI signals through the J7 SPI header on the Arty S7. The reason I found this was because, when I scoped the SPI header as a test to see if it was activated, I saw the signals from my I/O pins 10-13. In the Arty S7 User Guide, it states that I/O pins 10-13 are tied to the SPI header pins, so I think that I activated the SPI header accidentally, but constrained I/O pins 10-13 which meant that the SPI header was getting my signals from those pins instead. However, when I create the IP from scratch and select Custom for the Board Interface, the sck_io signal is disabled. How am I supposed to communicate with my SPI peripheral if I can't route a clock to its SCK pin?

Hello, I am using Vivado and Vitis 2020.2 to build a MicroBlaze application for the Arty S7. My objective is to control a DAC using SPI. I have the QSPI IP configured in standard and running at 390 kHz. I created an interface port spi_port for the IP and constrained the port to match I/O pins 0, 2, 3, and 4 on the Arty. Finally, I initialized the XSpi instance, selected the first (and only) slave, and used XSpi_Transfer to MOSI a simple buffer. When I probe the pins on an oscilloscope, the issue I am seeing is there is no SPI clock on the Arty pin nor data on the MOSI line. Does anyone know where my error is? Thank you

Hello, I am using Vivado and Vitis 2020.2 to build a MicroBlaze application on an Arty S7 development board. At the moment, I have a 300 MHz clock routed to the UARTLite IP and have selected 921600 as my current baud rate. I've read in two Xilinx articles (https://support.xilinx.com/s/article/35903?language=en_US and https://support.xilinx.com/s/article/14760?language=en_US#:~:text=UART%20Lite%20can%20handle%20baud,rate%20will%20be%208%20MBaud) that I can set the baud rate to the AXI clock frequency divided by 16, though neither give a guide on how to do this. I'd like to set the baud rate to 2 MBaud, which is theoretically allowable for a 100 MHz AXI clock. Is this possible? Thank you

@zygot why would I need to add a delay between register reads? And why would disabling data caching solve this problem? Thank you.

Hey @zygot, thanks for your response. I placed usleep(5), usleep(100), and usleep(1000) before each of the reads and it did not work. For the specific code below, failure means that the TempArray is not equally populated at each index. while(counter < 100){ // reg1 is an array index reg1 = Xil_In32(BASEADDR + SLV_REG21_OFFSET); // reg2 is the data at that index reg2 = Xil_In32(BASEADDR + SLV_REG18_OFFSET); // write to array TempArray[reg1] += 1; // increment counter counter += 1; } After I read the array index at REG21, I want to simply add 1 to the TempArray at that index. When I read REG18, TempArray is not populated with anything, but when I read another register, say REG19 or REG20, TempArray is populated at whichever index is given by REG21. When I go to the MicroBlaze IP, I can see that both instruction and data cache are disabled. Thank you

Hello, I am using Vivado and Vitis 2020.2 and an Arty S7-50 board. Something in the AXI register read is failing. The specific failures I've come across are: The AXI read will hang depending on which register I'm reading. Not only that, but if a register read fails, I will test it in a basic while(1) loop and will read/print it successfully. First, it's as if moving the register to a different part of the code causes the read to fail. Second, even registers that are unmapped in my custom IP are causing the application to hang, making it seem like the application will hang on a random register (and yet, if I take that specific unmapped register out of my main logic and just read/print it in a basic while(1) loop, it will work just fine). Here is some code that hangs: while(counter < 100){ // reg1 is an array index reg1 = Xil_In32(BASEADDR + SLV_REG21_OFFSET); // reg2 is the data at that index reg2 = Xil_In32(BASEADDR + SLV_REG18_OFFSET); // write to array TempArray[reg1] = reg2; // increment counter counter += 1; } while here is some code that completes: while(counter < 100){ // reg1 is an array index reg1 = Xil_In32(BASEADDR + SLV_REG21_OFFSET); // reg2 is the data at that index reg2 = Xil_In32(BASEADDR + SLV_REG19_OFFSET); // write to array TempArray[reg1] = reg2; // increment counter counter += 1; } The difference being going from REG18 to REG19. Finally, I can also run the following code no problem: while(counter < 100){ // reg2 is the data at that index reg2 = Xil_In32(BASEADDR + SLV_REG18_OFFSET); // print reg2 xil_printf("\n\rData: %d", reg2); counter += 1; } and the output for REG18 is what I expect. The AXI read will read something completely unexpected. For example, in my custom IP I had a single bit mapped to R22. When I read and printed that register, instead of getting either 0 or 1, I got decimal 129. I then went back to Vivado, mapped the bit to R20, updated the hardware in Vivado, updated the platform in Vitis, ran the application on the Arty, and sure enough the bit was read correctly at R20 and R22 no longer read 129. The timing will vary depending on which platform I'm using / which register I'm reading. Similar to above, I have a counter in a basic while loop, where the while loop exits once a single bit in my custom IP is toggled. I built two platforms using the same .xsa file, using the exact same code in both applications, and the counter value is different between the two applications (one platform having a counter value 4x higher than the other). Also, the counter value will vary depending on which register is read. If I read, say, REG4 and REG5, the counter will be 1000; if I read REG4 and REG6, the counter will be 5000; and if I read REG5 and REG6, the counter will be 700; overall, it seems like the number of times the loop executes (if it executes at all) depends on which registers I'm reading. What could be the problem? Thank you for your time.

Including the xil_io.h header removes the error and allows me to successfully run the application. I assumed that my custom IP header contained all the necessary operations, but I traced them and there was no mention of the read/write operations. Looking at my other applications, they all include files which somehow trace to xil_io.h.

Hello, I am using Vivado and Vitis 2020.2 to implement a simple MicroBlaze program with a custom IP. The error I am encountering is, when I build my platform, the drivers\ folder and .bit and .mmi files in export\project_wrapper_name\hw\ are removed. I can visually witness them being removed from the platform just at the end of the build. Not having the drivers folder causes Vitis to return errors when I try to build my application. These errors are undefined reference for Xil_Out32() (I am writing to a register in my custom IP) and [makefile:38: application.elf] Error 1. Why does Vitis delete these items? For reference, I have successfully implemented projects with custom IPs on my Arty S7 and am following the same steps as with those projects (and the aforementioned files are in the hw\ folder as expected). Thank you. EDIT: For reference, I am adding #include "custom_IP.h" at the start of my application and using custom_IP_mWriteReg() to write to the register.

Hey @JColvin, thanks for taking a look at this post. Your solution worked: I added the "main.c" file, built the program, programmed the FPGA, and ran the debugger and the board performed as expected. Regarding the tutorial, everything does appear in the correct order, the only step that could possibly be added is rebuilding the program (like you suggested) after adding the "main.c" file. Thanks again for your help.

Hello, I am following the "Getting Started with the Vivado IP Integrator" tutorial using the Arty S7-50 with Vivado 2020.2, though when I attempt to create the hardware (.xsa) file I receive the error WARNING: [Project 1-645] Board images not set in Hardware Platform and when I attempt to debug the program in Vitis I receive the error Executables selected for download on to the following processors doesn't exist or incorrectly specified. Do you wish to ignore them and proceed? 1. microblaze_0. I have the arty-s7-50 board files in the Vivado new board files directory as per the tutorial, though it looks like the revision is for B.0 and I have revision E.0. Does the revision discrepancy prevent Vivado from creating the board image? Thank you.