All Activity

Hi @digility, A hub will only become a problem if the USB traffic back to the host computer (whether that's UART or JTAG or your keyboard/mouse or whatever) becomes congested and you end up losing samples (or if your hub cannot provide sufficient power to all of the connected devices). A lot of computer motherboards have internal USB hubs for their multiple USB ports (albeit potentially with controllers for each connection depending on the setup). I have two USB hubs (out of necessity) for the collection of Digilent devices that I have at my work station. If I know that I am going to be streaming a lot of data at a rate that can't afford to have dropped packets (or that is going to saturate the bandwidth of the hubs connection back to the host computer), I'll just make sure that I let that device have a direct connection to the host computer so it is not competing with other devices for bandwidth. But using a device with a USB 2.0 connection, a keyboard, and a mouse on some hub should realistically not be a problem, as keyboards and mice are pretty "light weight". I don't quite understand your use case of communicating with the FPGA over UART while also configuring the FPGA as that would reset the entire FPGA (unless you're doing partial reconfiguration that doesn't touch the UART portion?) Thanks, JColvin

I have a Rev D Arty Z7. After reading your post, I walked through the Zynq Server guide using Vivado 2023.1 and did not experience the same trouble. Older Arty Z7 boards use an older Rev Realtek PHY chip and should work as is with Vivado, whereas new boards require a patch to the LWIP Library. To patch your system, use the attached file and overwrite: C:\Xilinx\Vitis\2023.1\data\embeddedsw\ThirdParty\sw_services\lwip213_v1_0\src\contrib\ports\xilinx\netif\xemacpsif_physpeed.c, assuming you have 2023.1. Could you walk through the Zynq Server guide using one of your new boards to see if you can get the echo server working with the update to the LWIP Library? xemacpsif_physpeed.c

Hello, I'm trying to use the WaveForms SDK version 3.21.3 with an ADP3450 and seeing some really bizarre behavior. I'd appreciate if anyone can explain what's going on. I'm trying to record a fixed length scope capture with a variable trigger offset, e.g. for a capture duration of 10ms, I might set the trigger position to 0 to capture from the trigger to 10ms afterward set the trigger position to -5ms to capture from 5ms before the trigger to 5ms afterward My fixed settings are as follows: acquisitionMode: 3 (Record) AnalogInFrequency: 100000 (100kHz) recordLength: 0.01 (10ms) bufferSize: 33554432 (the maximum) triggerSource: 2 (DetectorAnalogIn) triggerChannel: 0 triggerPosition: 0 triggerType: 0 (Edge) triggerCondition: 0 (Rise) triggerHysteresis: 0.01 My test waveform is a 200Hz, 1V amplitude sine wave. Expected results: The scope records 1000 samples (10ms * 100kHz.) The trigger occurs when the sine waveform rises through 0. After the capture is complete, FDwfAnalogInTriggerPositionStatus returns the timestamp of the first sample relative to the trigger (roughly equal to the trigger offset.) The above behavior does not depend on the trigger position or the voltage range. Actual results: When I use the fine voltage range (2V) and a trigger position of 0, the behavior is as expected. if I do the same with the coarse voltage range (50V), the scope does not trigger only on rising edges despite the setting, but on either rising or falling edges. Sometimes I get the sample above, sometimes the one below. Why is the trigger condition different in this range? I have confirmed by looking at the raw samples that this is not a jitter issue, i.e. the first two samples are in fact positive then negative, forming a falling edge. There is only one sign change in the vicinity. I have confirmed that the trigger condition is set correctly, i.e. FDwfAnalogInTriggerConditionGet just before the capture is 0 for rising edge. When I set a nonzero trigger position, The number of samples taken increases and is not constant between captures, even with the same settings. The trigger does not occur at a zero transition and does not occur at a constant place in the waveform, i.e. the waveform shifts left and right. I do notice that the end of the capture always seems to occur at the correct place in the waveform, so it seems the scope is prepending a random number of samples to the start of the capture, and then FDwfAnalogInTriggerPositionStatus is not returning the correct timestamp of the first sample. Why is this happening? If I chop off the start and take only the last 1000 samples, is it guaranteed that I'll get a correctly lined up waveform with the starting point given by FDwfAnalogInTriggerPositionStatus? Here are several captures in a row taken with exactly the same settings.

Hi, I'm trying to understand the idxDevice value in the FDwfDeviceOpen() function. The documentation says it is a 0-based value for the devices, so I assumed if I only have one device connected then the idxDevice would be 0. But, if I specify 0 then no devices get opened. I ran a loop from 0-255 for the index, and it found no devices. If I specify the -1 value for "open all devices", then the device gets opened. One reason I want the index is for using the FDwfEnumDeviceIsOpened(int idxDevice, int *pfIsUsed) function so I can tell if the device is already opened for managing multiple measurements in my software. I prefer not to keep opening and closing devices as it takes some time to do this. Can you explain how to determine what the value for this index should be for my device? Is there a way I'm not seeing to determine the index of a device that is opened? I'm using a Analog Discovery 3 device. Thank you. Robert

Hello I understood that running a python script with a neural network on the ADP3450 is possible. Is the below doable? 1. Training a neural network to run in python script. The training can be done on a host PC (Offline). 2. Saving the trained neural network. When the neural network is trained, it has parameters that will use to predict the output when it receives a new input. I would assume the trained neural network to be saved on the Digilent. 3. Sampling waveforms in realtime in linux mode. 4.Running the trained neural network in a python script on the ADP3450 in linux mode and feed it with some information from the sampled waveforms. 5. Repeating 3 and 4.

Yes, you can program the PS alone without loading a bitstream, but you still need to export a hardware project from Vivado to get the correct set of PS initialization settings, even if the project only contains the Zynq PS in a block diagram. There isn't much in the way of dedicated DSP features in the PS - this section of the Zynq TRM provides a feature overview: https://docs.amd.com/r/en-US/ug585-zynq-7000-SoC-TRM/Processing-System-PS-Features-and-Descriptions.

You should lock into device tree binding: /* * See Documentation/devicetree/bindings/dma/xilinx/xilinx_frmbuf.txt * to find the equivalent DRM fourcc code for the format selected in * the Frame Buffer Reader, then see See include/uapi/drm/drm_fourcc.h * to find the corresponding 4-char string that should be placed here. */ xlnx,vformat = "XR24"; Change according to your kernel version.

Hello Check below steps Understand Hardware: Know Nexys A7 FPGA board and Pmod AQS sensor. Learn VHDL Basics: Get familiar with VHDL syntax and data types. Study I2C Protocol: Learn about I2C communication. Implement I2C Communication: Set up basic communication between devices. Interface with Pmod AQS: Read air quality data from the sensor. Calibration and Testing: Ensure accurate measurements and test functionality. Documentation and Support: Document your work and seek help if needed. Hope it helps

In Network Analyzer you can set Source: External and control the sweep from Wavegen or external equipment. The NA will look for peak in the spectrum and consider this the signal frequency. Under Options menu you can adjust the External Threshold, the minimum peak magnitude. Depending or number of Steps, set the sweep time to seconds or minutes, for wide logarithmic scales you can adjust the sweep frequencies manually. When all the step points are captured it will draw a line, until this only dots.

Thank you!!! can you please post me any link or document to interface high speed ADC with zynq soc

Hi, I am trying to design an ethernet controller for my Genesys 2. From specifications (RGMII, Realtek RTL8211E-VL PHY) or other projects (special thanks to @zygot and his Ethernet PHY Test Tool project), I have successfully implemented the Tx transmitter part: I can now see the different packets with WireShark. However, I am now facing a problem in the Rx receiver part. After analyzing the signals, I've noticed that the issue seems to come from the signals that are received from the PHY. Below is a screenshot of a received packet observed from an ILA: the sampling clock is at 500MHz (so the waveform accuracy must be put into perspective). The original packet starts with: ff ff ff ff ff ff a4 b1 c1 31 d8 05 08 00 45 00 ... But as early as the preamble/SFD, it seems that a shift exists with the first 4 bits received on a falling edge. So my frame becomes 5X 55 55 55 55 55 55 fd ff ... instead of the expected 55 55 55 55 55 55 55 5d ff... And it stays like that until the end of the frame, and for all the received frames. Here are the corresponding Verilog and constraints parts inspired by the previously mentioned sources: // Verilog top file input logic i_eth_mii_rx_clk; // Input Rx Clock input logic i_eth_mii_rx_ctl; // Input Rx CTL input logic [3:0] i_eth_mii_rx_data; // Input Rx Data logic w_eth_mii_rx_clk; // Internal Rx Clock logic w_eth_mii_rx_rst; // Internal Rx Reset logic [1:0] w_eth_mii_rx_ctl; // Internal Rx CTL logic w_eth_mii_rx_en; // Internal Rx Enable logic w_eth_mii_rx_err; // Internal Rx Error logic [7:0] w_eth_mii_rx_data; // Internal Rx Data ... assign w_eth_mii_rx_clk = i_eth_mii_rx_clk; ... IDDR #( .DDR_CLK_EDGE ( "SAME_EDGE_PIPELINED" ), .INIT_Q1 ( 1'b0 ), .INIT_Q2 ( 1'b0 ), .SRTYPE ( "SYNC" ) ) m_IDDR_eth_mii_rx_en ( .Q1 ( w_eth_mii_rx_ctl[0] ), .Q2 ( w_eth_mii_rx_ctl[1] ), .C ( w_eth_mii_rx_clk ), .CE ( 1'b1 ), .D ( i_eth_mii_rx_ctl ), .R ( w_eth_mii_rx_rst ), .S ( 1'b0 ) ); assign w_eth_mii_rx_en = w_eth_mii_rx_ctl[0]; assign w_eth_mii_rx_err = w_eth_mii_rx_ctl[1] ^ w_eth_mii_rx_ctl[0]; genvar et; generate for (et = 0; et < 4; et = et + 1) begin IDDR #( .DDR_CLK_EDGE ( "SAME_EDGE_PIPELINED" ), .INIT_Q1 ( 1'b0 ), .INIT_Q2 ( 1'b0 ), .SRTYPE ( "SYNC" ) ) m_IDDR_eth_mii_rx_data ( .Q1 ( w_eth_mii_rx_data[et + 0] ), .Q2 ( w_eth_mii_rx_data[et + 4] ), .C ( w_eth_mii_rx_clk ), .CE ( 1'b1 ), .D ( i_eth_mii_rx_data[et] ), .R ( w_eth_mii_rx_rst ), .S ( 1'b0 ) ); end endgenerate # Top constraints file ... ## Ethernet PHY set_property -dict { PACKAGE_PIN AK16 IOSTANDARD LVCMOS18 } [get_ports { i_eth_int_b }]; set_property -dict { PACKAGE_PIN AK15 IOSTANDARD LVCMOS18 } [get_ports { i_eth_pme_b }]; set_property -dict { PACKAGE_PIN AH24 IOSTANDARD LVCMOS33 } [get_ports { o_eth_phy_rstn }]; set_property -dict { PACKAGE_PIN AF12 IOSTANDARD LVCMOS15 } [get_ports { o_eth_mii_mdc }]; set_property -dict { PACKAGE_PIN AG12 IOSTANDARD LVCMOS15 } [get_ports { t_eth_mii_mdio }]; set_property -dict { PACKAGE_PIN AE10 IOSTANDARD LVCMOS15 } [get_ports { o_eth_mii_tx_clk }]; set_property -dict { PACKAGE_PIN AK14 IOSTANDARD LVCMOS15 } [get_ports { o_eth_mii_tx_ctl }]; set_property -dict { PACKAGE_PIN AJ12 IOSTANDARD LVCMOS15 } [get_ports { o_eth_mii_tx_data[0] }]; set_property -dict { PACKAGE_PIN AK11 IOSTANDARD LVCMOS15 } [get_ports { o_eth_mii_tx_data[1] }]; set_property -dict { PACKAGE_PIN AJ11 IOSTANDARD LVCMOS15 } [get_ports { o_eth_mii_tx_data[2] }]; set_property -dict { PACKAGE_PIN AK10 IOSTANDARD LVCMOS15 } [get_ports { o_eth_mii_tx_data[3] }]; set_property -dict { PACKAGE_PIN AG10 IOSTANDARD LVCMOS15 } [get_ports { i_eth_mii_rx_clk }]; set_property -dict { PACKAGE_PIN AH11 IOSTANDARD LVCMOS15 } [get_ports { i_eth_mii_rx_ctl }]; set_property -dict { PACKAGE_PIN AJ14 IOSTANDARD LVCMOS15 } [get_ports { i_eth_mii_rx_data[0] }]; set_property -dict { PACKAGE_PIN AH14 IOSTANDARD LVCMOS15 } [get_ports { i_eth_mii_rx_data[1] }]; set_property -dict { PACKAGE_PIN AK13 IOSTANDARD LVCMOS15 } [get_ports { i_eth_mii_rx_data[2] }]; set_property -dict { PACKAGE_PIN AJ13 IOSTANDARD LVCMOS15 } [get_ports { i_eth_mii_rx_data[3] }]; ## Clocks create_clock -add -name CLK_ETH_MII_RX -period 8.00 -waveform {0.0 4.0} [get_ports {i_eth_mii_rx_clk}]; create_generated_clock -name CLK_25MHZ [get_pins m_MMCME2_BASE/CLKOUT1] create_generated_clock -name CLK_50MHZ [get_pins m_MMCME2_BASE/CLKOUT3] # Design Cock create_generated_clock -name CLK_125MHZ [get_pins m_MMCME2_BASE/CLKOUT4] # Tx Clock create_generated_clock -name CLK_125MHZ_P90 [get_pins m_MMCME2_BASE/CLKOUT5] # Tx Clock with 90 Phase Shift create_generated_clock -name CLK_500MHZ [get_pins m_MMCME2_BASE/CLKOUT6] # ILA Clock set_clock_groups -asynchronous -group {CLK_50MHZ CLK_ETH_MII_RX CLK_125MHZ} After several checks, I seem to have used the same blocks (IDDR) and constraints as in the examples I've seen. However, what I'm observing doesn't seem to be consistent with what I expected. Any idea what I might have missed as a problem or constraint? I'm pretty sure it must be an obvious problem, but impossible for me to identify it ... Thanks for your help!

yes, I would need to have a fixed offset. Example: An input frequency of ~14MHz would be mixed to 900kHz. I would like to sweep the input frequency within a span of ~5MHz and measure the amplitude of the resulting frequency. Is it possible to use a script for this purpose?

Hi @Andreas Schröck This is currently not possible. Do you need a fixed offset between the two frequencies?

I would need to measure a mixer using the Network functionality. Currently, it is not possible to set a frequency offset between the wavegen and the measurement. Any suggestions where I can start to search for additional information?

Hi @gcb As you can see in the changelog, beta versions are frequent updates that add new features and fix bugs. The release version comes out about twice a year, usually in sync with a product release, and is tested a bit more. These are useful in class so that everyone uses the version over the course of a semester.

I have trying to interface PMOD AD1 to CoraZ7 , board but im facing issue with genarating bitstream , ERROR Implementation Write Bitstream DRC Pin Planning [DRC NSTD-1] Unspecified I/O Standard: 8 out of 138 logical ports use I/O standard (IOSTANDARD) value 'DEFAULT', instead of a user assigned specific value. This may cause I/O contention or incompatibility with the board power or connectivity affecting performance, signal integrity or in extreme cases cause damage to the device or the components to which it is connected. To correct this violation, specify all I/O standards. This design will fail to generate a bitstream unless all logical ports have a user specified I/O standard value defined. To allow bitstream creation with unspecified I/O standard values (not recommended), use this command: set_property SEVERITY {Warning} [get_drc_checks NSTD-1]. NOTE: When using the Vivado Runs infrastructure (e.g. launch_runs Tcl command), add this command to a .tcl file and add that file as a pre-hook for write_bitstream step for the implementation run. Problem ports: ja_pin10_io, ja_pin1_io, ja_pin2_io, ja_pin3_io, ja_pin4_io, ja_pin7_io, ja_pin8_io, and ja_pin9_io. [DRC UCIO-1] Unconstrained Logical Port: 8 out of 138 logical ports have no user assigned specific location constraint (LOC). This may cause I/O contention or incompatibility with the board power or connectivity affecting performance, signal integrity or in extreme cases cause damage to the device or the components to which it is connected. To correct this violation, specify all pin locations. This design will fail to generate a bitstream unless all logical ports have a user specified site LOC constraint defined. To allow bitstream creation with unspecified pin locations (not recommended), use this command: set_property SEVERITY {Warning} [get_drc_checks UCIO-1]. NOTE: When using the Vivado Runs infrastructure (e.g. launch_runs Tcl command), add this command to a .tcl file and add that file as a pre-hook for write_bitstream step for the implementation run. Problem ports: ja_pin10_io, ja_pin1_io, ja_pin2_io, ja_pin3_io, ja_pin4_io, ja_pin7_io, ja_pin8_io, and ja_pin9_io. [Vivado 12-1345] Error(s) found during DRC. Bitgen not run.

can you please help me with that?

Thank you for the feedback, but the costumer ask for nexys 7-100T Powered from USB or any 7V-15V source with Block RAM (Kbits) 4,860.

Yep, Pmod I/Os are generally general purpose. Just make sure that whatever circuit you're connecting to shares a ground with the board.

Hi @loser Try pushing some known points in and see what the result is - change the testbench input and see what happens. Below is a testbench that just counts through all bit values that phase could be, using your IP settings: module cordic; reg clk; initial begin clk = 0; forever #0.5 clk = ~clk; end reg [15:0] din; wire [31:0] dout; wire dout_valid; initial begin din <= 0; forever @(posedge clk) din <= din + 1; end cordic_0 dut ( .aclk(clk), .s_axis_phase_tdata(din), .s_axis_phase_tvalid(1'b1), .m_axis_dout_tdata(dout), .m_axis_dout_tvalid(dout_valid) ); endmodule Waveform Style -> Analog Settings for dout: Radix -> Real Settings for dout: Thanks, Arthur

I have ordered 4 ARTY-Z7-20 boards in the last few years. I bought 2 a month ago (Rev D), and 2 several years ago (Rev B). There seem to be some build quality issues, or perhaps someone can explain why out of *Four Arty-Z7 boards*, *NONE* of them work completely. They fail in 3 different ways: OTP memory doesn't work, ethernet PHY doesn't work, or the ARM program will not launch at all. I developed a simple telnet interface running on the ARM (from a simple TCP echo example), utilizing lwip library and the RJ45 network connection. It echoes a few commands and gets some data from the FPGA. However, all 4 boards have problems. Only board #1 can successfully run the telnet program on the ARM. However, this board cannot read the OTP memory, which has a unique ID that I need to read (EUI-48ID). Boards #2 and #3 cannot run the telnet program. They fail during the ethernet PHY autonegotiation, with the message: Start PHY autonegotiation Waiting for PHY to complete autonegotiation. autonegotiation complete Phy setup error Phy setup failure init_emacps Board #4 immediately fails after programming (via the PROG USB) with a strange error in a VITIS popup dialog: Error while launching program: Memory write error at 0x109000. MMU section translation fault I am extremely frustrated by this. With 4 boards, none of them work 100%, each with different failure modes. Can someone please explain? Otherwise, it seems Digilent has a serious problem with build quality and board testing.

The Nexys A7 only supports 5 V power at the barrel jack input. You might be able to use a DC-to-DC converter to step your input voltage down to 5 V. That said, we don't have any particular converters that we've tested to recommend.

I found those examples - great! What is in the beta version of Waveforms that I need? I will download it, of course - just curious...

Hello, I bought a Basys 3 two months ago, the problem is the basys is not turning on, yesterday it was ok, I tried everything, I changed the USB Port with I was working, I connected it directly to the light and nothing

It will not be a problem to access ther FPGA over a USB Hub. Take a look into the Device Driver of your PC, all serial connections to the USB will be separately listed.