artvvb

Hi @JimR2, This looks like a spot that a fix for the UI should be made, I'll pass it on. Thanks for pointing it out. -Arthur

Hi @fenixzhang First off, I agree with what zygot has said about how Zynq designs should not ignore the PS. That said, you ought to still be able to use the ethernet clock to clock FPGA logic without touching PL. Driving E17 to logic high shouldn't even be necessary, as the pullup resistor is there to handle that for you, as long as the FPGA isn't actively pulling the line down. How did you determine that the clock wasn't working? The following dead simple test design works fine on my hardware, with and without the eth_rst_b port. Verilog module: `timescale 1ns / 1ps `default_nettype none module top ( input wire clk, input wire btn, output reg led, output wire eth_rst_b ); always@(posedge clk) begin led <= btn; end assign eth_rst_b = 1; endmodule XDC file: set_property -dict { PACKAGE_PIN K17 IOSTANDARD LVCMOS33 } [get_ports { clk }]; #IO_L12P_T1_MRCC_35 Sch=sysclk create_clock -add -name sys_clk_pin -period 8.00 -waveform {0 4} [get_ports { clk }]; set_property -dict { PACKAGE_PIN K18 IOSTANDARD LVCMOS33 } [get_ports { btn }]; #IO_L12N_T1_MRCC_35 Sch=btn[0] set_property -dict { PACKAGE_PIN M14 IOSTANDARD LVCMOS33 } [get_ports { led }]; #IO_L23P_T3_35 Sch=led[0] set_property -dict { PACKAGE_PIN E17 IOSTANDARD LVCMOS33 } [get_ports { eth_rst_b }]; #IO_L3P_T0_DQS_AD1P_35 Sch=eth_rst_b Thanks, Arthur

Yup, the AD2 is just there as a way of providing a signal source. The author of the writeup just happened to have the AD2 on hand instead of some other piece of kit.

Hey @Manan Oza, sorry for the delay. Your connections to the board look fine. This might be, but probably isn't, some specific issue with Vivado 2021.2. One of my coworkers quickly tried out the project in it and has almost ruled it out. A more likely theory: If the resistances of your resistors are too large, the input divider used to scale the single-ended pin voltages down from 0-3.3V to 0-1V could be forming a resistor divider with your network, and effectively pulling the analog input pin to ground. I've now tried the demo out with sets of three of: 5MOhm resistors (didn't light up, near-0 V reading in hardware manager), 20 kOhm resistors (didn't light up, 0.047V reading at the where it should be ~1.0V/3), and 6.8 Ohm resistors (3 leds lit up, 0.326V reading at the 1.0V/3 point). You can find more detail on the analog input circuitry in the analog input section of the reference manual: https://digilent.com/reference/programmable-logic/arty-a7/reference-manual#shield_analog_io. This wouldn't explain issues with the differential XADC inputs, or with measuring the 3.3V rail directly, if you are also seeing issues there. Thanks, Arthur

Hi Roberto, The chipkit header pins are connected directly to the Zynq PL, so yes, as long as you have a design that has an anode output bus in the top module's port map (maybe, if an IPI design, driven by an AXI GPIO with GPIO ports made external) and these constraints, that will be sufficient to control the pins. Thanks, Arthur

Hi @swarit It depends on the timing requirements of the parts you're using. 30 digital inputs to PL is doable on Cora, between Pmod ports and shield I/O, but there are series resistors which may limit speeds if your signals are faster than maybe 5-10 MHz. Vitis provides C++ support, rather than Vivado. Using it to design software for the ARM processor is relatively straightforward. Digilent's support for HLS (using C++/C to target the FPGA PL) is very limited. Expect to be writing HDL or integrating existing IP to talk to your sensors. If you take the HDL route, getting more than a little bit of data from your custom hardware back into DDR or the ARM processor will involve a steep learning curve. Using existing IP gives you less control over the timing and involves more datasheets to dig through. Hope this helps, Arthur

What does your physical setup look like? Here's an equivalent screenshot of me moving a 1V source from A0 to A1 and back several times with the modified code: Thanks, Arthur

Hi @kuyd2233 There might be a misconception here, but please correct me if I'm wrong. The ADC on the Zmod Scope samples on the rising edge of the clock signal. Data is interleaved in a double-data-rate clocked serial bus when it is sent back to the FPGA, which might be what you are looking at in the Scope Controller manual. The thing that matters for interpretation of the data after it comes out of the Zmod Scope Controller is that channel A and B were sampled at the same time, regardless of how that data was formatted during the transfer. The Zmod Scope Controller accounts for this encoding and makes sure that the data from the two channels is re-parallelized. There's some more information on this in the Theory of Operation section of the AD9648 Datasheet, starting on page 24. Thanks, Arthur

Hi @Manan Oza I suspect that some unnecessary bad_address logic in the verilog source is causing XADC transactions to not be restarted. If the switch value ever goes above 8, bad_address gets asserted and masks out all future end of conversion signals, which are normally used to trigger the DRP enable port to start a read. It breaks the continuous conversion XADC setup. Removing this logic, by cutting the bad_address instantiation on line 34, modifying the port connection to den_in to only "enable" on line 45, and cutting lines 112 through 115, should fix the problem. This has been corrected in this release: https://github.com/Digilent/Arty-A7/releases/tag/100/XADC/2022.1-2 Thanks, Arthur

Thanks for the feedback. This is a request we've gotten somewhat consistently over the years, and one that we should be taking more seriously. The general argument for going with web-based documentation is that it allows us to more quickly go in and fix potential errors - which obviously doesn't help in your case of saving documents alongside project materials, as those errors shouldn't exist in the first place, and wouldn't be updated unless you revisited the site. From our end, converting material to a PDF from a webpage instead of the other way around can be tricky, since it either adds more places to maintain the materials, or we have to rely on the same tools you've been trying to use. PDF first and then web page might be a better option, as you mention. We're looking for ways to give customers the best experience with our documentation that we can, and that just might including adding PDF manuals. Thanks again, Arthur

