artvvb

You may need to use SDK exclusively for a bootloader, either omitting an application elf file from the boot image or using the simplest one it's possible to create, like a Hello World example.

Reprogramming the FPGA whenever you launch a project for JTAG debugging or just to run the project from SDK in general is pretty normal in my experience. If you wanted to, you could disable FPGA programming in your Run Configurations - Go to Run->Run Configurations in the top menu, then find and uncheck the reset entire system and program FPGA boxes, see the screenshot below. However it is then the responsibility of the application project to return all of the hardware devices implemented in FPGA fabric to a known state - potentially requiring PS to perform software resets of any peripherals in the system that require it - this functionality hasn't necessarily been implemented in demos you may be working with. You'd also need to use the Xilinx->Program FPGA menu option to load the bitstream before running software. Later down the line, you can also create a boot image including your bitstream, application ELF file, and a first stage bootloader to boot the project from SD or SPI Flash. See here: https://digilent.com/reference/programmable-logic/guides/zynq-baremetal-boot Thanks, Arthur

In published software demos, the 14-bit data bus is connected to the Zmod AWG/DAC low-level IP, which provides an AXI4-stream interface through which data is sent. There is no PS-connected register which would bypass the DMA, high level IP, or the AXI4-stream interface. The base addresses you see in software correspond to AXI peripherals that are connected to the PS, not necessarily any register in the PL. You will be limited by the capabilities of whatever is implemented in the FPGA fabric. The manual for the Zmod DAC AXI Adapter can be found on the Zmod AWG's resource center, or through the IP configuration wizard in Vivado - the latter will get you the most accurate version of the manual for the version of the IP you are working with. Double-click on the IP you want to see documentation for, and in the window that pops up and check the top left corner for a "Documentation" dropdown. In short, sending data directly to the data bus without going through the data paths implemented in the hardware platform you have access to would require you to modify the hardware platform by modifying the Vivado project, which is not necessarily a simple process. You could potentially get direct access to the AXI4-stream interface and develop an HDL module to generate data and send it to the port by adapting the Low-Pass Filter demo, which instantiates the low-level IPs without any connection to the PS, however this would mean you would not be writing software for the PS at all, and would be working primarily in RTL. Thanks, Arthur

I've suggested to our web team that we cut this from all applicable feature lists. Thanks, Arthur

I'm assuming you're referring to the "factory programmed 128-bit random number" placed in the OTP region of the Eclypse's SPI Flash, please correct me if I'm wrong. This is not a random number generator, but rather a unique identifier programmed into the flash chip by Spansion, which is intended as a security feature. It allows a host board to compare an expected ID against one read out from the flash to detect if someone has switched out the flash chip. None of Digilent's demos use it. Thanks, Arthur

The baud rate is 115200 by default in all projects Digilent has released - this was previously omitted and is now specified in the demo documentation. The username and password are only required if using the PetaLinux image and associated demos, but you can find instructions for setting up either those projects or the baremetal ones here: https://digilent.com/reference/programmable-logic/eclypse-z7/demos/zmod-awg https://digilent.com/reference/programmable-logic/eclypse-z7/demos/zmod-scope The baud rate is typically specified in the Vivado project's Zynq PS configuration. It may be possible to change from software through the use of some configuration register associated with the PS UART core, however, I haven't verified that this is the case. Thanks, Arthur

Hi @HEM, Welcome to the forum! What errors are occurring when you try to generate a bitstream? Thanks, Arthur

For others that might run across this, this question has been responded to in this other thread:

Attached are xparameters files pulled out of the DAC1411 baremetal demo BSP, from the zmod_adc_dac/master branch of the git repo - if you are trying with a different branch or a different commit, then these copies of the files may differ from what is needed, since the addresses and other configuration parameters must match the hardware design that got built into the bitstream. xparameters_ps.h xparameters.h There's a fair chance that other important files that come from the BSP may also be missing... The xaxidma driver is one example that comes to mind. If you are able to open the Vivado project, after generating a bitstream, an HDF can be exported and a fresh workspace can be created by following steps found in this guide, starting around 5.1: https://digilent.com/reference/vivado/getting-started-with-ipi/start From there, the demo sources would need to be added to the freshly-created application (assuming SDK doesn't crash...). Zmodlib is able to be included in the src directory by adding the include paths shown in the screenshot below to the compiler's Directories. This screen is accessible through the Properties option that shows up when right clicking on an application.

