Technical Forum Moderator
  • Content Count

  • Joined

  • Last visited

  • Days Won


artvvb last won the day on April 11

artvvb had the most liked content!


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. I am nearly certain that the DRCs are caused by the incorrect settings. It's likely that opening the configuration wizard and following until the end with default settings to regenerate the core would create issues. A MIG for which the configuration wizard has not been stepped through appears to keep its settings from the board file. Looks like you have the correct file. According to appropriate documentation, linked below, you are correct. That said, I am fairly certain that have seen the MIG work when using the default BUFG global clock buffer selection. Recommended MIG settings are provided in the Arty A7 Reference Manual. Further reading on the topic of how the clocking wizard should be set up can be found in this Xilinx Answer Record and on page 95 of Xilinx UG472. (Should note that I am not an expert on this) Thanks, Arthur
  2. Hi @Erick In order for the processor to be able to read data from a module, the module needs to have a memory mapped interface connected to the processor, so that the processor can read or write register data through the addresses that have been assigned to the module's interface. For microblaze, this would (usually) be an AXI interface. This guide should be able to get you started, but is fairly out-of-date, and only handles data written from a processor to an IP. Fair warning, this is a pretty broad topic, and you can find plenty of posts on this forum, and elsewhere on the web, about designing AXI IP, and the common pitfalls you may run into. Thanks, Arthur
  3. Hi @okonomiyonda Some MIG configuration wizard settings terminology: The "Clock Period" setting is the period of the actual clock for the DDR interface. "Input Clock Period" is the period of the clock connected to sys_clk_i. There may be some issues with importing the board file MIG project in 2020.1, the MIG project file specifies 166.667 for Arty A7, while the configuration wizard shows a default of 333.333 (Plus, when selecting the MIG clock pins in IPI, 100MHz frequencies are shown). I can confirm that implementation can be completed with a MIG with default settings, changing only the input clock period to 166.667MHz. It also appears as though the imported .prj file contains the correct InputClkFreq setting, despite what the configuration wizard default shows. I will be looking into this further. It may be worthwhile double checking the imported .prj file against the copy in the board files. Example path to the imported file: arty-a7-100-mig\arty-a7-100-mig.srcs\sources_1\bd\design_1\ip\design_1_mig_7series_0_1\board.prj Input clock buffers should not be used when sys_clk and ref_clk are connected to a clocking wizard. The clocking wizard sets up clock buffers for its output clocks (BUFG by default). The Arty A7's D5 pin is not connected to a clock, and should not be used with the MIG (it is connected to one of the chipkit header pins). The Arty A7 does not include the onboard oscillators that would be required to directly use off-chip clocks to clock the MIG for the Arty's highest achievable DDR speeds. It is possible to directly clock the MIG from the 100MHz clock on pin E3, as with the Arty S7's R2 pin, however, the MIG settings must be changed, and the full 667MT/s rate would not be achievable, due to the clocks internal to the PLL going outside of the FVCO range. The diagram on page 61 of Xilinx UG586 (version 4.2) should help answer other terminology questions. Thanks, Arthur
  4. Hi Tim, Some more info, I've been working on getting the Pmod IPs updated to 2020.1. A working branch is available on GitHub here: So far, I've updated most of the Makefiles on this branch, but have not yet updated the software drivers. Thanks, Arthur
  5. @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: 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
  6. artvvb

    Eclypse Z7 Repository

    @mgberry Thanks for pointing this out. This also affects several nested dependencies of the hw directory (vivado-library and digilent-vivado-scripts). Using git submodule update --init --recursive in the root Eclypse-Z7 directory (instead of submodule init then submodule update) will pick up all of the nested dependencies. I'm looking into getting the appropriate documentation revised. -Arthur
  7. Hi @edge30 Using Vivado/SDK 2019.1, I tested out the Xilinx interrupt mode example for xuartps using a Zybo Z7-20 (I'm working from home, and don't have all of the hardware I would normally have access to). The Zynq PS on this board is functionally the same as the one on the Cora Z7-10. Note that this is the same example project used by the original poster in this thread, and is available through the system.mss file in a compatible project. My block design contains only the Zynq PS with the default configuration from the board files, with AXI GP0 and FCLK 0 disabled. The PL is not used whatsoever. As long as a UART and the GIC are enabled in the Zynq configuration, the PS interrupts should work. The Zynq has two MIO UART peripherals, and the one used differs between the Cora and Zybo presets. The interrupt example project picks up the right device ID from xparameters.h regardless of the UART used, but it looks like the interrupt ID is specified as the one for UART1. As such, XPAR_XUARTPS_1_INTR in the Constant Definitions section of xuartps_intr_example.c likely needs to be changed to XPAR_XUARTPS_0_INTR for the Cora. Documentation, guides, and examples for the Cora can be found linked from its Resource Center on our wiki. Thanks, Arthur
  8. @Paul Chang I can confirm that you are using the correct flow to get the project. There aren't any licensing concerns around either the smartconnect or fifo generator IPs. I may be able to get some more information from the errors in the third image (Windows 10), if you expand the [IP Flow 19-167] error, or if you upload a log file for that project. However, since each of the errors that show up in your screenshots appear to be related to files inside of the Xilinx installation directory, I'd recommend that you reach out to them on their Forums. Apologies, Arthur
  9. artvvb

    UART interface in Zedboard

    Hi @Anji The Zedboard's UART interface is part of the Zynq PS (Processing System). If you are using our board files, then it is enabled by default in the Zynq preset that gets applied through Block Automation. This means that the current design should already be able to receive UART data into the PS. You can use the xuartps drivers in Xilinx SDK in order to receive data. Tera Term has a menu option for transferring files (File -> Send File). The Nexys A7-100T DMA Audio demo uses a similar approach to bring in .wav files to play back through headphones or a speaker, although it uses the MicroBlaze softcore processor instead of Zynq. README, Main C file. I have also found Python's PySerial module useful for this kind of project, as it helps avoid some of the issues that can happen with Tera Term (accidentally pressing keys, difficulty in copying and pasting out of the application). In this case, you open a port and use some straightforward read and write commands to directly send and receive bytes over the UART connection. This hackster article has some potentially useful example code. Thanks, Arthur
  10. @Paul Chang I haven't managed to reproduce this yet. For what it's worth, I also use a Windows 10 system. Thanks for posting the log file. According to this Xilinx Forum thread, there may be some strange issues relating to the AXI SmartConnect that depend on system settings. I have a couple of ideas for things that we could try to work around it. 1. I've attached an archived version of the project, which I checked out on my machine. 2. If (1) doesn't work, it may be necessary to replace the AXI SmartConnect with an AXI Interconnect. This could get a bit complicated, and I am looking into it. Thanks, Arthur
  11. The material I referenced discusses how to recreate an HDF file from the sources. After this, using the demos in baremetal should only require updating the hardware specification for the SDK hardware platform to the new HDF in the SDK workspace in the SW submodule. Using them in Linux requires retargetting the petalinux project (the OS submodule) to the new HDF and rebuilding it (I am less clear on this process, but the Adding Zmod Support in Petalinux guide should cover the relevant commands) - this is only possible in Linux, due to the Petalinux installation requirements. The OOB is the source for the demo programmed into flash during manufacturing. It's really barebones, but is intended to be enough to know that the Zynq can be programmed and actually works. There is currently some duplication of these sources between the OOB branch/es of the Eclypse-Z7 repo and the Eclypse-Z7-OOB repo - I am looking into resolving this. -Arthur
  12. 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
  13. 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
  14. 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
  15. 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