artvvb

Technical Forum Moderator
  • Content Count

    284
  • Joined

  • Last visited

  • Days Won

    17

artvvb last won the day on September 8 2019

artvvb had the most liked content!

2 Followers

About artvvb

  • Rank
    Prolific Poster

Profile Information

  • Gender
    Male

Recent Profile Visitors

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

  1. 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"), as seen in the screenshot below: At least when using a Verilog wrapper file, this results in the ports being generated like so: 4. The Pmod RTCC IP core enables the I2C pullups on its IO buffers. This can be done for your own ports in an XDC file like so: set_property PULLUP TRUE [get_ports <port>] Thanks, Arthur
  2. 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
  3. 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 button, BTN0-4 would work. A quick simulation of the module shows that the module should be working properly, assuming that it is constrained properly. I've attached a quick and dirty testbench, as well as a screenshot. Thanks, Arthur `timescale 10ns / 1ps module tb; reg clk = 0; reg reset = 0; initial begin #1 clk = 1; forever #0.5 clk = ~clk; end initial begin #1 reset = 1; #1 reset = 0; end reg rxd = 0; wire [7:0] rxdata; wire led01; wire led02; receiver dut ( clk, reset, rxd, rxdata, led01, led02 ); endmodule
  4. 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 named in the wrapper, basing the locations of the pins on whatever materials Avnet provides. Generate a bitstream, etc. Continue as normal. If you want to go with the QSPI route instead, it may be tricky. Standard SPI mode likely only exposes a single AD1 channel, while dual mode likely requires deinterlacing of the channels' data in software. The AD1 is designed such that data is provided on both pins at once. To use both channels simultaneously, data must be shifted off of both pins, you select a channel by picking which bits to read. See the code block below for a vague sketch of how this works: SPI MISOs: D0: (MSB) An, ... A2, A1, A0 (LSB) D1: (MSB) Bn, ... B2, B1, B0 (LSB) Dual Read Result: (MSB) Bn, An, ..., B2, A2, B1, A1, B0, A0 (LSB) Automatic slave select is likely fine, as long as the number of bits in a transfer is correctly specified (32 for a read of both channels). Thanks, Arthur
  5. 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 the Basys 3. Assuming you have BNC-terminated probes that can be used to connect to a pin on the Basys 3, doing the physical connection should be fairly straightforward. Thanks, Arthur
  6. 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 an issue, check the specifications to see if there may be consequences. This may end up discarding the least significant bit. Thanks, Arthur
  7. 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
  8. 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 manually remove some files to make the application smaller, or you may be able to set some linker settings for the compiler to optimize it as much as possible. Thanks, Arthur
  9. 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, below). Unrelated to your question, but take care to make sure that the block memory that Microblaze is connected to is big enough to fit you application. The drivers we provide are quite large - minimum 385 KB as noted by the Pmod IP guide's compatibility table. Unfortunately this won't fit in the Basys 3's BRAM without some work to reduce their size, or to find some other solution. -Arthur
  10. 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 code. Thanks, Arthur
  11. 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
  12. 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 this post. The project only uses the GPIOs and Zynq preset from our board files. Once you have a specification, you can launch Vitis. In the new application project dialog in the image you posted, if you click on the + button at the top left, you can choose a custom specification for your project. This can be any XSA file that supports the Arty Z7-20, whether you are using mine, or exported your own. If you keep clicking next through the dialog, you are able to choose an application template. This works the same as it did in Xilinx SDK. I have attached a zipped Vitis workspace with a hardware platform and a slightly modified Hello World application. The Arty can then be programmed from Vitis through the Xilinx > Program FPGA dialog, provided that the XSA included a bitstream. The application can be run by right clicking on the system project or application project and clicking Run As > Launch on Hardware. I hope that this provided a decent starting point. Thanks, Arthur vitis_export_archive.ide.zip arty_z7_20_base.xsa Arty-Z7-20-Base.xpr.zip
  13. 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 am working with the template with no other changes, and have not tested this to make sure that it works. EDIT: Note that I am using Vivado 2019.1, there may be some differences in the AXI IP template between versions. File Groups -> Advanced -> Software Driver -> myip.tcl proc generate {drv_handle} { xdefine_include_file $drv_handle "xparameters.h" "myip" "NUM_INSTANCES" "DEVICE_ID" "C_S00_AXI_BASEADDR" "C_S00_AXI_HIGHADDR" "C_S_AXI_INTR_BASEADDR" "C_S_AXI_INTR_HIGHADDR" } File Groups -> Advanced -> Software Driver -> myip.h <...> /****************** Include Files ********************/ #include "xil_types.h" #include "xstatus.h" #define MYIP_S00_AXI_SLV_REG0_OFFSET 0 #define MYIP_S00_AXI_SLV_REG1_OFFSET 4 #define MYIP_S00_AXI_SLV_REG2_OFFSET 8 #define MYIP_S00_AXI_SLV_REG3_OFFSET 12 #define MYIP_S_AXI_INTR_REG_GLOBAL_INTR_EN_OFFSET 0 #define MYIP_S_AXI_INTR_REG_INTR_EN_OFFSET 4 #define MYIP_S_AXI_INTR_REG_INTR_STS_OFFSET 8 #define MYIP_S_AXI_INTR_REG_INTR_ACK_OFFSET 12 #define MYIP_S_AXI_INTR_REG_INTR_PENDING_OFFSET 16 <...> Thanks, Arthur
  14. 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 simulator will take you a long way. Thanks, Arthur testbench.vhd
  15. @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 reducing the number of bytes (stripping out the leading "Pin V" substring for example), or try to increase the baud rate, or something else. -Arthur