artvvb

Hi @connoisseur_de_mimi Yeah, the issue is likely that it's a differential buffer. Manual instantiation of the IO buffers isn't necessary. You could just make the entire I2C interface external and constrain the two pins. Vivado will automatically add tristate buffers as appropriate. You can also add pullups through an XDC file with "pullup true" constraints like here: Also, port names for the below screenshot would be "IIC_0_scl_io" and "IIC_0_sda_io". Thanks, Arthur

Yep, the Zybo Z7 doesn't have an I2C EEPROM, inside the FPGA chip or otherwise. If you want EEPROM functionality that isn't based on I2C, look at the QSPI flash. If you need it to be I2C, look for external modules you can connect.

For a start on ethernet, check out this guide for using TCP with Zynq: https://digilent.com/reference/programmable-logic/guides/zynq-servers. That said, 100 MBps is likely too much data for this setup, I'm not certain. In addition to the LwIP example, Xilinx also provides some examples for checking performance. AXI ethernet is not required - it's for interfacing with PHYs that are connected to the PL, whereas the Arty Z7 makes use of the PS ethernet controller, which is enabled by default in the Zynq config. As for interfacing between PL and PS, there are many ways of going about it, depending on throughput requirements. Connecting the IOs of an RTL module to Zynq EMIO pins or an AXI GPIO would be an easy first step, but both have significant data throughput limitations. Creating an AXI interface for the frequency counter is an option, but would be a lot for a beginner. Putting data into an AXI stream interface which forwards data to DDR via an AXI DMA would be the most straightforward solution if you need to move a lot of data, or move data nearly every clock cycle, but again, there's quite a bit involved - DMA audio demos for other Zynq boards, like this one, might be a decent starting point, but would still require quite a bit of learning to implement. Thanks, Arthur

Responded over in another thread, but the gist is that we're unfortunately not able to help much. The SiFive repo that the guide depends on was archived back in 2021, so they may not be much help either.

Hi @shreyash Unfortunately, we can't provide much support for this guide anymore - the sources it clones from were archived as read-only by the third party who created it some time ago. We're looking at either taking down the guide or strengthening the warnings at the top so that others don't run into the same issues you have. Apologies, Arthur

Unfortunately, Digilent generally doesn't provide this kind of consulting service. Thanks, Arthur

Hi @Stefanski881, Interesting. Does the design meet timing? An intermittent failure like this might mean that data doesn't have enough time to make it to the next register. Any related critical warnings and warnings would be helpful. There are likely various small optimizations that could help. Thanks, Arthur

Hi @tew, Apologies for the delay, I reached out to our manufacturing folks and they indicated that the electrical contacts are copper and the plastic is polypropylene. Thanks, Arthur

These connections look plausible for a PS-PS loopback, but the AXI IIC is fundamentally a peripheral of the processor, and the processor is still controlling it. How is your EEPROM instantiated in the FPGA, would it be controlling the AXI IIC S_AXI interface? At that point, it would just be easier to implement an AXI slave that the processor can use to read data from the EEPROM. The EEPROM ought to either be written in HDL and added as an RTL module, or encapsulated in an IP. It could have an I2C interface and connect to IIC_1 on the PS block, but it needs to be represented in the project first.

Oh - that's the HDMI input DDC, not the output. If using that connection, the AXI IIC needs to act as an I2C slave that can provide EDID information to computers connecting to the board, instead of as a master on the bus. Please confirm what physical connection you are trying to make between the board and the outside world. Thanks, Arthur

It looks like HDMI DDC interfaces use one of a couple of different fixed slave addresses, depending on the version of the standard that the particular display implements: https://en.wikipedia.org/wiki/Display_Data_Channel. The block design is likely functional, but I'd need some configuration settings from the IIC IP and maybe Zynq PS to confirm. Constraints also matter, presumably the DDC interface is connected to the correct pins on the HDMI source/TX port. If possible, archiving the entire Vivado project would be ideal. See the attached screenshot That particular IIC software example writes to an EEPROM and reads back to verify. You definitely don't want to be writing to the monitor's EDID. Look for something that only reads. Thanks, Arthur

