artvvb

Technical Forum Moderator
  • Content Count

    336
  • Joined

  • Last visited

Everything posted by artvvb

  1. With regards to this, the process is described in Workflow 5 of the digilent-vivado-scripts readme. In addition to these, the steps in the Eclypse Z7 Git Repo Documentation's Navigating and HW sections should be used after cloning, and before running any scripts. I am looking into getting these steps all in one place. -Arthur
  2. Hi @Phil 1. Yes. 2. The error appears to be coming from Vivado generating invalid VHDL syntax for this specific scenario. Make sure that your HDL wrapper file is in Verilog, rather than VHDL. Here is a thread on the Xilinx Forums with some more detail. 3. IOBUFT can be used from within an Verilog module, but cannot directly be instantiated in IPI, as far as I know. It is likely what is being inferred by your module. This should also work though: you can directly make the AXI IIC's IIC interface port external (by right clicking on the interface port and selecting "Make External"
  3. Hi @Abuzar The VP and VN pins are dedicated analog inputs and should not be connected to the ILA. Only the auxiliary analog inputs may be used as digital I/O, but even then, cannot be used for both analog and digital I/O at the same time. Page 16 of the XADC User Guide has some more information. Thanks, Arthur
  4. Welcome to the forums! Please provide your XDC file, if possible. The behavior described sounds like it may be caused by one of two things: 1. The RxD port may be tied to the wrong pin. Pin A9, labeled uart_txd_in is the correct pin for receiving UART data. 2. The source that you are using for the reset port. The button labeled RESET (ck_rst, pin C2) is active low. If this is what the reset port is tied to, then the module would be held in a permanent reset state. This could be resolved by either modifying the core's reset condition/s, or by tying the reset to an active high but
  5. Hi @rebelsequeira Welcome to the forums! The Pmod AD1 IP core can be used without board file support: Add the IP to the diagram with the Add IP button. Select the IP's Pmod_out interface. Right click on the Pmod_out interface and select "make external" Connect clocks, interrupts, and AXI interfaces as usual. Create an HDL wrapper or make sure that the existing one is up to date. Open the HDL wrapper to find the port names for the Pmod pins (typically something like Pmod_out_*_pin1_io by default). Create an XDC to constrain the Pmod pins as they are
  6. Hi @Juliana converting from PWM data to PDM data on the Basys 3 can be fairly straightforward. There are some good examples of PDM output modules on the web - this article is pretty good. If both the input and output use the same frame size and sample rate, it could be as simple as just wiring up a single data bus between the two, although some handshaking signals may still be needed. If you need the PWM and PDM on different clocks, it could be harder, but it looks like the APX555 can handle some pretty wide ranges, as well as a 3.3V standard that you'd get out of the Pmod connectors on t
  7. Hi @tomii The schematics of the Pmod AD1 are available through the Digilent Wiki, in the sidebar of the linked page, and may be helpful. The protection resistors are in series with schmitt triggers. I'd recommend double checking that the timing requirements of the AD7476 (page 8 of its datasheet) are being met. I suppose it's possible that if your nCS line is peaking at ~2.5V (I may be reading the scope diagram wrong), it might not be spending enough time high (not meeting the t1 spec). I also count 15 falling edges in the CS/SCLK scope diagram? While this may not necessarily be
  8. The messages may need to be sent after RX.c has already been launched. CAN_ReadStatus directly returns the result of the READ STATUS command specified in the MCP25625 Datasheet. It could also be worthwhile to print the result of a CAN_RxStatus call, as it has more information about the status of the chip's read buffers. Thanks, Arthur
  9. The Pmod SD comment is correct, it is normally used to store webpage info. I believe that the maximum Microblaze local memory size is 64 KB. Since the Basys 3 doesn't have additional RAM outside of the FPGA, the entire program needs to be able to fit in block RAM. The 385 KB specified is the size of the program that SDK compiles, without any modifications to the example code or drivers. I'm not certain how big your application will end up being, but you will be able to find out by looking at the compiled ELF's size in the application project's Debug folder. You may need to manua
  10. Welcome to the Forums! The critical warnings about not being able to find the Pmod interface are likely to be causing the issue. The vivado-library folder contains two main subfolders, "ip" and "if". The Pmod IP is contained in the former, while the itnerface is contained in the latter. Make sure that you picked the root "vivado-library" folder when adding the IP repository to your project (first image, below). When the IP's Pmod interface is successfully connected to the board interface, you should see the connection show up in the board tab and in the block diagram (second image, b
  11. Welcome to the Forums! The "bitstream is not compatible with the target" error means that the part selected when you created the project does not match the part that the hardware manager found on the Pynq. You can change the part or board through the first page of the project's Settings dialog. Make sure that the part matches "xc7z020clg400-1". All communication with the Pmod CAN from the host board goes through a SPI bus. The Pmod IP core and its drivers wrap a Xilinx Quad SPI IP core and xspi drivers, so the actual SPI protocol is mostly abstracted away when you are writing your co
  12. Hi @asmi You can launch Vitis through the Tools > Launch Vitis menu option in Vivado. I briefly cover the steps required to create a new application project in this other thread. Edit (link didn't work): Go to developer.xilinx.com, click on Documents, search for "create a sample application", and click the first link. Thanks, Arthur
  13. Hi @Arty7_Lover Unfortunately the Arty Z7 does not yet officially support Vitis. That said, you can still use the Arty Z7 with Vivado 2019.2 and Vitis. The workflow for creating a basic embedded application has not changed much from previous version of Vivado with Xilinx SDK, described here. In order to create a application project, you must have a hardware specification (.xsa file) that targets the board. This hardware specification is exported from a Vivado project (File > Export > Export Hardware). I have attached both a project and specification for the Arty Z7-20 to t
  14. artvvb

    Custom IP interrupt

    Hi @HasanWAVE The address range assigned to the custom IP's AXI_INTR interface can be found in IPI's Address Editor and manually brought into SDK. To bring the base address into SDK automatically, you will need to add C_S_AXI_INTR_BASEADDR (and possibly C_S_AXI_INTR_HIGHADDR) to the list of parameters found in the TCL script in the IP's Software Driver file group. Offsets from the base address for particular registers are typically manually defined in SDK through the use of macros. The code blocks below show the changes to the IP's sources I would suggest as a starting point. I
  15. Hi @Mosi_513 Simulating your design will help a lot in debugging the issues with it. For example, it looks like your clock_divide process is actually dividing the clock by 12, not by 5. The counter counts from 0 to 5, and on 5 (the 6th iteration), it toggles the clkdiv signal. Doing a toggle like this doubles the period of the enable strobe, so the main process only actually activates every 12 cycles. See the attached screenshot. I have also attached the testbench I used, which should help to get you started. There are likely other issues that I haven't spotted yet, but using the sim
  16. @johnsan1 I'm not sure w/ regards to tera term, but there are some other options. Assuming you aren't running up against the baud rate as a speed limit, you could add a Xilinx AXI Timer/Counter IP to your block design, that could be used to fairly precisely time how long your code takes to execute. The time values captured from the counter, either raw or formatted however you want could then be printed over serial, along with your data. Adding in extra bytes to the serial transfers would slow the system down, but you could either increase the data density of the transfers by red
  17. Hi @youngpark Looks like the AXI GPIO (axi_gpio_0) connected to the module's key input is set to input only. This should be changed to output only. the connection between led and axi_gpio_1 is also a potential issue. When you connect only some pins of an interface to a module, it disables the board interface's version of those pins. What this means in your design is that clock_divider_0's output is not going to be reflected on the LEDs. From the point of view of the processor, when it reads from the GPIO, it will see the clock_divider module's output, and when it writes, it writes di
  18. We've used XIT scripts to apply additional constraints. Example from the PmodAD5, which handles hooking the IP's interface to the board file interface. I've pasted the contents of the "xitscript.tcl" script we use to add this file to the IP packager below: set imp_fg [ipx::add_file_group -type {xilinx_implementation} xilinx_implementation [ipx::current_core]] ipx::add_file {utils/board/board.xit} $imp_fg set_property type {{xit}} [ipx::get_file utils/board/board.xit $imp_fg] set_property used_in {{implementation} {board}} [ipx::get_file utils/board/board.xit $imp_fg] -Arthur
  19. Hi @dmeads_10 The error message is telling you that the port names you use in your XDC do not match the ones that are at the top level of the design (the HDL wrapper file). The issue appears to be that the block diagram's ports are interface ports as opposed to just ports. Since interface ports could contain multiple buses (_tri_i, _tri_o, and _tri_t for example), they typically have an extra suffix tacked on when Vivado generates the HDL wrapper. There are a couple of solutions: 1. You could make the individual ports of the interfaces external, as opposed to the interfaces them
  20. Hi @krjdev The "Connect Board Component" flow requires modifications at least to the generated xgui.tcl, and to the parameters of the Pmod interface port, within the IP. You can see how we added board file support in the existing IPs. Internally, we typically create new Pmod IPs by modifying an existing one that is known to be good. You can also connect custom IP to the interfaces of the Pmod Bridge, but this will likely not be doable through connection automation. Thanks, Arthur
  21. Welcome to the forum! Those clocks should be fine. As mic hardware and line hardware are different, an amplifier is required. This why computers use two ports. The converter you linked only splits the cable, and does not appear to do any kind of amplification. Mic to line amplifiers are available for purchase online, but I do not have any specific ones to recommend. -Arthur
  22. Hi @Rodrigo_Montero I don't think the issue is with the clock or with the XADC core, as you are seeing data on the LEDs, and the data on the LED line is synchronous to the clock. The issue is likely due to the control signals for the SPI core and Pmod DA3. First, If you look at the Pmod DA3 Reference Manual and AD5541A Datasheet, you can see that the MISO pin is replaced by an "LDAC" input to the chip. Data transferred over SPI is not actually output by the DA3 until this LDAC pin is brought low by the FPGA. Since your block design's MISO port is an input, you don't currently ha
  23. artvvb

    Nexys 4 DDR - UART ERROR

    Hi @AvaTRm Simulating your design is a very good approach to debugging stuff. I ran your file against a simple testbench (written in Verilog and pasted below) in Vivado's simulator. It looks like, (1.) you are not sending a start bit, and (2.), the r_data_indis counter is rolling over before you send the last few bits of your byte (this is why those "1"s are showing up). See the timing diagram below. // uart_sim.v `timescale 1ns / 1ps module uart_sim; reg clk = 0; initial begin #5; forever #5 clk = ~clk; end reg reset = 1; initial begin
  24. Apologies for the late response. From the hardware's point of view, BRAM is placed within the PL itself, and reading from it is both fast and consistent. DDR is also fast, but located off-chip, and the bus to it is shared by PS. This means that if the PS is doing some kind of memory-intensive operation, bandwidth from DDR to PL may be limited. Typically in Zynq applications, DDR memory is dumped to PL BRAMs in bursts, through a DMA controller. When DMAing data, BRAM-based FIFOs are used to ensure that data can be read at the time it is needed. This means that the two approaches could be s
  25. Welcome to the forums! Some comments: You really should simulate this. Even a simple testbench could help you to start identifying potential issues. How are you driving the chip select and serial clock? If the chip select is held low, it may cause the DAC to misinterpret data as 32-bit words, which could cause the DAC to discard the command bits, at least. Because of the counter=0 check, index=0 only lasts for a single clock cycle. Why hardcode the command bits? You have plenty of space left in your slave register. Thanks, Arthur