artvvb

Hey @fenixzhang,
The Zentel and Micron parts are effectively drop-in replacements that don't require any changes to Vivado projects, so you can use existing materials like the Zynq preset in the board files as-is. That either part might be loaded isn't mentioned in the reference manual and we'll be sure to add some text to call it out. Apologies for the confusion.
Thanks,
Arthur

Hi@fenixzhang
As asmi mentions, you don't need to select the part yourself. Block automation handles it for you by applying a Digilent-provided preset, which also requires using Digilent board files and a block design (if you really don't want to use IPI, there are likely still workarounds for pulling the provided parameters over). The preset also pulls in some other critical parameters like the delay introduced by PCB trace lengths. Do note that using the preset will result in some critical warnings related to those delays, caused by some changes in Xilinx's recommendations since the board was originally designed - these can be safely ignored.
Thanks,
Arthur

For using IPI, instructions are in here, you run block automation after adding the Zynq PS to the block design, and make sure the apply preset box is checked: Getting Started with Vivado and Vitis for Baremetal Software Projects
Without IPI, it's more complicated, and requires a file that you would need to export from the Zynq config with it loaded in IPI, which is where asmi's suggestion comes from - which we'll consider, I think it's a good idea.
Thanks,
Arthur

You might want to consider uploading a Zynq preset (.tcl file) for those who don't want to use the board files for some reason, as that preset file will let them configure Zynq to the board specification. If you open Zynq's IP dialog, there are options to save/load presets, that's how you can generate this file.

Hi @Nicolas Deup
You could use a global custom measurement like this to be very precise:
const thr = Scope.Trigger.Level.value; var ch1 = Scope.Channel1; var ch2 = Scope.Channel2; var data1 = ch1.visibledata; var data2 = ch2.visibledata; var cnt = data1.length; var i1 = 0; for(; i1 < cnt; i1++){ if(data1[i1]>thr) continue; i1 = i1-(data1[i1]-thr)/(data1[i1]-data1[i1-1]); break; } var i2 = 0; for(; i2 < cnt; i2++){ if(data2[i2]>thr) continue; i2 = i2-(data2[i2]-thr)/(data2[i2]-data2[i2-1]); break; } (i2-i1)/Scope.Time.Rate.real;
 
Other similar posts with digital data.
 

Hi Arthur,
Thanks for the reply and answer! Yes, this meets the bill perfectly. Interesting that my version of Waveforms BETA (latest as of this writing), is a tad different then yours. I had to use DIO24/25/26/27. BTW, it looks like the default for DQ0 was 25 instead of 26. Also, without custom programming, can I remove the dummy value from the display?
Data: b11111111 | b00000000, b11111111 | b11111100, b11111111 | b00010011, b11111111 | b11000000,
the 0xff is the default dummy SPI value from the Micro SPI...
it would be nice to get just the 4 8-bits
Data: b00000000, b11111100, b00010011, b11000000,
 
ALSO, funny enough, I've been using 0xDEADBEEF since the 80's when I starting in C and needed magic numbers...😁
thanks again,
 
~Kam
 

Hey Daniel,
I'm looking into this and should have something in a day or two.
Thanks,
Arthur

Hi @JimR2 @artvvb
The sync mode implementation can capture up to one sample per system clock, default 100MHz.

HI @engrpetero,
Kvass is correct. Here is a post describing the process in a bit more detail (for a non-zynq board but the general process is the same):
And this post has some basic Vitis code that does external UART loopback (PC -> board -> external loopback to board -> PC) for a different Zynq based board
Thanks,
JColvin

This issue has since been fixed in the Digilent board files in version 1.1 of the Zedboard board files, which can be found in the vivado-boards repo on Github: https://github.com/Digilent/vivado-boards
Thanks,
Arthur

I forgot about the fact that the ADC converters on the ZMODs can be programmed to output a reference signal instead of conversion data. In fact, I'd recommend that the first objective of anyone wanting to implement their own ADC capture design start off using this capability to verify connectivity between their design and the ADC device. In addition, no external signal is required. That means no offset or gain scaling is required. It's a good starting point for working with the signed output code of the converter. If you can't properly interpret the ADC test output, then trying to work with actual conversion data is going to be a rough ride. Before you hop on top of a real bull you might want to try a few practice runs on a mechanical bull at the local tavern. Similar concept for FPGA development.

Thanks Arthur @artvvb,
 
Thanks to your coworker and team too.
 
I tried with 18 Ohm and now it is working fine.
 
I really appreciate you and your team's hard work and zeal to solve the issue.
 
regards,
Manan

