artvvb

Hi rehsd, Unfortunately we don't have any examples of doing non-pixel-by-pixel drawing over HDMI at this time. Thanks, Arthur

Yes, the high speed Pmod connector pins can be used for single-ended signals. Section 12.1 of the Cora's reference manual has a little more information on this: https://digilent.com/reference/programmable-logic/cora-z7/reference-manual#high-speed_pmods Thanks, Arthur

Yes. The IP uses the sample clock period parameter internally to compute parameters for an MMCM (the primitive generating the differential clock), if they do not match, DcoClkOut may fall out of spec. The "sample clock" referred to in the IP GUI is ADC_SamplingClock, so for example, a 40 MHz ADC_SamplingClock requires a period of 25000 ps be specified. Thanks, Arthur

Hi @OscarW, welcome to the forum, Unfortunately there isn't a good way of doing this with the board interface, since connecting anything to the pins in the interface will override the connection of that pin to the external port. All three of the i/o/t pins associated with a pmod pin get connected to one IO buffer. If you look at the HDL wrapper's port map, you can see that these three pins are merged into a single "_io" port that is the thing that gets a location constraint applied to it. Additionally, making the entire interface external doesn't solve the issue, since you still wouldn't be able to split out any particular pin. Expanding the interface to make all three of the individual pins you care about external doesn't automatically put in the required I/O buffer, and creates a set of three ports in the wrapper instead of the needed single inout port. I would try to go about solving it by writing an RTL module which can sit in front of the GPS IP that handles instantiating the necessary tristate IOBUFs. You will also need to constrain this module's ports the manual way. I've attached an RTL module, below, which might give a decent start at this, but please note that I've only checked it by validating a block design and not by actually generating a bitstream. I've also attached a screenshot of how it would be wired up in a BD, the Pmod bridge is a stand-in for your Pmod GPS, as is the (empty) "other_logic" module. Thanks, Arthur `timescale 1ns / 1ps ////////////////////////////////////////////////////////////////////////////////// // Company: // Engineer: // // Create Date: 06/21/2022 11:31:12 AM // Design Name: // Module Name: pmod_breakout // Project Name: // Target Devices: // Tool Versions: // Description: // // Dependencies: // // Revision: // Revision 0.01 - File Created // Additional Comments: // ////////////////////////////////////////////////////////////////////////////////// module pmod_breakout( inout pmod_ext_j1_io, inout pmod_ext_j2_io, inout pmod_ext_j3_io, inout pmod_ext_j4_io, inout pmod_ext_j7_io, inout pmod_ext_j8_io, inout pmod_ext_j9_io, inout pmod_ext_j10_io, (* X_INTERFACE_INFO = "digilentinc.com:interface:pmod_rtl:1.0 pmod_int PIN1_I" *) output pmod_int_j1_i, (* X_INTERFACE_INFO = "digilentinc.com:interface:pmod_rtl:1.0 pmod_int PIN2_I" *) output pmod_int_j2_i, (* X_INTERFACE_INFO = "digilentinc.com:interface:pmod_rtl:1.0 pmod_int PIN3_I" *) output pmod_int_j3_i, (* X_INTERFACE_INFO = "digilentinc.com:interface:pmod_rtl:1.0 pmod_int PIN4_I" *) output pmod_int_j4_i, (* X_INTERFACE_INFO = "digilentinc.com:interface:pmod_rtl:1.0 pmod_int PIN7_I" *) output pmod_int_j7_i, (* X_INTERFACE_INFO = "digilentinc.com:interface:pmod_rtl:1.0 pmod_int PIN8_I" *) output pmod_int_j8_i, (* X_INTERFACE_INFO = "digilentinc.com:interface:pmod_rtl:1.0 pmod_int PIN9_I" *) output pmod_int_j9_i, (* X_INTERFACE_INFO = "digilentinc.com:interface:pmod_rtl:1.0 pmod_int PIN10_I" *) output pmod_int_j10_i, (* X_INTERFACE_INFO = "digilentinc.com:interface:pmod_rtl:1.0 pmod_int PIN1_O" *) input pmod_int_j1_o, (* X_INTERFACE_INFO = "digilentinc.com:interface:pmod_rtl:1.0 pmod_int PIN2_O" *) input pmod_int_j2_o, (* X_INTERFACE_INFO = "digilentinc.com:interface:pmod_rtl:1.0 pmod_int PIN3_O" *) input pmod_int_j3_o, (* X_INTERFACE_INFO = "digilentinc.com:interface:pmod_rtl:1.0 pmod_int PIN4_O" *) input pmod_int_j4_o, (* X_INTERFACE_INFO = "digilentinc.com:interface:pmod_rtl:1.0 pmod_int PIN7_O" *) input pmod_int_j7_o, (* X_INTERFACE_INFO = "digilentinc.com:interface:pmod_rtl:1.0 pmod_int PIN8_O" *) input pmod_int_j8_o, (* X_INTERFACE_INFO = "digilentinc.com:interface:pmod_rtl:1.0 pmod_int PIN9_O" *) input pmod_int_j9_o, (* X_INTERFACE_INFO = "digilentinc.com:interface:pmod_rtl:1.0 pmod_int PIN10_O" *) input pmod_int_j10_o, (* X_INTERFACE_INFO = "digilentinc.com:interface:pmod_rtl:1.0 pmod_int PIN1_T" *) input pmod_int_j1_t, (* X_INTERFACE_INFO = "digilentinc.com:interface:pmod_rtl:1.0 pmod_int PIN2_T" *) input pmod_int_j2_t, (* X_INTERFACE_INFO = "digilentinc.com:interface:pmod_rtl:1.0 pmod_int PIN3_T" *) input pmod_int_j3_t, (* X_INTERFACE_INFO = "digilentinc.com:interface:pmod_rtl:1.0 pmod_int PIN4_T" *) input pmod_int_j4_t, (* X_INTERFACE_INFO = "digilentinc.com:interface:pmod_rtl:1.0 pmod_int PIN7_T" *) input pmod_int_j7_t, (* X_INTERFACE_INFO = "digilentinc.com:interface:pmod_rtl:1.0 pmod_int PIN8_T" *) input pmod_int_j8_t, (* X_INTERFACE_INFO = "digilentinc.com:interface:pmod_rtl:1.0 pmod_int PIN9_T" *) input pmod_int_j9_t, (* X_INTERFACE_INFO = "digilentinc.com:interface:pmod_rtl:1.0 pmod_int PIN10_T" *) input pmod_int_j10_t, output [7:0] pmod_pins ); assign pmod_pins = { pmod_ext_j10_io, pmod_ext_j9_io, pmod_ext_j8_io, pmod_ext_j7_io, pmod_ext_j4_io, pmod_ext_j3_io, pmod_ext_j2_io, pmod_ext_j1_io }; IOBUF j1_inst ( .O(pmod_int_j1_i), // Buffer output .IO(pmod_ext_j1), // Buffer inout port (connect directly to top-level port) .I(pmod_int_j1_o), // Buffer input .T(pmod_int_j1_t) // 3-state enable input, high=input, low=output ); IOBUF j2_inst ( .O(pmod_int_j2_i), // Buffer output .IO(pmod_ext_j2), // Buffer inout port (connect directly to top-level port) .I(pmod_int_j2_o), // Buffer input .T(pmod_int_j2_t) // 3-state enable input, high=input, low=output ); IOBUF j3_inst ( .O(pmod_int_j3_i), // Buffer output .IO(pmod_ext_j3), // Buffer inout port (connect directly to top-level port) .I(pmod_int_j3_i), // Buffer input .T(pmod_int_j3_t) // 3-state enable input, high=input, low=output ); IOBUF j4_inst ( .O(pmod_int_j4_i), // Buffer output .IO(pmod_ext_j4), // Buffer inout port (connect directly to top-level port) .I(pmod_int_j4_o), // Buffer input .T(pmod_int_j4_t) // 3-state enable input, high=input, low=output ); IOBUF j7_inst ( .O(pmod_int_j7_i), // Buffer output .IO(pmod_ext_j7), // Buffer inout port (connect directly to top-level port) .I(pmod_int_j7_i), // Buffer input .T(pmod_int_j7_t) // 3-state enable input, high=input, low=output ); IOBUF j8_inst ( .O(pmod_int_j8_i), // Buffer output .IO(pmod_ext_j8), // Buffer inout port (connect directly to top-level port) .I(pmod_int_j8_o), // Buffer input .T(pmod_int_j8_t) // 3-state enable input, high=input, low=output ); IOBUF j9_inst ( .O(pmod_int_j9_i), // Buffer output .IO(pmod_ext_j9), // Buffer inout port (connect directly to top-level port) .I(pmod_int_j9_i), // Buffer input .T(pmod_int_j9_t) // 3-state enable input, high=input, low=output ); IOBUF j10_inst ( .O(pmod_int_j10_i), // Buffer output .IO(pmod_ext_j10), // Buffer inout port (connect directly to top-level port) .I(pmod_int_j10_o), // Buffer input .T(pmod_int_j10_t) // 3-state enable input, high=input, low=output ); endmodule

