artvvb

Technical Forum Moderator
  • Content Count

    333
  • Joined

  • Last visited

Reputation Activity

  1. Like
    artvvb reacted to skinnypanda in how to create a block ram in zedboard, vivado 2020.1?   
    awesome! thanks!
  2. Like
    artvvb got a reaction from skinnypanda in how to create a block ram in zedboard, vivado 2020.1?   
    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

  3. Like
    artvvb reacted to rmccormack1 in Makefile:38 Error 1 in Vitis   
    I figured out thank you.
  4. Like
    artvvb got a reaction from RichardV in Does QSPI support legacy SPI devices?   
    Hi @RichardV
    Could you clarify what you mean by "the QSPI port"?
    You can create your own SPI controller and have it use any of the Cmod's IO pins - constraining the pins with an XDC instead of through the board files. The AXI QSPI IP can similarly be connected to various external pins, on the Pmod port, breadboard connector, pretty much wherever (but should be used with a Microblaze processor). You can configure the AXI QSPI to work in standard SPI mode (SPI Options: Mode = Standard instead of Quad).
    Thanks,
    Arthur
  5. Like
    artvvb reacted to helloworld1029 in [ZYBO Z720] External Sensor connect to XADC   
    @artvvb
    Thanks so much, I think I have managed to solve this issue, since I can see the real-time voltage value when I insert the measuring sensor into the solution. 
     

  6. Like
    artvvb got a reaction from Marycruz in Zybo processing image   
    @s223523
    I've done a few (less complex) VGA projects before, I don't have any exact examples online at the moment to send you to, but this would be my suggested route:
    In Vivado, you can instantiate two of Xilinx's Block Memory Generator IP cores in your project and hdl code, set up as Single Port ROMs with a COE initialization files. You can then stream data out of these ROMs to look up specific pixels in your images, depending on where the screen pixel horizontal and vertical count is - the specific math will be nontrivial and depend on your game logic - and then use these pixel values to select specific colors to put out over the VGA connection. This all assumes that you have the COE files to plug into the BRAM, creating these files will likely require a script or program of some kind running on your PC to convert PNG images to the COE format. A simple example of the COE format showing a 4x4 checkerboard pattern with a 2 bit address and 4 bit data would be below:
    memory_initialization_radix=16; memory_initialization_vector 5,A, 5,A; You might try finding a PNG python library, or something else you would be more familiar with for doing this conversion.
    As for instantiating the Block Memory cores, you might be able to refer to how the charLib core is used in the Nexys Video XADC example project - created in verilog, but the fundamentals are similar enough in this case. To create your own IP from scratch, you would use the IP Catalog window in Vivado (located under the Project Manager tab) and search for "block memory generator". This will pop up a "Customize IP" window, in which you will likely want to change things to be a "Single Port ROM" with Port A width and depth of your choice, no primitives output register, "always enabled" port type, and to load an init file to be the COE that you would have previously generated. These settings changes from default will get you a Port A read latency of 1 clock cycle (giving you two clocks to compute the address, one to look up data, and one to compute color, if you are running the VGA controller at 100MHz and the VGA at 25) and only the addra, clka, and douta ports. You can click the plus on the BRAM_PORTA interface on the image at the left of the window to check all of the exact port names your instantiation will require.
    Hope this helps,
    Arthur
  7. Like
    artvvb got a reaction from davec in Using an SPI device with ARTY board   
    Hi @davec
    I don't see anything wrong with your hardware design or the board files. So I spun up a similar design with port J6, working from the polled_example (Vivado/Vitis 2020.1 and version 4.6 of the xspi drivers). Debugging the modifications showed a problem where XSpi_Transfer was silently failing when checking if a slave was selected in the driver, and finding none. Make sure you are calling XSpi_SetSlaveSelect. See my main.c, below.
    #include "xspi.h" #include "xparameters.h" #include "xil_printf.h" #include "sleep.h" int main() { xil_printf("Hello World!\r\n"); XSpi device; XSpi_Config *pcfg; pcfg = XSpi_LookupConfig(XPAR_AXI_QUAD_SPI_0_DEVICE_ID); XSpi_CfgInitialize(&device, pcfg, pcfg->BaseAddress); XSpi_SetOptions(&device, XSP_MASTER_OPTION); XSpi_Start(&device); XSpi_IntrGlobalDisable(&device); XSpi_SetSlaveSelect(&device, 0b1); u8 bytes [4] = {0xDE,0xAD,0xBE,0xEF}; while (1) { XSpi_Transfer(&device, bytes, NULL, 4); usleep(1); } } Hope this helps,
    Arthur
  8. Like
    artvvb got a reaction from bobsmith in Arty Z7 peripheral connections   
    @bobsmith
    The Arty Z7's Reference Manual (Basic I/O and Shield Connector sections) and Schematic (sheets 1, 2, and 9) have information on how these components are connected.
    All four buttons are connected to pins on FPGA Bank 35 with resistors to pull down the pin while the button is open, and protect the FPGA pin from the voltage rail while the button is closed. IO pins 0-13 are connected to FPGA Bank 34 via current limiting resistors.
    The buttons can be noisy, so it may be worthwhile to debounce their signals, if you are not doing so already. Checking the debouncer output on an LED, or creating a simple toggle circuit to control an LED from a button could also be useful in figuring out if the buttons states are being captured as you expect.
    Edit: a coworker pointed out this Xilinx forum thread: https://forums.xilinx.com/t5/Implementation/Poor-placement-for-routing-between-an-IO-pin-and-BUFG/td-p/784930
    There is some additional information in there about what the warning related to BUFG is about. Some pin may be being misinterpreted as a clock or a reset by the tools, which is causing the poor placement. I'd recommend checking your design's edge sensitivities - in Verilog, [email protected](..., posedge btn) would be bad, for example.
     
    Hope this helps,
    Arthur
     
  9. Like
    artvvb reacted to elodg in Bug in the file "board.xml" (Nexys 4 board support files)   
    We need to do a pull request to XilinxBoardStore to update the board definition files there. Until then, you can try pulling in the most recent files manually.
  10. Like
    artvvb got a reaction from amkichu in PmodRS485 on Zybo   
    @Notarobot
    To add to what Jon has already said, I believe you will need to either try to use either the UART16550 IP Core or an AXI GPIO controller along with the basic AXI UART core in order to control the RTS and CTS pins of the PmodRS485. Controlling these pins appears to be required for transmitting and receiving data. Which of the above IP cores you use will depend on whether the RTS and CTS pins need to be switched in the middle of a transfer (I don't believe so, but am not positive). If you need control of the pins during transfer, you should use the UART16550, as it contains equivalents that you could also constrain by making each of the individual ports you need within the interface external, rather than making the entire interface external. Otherwise, making a 2 bit wide, single channel, output only GPIO controller should suffice. I'm not as familiar with the control-from-Zynq option, but something similar to the above should still be feasible.
    Hope this helps,
    Arthur
  11. Like
    artvvb reacted to Phil in I2C tristate pins without board definition files   
    @artvvb
    Arthur, thanks for the detailed reply.  This is the information I needed to move forward.  My HDL wrapper is Verilog, which threw me off when I got the error messages about VHDL.  In the top level settings the target language is set for Verilog.  I'm not aware of another setting somewhere that would affect this.
    From the example you provided, when the IIC port is made external and the HDL wrapper is updated to account for this, I did not realize before that the IOBUF buffers were instantiated and that the _io signals are then made available to make my pin assignment in my .xdc file.  This is the information I needed and I can see how the tristate is being handled.  I have tested this by assigning pins on different connectors than the ones pre-defined for I2C and PMOD in the board definition files.  After adding the pullup constraints it all works fine and I can now use other available I/O pins.
  12. Like
    artvvb reacted to Arty7_Lover in Vitis HW Platform in Arty7-20   
    Thanks, a lot.
    Your kind and easy answer is greatly helpful to me.
  13. Like
    artvvb got a reaction from Arty7_Lover in Vitis HW Platform in Arty7-20   
    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
  14. Like
    artvvb reacted to Mosi_513 in Working with DA4 PMOD on Nexys4   
    Thanks a lot Arthur,
     
    I am a beginner in Vivado so I didn't know about its simulation tool. I have now used it and solved most of the issues in the code and got the PMOD DA4 module to run correctly. I have attached the working file here in case someone else needs it.
     
    Thanks,
    Mohsen 
    DA4_v11_working.vhd
  15. Like
    artvvb got a reaction from johnsan1 in Can I get more accurate readings in Tera term?   
    @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
  16. Like
    artvvb reacted to johnsan1 in Using tera term for two pmods   
    Hello,
    Sorry this is a bit late, but yeah this is basically what I did and it worked. Thank you so much!!
  17. Like
    artvvb got a reaction from johnsan1 in Using tera term for two pmods   
    Hi @johnsan1
    As there is only one UART link between the PC and your board, you cannot use more than one instance of Tera Term.
    I am assuming you have a Vivado block design containing two Pmod AD2 IP cores.
    The provided SDK example code only configures and reads from one AD2. In order to view samples from both AD2's at the same time, you must edit the example code to configure and control both AD2s and print data from both out over the serial interface. A starting point would be to add a second device driver instance to the code by editing line 44 of the example code as follows:
    PmodAD2 myDevice_JA, myDevice_JD; Thanks,
    Arthur
  18. Like
    artvvb reacted to aadgl in Arty A7, DMA from FPGA memory to DDR memory?   
    Hi artvvb,
    The Nexsys board looks nice.  The demo does drive a speaker, but wasn't the right starting point for my project.
    I have since adapted from these examples:
    > http://www.fpgadeveloper.com/2014/08/using-the-axi-dma-in-vivado.html
    > https://www.xilinx.com/support/answers/57562.html
    The first gets a Zynq block diagram setup and the second has the C code.
    The second is referenced from this page that has three other examples, including interrupts.
    > https://www.xilinx.com/support/answers/57550.html
    These examples are good to get going, need significant work (including bug fixes), but do have enough working to get started.
    A month later I have several Zynq versions of Stream/FIFO/SimpleDMA working, one running 250 MB/sec.  I have also adapted the Zynq work to Artix. Lots of twists and turns along the way, but doable.  Your "general thoughts" were helpful.
    Thanks,
    Dave
     
  19. Like
    artvvb reacted to zygot in Using tera term for two pmods   
    Well I think that this is better stated as saying that most serial terminal applications can only connect to one COM port at a time. It is possible to mave multiple UARTs in your FPGA design and connect to multiple serial terminal applications. I like Putty myself, but there are other options.
    Another possibility is to look around in the Digilent Project Vault and see at least 3 project with source code that might accomplish what you want to do. If you instantiate your own UART you can access any number of internal registers or memory.
  20. Like
    artvvb got a reaction from tekson in Generating project failed   
    @kriob
    The TMDS interface can be found in the HDMI project's /repo/vivado-library/if subdirectory, the IP repository is supposed to be added when create_project is run, but this appears to be a difference between 2016.4 and 2017.2. You can add IP repositories manually through the project settings dialog, if 2017.2 has kept this dialog consistent, then you can go into the IP pane and select Repository Manager.
    As for the launch runs error, you will also need to manually create an HDL wrapper for the block design. In the sources tab, right click on the block design and select "Create HDL Wrapper".
    EDIT: Whoops, mistook the two of you...
    I will be releasing a fixed version of the project on Github within the next few hours...
    Hope this helps,
    Arthur
  21. Like
    artvvb got a reaction from johnsan1 in "#include "sleep.h"" error   
    Hi @johnsan1
    Microblaze does not support sleep.h in some older versions of Vivado. A nearly equivalent set of functions can be found in microblaze_sleep.h, though it may not include microsecond sleeps.
     
    Thanks,
    Arthur
  22. Like
    artvvb got a reaction from jpeyron in Accessing GPIO through PS   
    Hi @HasanWAVE
     
    Pin 14 won't work with the Arty Z7, as it corresponds to MIO 14, which is connected to the UART on the Arty Z7, rather than a button or switch.
    The Arty Z7 doesn't have any switches/buttons/LEDs connected to the Zynq's MIO pins. This means that to use the PS GPIO, you need to enable GPIO EMIO (extended MIO), which routes its signals through the PL. This allows you to connect and constrain the EMIO GPIO pins as you would any other GPIO interface in the IP Integrator. Unfortunately the EMIO can't be connected to the components in the board files, however, you can still make the EMIO GPIO bus external and constrain its pins with an XDC file.
    The EMIO GPIO is enabled through the Peripheral I/O Pins screen when re-customizing the Zynq block. You can then set the width of the bus through the MIO Configuration screen, under I/O Peripherals / GPIO.
    For SDK, the xgpiops pin numbers associated with the EMIO pins are assigned in ascending order above all of the MIO pin numbers - so, in the case of having only an EMIO GPIO interface with a width of 4, the pin numbers are 54, 55, 56, and 57. Note that the first 32 EMIO pins use the bank number 2, and that the way that the interrupt example creates the interrupt enable bit mask passed to XGpioPs_IntrEnable doesn't work with pin numbers greater than 31. I've attached a modified version of xgpiops_intr_example.c in the spoiler below that works with button 0 of the 4-button GPIO EMIO as described above.
    If you want more depth, there's some more information and references to Xilinx documentation in this thread from the Xilinx forums.
    Thanks for the question!
    -Arthur
  23. Like
    artvvb got a reaction from Azzor in Zybo Z7 Pcam 5C Demo - Warnings   
    To add a little bit to what Jon said, these warnings appear to be ignorable. They all relate to design choices made when connecting custom IP in the block design.
    Typically, even when designing with Xilinx IP, many warnings are seen in the project. These messages are there to help get information on why something may be causing bigger problems later (errors, critical warnings, something not working in actual hardware). Note that even some critical warnings may be ignored.
    -Arthur
     
  24. Like
    artvvb got a reaction from jpeyron in Zybo Z7 Pcam 5C Demo - Warnings   
    To add a little bit to what Jon said, these warnings appear to be ignorable. They all relate to design choices made when connecting custom IP in the block design.
    Typically, even when designing with Xilinx IP, many warnings are seen in the project. These messages are there to help get information on why something may be causing bigger problems later (errors, critical warnings, something not working in actual hardware). Note that even some critical warnings may be ignored.
    -Arthur
     
  25. Like
    artvvb got a reaction from jpeyron in Axi DMA from all memory   
    Hi @Rickdegier,
    Welcome to the Digilent forums!
    I am not the most confident on this topic, but I have used the DMA some. The most important facet here is to make sure that your buffer is actually contained in the DDR memory. Different parts of the program can be placed in different memories using the linker script in your application project's src folder (lscript.ld). You should check that file to make sure that your global arrays are placed in the DDR. Second, if the data cache is enabled (likely), you should make sure to flush and invalidate the buffer memory area around your SimpleTransfer calls (functions to do this are in xil_cache.h). Lastly, I personally have had more success using malloc to create my buffers than using global or local arrays - I'm not sure why this is, from a cursory google search, it looks like the DMA will allow transfers into program memory when you aren't careful. You may want to reach out to Xilinx on their forums.
    Thanks,
    Arthur