Hi.
So out of fun, I tried to make ChatGPT spare me a half an hour coding today. It responded like this:

However, I've never came across such a package. Could not find it on the internet as well. Confronting ChatGPT with this, it came up with an explanation and a way more realistic code:

So, dear Digilent Support Team. Do you really have an internal package called waveforms_live that ChatGPT knows about somehow or is it just a hallucination like so often when asking ChatGPT specific stuff?
 

Good info, thanks. For what it's worth, there are also some pretty gnarly GUI bugs that started showing up in the MIG at some point where it wouldn't keep the previous settings when you go in to change things. I'm not sure if Xilinx has fixed it or not (had seen it some time around the early 2020 versions), but I expect not. The Arty S7 had a bunch of related issues a while back, which is where the change got started off from. It's a different board, so using it to justify changes for this one might not have been the best practice.
I tested both today, and the v1.1 and 1.0 board files can both be used to create ethernet designs that work in hardware with the lwip echo server example. The clock architecture for version 1.1 can be seen here:

I manually constrained sys_clk_i instead of using the board file interface, as noted in the guide I previously linked. The clk_wiz_0 IP is configured to automatically pick up the input frequency, have an active low reset, and have a 25 MHz output frequency.
Version 1.0 as well, for good measure:

It uses the recommendations from the guide.
Thanks,
Arthur

As of Vivado 2022.1, the board store includes both the updated and original version of the board files. The original version (1.0) is set up in the way you described, with a 166.667 MHz clock input. Rather than modifying the MIG manually, the older version can be picked up by selecting the 1.0 file version in the project settings, the "All board revisions" filter also needs to be selected in order to see it once installed. 1.0 is the only version available in the board store in previous versions of Vivado - though you can install board files manually and get 1.1.

I'm working on checking the guide steps with both the 1.0 and 1.1 versions of the files. We'll also look at getting the guide updated to support the updated clock architecture, this same change was implemented across a fair number of boards, while these ethernet guides haven't been touched in some years.
Section "System Clock, PLL and MMCM Locations, and Constraints" of the MIG 4.2 user guide (starting on page 194 here: https://docs.xilinx.com/v/u/en-US/ug586_7Series_MIS) has some more info on the clocking recommendations. That said, I think the 1.0 board file MIG preset for the Arty A7 likely still works, just need to test it.
Thanks,
Arthur
 

I had these issues in the past, and I traced them to a realtime backup solution I used (OneDrive). Apparently the likes of OneDrive (also Dropbox, Synology Drive and others) somehow interfere with MIG, but once I've gotten rid of it (by moving my projects outside of OneDrive replicated folder), all problems went away. To make sure my projects are still backed up, I set up the Synology Drive (I have a Synology NAS in my network, so using their solution was an obvious choice for me) to perform backup daily during the night when I'm not using my PC instead of realtime backups. So if you still experience those and use any of those things I mentioned above, try moving your projects outside of them and see if problem still persists.

I'm pretty sure it's an active-low, but you can measure it with a multimeter just to be sure. As for duration, it's an asyncronous reset, so it can be of any length.

This turned out to be a problem with the way Vivado was running.  After rebooting the computer and rerunning the demonstration, everything worked normally.

To get a useful answer you need to post some actual information about your design, such as how the XADC is connected up within it, and the settings you used for the XADC wizard. Given the question you posted, the best one can say is that you are probably doing something wrong in the XADC wizard or how you are instantiating the XADC module in your design.

looks like the script was renamed here
https://github.com/Digilent/digilent-vivado-scripts/blob/master/checkout.tcl

The ports you are referring to are likely interface ports, which are effectively buses made up of multiple individual ports/signals. Check your HDL wrapper file to determine the actual ports which are created for your design - I expect you will find sixteen inouts instead of two output ports, see below for an example with one interface port.
Thanks,
Arthur

The problem was the lwIP and the AxiDma interrupts interracting.  See this Xilinx thread for details: 
https://support.xilinx.com/s/question/0D52E00006iHxBYSA0/lwip-interrupt-setup?language=en_US

It depends on your XDC file. Pin 1 of the IP/module is intended to be connected to Pin 1 of the physical pmod port (same goes for the rest of the pins, 2-4, 7-10). However, the XDC file decides what pin on the IP actually connects to what physical FPGA pin. This means you can constrain one module's pins 1-4 to pins 1-4 of JA, constrain another module's pins 1-4 to pins 7-10 of JA, and pins 7-10 of both modules to whatever other FPGA I/O is available.

@artvvb Assigning to unconnected pins has solved my problem.

Assigning random pins should work. I'd suggest using pins from another Pmod port, if you have any that are unused/free.