• Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by JColvin

  1. Hi @SGY, You could realistically use any version of Vivado to program the Zynq chip on the Zedboard, though some of the projects will expect certain versions of Vivado and Xilinx SDK to be used in order for the projects to work the first time without any modifications. As for the pin requirements, it depends what GPIO functions you need. There are 4 Pmod ports on the Zedboard that are not constrained to any particular usage, but otherwise the Zedboard has 8 switches and 5 buttons as well. However, this only adds up to about 45 GPIO, so the other unassigned GPIO are present on the FMC connector. However, depending on what application you need for your GPIO, you may be hard pressed to find a FMC card that suits your needs. What sort of simple controls are you hoping to do? Thanks, JColvin
  2. Hi @sbellamy, If you are referring to the pins in the schematic, those names tend to be based on what Xilinx dictated the pin names for the Zynq. Otherwise, I would recommend looking at the Avent User Guide that is on the Zedboard Resource Center. Digilent doesn't make the KC705, but it has it's own user guide from Xilinx here that also explains the pin assignments here https://www.xilinx.com/support/documentation/boards_and_kits/kc705/ug810_KC705_Eval_Bd.pdf. Thanks, JColvin
  3. Hi @jamesW, I think that the bit depth of both images would need to be the same in order for it to work correctly (which I believe you said did work correctly at the end of your original post), though I am not certain of this. From what I can tell in the MTDS Library Programmer's Reference Manual (available as part of the documentation included in library download), it says in the BitMap Objects section that "Depending on the coordinates specified and the graphical element being drawn, the clipping can result in all, some, or none of the pixels making up the graphical element to be rendered actually being drawn on the bitmap itself. This is not an error, it is simply a natural consequence of the view that a bitmap is a viewport onto a larger virtual coordinate space." Truthfully, though I'm not certain when these circumstances would occur, though it seems to support the idea that both images would need to be the same bit depth. I also know there are a number of raster operations you can apply in the BitBlt() function as it's own parameter which specifices how the source and destination pixels are combined, but I'm not very familiar with how those all work visually, but the operations are defined on page 12. Thanks, JColvin
  4. JColvin

    Vivado free for Artix-7?

    Hi @TerryS, Unfortunately, the download speeds you are reporting are due to your end (either your internet connection or your computer hardware), not Xilinx's end. Note also as a fair warning (since I believe this is your first time using Vivado) that even simple projects, such as LED blinking project that xc6lx45, will probably take more time than you expect as the Vivado software needs to program and set every transistor inside the FPGA. There is a nice comment summarizing what all the tools need to during synthesis, implementation, and bitstream generation here. But as @xc6lx45, a lot of the material looks more complicated than it actually is, mostly because it's a different language. Thanks, JColvin
  5. Hi @dcc, I'm not certain how you are verifying that the HDL is writing to and then reading back from the SD card in a normal formatting style, but in general FAT32 is a widely used format for SD cards that has existing material for it. I am uncertain why you are using a special tool to write to the SD card though; from what I can tell the tool is Windows compatible, so why not just use the Notepad program which comes with Windows and save a .txt file with the data you are interested in reading to the SD card or just using Windows Explorer (the file manager) to move the file of interest onto the SD card? If you do have a header in your file, you will need to take account for that, though I do not know what you mean by "random file" in this case. Thanks, JColvin
  6. Hi @sgrobler, Our design engineer who designed the OpenLogger did an end-to-end analysis to determine the end number of bits of the OpenLogger. This is what they ended up doing in a summarized fashion: <start> They sampled 3 AAA battery inputs to the SD card at 250 kS/s and set the OpenLogger sample rate to 125 kS/s and then took 4096 samples; they then took the raw data stored on the SD card and converted it to a CSV file and exported the data for processing. Their Agilent scope read the battery pack at 4.61538 V and as they later found from FFT results the OpenLogger read 4.616605445 V, leading to a 0.001226445 V or ~1.2mV difference, which is presuming the Agilent is perfect (which it is not), but it was nice to see that the values worked out so closely. They calculated the RMS value of the full 4096 samples in both the time domain and using Parseval's theorem in the frequency domain as well, both of which came up with the same RMS value of 4616.606689 mV, which is very close to the DC battery voltage of 4616 mV. Because RMS is the same as DC voltage, this gives the previously mentioned DC value of 4.616605445 V. They can then remove the DC component from the total RMS value to find the remaining energy (the total noise, including analog, sampling, and quantization noise) of the OpenLogger from end-to-end. With the input range of +/- 10V input, this produces an RMS noise of 1.5mV. At the ADC input, there is a 3V reference and the analog input front end attenuates the input by a factor of 0.1392, so the 1.5mV noise on the OpenLogger is 0.2088mV at the ADC. With the 16 bits (65536 LSBs) over 3V, 0.0002088V translates to ~4.56 LSBs of noise. The ENOB is a power of 2, so log(4.56)/log(2) results in 2.189 bits, giving us a final ENOB of 16 - 2.189 = ~13.8 bits. Note though that this ENOB of 13.8 bits is based on system noise and not dynamic range, so for non-DC inputs (which will likely be measured at some point) the end number of bits is not easily determined. The datasheet for the ADC used in the OpenLogger (link) shows that the ADC itself gives an ENOB of about 14.5 bits at DC voltage (so the 13.8 bits is within that range), but at high frequencies, this of course rolls off to lower ENOB at higher frequency inputs. Thus, they cannot fully predict what the compound ENOB would be over the dynamic range, but they suspect it all mixes together and is 1 or 1.5 bits lower than the ADC ENOB response. </end> Let me know if you have questions or would like to see the non-abbreviated version of his analysis. Thanks, JColvin
  7. Hi @tjaplayer, When you say WaveForms would not recognize it, do you mean WaveForms does not detect the Analog Discovery 2 at all, or does it just come up as an unknown device? Additionally, are you able to see the Analog Discovery 2 on the Windows Device Manager (presuming) you are Windows? It will appear as "USB Serial Converter" under Universal Serial Bus controllers. Thank you, JColvin
  8. Hi @GMA, Yes, the standard micro USB cables will be sufficient, so long as they are not charging only cables. If you're looking to transfer data at high speeds, you may want to also look into getting a USB certified cable for better results. Those of us at Digilent have used standard cables (such as ones that come with phones to charge and connect to your PC) without issue though. Let me know if you have any other questions. Thanks, JColvin
  9. JColvin

    Genesys 2 DDR Constraints

    Hi @SeanS, Jon and I looked at this a bit further, and it looks like you are using ISE rather than Vivado. Is there a particular reason you are using ISE rather than Xilinx's newer Vivado software? Otherwise, my understanding is that you would need the UCF file loaded with the correct information (as per the legacy ISE material we have for the Genesys and MIG tutorial here). However, the Genesys 2 was developed and released a few years after the last formal release of ISE, so we do not have a UCF file for the Genesys 2 available (nor do we have the appropriate details in the .xdc file thanks to the existence of the board files for Vivado. Thanks, JColvin
  10. Hi @doconnor, I emailed our sales team about this; haven't heard back from them yet myself, but I am confident they will get back to you sometime today or tomorrow. Thanks, JColvin
  11. JColvin

    booting from sd card

    Hi @Michael P, I'm still a little confused. Does Vivado give an error when you are attempting to create the bitstream file? In one of your earlier posts you mentioned that you were able to program the FPGA with the bitstream file stored on the SD card and Jon gave some instructions on how to program the SD rather than QSPI for SDK projects, so I'm not certain what you are running into now. How much space does Vivado claim to this project of yours requires? Thank you, JColvin
  12. Hi @flying, I believe you can implement it (or at least for the Pcam 5C demo, not necessarily the PetaLinux project, as per these two threads here and here). My understanding is that the Z7-10 simply didn't have enough space to also contain the debug portion of the CSI-2 IP core. Otherwise, I believe the Petalinux release uses V4L2 drivers to receive the Pcam inputs. Let me know if you have any questions about this. Thank you, JColvin
  13. Hi @doconnor, Have you received a response yet? The team that manages that email is on a different timezone so they may have been out for the weekend; otherwise, there is no link to go to. The forum is otherwise the appropriate location to ask questions as the Digilent engineers (including the creator of the WaveForms software who responded to you) are the staff that respond to questions. Thanks, JColvin
  14. Hi @LazerBoi64, I'm not certain on the hardware/software (in)compatibility, but I do seem to recall that it should be okay with regards to LINX 3.0 working on both the Raspberry Pi 3 and 3+. The older versions of Raspian are available for download from this page here: http://downloads.raspberrypi.org/raspbian/images/. Based on the dates from other threads, I would recommend going for either the one late 2016 (Nov 29 or Sept 28), or perhaps the early 2017 one. With that, you should be able to install and use it through the Instructables tutorial you linked or through the tutorial here: https://www.labviewmakerhub.com/doku.php?id=learn:tutorials:libraries:linx:3-0. Let me know how this works and if you have any questions about this. Thank you, JColvin
  15. JColvin

    Sample mode

    Hi @Dejdys, I apologize for the delay. I'm not certain what the function would be for that. @attila, do you happen to know the equivalent function name that they can call it within the LabVIEW VI's? Thank you, JColvin
  16. Hi @davittarius, I apologize for the delay; I have sent you a PM about this. Thanks, JColvin
  17. Hi @Ashish Kashinath, I apologize for the delay. The folks over on the NetFPGA mailing list (link if you are not already signed up) which have more experience specifically running the acceptance tests. However, based on what you have described, it seems like the acceptance tests projects are not loaded on your computer if the script does not find the bitstream nor the acceptance test project. Vivado getting stuck during the synthesis and implementation procedure would not be a board issue as the board is not directly involved at this point of the procedure. One potential solution that you could try that has resolved this sort of issue before is using a different, known working USB cable to connect to the NetFPGA SUME and a different USB port on the host computer, as a faulty USB cable can lead to the Vivado Hardware Manager not detecting the attached FPGA. Thank you, JColvin
  18. Hi @LazerBoi64, I responded to your other thread here. Thanks, JColvin
  19. Hi @LazerBoi64, I asked another one of our engineers about this and they informed me that the LabVIEW MakerHub LINX was not ever tested with the newer Raspberry PI and BBB OS's, so we do not know if anything has changed has changed under the hood which breaks this functionality. There are no plans to update or test the LINX deployment on these newer versions; I believe the last versions that were tested were late 2016 versions. I'm sorry I could not be of more help. Thanks, JColvin
  20. Hi @TaiShengY, Are you looking to measure a periodic waveform or a less standard/non-period waveform? If you are looking to measure a periodic waveforms, the OpenScope MZ can trigger the oscilloscope channels and capture a buffers worth of data at 6.25 MS/s. However, the delay between one external trigger (whether event driven or manually done or otherwise) is very much dependent on other factors outside of the OpenScope MZ's control, such as the network speed and traffic, and how cleanly WaveFormsLive processes and displays the data. The drawback with these things is that any delays and processes are variable in their length of time, so not only will there be a gap in the data, you won't know how long the gap will be. But anytime you are collecting data, you will collect the data at full speed and fill up the buffer with it. If you are instead looking at a less standard set of data, I would actually consider the OpenLogger which has been specifically designed for logging. Rather than external triggers and a lot of handshaking between the host board and the receiving end (mobile phone, pc, etc), each set of data is collected by a clock and placed into a buffer that is then simultaneously sent to WaveFormsLive or SD card. Let me know if you have any questions about this and let me know a bit more of what you are looking to measure. Thank you, JColvin
  21. Hi @Guillermo Lugo, I would recommend checking out this thread on our Forum which uses the Pmod KYPD to display information on the 7 segment display on the Basys 3. The Pmod CLP Resource Center has some HDL demos that display data on a Pmod CLP using a Nexys 3. You could use that demo as a reference to see how data is placed on the Pmod CLP and then use the corresponding keypad presses to correlate to specific characters to display on Pmod CLP. Let me know if you have any questions about this. Thanks, JColvin
  22. Hi @Raghunathan, I have responded to your question on the thread you referenced. Thanks, JColvin
  23. Hi @Raghunathan, Do you have the OpenLogger or the OpenScope MZ? The latest OpenLogger Firmware is 0.1719.0; the 1.301 firmware you referred to is only for the OpenScope MZ and will not work on the OpenLogger MZ. What version of the Digilent Agent are you using? When you right click on the Digilent Agent in the system tray (the Digilent Agent icon in the default bottom right hand corner of the Windows 10 desktop display), does it say the "Digilent OpenLogger MZ" is connected? You can power the board just through USB. Offline support is possible by just using the copy of WaveFormsLive that is part of the Digilent Agent and is described in the related tutorial on the OpenLogger Resource Center. However, it is recommended to use WaveFormsLive.com as that will be the most up to date. Thank you, JColvin
  24. Hi @bhclowers, If you are looking to generate a signal with Pynq with a python script, I would recommend asking on pynq.io as they are the ones that created all of the material for the Pynq board. Although, if you had questions on how the Analog Discovery generates it's waveforms, I would recommend asking on the Scopes and Instruments section of the forum (which I believe you've done before) where attila will be able to see and respond to your question. I know quite a few versions of WaveForms have come out since you originally posted there. Thanks, JColvin
  25. Hi @Peggy, I spoke with some of the firmware folks for WFL and OpenLogger and learned that they haven't yet implemented the parsing of the header into the Digilent agent yet. I did receive a picture that showed the structure of the header file, which I have attached below. Thanks, JColvin