artvvb

Hi @biosbob FPGA logic, such as the mentioned Quad SPI IP, is required to access the flash. As I understand it, the way that Vivado writes to flash via JTAG is actually by putting a pregenerated bitstream into the FPGA that creates a bridge between the JTAG circuitry and the flash's SPI interface. Thanks, Arthur

Not much to add to what Zygot has already said, it's spot on. Digilent's applications and support team is pretty small - we're doing what we can. That said, the frustration is heard. For debugging the UART connection, I've attached a couple of python scripts, and a modified version of the source. There could be additional libraries to install off of a baseline python installation, but pyserial and numpy are both common. For using either, start the Vitis app first, it should be sitting in the recv while loop when the host is sending characters. The first one connects to the serial port and dumps out imageSize characters, and checks a returned checksum. The second one generates a file full of random 0-9 characters which can be dumped through teraterm, where you can see a returned checksum and whether there were UartLite overruns. Worked with no loss on my machine at 10k bytes, but your mileage may vary. import serial import numpy as np imageSize = 10000 with serial.Serial('COM13', 9600) as ser: buffer = [x & 0xFF for x in range(imageSize)] s = ser.write(buffer) line = ser.readline() if (np.sum(buffer) & 0xFF) != int(line[0:2], 16): print("checksum mismatch") else: print("all good") import numpy as np imageSize=10000 with open("./file.txt", "w") as out: buffer = [] for x in np.random.randint(0, 10, imageSize): buffer.append(x + ord('0')) for c in buffer: s = out.write(chr(c)) checksum = np.sum(buffer) & 0xFF print(f'checksum: {hex(checksum)}') #include "xparameters.h" #include "xuartlite.h" #include "stdlib.h" #include "xil_printf.h" const u32 imageSize = 10000; int main() { u8 *imageData; u32 receivedBytes, totalReceivedBytes=0, sentBytes, totalSentBytes=0; XUartLite_Config *myUartConfig; XUartLite myUart; u32 status; imageData = malloc(imageSize); myUartConfig = XUartLite_LookupConfig(XPAR_AXI_UARTLITE_0_DEVICE_ID); status = XUartLite_CfgInitialize(&myUart, myUartConfig, myUartConfig->RegBaseAddr); // start python script after starting app while (totalReceivedBytes<imageSize) { receivedBytes = XUartLite_Recv(&myUart, imageData+totalReceivedBytes, 1); totalReceivedBytes += receivedBytes; } u8 checksum = 0; for (u32 i = 0; i < imageSize; i++) { checksum += imageData[i]; } xil_printf("%02x\r\n", checksum); XUartLite_Stats stats; XUartLite_GetStats(&myUart, &stats); if (stats.ReceiveOverrunErrors > 0) { xil_printf("%d overrun errors\r\n", stats.ReceiveOverrunErrors); } }

If you've got the checkout script, you at least picked up the submodules correctly. Do confirm that you cloned targeting the demo branch you want.

Hi @davwamai, There should be a block design generated when running that command, it's not necessarily the case for all projects, but all of the ones for Eclypse have block designs. Check to see if the version of the tools you are using is the same as recommended by the project (likely 2019.1, depending on the demo). Error messages should also be appearing in the TCL console, which would help to figure out what might have gone wrong. Thanks, Arthur

@zzzhhh Arty A7 doesn't have hardware flow control pins for the USB UART bridge. I find it surprising that the processor is unable to keep up with a 9600 baud rate interface, especially with the low-level UARTLite code. How are you allocating imageData in the second chunk of code? You can also see if the issue is actually a UARTLite FIFO overrun by checking the status register, documented in https://docs.xilinx.com/v/u/en-US/pg142-axi-uartlite, page 11-12. There's an API call that lets you check this, XUartLite_GetStatusReg with the right mask. If the overrun bit isn't set, the issue shouldn't be in the UARTLite IP. That said - in addition to the mentioned flow control - to improve the processor end of the connection, you could increase the max number of bytes that can be received per recv call - passing "1" for the byte count means each call can only pick up zero or one byte, and makes the number of times it needs to be called higher. You could also use interrupts triggered when the hardware buffers are too close to full. Note that the AXI UARTLite hardware buffers are both (RX&TX) 16 bytes. You should have something on the order of ~2 ms (11 bits / 9600 hz) per byte to service the buffers. Thanks, Arthur

hi @mohamedabdulrahman2024 All material we have for the Spartan 3E can be found here: https://digilent.com/reference/programmable-logic/spartan-3e/start The user guide, linked there, appears to contain template UCF constraints, and the schematic is also available. Thanks, Arthur