Hi @Niranjana Please review the section of the reference manual on QSPI flash: https://digilent.com/reference/programmable-logic/zybo-z7/reference-manual#quad-spi_flash This memory can be used both for boot and for user data. Thanks, Arthur

Hi @oldViking Yes, providing clocks, resets, and some logic to control the XADC DRP interface is required from the user. Digilent doesn't provide VHDL for it, but you can see equivalent Verilog in this demo: https://digilent.com/reference/programmable-logic/arty-s7/demos/xadc. The source for the top module is here: https://github.com/Digilent/Arty-S7-HW/blob/9904101ccd8f35003e4a6760a2d500f814d21b73/src/hdl/XADCdemo.v. In the case of this demo the reset is tied low. Thanks, Arthur

Hey Bill, Zynq-7000 is little endian, so the first byte in memory is treated as the least in a u32. The best way to fix it would just be to declare the data to be transferred as the same width you are using in the QSPI, so "u32 buffer[1] = {0xDEADBEEF};". Note that you can see the same effect happen if you print the u8 buffer after casting to a u32 pointer: "xil_printf("status: %08x\r\n", *(u32*)buffer);". Best guess, an 8 MHz sampling rate is insufficient. Run the analyzer faster, and potentially at an integer multiple of the SCLK frequency. At least 4x or ideally 10x the signal's 3.125 MHz. Thanks, Arthur (Edited an incorrect code snippet)

The Zynq preset included in the board files includes all necessary DDR configuration settings, clock settings for the PS, and MIOs. It's applied when you run block automation with the board files installed. This preset is also applied in both of the demos linked previously, one of them could be adapted with different PL IP and constraints modified as needed. Some changes to the Zynq config may be necessary depending on the specifics of the project, like enabling the AXI HP slave ports or setting different FCLK frequencies - AXI HP ports would be necessary for PL access to DDR through DMA, for example.

Yes, I have an AD3 hooked up to some Pmod pins with a different FPGA board - there aren't any fundamental differences between 7-series boards that would affect the IP in this case. This is what a single-shot capture looks like, using the code I sent previously, triggering on protocol start (chip select falling edge). Works on the first pass, using the Vitis debugger to step through the code and only perform one transfer. I don't have personal experience with Saleae devices, so I'm not certain how it is decoding the data, or how it triggers, but make sure that the SPI mode it uses to decode the protocol matches your expectations. Mode is configured in AXI QSPI by setting the XSP_CLK_ACTIVE_LOW_OPTION and XSP_CLK_PHASE_1_OPTION bits via XSpi_SetOptions. By default, clock is active high, and the slave should sample on the rising edge, so SPI mode 0.

Hi Omer, Please refer to https://digilent.com/reference/programmable-logic/eclypse-z7/demos/zmod-scope or https://digilent.com/reference/programmable-logic/eclypse-z7/demos/oob. Thanks, Arthur

Where is the device instance declared? Using it at the same time as the BaseAddress-based low-level API is strange. It would need a LookupConfig/CfgInitialize pair to work.

I'm not too familiar with the lowlevel polled example, which I assume is what you are basing this on. Stripping down the (not low-level) polled example (adding the SetSlaveSelect call), gets something like the following, which is working fine on my system: #include "xparameters.h" #include "xspi.h" void main() { XSpi spi; XSpi_Config *cfgptr; u8 buffer[4] = {0xde, 0xad, 0xbe, 0xef}; u32 status; cfgptr = XSpi_LookupConfig(XPAR_AXI_QUAD_SPI_0_DEVICE_ID); XSpi_CfgInitialize(&spi, cfgptr, cfgptr->BaseAddress); XSpi_SetOptions(&spi, XSP_MASTER_OPTION); XSpi_Start(&spi); XSpi_IntrGlobalDisable(&spi); XSpi_SetSlaveSelect(&spi, 1); while (1) { status = XSpi_Transfer(&spi, &buffer, NULL, 4); } } Thanks, Arthur

