All Activity

Yes No, Don't own the higher end units. Yes No Yes No I'm actually a new user to Digilents offerings and haven't had a need yet to use an SDK. With respect to the last two questions: Right now I'm happy with the 2230 and its bandwidth, Sampling rates needs vary. As far as current and future needs there likely is a need in the future for more channels and even better isolated channels. Ideally more channels with out a significant loss of sampling rate. Realistically though my interests are more industrial so extremely high bandwidth / sampling rates are seldom needed. In any event more channels, including a trigger channel go a long ways. As for features or improvements, in all honesty I'm a new owner and have not had a lot of exposure yet. However that has never stopped me from making suggestions: (realize I'm a new owner / learner) PC's these days almost always come with some sort of "Sound Card", I'd like to see these used via another instrument that is always available and can handle basic oscillator duty. In fact you can literally call it an Oscillator instrument though most sound cards can do better. Now I realize that we have the WaveGen Instrument but I look at this as additional capability and frankly parallel capability that does not interfere with the channel to the Analog discovery. A higher voltage range on a per div spec. This would make the platform even more useful. Add supported external DVM's instead of or in cooperation with the Analog Discovery. These days that means a USB interfaced DVM's. The idea would be zero effort implementation on the part of the user, even if that means a limited number of DVM's. You can never have too many DVM's available and sometimes you need the safety of system multi meter. I will likely have more to add as I learn about the hardware and software. I'm especially interested i how the logic instrument works with slow electromechanics.

I pretty much have to agree with the first post in this thread, the need to have an account to install and keep up your installed software is Extremely anti consumer. It is unfortunate that Digilent has gone this way. In fact I'm going to suggest going in the opposite direction and make life even easier for your users. In this regard use Home Brew for Mac Software support. For Linux setup an RPM repository for Fedora and possibly some of the lesser distros. Why? Simply because it makes keeping a computer up to date and your customers will love you for it. I suspect that what Digilent and their marketing people, don't realize is that too much non sense drives people to other companies. This includes excessive marketing crap but also things that just get in the way like diving through hoops to update a piece of software. Keeping your software up to date on a computer should be effortless using accepted methods. Please realize I'm a new customer of Digilents, I'd like to be a long term customer but I'm left with the impression that the ownership by National Instruments has infected the company with BS that educated engineers and technicians don't want to deal with. Effectively the markets NI and Digilent server are not the same and what is good in one domain really sucks in another.

Interested if you could post your solution here. It would be helpful to maybe put an example of how to snoop on and analyze traffic on a can network. Thank you for your time

The only caveat being what you've said just above the quoted - just because you connect a device directly to a USB port of a motherboard, it doesn't mean that this is actually a root USB port and not merely one of ports from onboard USB hub. This is not so bad for USB 2.0 as most hub chipsets I've came across had no problems processing nearly full USB 2.0 bandwidth at line speed, but things get a lot dicier with USB 3.x hubs and multiple USB 3.x devices. But since USB 3.x hubs actually contain two separate hubs (one for USB 2.0 and below, and another one for USB 3.x), a USB 3.x device can coexist with USB 2.0 device(s) without any interference because these two standards use physically separate channels for communication (and two separate controllers inside chipset/port controller). Given the question in the OP - since UART doesn't come anywhere near saturating USB 2.0 bus, (infact it won't saturate even USB FS at 12 Mbps), I don't see the problem. Unfortunately there is another "but" - if you use some sort of UART over USB-JTAG adapter (like Digilent's HS2/HS3), there are known cases when they refuse to work when connected through certain hubs. I'm not entirely sure if it's a hardware problem or a software one (or a combination of two), but it does happen sometimes, and in this case user will need to connect those adapters directly to motherboard USB port.

Hi @NAOUZ, Unfortunately, Digilent does not have a version of the Nexys A7 that is able to be powered over both USB as well as being able to accept an external power supply in the 7 Vto 15 V range. Thanks, JColvin

Hi @Mohammad Alsmadi, I have zero experience with neural networks and don't know what kind of neural network you are thinking of (it sounds like some version of a PID controller), but I suppose in theory if you trained the neural network elsewhere and then fit it within into the Linux image for the ADP3450 and set up to either: - access either the WaveForms SDK API functions directly - access some script that separately runs the WaveForms SDK then feeds the received buffer data to the network and then in turn adjusts some parameter through the SDK API - read a saved file containing pre-recorded data then it could presumably work. The ADP3450 only has 512 MB of DDR RAM, so you'll probably be limited in the amount of processing you can do while also running the Linux OS and whatnot. Thanks, JColvin

Hi @linc With the 50 V range, the resolution decreases, so a larger hysteresis may be required to reject noise. Use the easier to use acqmodeSingle. The record is only required for streaming for captures longer than the device's buffer size. Use newer software version which provides simple capture up to 128M samples for ADP3X50

Hi @rjratnip See the manual and examples, like Device_Info.py

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.