artvvb

To add on to what zygot has already said, the override register also requires information from the DNA, and PMCU firmware does not allow values to be set which fall outside of the bounds specified by connected pods. From the PMCU spec: Thanks, Arthur

Hi @kadri, Welcome to the forums! XGpioPs_SetOutputEnable accepts a bank number instead of a pin number. Use the following instead: XGpioPs_SetOutputEnable(&my_Gpio, 0, 1); Debugging the program shows an assertion firing when you try to step past the SetOutputEnable call. By stepping into this call, it can be seen that the following line is where the assertion occurs: Xil_AssertVoid(Bank < InstancePtr->MaxBanks); Thanks, Arthur

Hi @Jonno, welcome to the forum! The Nexys A7 reference manual states, in referring to how to handle the ADT7420's temperature value register: The TempSensorCtl file is already effectively performing the right shift by three, which discards some extra flag bits present in the temperature value registers. I'd first extract the sign bit, and convert the data to unsigned. The multiply by 0.0625 described could be performed by treating the unsigned data as fixed point, and shifting the point. Converting fixed point numbers to BCD is a little more complicated than unsigned integers to BCD. There's a good discussion of it here: https://electronics.stackexchange.com/questions/320416/how-to-break-multi-digit-number-into-separate-digits-in-vhdl Lastly, a seven segment display controller that can handle the sign bit and decimal point would be needed. Hope this helped, Arthur

The VADJ rail is automatically set by the Eclypse's platform MCU when the board is powered on. You can find more information on this in section 3 of the the PMCU Specification document: https://files.digilent.com/resources/programmable-logic/eclypse/Eclypse-PMCU-Specification-Public.pdf The rails can be further configured after the fact by using decutil from the Linux images to communicate with the PMCU. The command manual for decutil can be found here: https://digilent.com/reference/_media/reference/programmable-logic/eclypse-z7/decutil.1.pdf Thanks, Arthur

That was pretty vague on my part, apologies. I should have said that XPR and workspace files which can be opened in Vivado and Vitis 2020.1 exist, however, I haven't personally had the opportunity to check whether their documentation is accurate to the steps needed to get them running. The documentation may be incomplete and the projects may be buggy. I'm looking into it. It looks like you downloaded the "Source Files" zip on Github which does not contain sources as you noted. The correct downloads should be the -hw.xpr.zip and -sw.ide.zip files, as pointed out in the release description. I'll be updating these reference pages to make sure that they point directly to the file downloads, as opposed to the GitHub page, as the use of the releases page has definitely been confusing.

Hi Vikram, welcome to the forum. Xilinx officially supports the following versions of Windows in 2022.1: Microsoft Windows Professional/Enterprise 10.0 1903 Update; 10.0 1909 Update; 10.0 2004 Update: 10.0 20H2 Update; 10.0 21H1 Update Home edition may still work, this just means they haven't tested with it. As for Vivado, ML Standard Edition will work with the Nexys Video, however, you should be aware that the example projects Digilent provides may or may not be supported. The most up-to-date (but still marked under construction as they haven't been fully tested) materials, supporting Vivado 2020.1, can be found here: https://digilent.com/reference/programmable-logic/nexys-video/demos/start Hope this helps, Arthur

Hi @pablo_gatearray The additional clocking wizard was in there solely in case I wanted to tweak the clock frequency later. It's easier to change a clock frequency output by a clocking wizard than it is to run through the MIG wizard. Additionally, there are some bugs in the MIG wizard in some versions of Vivado where some settings pulled in from the PRJ files aren't necessarily visually shown in the default settings of the wizard, which makes it really easy to mess up a design when using the wizard. Using ui_clk or a ui_additional_clk to drive the Microblaze works fine, and the clocking wizard is not necessary. Thanks, Arthur

Hi @Eran Zeavi, Try this tutorial instead: https://digilent.com/reference/programmable-logic/guides/getting-started-with-ipi Xilinx replaced SDK with Vitis starting in version 2019.2. You might also need to go back and install Vitis through Vivado's "Help -> Add Design Tools and Devices" menu, which reruns the installer. Thanks, Arthur

Hi @Dave Peterson, welcome to the forum! We don't currently have a guide for this. The steps below detail creating a BOOT.bin file for baremetal projects only: In Xilinx SDK 2019.1 and the first few versions of Vitis, you need to create a first stage bootloader project - the template works without modification - then use the "Create Boot image" tool to make a boot.bin file consisting of the FSBL elf file (has to be first), then the bitstream file and the application project ELF file. First create the FSBL: Then create the boot image: with the necessary partitions, elf files can be found in the Debug folders of each project after they are built: When creating a new application in the latest versions of Vivado/Vitis, the BOOT.bin file is created automatically as long as the "Generate boot components" box was checked when the hardware platform was created, and it can be found in the system project's Debug folder after the project is built. Thanks, Arthur