Hi @jt123 Assuming you're working with SDK or Vitis, you will need to package a first-stage bootloader, bitstream, and application elf file into a boot image and load it into flash or onto an SD card. You can find some instructions here: https://digilent.com/reference/programmable-logic/guides/zynq-baremetal-boot Check the board's reference manual for information on how to change the boot mode from JTAG to SPI or SD card boot. If your project is hardware only, you'll need to load the bitstream into flash through Vivado's hardware manager. Thanks, Arthur

Hi Tibor, Primarily, the flash part changed, and may have one of two different parts loaded on the E.2. Refer to the Flash Memory PCN found here: https://digilent.com/reference/programmable-logic/arty-a7/start#documentation Thanks, Arthur

Hi Tibor, The Arty A7 100T Rev E has the same pinout as the Rev D, so the XDC file for it on Github, link below, is compatible. I've updated the file to indicate this. https://github.com/Digilent/digilent-xdc/blob/master/Arty-A7-100-Master.xdc Thanks, Arthur

Oh I see. The xparameters file is required, as it contains all of the definitions of various IP parameters and all of the base addresses for the different AXI-connected modules in the hardware design. It is automatically generated and is specific to the hardware platform used. It would be extremely painful (nearly impossible) to write by hand. It being missing suggests that the hardware platform could be somehow misconfigured, or that the application project is not pointing to the hardware platform and BSP in the right way. There are a few things that might work for getting it up and running, but it might require setting the workspace back up from scratch: opening SDK into a new workspace, creating a hardware platform targeting the same HDF file, and a fresh application project that imports the all of the sources, and configuring the compiler include paths in the app's C/C++ Build settings to account for any subdirectories of the app's src directory that contain sources that will be used. I'd really recommend using the instructions for recursively cloning the projects via git if at all possible. Thanks, Arthur

Yes, the tutorial is generic, supporting multiple boards, and the Nexys A7's master XDC file had the reset button mixed in with the rest of its buttons. This is unlike any of the other boards the tutorial supports, which was missed when the tutorial was written. The file that was changed was the master XDC file, found in the digilent-xdc repo. The tutorial doesn't link to directly to github, but includes a download link for a ZIP file that comes from there. Thanks, Arthur

Hi @Rochus The critical error indicates that two ports have been constrained to use the same pin location, which is not allowed as it could result in problems like nets being driven by multiple sources. Timing issues that arise while the location constraint issue is present won't necessarily indicate any issues with the final design - the tool could be trying to do something weird to fix an otherwise untenable situation. In short, you need to use any of the other buttons on the Nexys A7, because the CPU_RESETN port is the same one that is connected through the "Reset" board interface. I've split the Nexys A7's CPU reset button out from the rest of its buttons in the Github repo, to better indicate that this button is different, so that this error will be more easily avoided with new downloads of the digilent-xdc-master ZIP. Thanks! Arthur

hi @atown622 Per this note in the base library user guide, the zmodlib folder is not populated as it would be when cloning recursively using git. Github does not automatically include submodule sources in ZIP downloads, which is why the document recommends cloning. You can download the necessary contents of the folder from the zmodlib repo here: https://github.com/Digilent/zmodlib/archive/f2f491971aa43fa23d3d2a1d6640d6f97ad69318.zip This is the download for a specific commit pointed at by the Eclypse-Z7-SW repo's zmod_adc_dac/master branch, which is currently on commit 4aa5430 at time of writing. In future, the download would always be able to be found through the submodule link here: Thanks, Arthur

hi Vikram, The IP in this download were packaged with Vivado 2016.4, and are locked until you upgrade them - Vivado ships with only the most recent version of any particular IP core used. Upgrade the IP by navigating through Reports -> Report IP Status -> Upgrade Selected, as below. Since the affected IP only increment the minor version, no port name changes (that would require modifications to verilog sources) should be present. I've verified that (despite the language server freezing and requiring me to kill and restart the 2022.1 instance) a bitstream can be generated after doing this. Thanks, Arthur