Booting from QSPI flash, or any other nonvolatile media, works pretty much the same way that booting from an SD card does, and still requires that a first-stage bootloader running in Zynq PS be used.

Hi @vasilistheodo, welcome to the Forum! It looks like the data output stream from the AWG is wired directly to the Scope input stream, without any additional DSP happening? The Scope's high gain input range is ±1V and the AWG's low range is ±1.25V. Thanks, Arthur

The scheme I described above assumes the data in the files ends up stored in BRAM and not on an SD card. The txt files would need to be converted into some kind of intermediate file (like a coe as mentioned above), but what exactly you do with them depends on how you implement your design and on the starting format of the data in the files. It also requires the data to fit in the chip's available BRAM. The SD card slot on the Eclypse is connected to Zynq PS and likely requires mounting a filesystem and reading data from the SD card from SDK software. It's maybe "easiest" to do this within Petalinux, but as stated, requires use of SDK and Petalinux.

The amount of data that can be stored in the bitstream is limited by available on-chip resources. You could, for example, use all of the block RAM memory on the chip, by either using a Xilinx block memory generator IP or by inferring RAMs in your RTL code, then load data into those memories. Data would come from a .coe file in the case of the IP. Inferred RAMs would likely be filled up using readmemb or readmemh if using verilog - there are a fair number of canned examples of doing this around on the web. The Zynq-7020 chip has a total of ~630 KB of block ram available (140x 36 Kb blocks). - EDITED

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