Hey @peterhu There are a couple of options, you can flash the device using Vitis or Xilinx SDK (depending on the tool version you're using), or you can boot from an SD card. See this guide: https://digilent.com/reference/programmable-logic/guides/zynq-baremetal-boot. In either case, you would use the boot mode jumper (JTAG/QSPI/SD) to select which source you want to boot the board from. Thanks, Arthur

Hey @baywil, QSPI settings would potentially be helpful, either as screenshots of the configuration wizard or copied from the Block Properties pane's Properties tab (everything in the Config dropdown). Xilinx doesn't specify Fmax for ext_spi_clk for Spartan 7 in the AXI QSPI user guide (https://docs.xilinx.com/r/en-US/pg153-axi-quad-spi/Performance), but you may need to pass it a 50 MHz or slower clock instead, which can further be divided down. 25 MHz may also be too fast for the chipkit header pins. Common settings we've had work for Pmod connectors would be a 50 MHz ext_spi_clk with an x16 frequency ratio (3.125 MHz). Thanks, Arthur

Hi @Niranjana Please check your uploaded image, looks like it didn't come through correctly. Digilent doesn't provide any examples of an I2C slave at this time, but it should be possible to configure an AMD/Xilinx AXI I2C IP, or the Zynq PS itself via EMIO, to act as a slave. There's some info here which may be helpful: https://support.xilinx.com/s/question/0D52E00006hpi0rSAA/zynq-i2c-slave-readback?language=en_US, https://docs.xilinx.com/r/en-US/ug585-zynq-7000-SoC-TRM/I2C-Controller. Thanks, Arthur

Hi @Xband The ZMODADC1410 class is defined in the zmodlib sources https://github.com/Digilent/zmodlib/blob/master/ZmodADC1410/zmodadc1410.h#L82. The hello Zmod tutorial should show you how to import these sources. I'd also double check whether your application is using C++, C and C++ don't necessarily play nicely together in the same Vitis project. Thanks, Arthur

Hi @Razvan1203, I'm unaware of a feature in serial terminal applications like Tera Term or PuTTY that would signal key release events. One option is to put together a custom app or script capable of detecting keypress events and forwarding them to the board over USBUART. A script using the python pygame and pyserial modules would be capable of this. Plenty of guides exist online for getting keyboard input in pygame and sending data to a board via a serial port with pyserial. Alternatively, the Nexys A7 has USB keyboard support via an emulated PS/2 interface that you can use instead of UART. Check out the appropriate section of its reference manual for more information. There's also a demo that shows the use of a keyboard: https://digilent.com/reference/programmable-logic/nexys-a7/demos/keyboard Thanks, Arthur

Hi @OmerKv, Assuming you are using an Opal Kelly SZG-ADC-LTC2264 pod, Digilent doesn't provide example designs for it for the Eclypse, which means that you'd need to port an example design targeting another board (probably some Opal Kelly board) to Eclypse. I would expect that the B7 pin you are looking at is for a demo targeting another board, where the physical pin connections between various peripherals and the FPGA could be different. B7 is likely connected to some pin of the other host board's Syzygy connector. You need to compare the pin locations for the Eclypse and for the other host board, and modify the example design constraints so that the design's ports connect to the physical pin locations for the Eclypse. There could be other issues that come up as you port the design as well, for example, if the example design includes a Zynq PS configuration, you'd need to make sure to use relevant settings from the Eclypse Zynq preset as well as any relevant settings from the example configuration. Clocking architecture and various other things might also differ, depending on the feature sets of the two boards. Thanks, Arthur