artvvb

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

Hi @msamirh You will need to use the XADC wizard IP to configure the XADC and get an interface to pull data from it - likely a DRP interface if you don't want to use the Zynq PS. For a starting point to see how this works, I'd recommend checking out the Zybo Z7's xadc demo: https://digilent.com/reference/programmable-logic/zybo-z7/demos/xadc Thanks, Arthur

Hi @Nico89 The Pmod CAN IP encapsulates Xilinx's AXI QSPI IP and AXI GPIO IPs (looks like versions 3.2 and 2.0, respectively, in the latest vivado-library release). Each of it's AXI interfaces connects to these and provides direct access to one of these IP's register spaces. The AXI GPIO is connected to the bottom row of the Pmod connector, to provide software interrupts and the ability to trigger a reset. The Pmod IP is intended to be used through C code and the software drivers provided with the IP - the drivers for the encapsulated Xilinx IP are wrapped by an additional software layer for the CAN. Hope this helps, Arthur

Hi @skinnypanda Take a look at the "Language Templates" menu in the tool. There's both some example code for inferring BRAMs as well as some templates for instantiating BRAM primitives directly. Thanks, Arthur

The voltage provided by a microphone tends to be quite low. You could potentially amplify the signal before it reaches the I2S2, multiply it up in the FPGA (resulting in a poor quality signal, since you are only effectively using the lowest couple of bits), or try out your project with a cable connected to a computer's audio out. I'd recommend the latter if you happen to have a 3.5mm-3.5mm cable lying around. Getting a bunch of samples dumped into block RAM and then potentially out over UART or into the ILA in a burst could be a good way of looking at more than just one sample at a time. Could potentially also wire something up to look for the minimum and maximum values received in the incoming data. Thanks, Arthur

@Jan Kager It looks like the constraints for the top and bottom row of the Pmod port are swapped. I don't have a Pmod I2S2 to test with at the moment, but was able to get the transceiver core running with your constraints and a Pmod I2S (which uses the same CS4344 chip used in the I2S2's line-out) connected to the bottom row of port JA. I've attached the Verilog module I used to generate the audio output data for testing, as well as a screenshot of the block design. Please also check that your MST/SLV jumper is in the SLV position, since the transceiver core generates the clocks for the line-in chip, rather than taking them as input. Thanks, Arthur module audio_test_pattern( input clk, // 11.29 MHz mclk input lrck_in, // 44.1 kHz lrck output [23:0] count_out ); reg store; wire enable; always@(posedge clk) begin store <= lrck_in; end assign enable = store & ~lrck_in; reg [23:0] count = 0; assign count_out = count; always@(posedge clk) begin if (enable) begin count <= count + 24'd100000; // the counter rolls over at ~262 Hz end end endmodule

Hi @rmccormack1 Something in the project is misconfigured. Undefined reference to main implies that either the "int main (void)" pattern of the definition isn't the one that the tools are looking for - maybe the application was created using a C++ template, or some other template that doesn't work for your code. It's also possible that the source file isn't in a directory that the tools are looking in for sources. Console logs and/or a project archive would help me to figure out what exactly is going on. Thanks, Arthur

Hi @rmccormack1 This error message means that the project's build outputs don't exist; either the project hasn't been built, or it failed to build. The processor exists (probably), but the file that its supposed to run doesn't exist. Either way, there is nothing to be run on the device. If you can provide either the Vitis console logs or an exported ZIP archive of the project, I might be able to determine why the required ELF file is missing. Thanks, Arthur