A lot depends on the signal you are trying to receive. Are you trying to capture some parallel data without any control signals, or using some protocol like SPI? How fast do you need to be sampling the signal? In general, PL to PS data transfers will be going through some AXI IP, whether that's an AXI DMA and some custom frontend, a custom AXI Lite core, or, if speed/throughput isn't a concern, some slow interface like an EMIO or AXI GPIO core. Of these, AXI DMA is the only one that doesn't require constant attention by the processor - transferring data into the DDR reading a single register into a variable or array stored in DDR - but is also probably a more complex option to start trying this with. Thanks, Arthur

Hi @RyanW When receiving, the DMA can stall if it is expecting the wrong number of bytes, as you allude to in referring to potential issues with tlast. As such, if you are raising tlast for the 32nd word of the transfer, the transfer length passed to the simple transfer call should be 128. Refer to the Programming Sequence / Direct Register Mode (Simple DMA) section of the AXI DMA Product Guide, p70-72. It could also be helpful to add an ILA to your hardware design, so that the Vivado hardware manager can be used as a logic analyzer, letting you observe the axi stream while the bitstream is running on the board. There's a System ILA IP in Vivado that can be used to do this. Also, once this problem is resolved, you will probably need to use xil_cache.h functions to flush and invalidate the cache before and after the transfer, respectively. Thanks, Arthur

Looking at the VHDL module's portmap (line 76-85), this module only controls the sync signals, and requires a 25 MHz clock. The VGA interface requires you to also control the red/grn/blue lines from a vhdl module. The Basys 3's input clock is 100 MHz, so you also need a way to divide the clock down. If you haven't yet, I'd recommend starting with a simpler project like writing some VHDL that blinks a single LED at a fixed frequency, writing the constraints file to map the top level ports to FPGA pins, and building it and deploying it to your board, prior to taking this project on. There are several tutorials available in various places online that walk through this. THanks, Arthur

Hi @aries Referring to the Basys 3 Reference Manual's section on the VGA port, if you already have syncs being generated, driving the four red signals high and the green and blue signals low during the "display time" ought to do the trick. The reference manual will also include information which can tell you about the sort of circuit (but not necessarily the exact circuit) that the VHDL file you found is describing. Thanks, Arthur

You can use, for example, xil_printf("%04x", my_short_int); to pad the values sent to four characters with leading zeroes (in this case formatted in hex), to keep the length of the printed string consistent. usleep(microseconds); can also be used if you need a shorter sleep function. Thanks, Arthur

The ADC IIC base address should also be I2C_1, both Zmods share that MIO I2C: #define IIC_ADC_BASE_ADDR XPAR_PS7_I2C_1_BASEADDR The heap size should also be increased in the linker script (lscript.ld). 0x4000 should be sufficient, though larger won't hurt (and if you want to use significantly bigger software buffers, it will need to be larger). I'd adjusted this while debugging yesterday prior to correcting the length, in order to see if there was a memory leak or something progressively eating more of the heap on each pass through the DAC demo. In case it's helpful, I've attached the modified dma.c that I've been using while debugging, which takes advantage of the mallinfo function to track when and how much of the memory in the heap is being allocated and freed. This produced the following log, which I've annotated with the objects getting allocated and freed. Note that fordblks shows the amount of free memory that can be accessed by the malloc function. This shows that when the DAC XAxiDma is being allocated, there isn't enough memory left for malloc. The length variable is still an issue (but has now been corrected in the Github sources). The 14 bit length limit you note is due to the size of the AXI DMA's transfer length register rather than the size of the allocated buffer in DDR. The overflow I'm describing happens solely in software. In the original code, with amplitude 5 and step 2, the following line allocates an 8-word memory space: length = (size_t)(amplitude/step) << 2; buf = dacZmod.allocChannelsBuffer(length); // (size_t)(5.0 / 2.0) << 2 // = (size_t)(2.5) << 2 // = 2 << 2 // = 8 while each of the for loops count five times. for(val = -amplitude; val < amplitude; val += step) // expands to -5, -3, -1, 1, 3 for(val = amplitude; val > -amplitude; val -= step) // expands to 5, 3, 1, -1, -3 This can be checked by printing the value of length and the value of i after the for loops. Yesterday, before correcting the length, the mallinfo technique showed the uordblks, fordblks, and keepcost values to be underflowing at some point prior to the failed DMAEnv allocation (which was a different failure point than the xAxiDma), meaning that more memory had been freed than had previously been allocated. Thanks, Arthur dma.c