It's possible, but trickier on Zynq than it would be on non-Zynq boards, since the PS is still there. Check out these materials, it should work the same on Zybo Z7 as it does on Arty Z7: https://digilent.com/reference/programmable-logic/arty-z7/intro-to-fpga https://digilent.com/reference/_media/programmable-logic/arty-z7/session_two_lab.pdf Thanks, Arthur

The xiicps driver is the driver for the Zynq PS's hard IIC controller rather than the soft-core AXI IIC used inside the PmodTMP IP. Drivers for the PmodTMP should be included in the hardware platform project, including example code. You should be including the "PmodTMP.h" header. It would also be possible to reconfigure the Vivado project to map a hard PS IIC controller to Zynq EMIO and connect it to the relevant Pmod pins, in order to save FPGA resources and use the xiicps driver, but that would potentially be more work than trying to use what you've already got. In that scenario, you'd also potentially need to map the other Pmod pins to EMIO GPIO or an AXI GPIO, and rewrite software found in the PmodTMP drivers. Thanks, Arthur

Hi @Esmail As zygot mentions, there are modules missing from the project that SimUAid should be providing as a VHDL package, or that might be included somewhere in its installation files. This additional file is necessary to provide the descriptions of the various inverters and logic gates. Digilent unfortunately doesn't have experience with using SimUAid. Thanks, Arthur

Hi @tidEman, welcome to the forum, Looking into fixing the issues, apologies that you're experiencing them. Assuming you're following the "In order to program the project onto an FPGA" steps to download the Cmod S7 release archive and using "generate bitstream" to get a bitstream out of the projects, did you redownload the project archive between trying to open it in the latest version and in 2018.2? Just opening a project in a newer version could maybe change the underlying files. The verilog sources should still be usable in recent versions, and the only change that was originally made to the default settings of the clocking wizard IP in the original version was to set it's CONFIG.PRIM_IN_FREQ to the appropriate clock frequency depending on the board being used. You could potentially delete the existing clocking wizard from the project, add a new one from the IP Catalog (found under Project Manager on the left side of the app), and change this setting to suit the board: The top level parameters are the other thing to check. They can be found in the project settings, seen below, and override the parameters at the top of the top verilog file. Thanks, Arthur

I don't see any immediate issues with this setup. Can you share what board you're using and how you're measuring the pin values? The following worked fine in trying to reproduce the issue, using a logic analyzer directly connected to an Arty Z7-10's Pmod ports. Thanks, Arthur

@zzzhhh This repository should allow you to use RISC-V on an Arty A7-100T, write software for it in Vitis, and debug it over JTAG using the built-in debugging tools: https://github.com/eugene-tarassov/vivado-risc-v. I haven't run through setting it up, but the contributors seem to be affiliated with AMD/Xilinx. Thanks, Arthur

Hi @jacklu333333, That's the only RISC-V tutorial that we've tested internally, and it hasn't been checked in several years. We'll get a warning added to the page so that other folks don't get the same surprise you did. I haven't tried it myself, but this repository seems to be actively maintained, with commits within the last several months and a release as recent as November '22. It claims support for the Arty A7-100T and several other Digilent boards: https://github.com/eugene-tarassov/vivado-risc-v Thanks, Arthur

Replied to the further question over here:

