Jump to content

All Activity

This stream auto-updates

  1. Past hour
  2. Hello @Dauple. Unfortunately, the DT9847-3-1 is no longer manufactured and an equivalent replacement is not available. Regards, Fausto
  3. Hello @Mike R. I am unable to find a NI PCI-6053E, but did find a NI PCI-6052E. Please confirm the NI device model. The NI PCI-6052E supports two analog output channels, which the MCC USB-1608G does not support. Please consider the MCC USB-1608GX-2AO. Since you and/or your colleagues are familiar with how the NI device is used and your application's requirements, compare those NI specs with the MCC USB-1608GX-2AO to determine if the MCC device is a suitable replacement. Note that your software application will need to be updated to support the MCC device. Regards, Fausto
  4. Hi Team, I am using Digilent Analog Discovery 3 device for my device testing and trying to capture 100msec from D2 channel. In my testing one digilent device is connected in remote system(linux machine) and another one is connected in my windows machine(locally) in both machine I am trying to measure 100msec data from channel 2. My sample rate is 1024 which I am setting in python script. for this sample rate my total capture is 15.96sec. In windows machine number of samples per signal is 204 and I am able to verify that it is 100mesc, whereas in linux machine also it is 204 but I am not able to verify it as 100msec. only difference in linux and windows machines is internal frequency. in linux machine is 50Mhz and window machine is 100MHZ. Attached csv file for the both machines. Please help to resolve and explain me this issue. output_100msec_Linux.csv output_windows.csv
  5. Today
  6. Hello @Ron Byron. Welcome to the Digilent Forum community. MCC related questions reside in the Measurement Computing (MCC) sub-forum. Use this link for the current version of MCC software for Windows, which includes InstaCal. The MCC software installation copies Universal Library examples to the C:\Users\Public\Documents\Measurement Computing\DAQ directory on the target system. Recommend using the UL Help as a reference for the supported functions of each device. An updated firmware version is available for the USB-1608GX via this link, along with instructions. Two versions are available depending on the hardware revision of the USB-1608GX. Select the firmware update compatible with your hardware revision. A label on the device identifies the revision. The letter just before the dash denotes the hardware revision. For example, part number 151440E-xxL indicates revision E. Regards, Fausto
  7. Hello @JMG. I am unable to assist on-site, but can attempt to troubleshoot your issue via this forum given additional information from you. Which MCC device, software application (and version), and operating system (and version) are you using? If you are unsure of the device model, please connect the device to a Windows system, launch MCC's InstaCal utility, and capture a screen image of the device information. Alternatively, snap an image of the physical device (top and bottom) and include it with your reply. Can you describe in detail (and capture screen images) of the issue(s) you are experiencing? Regards, Fausto
  8. Hi JRys I appreciate your fast response on this. I would like too that there are also couple other issues with the board. Some other issues were the voltage not being able to get anywhere near 0 on the output channels. The temperature readings were also several degrees higher than they should be for room temperature indicating a need for calibration. The auto calibration with instacal didn't help for the inputs, and won't run for the outputs. For these issues, could this be some problem with the board? If so, my research lab would like to seek for some assistance fixing it. Thank you. Yours Alex
  9. It's not for synchronization, the PS is waiting in a loop while the core runs. I just had problems with the core locking up the bus if I manually stopped it in the middle of an AXI transaction so now I just reset the whole network. Thanks for the tip on the signals!
  10. Adding circuit information, No diodes are inserted between the connector and pins 17/16(USB_DP/USB_DM), No diodes are inserted between the connector and pins 17/16, and the pattern length between the connector and pins 17/16 is wired as short as possible. Currently, pins 3(CTS), 6(TXD), 5(RXD), and 4(RTS) are functioning, but pins 13(TMS), 10(TCK), 12(TDI), and 11(TDO) are not functioning. Are there any other factors?
  11. I don't know - that's what debugging is for. I would begin with inspecting an AXI bus from that core in a debugger just to see what's going on there. Also the kind of syncronization you use is not the best - I would use a mutex or a spinlock with atomic operations on both sides, instead of constantly resetting the core. Ditto for using AXI GPIO to control internal signals - I would create a simple custom AXI-lite slave with a single register. Thought I know some people prefer using PS GPIO ports 2 and 3 via EMIO as they give up to 64 channels for zero logic cost (you wil probably need to resyncronize it in PL as PS GPIO is likely running on a different clock from whatever you've got in PL - but that of course is only important for syncronous signals).
  12. Yeah, what I meant is, I tried the same thing but with the ports/interconnects swapped i.e. 0x4000_0000 for cpu control and 0x8000_0000 for memory access. That's the only way to do it, no? Since the settings in the controller and BRAM generator are greyed out. I'll try removing the RISC-V core and debugging some more. If it is indeed the core, how does that even happen? It's held in reset until the command to enable it is sent. Thanks for your help!
  13. Maybe you should stop for a second and actually read and attempt to understand what IDE is telling you? Specifically, you are trying to create a 128x131072 FIFO, which requires almost 17Mbit of BRAM, while your target device (Artix-7 A100T) only contains 4.8 Mbit. Hence the message - "you're requesting more BRAM blocks than your target device actually contain. Consider targeting a larger capacity part, or reduce your demands to something which your target device actually has".
  14. That doesn't make any sense. Try getting rid of RV core and see if problem persists, then you will know what the problem is. You do know that each of GP ports has it's own address space, and attempting to access any addresses outside that space will never reach the port? See address map in UG585, Ch 4.1 Again, try getting rid of RV and see if problem persists. Alternatively, you can use a debugger to inspect live transactions on AXI interface(s) to see what the heck is actually going on. You did update the "range" column in address editor for a wider address window, right?
  15. Yesterday
  16. Hi, I'm having some problems with implementing a RISC-V SoC using a PicoRV32 soft core. The board I'm using is PYNQ-Z2, the FPGA part is XC7Z020 and the IDE is Vivado/Vitis 2023.2.2. The design is visible in the two attached PDFs exported from Vivado, one in default and the other in addressing view. You can also see my current settings in the Address Editor in the picture attached below. I also attached my Vitis program. The idea is to use a PC to send commands and data to the PS using UART. For example, after booting the board, you send the command to write the program instructions to memory, start the RISC-V core by writing to an address which controls the enable signal using AXI GPIO and when the core sends a halt signal (also controlled by AXI GPIO) or the PS receives a stop command, you read a segment of memory the core wrote to. The basic workflow described above is functional, but I still have some problems: 1. AXI peripherals only work if their base addresses are 0x4000_0000, 0x4200_0000, 0x4400_0000 or 0x4600_0000 Anything other than that, be it 0x4100_0000, 0x4001_0000 or 0x4800_0000, just doesn't work and both the PS and RISC-V core won't read or write to those addresses. The PS blocks on reading, which I confirmed when debugging and I'm not sure what the core does. The PS writing directly to AXI GPIO which controls the onboard LEDs works fine when its address is 0x4600_0000 but not when it's 0x4800_0000. There are no addressing overlaps or such and the design validation I run every time passes normally. For some reason, the AXI GPIO registers I'm writing to from the PS's second AXI GP master port through "cpu_ctrl_interconnect" work fine with packed addresses. Although, just swapping 0x4000_0000 for 0x8000_0000 and the PS's AXI ports yields the same result. 2. Third AXI memory controller/BRAM generator pair doesn't work I'm currently using 2 AXI BRAMs, one for the program and data, and the other as a stack. I'd like to add a third one but it seems broken. Writing to it is seemingly fine, but reading just gives a sequence of 0x0000_0000/0xFFFF_FFFF/0x0000_0000 etc. The same is true even if I remove the AXI GPIOs so it could use one of the working base addresses. 3. When using AXI GPIO only the first channel is functional If I try to use the second channel and configure it, it just doesn't work. As per the manual, the GPIO2_DATA register should be on a +0x8 offset from the base address, but writing to the address does nothing and reading from it gives zeroes. The first channel still works normally, though. I don't know if this is a bug or a normal FPGA part limitation but: 4. The AXI BRAMs are limited to 32 kB When choosing more than 32 kB, for instance 64 kB, only the first 32 kB (up to base + 0x7FFF) are usable and writing or reading from it doesn't work and blocks the PS indefinitely. I don't know if this is intended since I get no warnings and design verification passes normally. The board isn't broken, I tried a different PYNQ-Z2 board and got the same result. I'm probably doing something terribly wrong since I'm still a beginner with AXI stuff. Thanks in advance. design_1.pdf design_1_addressing.pdf main.c
  17. Mamatchai, I'll need a bit of time to reproduce and double-check whether there are other important interrupts. Addresses for PL IP are different per project, they're assigned in the address editor in Vivado. You can either let Vivado automatically assign them (the default behavior) or manually set them. Either way, the address map is exported with the XSA file after generating a bitstream, along with various additional information about the hardware design (this is also how IP configuration information makes its way into the files used by *_LookupConfig functions). Including the xparameters file in your code and using the macros it defines is recommended in case the peripheral addresses are changed in Vivado.
  18. 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. 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: There was another user building a similar system in this thread:
  19. Hello all, Needing some guidance, we integrated the DT-9847-3-1 analyzer in to our test systems but the DT-9847-3-1 is no longer manufactured. Was our understanding that this model was manufactured in Hungry, is it possible it is still available outside the US? We rely on the 24 bit 216 Ks/s specs on this analyzer for our testing as well as the quality signal and immunity to outside noise, is there an alternative to the DT-9847 still available? We have searched but cannot seem to locate one, we have tried other manufactures with the same specs only to find them inadequate, slow, addons required and inherent to unwanted noise. Please, Any support would be greatly appreciated.
  20. Does anyone have a technical resource with experience with TC and the Measurement Computing application that is willing to assist on site in Chula Vista / San Diego area? Please advise.
  21. Hi Arthur, I was able to generate the project following the example at https://digilent.com/reference/programmable-logic/guides/zynq-servers?_ga=2.132423246.1936083739.1710846565-1774928201.1710252575/. Cant test is as we just ordered the boards. 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. In the above design it looks like the PS is able to receive a packet (which I am assuming is one character) and echo it back via the echo.c: err = tcp_write(tpcb, p->payload, p->len, 1); As the comment in the code says, we assume that the payload is < TCP_SND_BUF. I am not sure the PS can handle that kind of rate??? I was reading the Zynq 7000 SoC Technical Reference Manual (https://docs.amd.com/r/en-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? Any help would be appreciated.
  22. Hi, I have what seems to be a working hardware design with the Zmod 1410 scope module (see below). My thought then was to modify the DDR example code removing all references to "triggering" (I don't care about that at this point) and recycle the multi S2MM_cyclic_transfer_test example. I created a new "helloworld" application in Vitis, copied the main.c from the above application and rebuilt the project. Then added what seemed to be relevant libraries in the main.c file. I did this 2 times and am having the same problem with the UserRegister path, I've built and cleaned the project, the cleaned version looks like it should run but then cannot find a valid platform when I try to launch from the Debug hardware option. Seems to be the same path issue for both versions, I was worried the "datatrans_" directory path was causing some problem so built the new "axidata" version. The scope below shows a 1MHz sine wave with 100MHz ADC sample from the Zmod and the lower sawtooth is a DSP accumulator. These seem ok before the AXI stuff happens is why I claim the hardware design is ok. Any ideas on what could be the problem? Thanks, Error: Error while launching program: The platform 'C:/GitHub/WN_Zmod/Vitis_notrig/design_1_wrapper_1/export/design_1_wrapper_1/design_1_wrapper_1.xpfm' used by the system project 'axidata_system' is not valid. The platform 'C:/GitHub/WN_Zmod/Vitis_notrig/design_1_wrapper_1/export/design_1_wrapper_1/design_1_wrapper_1.xpfm' used by the system project 'axidata_system' is not valid. Description Resource Path Location Type Invalid project path: Include path not found (C:\..\GitHub\WN_Zmod\Vitis_notrig\datatrans_\Debug\_sdk\bsp\ps7_cortexa9_0\include). datatrans_ pathentry Path Entry Problem Description Resource Path Location Type Invalid project path: Include path not found (C:\..\GitHub\WN_Zmod\Vitis_notrig\design_1_wrapper_1\export\design_1_wrapper_1\sw\design_1_wrapper_1\standalone_ps7_cortexa9_0\bspinclude\include). axidata pathentry Path Entry Problem
  23. Hi all, I created a script (below) using the Waveforms SDK to use an Analog Discovery 3 to sweep gate and drain voltages over a mosfet and generate IV curves. The plots look right but they seem to be limited by current and aren't showing the full plot. I was wondering if anyone knows why this is? The plots: This is the script I am runing: from WF_SDK import device, scope, wavegen # import instruments import matplotlib.pyplot as plt # needed for plotting import csv #needed for generating CSV files for graphing later """-----------------------------------------------------------------------""" #resistance = float(input("Enter the resistance in Ohms of the resistor in series with the mosfet: ")) TODO user inputs later resistance = 100 gate_voltages = [0, 1, 2, 3, 4, 5] #gate voltages to sweep across # name of csv files filename_currents = "chip_currents.csv" filename_voltages = "chip_voltages.csv" # connect to the device device_data = device.open() #TODO open again to get second device """-----------------------------------""" # writing to csv file for filename in [filename_currents, filename_voltages]: with open(filename, 'w') as csvfile: # opens csv files csvwriter = csv.writer(csvfile) # creating a csv writer object csvwriter.writerow(gate_voltages) # writes header row (gate voltages) # initialize the scope with default settings scope.open(device_data, sampling_frequency=10e5) # generate a 10KHz sine signal with 2V amplitude on channel 1 current_dict = {} volt_dict = {} for VG in gate_voltages: wavegen.generate(device_data, channel=2, function=wavegen.function.dc, offset=VG, frequency=10e2, amplitude=1) #generate dc signal to gate voltage at voltage i wavegen.generate(device_data, channel=1, function=wavegen.function.sine, offset=2.5, frequency=10e2, amplitude=2.5) #generation sine waveform to drain [mosfet_voltages, resistor_voltages] = scope.record2(device_data) # get data with AD3 oscilloscope mosfet_currents = [] for v in resistor_voltages: mosfet_currents.append(v/resistance) # calculate current with ohms law for filename in [filename_currents, filename_voltages]: #outputs currents and voltages to csv with open(filename,'a') as csvfile: writer = csv.writer(csvfile) if "current" in filename: writer.writerow(mosfet_currents) elif "voltage" in filename: writer.writerow(mosfet_voltages) plt.plot(mosfet_voltages, mosfet_currents) #plot curve of mosfet voltages vs. mosfet currrents #plot labels and show plt.xlabel("Voltage (V_DS) [V]") plt.ylabel("Current (I_D) [A]") plt.show() # reset the scope scope.close(device_data) # reset the wavegen wavegen.close(device_data) # close the connection device.close(device_data) In case anyone asks, record2 which I use to record data from the oscilloscope is just a modified scope.record function in order to get data from both channels at the same time. Even if I use record, I still see current limiting graphs but they are also just wrong because of the time offset so I don't think that is the problem. Regardless, the code for record2 in scope.py looks like this: def record2(device_data): """ record an analog signal parameters: - device data - the selected oscilloscope channel (1-2, or 1-4) returns: - a list with the recorded voltages """ # set up the instrument if dwf.FDwfAnalogInConfigure(device_data.handle, ctypes.c_bool(False), ctypes.c_bool(True)) == 0: check_error() # read data to an internal buffer while True: status = ctypes.c_byte() # variable to store buffer status if dwf.FDwfAnalogInStatus(device_data.handle, ctypes.c_bool(True), ctypes.byref(status)) == 0: check_error() # check internal buffer status if status.value == constants.DwfStateDone.value: # exit loop when ready break # copy buffer buffer = (ctypes.c_double * data.buffer_size)() # create an empty buffer buffer2 = (ctypes.c_double * data.buffer_size)() # create an empty buffer if dwf.FDwfAnalogInStatusData(device_data.handle, ctypes.c_int(0), buffer, ctypes.c_int(data.buffer_size)) == 0: check_error() if dwf.FDwfAnalogInStatusData(device_data.handle, ctypes.c_int(1), buffer2, ctypes.c_int(data.buffer_size)) == 0: check_error() # convert into list buffer = [float(element) for element in buffer] buffer2 = [float(element) for element in buffer2] return [buffer, buffer2] Thank you so much!
  24. Hi, I would have to make small changes and "wire" UART0 resource to the PMOD header ( all within ARM-PS domain) . Then I would have to generate the simple fsbl. Then make the SD card bin file to kick off QNX. At this time only one UART is exposed via USB-UART chip.... Thank you. Any help is appreciated.
  25. Are these addresses constant for the Eclypse Z7 platform or do you need to look at this file each time when wanting to get data? I was wondering how these came about, does building an application in Vitis automatically assign the values or properly route existing hardware values? or other magic? Thanks,
  26. The error indicates that your ODBC database is missing. Get the database from the computer that ran DASYLab 13. Once you have it, use the ODBC Data Sources (32-bit) tool (in the Windows Control Panel Administrative Tools) to make it visible to the DASYLab ODBC module. If it's an Excel worksheet, select Excel Files and press Add.
  27. Please take a look at the attached PDFs. RoHS_Statement_AI-EXP32_20240328.pdf RoHS_Statement_USB-2416-4AO_20240328.pdf
  1. Load more activity
×
×
  • Create New...