3 : MIO bank 0 is set to 3V3 VMODE (MIO7 pin pulled down to GND with 20k > UG933 table 5-3) and MIO bank 1 is set to 1V8 VMODE, but UG933 says "If the MIO bank voltage is incorrectly set, the I/O behaves unpredictably and damage might occur. An exception to this requirement are temporary Boundary Scan EXTEST operations which require 1.8V MIO banks to use a 2.5/3.3V VMODE setting for correct EXTEST operation". Since MIO bank 1 is set to 1V8 mode, the EXTEST operation won't work correctly on zybo z7 ?
1. Digilent has made the choice not to provide the details about the implementation of this in our boards. You can read more about it some other threads such as these two: -usb-proguart-schematic-request/, -schematic-for-original-arty-missing-usb-connector-and-ftdi-chip/.
DDR3_Vref sources this from a voltage divider (middle of page 10 of the Zybo Z7 schematic), and then the combination of C177 & C179 and C178 and C180 provide further stabilization of this voltage as required by Table 21 and Table 22 of the Micron datasheet. Addtionally, VrefCA and VrefDQ should track any variations on Vcc1V35. So the two equal-value capacitor pairs will represent relatively small impedances for short-term variations from Vcc1V35, effectively forming voltage dividers that cause short-term variations on Vcc1V35 to be tracked by both Vref inputs.
MIO bank 0 is set to 3V3 VMODE (MIO7 pin pulled down to GND with 20k > UG933 table 5-3) and MIO bank 1 is set to 1V8 VMODE, but UG933 says "If the MIO bank voltage is incorrectly set, the I/O behaves unpredictably and damage might occur. An exception to this requirement are temporary Boundary Scan EXTEST operations which require 1.8V MIO banks to use a 2.5/3.3V VMODE setting for correct EXTEST operation". Since MIO bank 1 is set to 1V8 mode, the EXTEST operation won't work correctly on zybo z7 ?
You are correct that the EXTEST operation will not work on the Zybo Z7 as per the note Table 5-3 in UG933 and the corresponding answer record ( =en_US). There is no way to temporarily change the bank voltage on MIO1/Bank 501 from 1.8 V to any other value on the Zybo Z7.
Hello everyone and nice to meet you
I accidentally plugged in the PMOD JE and JD to the pins 19 to 30 and 1 to 12 of my raspberry pi without thinking about it.
Since then the Zybo power led won't light up and won't connect via usb, so i suspect a short-circuit happened on the zybo between JE(6) and the ground from pin 30 of the raspi (although the raspi seems unaffected).
The power LED only turns on when the PG_ALL (power good all) signal from the on board regulator (page 14 of the Zybo Z7 schematic, -logic/zybo-z7/zybo-z7-d1-sch.pdf) is active. The PG_ALL signal then cascades and acts as the enable signal for a lot of other systems on the board including the Zynq SoC, the analog voltage supply, HDMI, etc.
You can check the voltage on a number of the larger capacitors around the regulator (IC25; it's on the underside of the board with the 4 inductors surrounding it) such as the 47 uF capacitors on each of the main output rails (C228 for 3.3 V, C232 for 1.0 V, C237 for 1.35 V, C240 for 1.8 V) and C222 for the 5.0 V source input. If you do end up finding any of the voltage rails non functional, some more debugging can be done to figure out if it is one (or more) capacitors that got fried or if it is the regulator. Replacing the potential multiple failure points will not be an easy endeavor though.
I don't have a Zybo Z7 with me at my home office so I can take a higher resolution picture showing the locations of the components of interest unfortunately.
However, if the FPGA bank 34 that JD was attached to (and received 5.0 V into its pins that do not have any series resistors on) was damaged beyond just the directly affected pins, there will not be anything you can do to recover that (as far as I know).
Thanks a lot for your fast and detailled answer,
I'll check this with my colleagues when we have some time (we bought a replacement one in the meantime so it's not as urgent anymore).
I hope that we'll be able to fix it nontheless...
Thanks a lot and wish you all best,
On the Zybo Z7 resource page there are several project examples. Do any of them use the ethernet port on the board to send and receive data to the programmable logic in the FPGA?. We are doing a project which requires access to the registers and memory in the programmable logic portion of the chip containing our design via an ethernet connection.
Please review this guide, "Getting Started with Zynq Servers", which runs through setting up one of AMD's TCP echo server example: -logic/guides/zynq-servers. This will get data into and out of the PS, after which PS-PL communication can be implemented using EMIO peripherals, AXI IP such as GPIOs or custom modules, or DMA. Digilent doesn't currently provide a demo for the Zybo Z7 that integrates every part of this communication chain.
Substantial UI changes in Vitis 2023.2 have changed much of the specifics of how to work with projects and this guide has not yet been updated. For a detailed rundown of changes, check out Adam Taylor's post about it on the adiuvoengineering blog.
The quoted text is intended to mean that the guide is unlikely to work as written with 2023.2. 2023.1 should work fine as it's what it was written for. We've updated the text in the infobox to be more clear.
Unless you have a particularly power-hungry demo, you can power the board over USB from your laptop - that said, this supply is compatible: -2-5a-switching-power-supply/. You can also program it directly over USB via J12. Installing Vivado should install the drivers that are needed to talk to it. I'd recommend you run through the reference manual and some of the tutorials listed on the board's resource center: -logic/zybo-z7/start.
One issue I keep thinking of is the fact that we have packets that are about 1400 bytes big coming in every 300 hz or so on a serial interface then we have to take them and send it out on the ethernet port. Same going the other say.
I was reading the Zynq 7000 SoC Technical Reference Manual ( -US/ug585-zynq-7000-SoC-TRM/Zynq-7000-SoC-Technical-Reference-Manual) and in there it has the following block diagrams of the Ethernet Controller it seems I don't have access to the buffers but only to the GMII pins that interface, see diagrams below.
What I need to do is grab the packet of data from the ethernet connection and send it to the PL so I can serially send it out. Going the other way, receive the serial data in the PL and send it to the host computer via the ethernet interface. It seems to do that I need to be able to access the AHB port (see diagram 2 below) or at least the buffers if they are big enough to put and grab data from? From what I can see in the second diagram the PL is not able to access that?
I haven't benchmarked the TCP echo server example, but this sounds plausible to implement. Packets for the echo server unmodified might be 1 byte, or however large the software creating the packets makes them (a serial terminal you're typing into seems like it would likely send one byte at a time), but the raw ethernet packets max out only a little smaller than 1500 bytes. This blog post also extends the echo server example to send more than a byte at a time, using a python script on the PC side.
What I need to do is grab the packet of data from the ethernet connection and send it to the PL so I can serially send it out. Going the other way, receive the serial data in the PL and send it to the host computer via the ethernet interface.
Once data is received in the PS & DDR, you could use AXI DMA or a similar mechanism to move it to PL. Note that AXI DMA is an IP that is added to a block design, and not the hard DMAs built into the Zynq PS (which I believe are much less performant, could be wrong). There are various demo projects around, you could check out the Zybo's DMA Audio demo, which uses DMA to move audio data between DDR (where PS can access it) and an I2S interface. I've also written about DMA a fair amount on the forum, this thread being one example:
Have you ever simulated the Zynq server project? Not sure if there is something that would mimic an ethernet connection to the Z7's FPGA that could send data to it and receive it from the board??? Is there something like that around? I am a firm believer of simulating the design before going to the actual hardware.
I have simulated an FPGA using a MicroBlaze, including the DDR3 interface as I found some models of the DDR3 memory we were using. The Microblaze code was put in via a LEF file generated in Vitis. I was never able to run it within Vivado, I used what is generated when I tried doing a behavioral sim and then had my own simulation command script to compile and run.
I downloaded the Audio zip files and followed the instructions for importing the project... however I got the error below. Mind you I am using Vivado 2023.1. Could that be the problem....I cant install every version of Vivado as I had a hard time getting 2023.1 installed due to space issues
I have not. There are some AMD resources on simulating the Zynq PS, but I'm not sure if they cover external HW like Ethernet or if they're primarily for simulating software in conjunction with FPGA gateware.
93ddb68554