Please check that your board is connected to a USB port of your PC and that the cable is capable of providing data connection (if it's the one included with the Basys 3 it's fine, some phone charging cables aren't, despite having the same physical connectors). If it's connected, check the device manager in Windows to see whether the board has an associated COM port. If it doesn't, check the "Tools -> Add Design Tools and Devices" menu in Vivado, rerun the installer, and check whether the "Install Cable Drivers" box was checked - see the step starting with "This screen provides more detailed options for the customization of the installation." in this guide: https://digilent.com/reference/programmable-logic/guides/installing-vivado-and-vitis Thanks, Arthur

Hi @jbird, apologies for the delay. The document has been created: https://files.digilent.com/resources/programmable-logic/arty-a7/Arty-A7-100T-RevE-SoV.pdf

Yeah, good point. It's also a reason to copy-paste from templates where available, though that still comes with some potential for typos.

Hi @Esmail Welcome to the forums! The property you should be setting in your constraints should be "PACKAGE_PIN" rather than "PAKAGE_PIN". This tutorial may be helpful: https://digilent.com/reference/programmable-logic/guides/getting-started-with-vivado Thanks, Arthur

No problem! Referring to the ZC702 datasheet, particularly "User PMOD GPIO Headers" starting on page 49, it looks like you may need to wire the Pmod to the eight Pmod1_# and Pmod2_# pins using some additional cabling, as there isn't a full 2x6 connector with FPGA-connected IO. Thanks, Arthur

I'm not sure why the symbols aren't available everywhere in a function while debugging in the BSP, perhaps something in BSP/platform build settings. A couple of related issues I've noticed with the debugger, and some suggested workarounds: _ReadReg, _WriteReg and other similar macros can plant the debug trace in the file that the macro is declared in rather than the spot it's being used, which can mess with the scope of what's visible in the debugger. You can work around this by either determining the address of the EventData variable and using the memory viewer to look at the address range it's in, or by making sure the debug trace is actually planted in the right place by setting a breakpoint on an expression that doesn't include one of these macros like the ReceivedCount increment on line 477. This is also why you sometimes see the debugger bouncing between files when stepping forward through code. Both workarounds aren't fun. Debugger trace placement in BSP sources also seems to not be consistent, stepping over lines sometimes skips lines. You could also copy driver source code into your application project to debug it there. There could be some additional macros or functions or other things that are only declared in the driver source and not included headers that you'd also need to copy over. Given that UART is default high when idle, I don't think there'd be much issue with either leaving the pullups enabled or disabling them, but I'm not certain. Shouldn't affect interrupts, as most of the interrupt sources are to do with decode errors, framing errors, and other things directly related to the UART protocol, rather than the logic level alone.

Hi @ptembras, welcome to the forum, Yes, it's possible to use interrupts for the SF3 at the same time as other interrupts. The InitInterruptController function in the intc sources in the driver overwrites the interrupt controller configuration - as seen by the fact that it calls LookupConfig and CfgInitialize - as does rerunning CfgInitialize after InitInterruptController. In retrospect, the intc sources should have been included in the software examples folder rather than in BSP sources from the beginning, since they need to either be modified to add your additional interrupts, or their functionality needs to be copied into your application project. To pull this off, you need to not use the InitInterruptController function, and set up your interrupts at the same time as the SF3 interrupts. Thanks, Arthur

Hi @Manan Joshi, welcome to the forum! Not sure if the IP will work in 2016.1 or not, we haven't tested it in that version any time recently, if at all. When adding vivado-library to your project as an IP repository, did you choose the "IP" folder inside of vivado-library, or did you choose "vivado-library" itself? That's one way that the interfaces folder, "if", might not get detected by your project. That folder is where the interface definition for Pmod_out resides. Thanks, Arthur

Hi @FPGA4Life There are still missing spaces in the constraints, at least between the end of the dicts' "}" character and the start of the get ports call's "[", in addition to missing the IOSTANDARD keys. XDC files use a subset of the syntax of the TCL language. set_property is a command with space-separated arguments, so every missing space "clumps together" several arguments, concatenating them, and making it so that Vivado treats them as only one (incorrect) argument. Similarly, the dict argument groups a bunch of individual settings together, and the curly brackets are there to make everything inside of them a string, so that the interpreter doesn't treat spaces within the brackets as delimiting arguments. This string must be made up of key-value pairs, the command sets the PACKAGE_PIN property to P18, the IOSTANDARD property to LVCMOS33, and so on. Having five elements in the dict breaks this. Refer to UG903's About XDC Constraints section for more info. Thanks, Arthur

I need to reproduce the issue to be able to say much. Would you be able to provide your Vivado project? Not sure if clocks might be the issue, since a baseline link seems to be up (are the LINK/ACT LEDs illuminated?). How are you clocking your design? Is eth_ref_clk still 25 MHz, and what are you using for the Microblaze input clock - an offshoot of the incoming sys_clk, downstream of ui_clk passed through another MMCM, something else? Switching your board files to a version prior to the switch from v1.0 to v1.1 of the Arty A7 board file could let you follow the design steps for adding the MIG more closely than using 1.1: https://github.com/Digilent/vivado-boards/archive/refs/tags/XilinxBoardStore/v1.zip. That said, you still might run into backbone crit warnings or similar. Thanks, Arthur

Hi @notooth Even when a project only runs in PL, the PS is responsible for loading the bitstream, and you need a bootloader. See here for creating an SD card image for an existing software application: https://digilent.com/reference/programmable-logic/guides/zynq-baremetal-boot. Notably, this might be easier to do following the SDK flow as opposed to the Vitis flow, since you might be to be able to use another software application created for the same board and just switch out the bitstream used to create the image. With the Vitis flow. You could instantiate the top level of your HDL design in a block design, add the Zynq PS, run block automation, connect necessary clocks, make sure your HDL design's ports are connected to ports in the block design, create a wrapper, and rebuild the bitstream. This would ensure you have a design that includes the configured PS, even if it's not connected to user logic. Not ideal, and there are probably workarounds - you might be able to follow the SDK flow in Vitis as well, manually creating a boot image from its constituent parts. See here for creating a project that meets the requirements to create a boot image: https://digilent.com/reference/programmable-logic/guides/getting-started-with-ipi Thanks, Arthur