Hi @Tommy 777 This looks like it's due to a bug in the DAC example code. The following line in your version of the code introduces a rounding error when the amplitude divided by step (5 / 2 = 2.5) is converted to an integer, causing the loop later in the function to count past the end of the allocated buffer, overwriting something critical above it. length = ((size_t)(amplitude/step)) << 2; Changing the line to the following should address the problem. length = ((size_t)((amplitude * 2.0) / step)) * 2; I'm working to get it addressed in the github sources. Thanks, Arthur

It looks like the print statements seen on the console are coming from the Arty Z7's out-of-box demo, programmed into flash during manufacturing. Please change the boot mode jumper (JP4) from QSPI to JTAG. While QSPI mode does not prevent JTAG programming, it does prevent QSPI programming, which will make it a little more obvious whether the hello world app is being programmed in or not. Could you provide a screenshot of the Vitis Log tab after trying to run the demo? It should show some launch scripts getting run, targeting the Arty Z7, see attached for an example (though this not the same application or board). Thanks, Arthur

Hi @Rai Taimoor Ali How did you move the workspace between the two computers? Vitis keeps some absolute paths to these files in the project files, so copy-pasting for example wouldn't work, even to a different location on the same computer. You can use the File -> Export function to create a ZIP file containing all of the projects, move the ZIP to the other system, and then File -> Import there. There are some potential bugs there, depending on the version of Vitis you have. Thanks, Arthur

Hi @Aditya Shandilya, You probably need some kind of serial interface connecting the Arduino and fpga so that the Arduino can issue commands and send data to the fpga and for the fpga to return data. UART or SPI would be fairly typical. Thanks, Arthur

The syncs and pixel data might be misaligned, depending on the constants used in the compares. There are a different number of register stages in the sync and color data paths, and a redundant extra output stage. Data arrives from the counters (through combi logic in the case of the sync data path) to the first set of registers "at the same time", assuming that timing is met. Refer to the attached screenshot of the RTL analysis schematic view in Vivado. Thanks, Arthur

Hi @engi Have you tried another monitor and/or VGA cable? Edit: I highly doubt this is a power issue. Your design is quite small, and the Pmod VGA does not provide any power to the monitor. The iostandards for all banks relevant to the design are applied in the xdc file and all of the power rails on the Arty run at fixed voltages. -Arthur

Hi @wolfgang6444and @engi The A0/A1 pins are connected to XADC channels 4 and 5 rather than channels 0 and 1 (edited). The mapping between the XADC channels and the arduino header pins can be seen in the master XDC file on github (here is line 120 of the 100T XDC). You can also see the mapping in the board's XADC demo: https://digilent.com/reference/programmable-logic/arty-a7/demos/xadc. You ought to be able to confirm this is the case with your current design by taking a measurement through the A5 pin, which is connected to aux channel 0. I'm looking into getting this clarification added to the reference manual. Thanks, Arthur

Hi @ilovefpga, Pmod port JF is connected to the Zynq PS and is controlled via the xgpiops driver, as you have seen. The other Pmod ports are all connected to the Zynq PL and need to be controlled through the FPGA fabric and constrained in an xdc, as you have seen. If you use an AXI GPIO or Pmod GPIO IP core (as seen in the thread you linked), you need to use the xgpio drivers (written for the PL IP) instead of the xgpiops drivers. Alternatively, you could configure the Zynq PS to provide an 8-bit GPIO EMIO interface, make that interface external, and constrain it in the xdc. The EMIO option would use the xgpiops drivers and likely reuse most of the same code you already have (changing some of the hardcoded pin numbers). A starting point for configuring the Zynq block for this can be seen in the attached screenshot. Could you provide a screenshot of your block diagram? Thanks, Arthur

Hi @GlenW, Yes, the Eclypse follows the SYZYGY mechanical specifications for double-wide standard pods. Thanks, Arthur

Hi @NithinA From software, short of decimating/averaging data captured at 100 MS/s down to some lower sample rate, there is not. It may be possible to reduce the clock frequencies in hardware, however we don't have an example or documentation detailing this, and the effectiveness of the calibration may be affected. The latest hardware-only demo release (https://digilent.com/reference/programmable-logic/eclypse-z7/demos/low-level-low-pass-filter) works with the ADC 1410 and runs it at 40 MS/s with a new release of the Zmod IPs, but these are incompatible with the currently-released AXI controllers. Thanks, Arthur