Hi @Hartley Assuming your project is a baseline Baremetal project, file I/O isn't necessarily implemented. You might need to bring in additional libraries that allow you to interact with a file system on, for example, an SD card. - I assume it's not baremetal if read works despite the warning. What's your project? Is this Vitis HLS or "plain-old" Vitis? Is this a petalinux project? Thanks, Arthur

Hi @BenBlaise I haven't reproduced the issue, but here are a couple things to check: Make sure the mode select jumper is in the correct position. Make sure the axi4-stream fifo is keeping up with the I2S controller, though based on throughput estimates in the AXI-stream fifo datasheet, I find it difficult to imagine that it wouldn't be able to keep up. The CS4344 datasheet is a little confusing, because it covers all three of the 4344, 4345, and 4348 parts, which have slightly different I2S data formats. Check whether the spec you are building to actually applies to the 4344. Figure 8 "Left Justified" on page 13 of the datasheet looks to refer only to the 4345. If this is the issue, you might just need to shift each sample in each channel right one bit. Thanks, Arthur

Howdy, Unfortunately Vivado is pretty much required in order to use any of our FPGA boards at this point - ISE went away years ago. As I understand it, Vivado isn't officially supported in Windows 11, but I've heard mixed reports, potentially depending on what version gets installed. The Nexys boards don't have any particular limitation on Vivado version. In terms of workarounds, they might be able to get Vivado running inside of a virtual machine that runs a better-supported OS. Our Adept software works in Win 11 and could potentially be used to load bitstreams onto boards. Thanks, Arthur

Hi @LWW21 Welcome to the forums. There's an Adept SDK download available in the Adept resource center that can be used to build applications that take advantage of it. The download includes some examples in the samples folder, along with some instructions on getting Visual Studio set up to build the apps, but I'm not sure if it's been updated or run through recently. There should be some materials in there that could help. There aren't any prebuilt command line applications however. Thanks, Arthur

Hi @3STTW, Yep, it's a mistake, the second R3 state should be unreachable. Thanks, Arthur

One inout and one input should be fine. Both could also be inouts, bbut then you need to be careful with the FPGA design to make sure that tristates for both sides of a shorted wire are not outputting different logic levels simultaneously. This is pretty much the way I2C works, it just specifies under which conditions either side of a connection has control over the wire. Thanks, Arthur

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

Hi @matrixrifle Assuming you are using recent versions of Vivado and the board files, there have been some changes to both since that guide was written or last updated. In particular, where the MIG used to not throw errors when it's system clock input is downstream of a clocking wizard, it now does. The board files were updated to reflect this, and now require the reference clock input to be connected to a MIG output clock, and the system clock needs to be directly connected to an FPGA input pin. You can find more info and some alternate guides here: Thanks, Arthur

Hi @Sridhar Balamurali There's a known issue currently under investigation with the PS clock input frequency specified by Digilent's Zedboard board files that could be causing the issues that you are seeing. Check out this thread for more info: A fix hasn't been tested yet, but if my suspicions are correct, the only change you need to make to your block design would be to customize the PS to specify 33.33333 MHz instead of 50.0: Thanks, Arthur

Hi @jglodde Welcome to the forums! Drivers are installed when you install Vivado, through a fairly easy-to-miss checkbox. See the fourth screenshot ("This screen provides more detailed options for the customization of the installation.") here: https://digilent.com/reference/programmable-logic/guides/installing-vivado-and-vitis You can relaunch the installer via the Help -> Add Design Tools and Devices menu in Vivado. If the USB cable you are using is one that didn't come with the Arty S7, it might not be capable of delivering data. Some charging cables that ship with cell phones are like this. Try another cable or check the cable with another device. Thanks, Arthur

Hi @Jakyx Sorry to hear that. My understanding is that there are some specific power sequencing requirements that need to be followed to get the FPGA to power on correctly. You can get some more information about how Digilent implemented the Nexys's power supplies in the board's reference manual. You might also be able to get some more information about the requirements imposed by the FPGA itself in various Xilinx documentation; the Artix 7 Datasheet could be a decent place to start. Thanks, Arthur

Welcome to the forums! Good catch, the issue has now been corrected in version 1.3 of the board files. Here's a link to the updated version of the board.xml file: https://github.com/Digilent/vivado-boards/blob/master/new/board_files/nexys-a7-100t/D.0/1.3/board.xml Thanks! Arthur

I think this question has been addressed in this other thread: Posting the link here so that others who run across this thread might be able to find it. Thanks, Arthur

Hi @LHji The DAC 1411 and AWG 1411 are functionally the same, and all IP and demos created for either can be used with either. The same is true for the ADC 1410 and Scope 1410-105. Both of these products were renamed after their initial launch. There are no upgraded projects released for Vivado and Vitis 2022.1 or 2022.2. However, existing projects could theoretically be used in newer versions, by recreating the project files, including the XPR file, in the older version of the tools or by downloading an already-created XPR archive. However, differences in Xilinx IPs or drivers may require further changes to the project than just updating all IP to the newest versions and generating a bitstream. This guide will walk you through the bare bones of getting a fresh Zynq project that uses software to control peripherals in the PL to blink some LEDs and read button states: https://digilent.com/reference/programmable-logic/guides/getting-started-with-ip. That said, instructions for integrating Zmod IP are not included in that particular guide. For starting with Zmods, I would recommend working from an existing example project, after getting the basics down. Thanks, Arthur