Technical Forum Moderator
  • Content Count

  • Joined

  • Last visited


About artvvb

  • Rank
    Prolific Poster

Profile Information

  • Gender

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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
  2. 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
  3. Hi @rmccormack1, Can you export your projects to a ZIP file and post it here? Errors that appear as makefile errors like this one may indicate that something in the board support package is failing to build properly, which would imply either a problem with the Vivado project and XSA, or with the configuration of one the software projects. It could be missing stdin, or it could be one of a couple other potential issues not directly related to the posted source code. Alternatively it might be down to xil_printf.h not being included, though I haven't managed to reproduce your error mess
  4. Adding fuel to the fire: Whether or not the tick pulse appears depends on whether you use non-blocking or blocking assignment in your testbench. If you observe the signals inside the mealy_edge_detect module as well, you can see that the state register is toggling as expected, but that since there is no delay in the simulation between the level rising edge and the state transition (when blocking assignment is used), the tick pulse never fires (or in reality very briefly fires, as you mention). -Arthur
  5. Hi Sheraz, I think that MAX_PKT_LEN is primarily there to inform the drivers about the size of the chunk of memory that it is allowed to put data into - it should match the size of the array that RxBufferPtr is pointing at, which also needs to be equal to or larger than the size of the longest packet that might be received, 2 words in this case. The missing bus interface is likely due to not including the [vivado-library]( repository as an IP repository in the project - it contains the definition of the Pmod interface used in the board files
  6. Hi @rmccormack1 Your verilog code has some issues. For example, writeCounter, readCounter, and Count should never hold the value of 8 - required to have some of the if statements and ternaries do anything - since they are all three bits wide, meaning that FULL is never asserted. The block design also presents issues, depending on your constraints. What pin locations are all of your ports connected to in your XDC? The prog_txen port should only be a single bit wide, and you are entirely missing the prog_d data bus. The USB104 A7's reference manual has some more information on which po
  7. Hi @westman The DDR Clock pin is intended to be connected to the MIG's sys_clk_i input. The MIG preset also is configured such that ui_addn_clk_0 is (near enough to) 200 MHz and can be used to drive ref_clk_i. The rest of the Microblaze design should be driven by the MIG's ui_clk or another clock derived from it. There's also a current issue that prevents the sys_clk_i input from being connected to the DDR Clock board interface, where the workaround is to instead manually constrain the port with an XDC file. There are some instructions on wiring the MIG up like this that can be found here
  8. Hi Sheraz, I'm not sure if anyone around here is familiar with that particular I2S IP, as it looks like it was released quite recently. As you might have seen in other threads and on the I2S2's resource center, there are a couple of different I2S demos/examples we've put together over the years - I recommend starting with these instead. That said, I'll try to provide some general comments on potential issues in getting this IP connected up: The AXI-stream master interface needs to be connected to something downstream to consume the data - this will be how the audio data exits th
  9. Hi @rmccormack1, There's an not-yet-fully-released version of the board files that helps to fix it available here: The solution is to reconfigure the MIG to accept a 100 MHz system clock (avoiding the upstream clocking wizard entirely, and just connecting the system clock to the 100 MHz clock pin) and produce it's own reference clock. This also entails constraining the sys_clk_i port in an XDC and, in the case of the USB104, either tying off the sys_reset or connecting it to a button through an inverter m
  10. Welcome to the forum. Unfortunately we don't currently have a manual available for the I2S IP. Likely the best source of information about the register set at the moment is going to be the name/address enums in the audio.h source files in the demos using the IP. Thanks, Arthur
  11. Hi @Sheraz Mainly, one, make sure that your packets can fit in the DMA buffer, as set in hardware by the AXI DMA's buffer length register width parameter. Two, make sure that the number of bytes specified by the third argument of the XAxiDma_SimpleTransfer calls matches the actual length of your packets in bytes (not transfer beats). If tlast doesn't show up on the transfer beat that the DMA is expecting (based on that third argument), then the IP can lock up. How is your AXI DMA configured? Thanks, Arthur
  12. @Zzingoh It looks like this thread on the Xilinx forum may have more information on this topic: Thanks, Arthur
  13. Hi @palmervb I tested the 2020.1 page's steps in Vitis 2020.2 today, and it is now functional. There was a step missing which was preventing the Vitis project from building due to some incorrect paths which must be manually updated. These steps have now been added to the document. Please make sure you are using the release files linked from the 2020.1 page. When opening the Vivado project (as the optional steps discuss), you are likely to also need to use the Tools > Report IP Status option, upgrade all IP, and (maybe) make changes required by new versions of the IP in the project
  14. Hi @Zzingoh The VP/VN signals are dedicated analog inputs and should not be used for your digital SPI signals. Descriptions of each of the analog-capable pins can be seen on page 16 of the XADC user guide ( Using differential signals requires you dedicate two package pins to each signal (you would have separate constraints for spi_clk_p and spi_clk_n, for example), and likely requires you to explicitly instantiate differential buffers in your design. The device on the other end of the connection w
  15. Hi @Joe_01 I've attached ZIP files with 2020.2 projects for the baremetal demos for the Zmod ADC and Zmod DAC, and the vivado project supporting both of them. Note, I have not tested this in hardware. You can also take a look at an updated version of the IPI getting started guide written for 2020.1 (there should be only minimal differences): Thanks, Arthur