To add on to what zygot has already said, the override register also requires information from the DNA, and PMCU firmware does not allow values to be set which fall outside of the bounds specified by connected pods. From the PMCU spec: Thanks, Arthur

Hi @kadri, Welcome to the forums! XGpioPs_SetOutputEnable accepts a bank number instead of a pin number. Use the following instead: XGpioPs_SetOutputEnable(&my_Gpio, 0, 1); Debugging the program shows an assertion firing when you try to step past the SetOutputEnable call. By stepping into this call, it can be seen that the following line is where the assertion occurs: Xil_AssertVoid(Bank < InstancePtr->MaxBanks); Thanks, Arthur

Hi @Jonno, welcome to the forum! The Nexys A7 reference manual states, in referring to how to handle the ADT7420's temperature value register: The TempSensorCtl file is already effectively performing the right shift by three, which discards some extra flag bits present in the temperature value registers. I'd first extract the sign bit, and convert the data to unsigned. The multiply by 0.0625 described could be performed by treating the unsigned data as fixed point, and shifting the point. Converting fixed point numbers to BCD is a little more complicated than unsigned integers to BCD. There's a good discussion of it here: https://electronics.stackexchange.com/questions/320416/how-to-break-multi-digit-number-into-separate-digits-in-vhdl Lastly, a seven segment display controller that can handle the sign bit and decimal point would be needed. Hope this helped, Arthur

The VADJ rail is automatically set by the Eclypse's platform MCU when the board is powered on. You can find more information on this in section 3 of the the PMCU Specification document: https://files.digilent.com/resources/programmable-logic/eclypse/Eclypse-PMCU-Specification-Public.pdf The rails can be further configured after the fact by using decutil from the Linux images to communicate with the PMCU. The command manual for decutil can be found here: https://digilent.com/reference/_media/reference/programmable-logic/eclypse-z7/decutil.1.pdf Thanks, Arthur

That was pretty vague on my part, apologies. I should have said that XPR and workspace files which can be opened in Vivado and Vitis 2020.1 exist, however, I haven't personally had the opportunity to check whether their documentation is accurate to the steps needed to get them running. The documentation may be incomplete and the projects may be buggy. I'm looking into it. It looks like you downloaded the "Source Files" zip on Github which does not contain sources as you noted. The correct downloads should be the -hw.xpr.zip and -sw.ide.zip files, as pointed out in the release description. I'll be updating these reference pages to make sure that they point directly to the file downloads, as opposed to the GitHub page, as the use of the releases page has definitely been confusing.

Hi Vikram, welcome to the forum. Xilinx officially supports the following versions of Windows in 2022.1: Microsoft Windows Professional/Enterprise 10.0 1903 Update; 10.0 1909 Update; 10.0 2004 Update: 10.0 20H2 Update; 10.0 21H1 Update Home edition may still work, this just means they haven't tested with it. As for Vivado, ML Standard Edition will work with the Nexys Video, however, you should be aware that the example projects Digilent provides may or may not be supported. The most up-to-date (but still marked under construction as they haven't been fully tested) materials, supporting Vivado 2020.1, can be found here: https://digilent.com/reference/programmable-logic/nexys-video/demos/start Hope this helps, Arthur

Hi @pablo_gatearray The additional clocking wizard was in there solely in case I wanted to tweak the clock frequency later. It's easier to change a clock frequency output by a clocking wizard than it is to run through the MIG wizard. Additionally, there are some bugs in the MIG wizard in some versions of Vivado where some settings pulled in from the PRJ files aren't necessarily visually shown in the default settings of the wizard, which makes it really easy to mess up a design when using the wizard. Using ui_clk or a ui_additional_clk to drive the Microblaze works fine, and the clocking wizard is not necessary. Thanks, Arthur

Hi @Eran Zeavi, Try this tutorial instead: https://digilent.com/reference/programmable-logic/guides/getting-started-with-ipi Xilinx replaced SDK with Vitis starting in version 2019.2. You might also need to go back and install Vitis through Vivado's "Help -> Add Design Tools and Devices" menu, which reruns the installer. Thanks, Arthur