All Activity

This stream auto-updates     

  1. Past hour
  2. Hi @Arjun, I typically use standalone applications. I would not have a lot of information on this topic. Here and here are xilinx forum threads where they discuss a similar issues. best regards, Jon
  3. Hi zygot: Thanks for your quick reply. Do I need Vivado 2014 or latest Version to develop Zync? My application is simple: we need 70 GPIOs and use CPU to do some simple controls through GPIOs. Is Zedboard suitable for the job? Thanks, Shuguang
  4. Hi @SGY, Welcome to the Digilent Forums! The Zedboard is a collaboration between a few companies. Due to this situation, there are a two places to look for good documentation. Here is the Digilent resource center for the Zedboard. The Avnet site is zedboard.org . The ZYNQ book was written for the Zedboard and the Zybo Zynq boards. The Zedboard OLED demo is written in Verilog. I would also look at the FPGA4FUN and Asic world for more basic non specific board HDL code. The Zedboard has a ZYNQ processor where some of the components like the DDR and USB UART bridge are tied directly to the Arm Core. These components will not be able to be used in the PL with HDL but can be used in the PS using the ZYNQ processor. I have attached an image that should help with visualizing this. best regards, Jon
  5. Today
  6. Hi @eric_holtzclaw, Welcome to the Digilent Forums! In your Vivado_init.tcl I would first try deleting the < in front of the F: and have the full path to the board files. Next, I would erase the "# test" text and have an empty first line of the file. It may help to make put the board files on the same drive that Vivado is on. I have attached my working .tcl file. Some of the older versions of Vivado i have installed requires a different file name(init.tcl). best regards, Jon init.tcl
  7. Have just started playing with the OpenLogger that just arrived. Did a firmware update and calibration via a Windows 10 VM on a macOS machine, and connected the OpenLogger to wifi, all went fine. Is wifi meant to be working? If so, consider the following as a bug report. If not, then what's the ETA looking like? OL firmware version: whatever the latest is (how can I determine this from a running device? the UI should have some method of viewing the connected device's firmware version (e.g. in device manager?)) env: Chrome Version 73.0.3683.103 (Official Build) (64-bit); macOS 10.14.4 (18E226) However when connected to the OpenLogger via wifi I see frequent errors, including - "Error Occurred Starting Or Running Acquisition" when interacting with the timebase and amplitude (i.e. mouse zooming/scrolling) - "Could not set AWG parameters" when interacting with the AWG controls, changing modes There doesn't seem to be anything in the browser dev tools console when these occur. (the console does show a bunch of warnings re. 't' plugin and a CORS policy error just on loading the waveformslive.com page, but there's nothing additional when the acquisition error occurs). Repro: 0. OpenLogger connected to wifi 1. go to http://waveformslive.com/ 2. start streaming 3. interact with the UI - scroll back and forth, zoom in/out 4. in very short order one of the above error messages pops up; at this point the UI becomes unresponsive and a page reload / device reconnect is required Occasionally the device will get itself so confused it won't connect at all (WFL reports "No response received"), and a OL board reset is required. PS: there needs to be some sort of error log mechanism, it's a real pain to try and capture the errors via toasts....
  8. set_param board.repoPaths This is the content of the first line. Vivado_init.tcl
  9. vivado_init.tcl: set_param board.repoPaths load_features core enable_beta_device* What's wrong with this picture? Thanks, >>Eric
  10. Well, I have to retract what I said - @JColvin you were correct - it looks like I had the screw terminal shifted across by one pin, so it was not correctly mounted! Problem solved. Not sure how I missed that the first time!
  11. Hi JColvin, Do I understand that you do not have the time to handle the issue. Please inform me. Yacov
  12. Hi @fangzr, It seems to me that you teacher has asked you to write a kernel driver from scratch (more or less) for a wireless module. Depending on what he expects the driver module to contain, you could either write only the driver for the module it self (RTL8812au for example) or the module and the corresponding dependencies which will make development very hard because you will need to integrate a lot in to the kernel. I have unfortunately no experience with WiFi kernel driver development, but I would take it one step at a time. Starting with understanding kernel drivers and what their role is and then looking over the WiFi kernel interface, you can read about this here, understanding the structure of it and then starting to write my own driver by looking at already existing one (RT3070 for example). I would also recommend to read about the various forms of kernel debugging like KGDB and how to do that or Xilinx has a brief step by step "tutorial" here about using Xilinx SDK for kernel debugging. It's no an easy task, Good Luck. -Ciprian
  13. Sergei

    CPR 290-006

    DC Motor/Gearbox (1:19 Gear Ratio): Custom 12V Motor Designed for Digilent Robot Kits has an encoder. How many counts per revolution (CPR) does it output? https://store.digilentinc.com/motor-gearbox-1-19-gear-ratio-custom-12v-motor-designed-for-digilent-robot-kits/
  14. Yesterday
  15. if you can bring it up once in Vivado HW manager (maybe with the help of an external +5 V supply), you might be able to erase the flash. If not, you may be able to prevent loading the bitstream from flash e.g. by pulling INIT_B low (R32 is on the bottom of the board, its label slightly below the CE mark). See https://www.xilinx.com/support/documentation/user_guides/ug470_7Series_Config.pdf "INIT_B can externally be held Low during power-up to stall the power-on configuration sequence at the end of the initialization process. When a High is detected at the INIT_B input after the initialization process, the FPGA proceeds with the remainder of the configuration sequence dictated by the M[2:0] pin settings.""
  16. @Reggs Glad to hear that you got things working. I also really appreciate your background story; thanks for taking the time to share! ISE 14.7 is the last version of ISE and I believe that you can still download it as Vivado doesn't support the older FPGA families. I still use ISE on a regular basis with WIN7. I do have a laptop with WIN10 but I don't consider WIN10 to be a real OS so I've never tried doing development on it; in fact I will never put any significant development on WIN10 as it ( or the company that makes it ) just isn't reliable enough to risk losing years ( or even a few days ) of work. I have installed Digilent tools and ported a few of my own PC FPGA applications to WIN10 so that I can use the laptop with some dedicated FPGA hardware projects that I need from time to time. So now you know what I know. You can make very useful debugging tools that are often better than what is provided by tool vendors. Keep on Truckin'!
  17. @Ahmed Alfadhel, One other thing to note is your scope was AC coupled in your pictures so you were "seeing" a bipolar waveform of -1.28v to +1.28v. If you had DC coupled, the waveform on the scope would have shifted up and you would have observed the 0v to 2.5v the DA was outputting. To get an actual bipolar output, you need the opamp level shifter/scaler.
  18. well, by default your signal is between 0 V and Vref. The opamp circuit has a gain of 2 (range 0.. 2 VRef) but subtracts a constant VRef (range now -VRef..Vref). It'll just shift the waveform on the scope, and double its AC magnitude.
  19. @Boris_S Since you are using Windows it might be worth your time to try an experiment. xc6lx45 has posted his awesome busbridge3 demo in the Project Vault. I have created an executable that runs on my WIn7 computer using the source code and SharpDevelop compiler. If, as I suspect, the issue is completely a hardware one then you shouldn't be able to run the code and configure your board. I made slight modifications to the source so that I could confirm the configuration step. Read the project postings. Once I resolved some basic C# issues I had no problem running the executable with either of my two boards ( again, I've not had issues programming them ). This project does not require a separate JTAG FPGA configuration application to be running. Download the project and read through the source code just because it's a great tutorial for anyone who hasn't tried creating a PC application that configures and interacts with an FPGA board before. When I first ran into the problem it certainly 'smelled' like a software or driver issue; Vivado Hardware Manager doesn't play nice with other applications, including the Adept tool for Windows which I generally favor for configuring Xilinx FPGA boards. Since I've been able to use my boards with a simple work-around I haven't allocated the time to doing what Digilent should have done and resolved long ago; that is fix this once and for all. The FTDI JTAG and UART should be enumerated as separate endpoints and not interfere with each other. I don't have a USB bus analyzer ( Digilent most certainly has no excuse for not investing in one ) so ferreting out the source of OS disconnects is more work than I want to do. FTDI doesn't provide the level of debugging support that Cypress does for their USB devices so tracking down issues involving a lot of software and hardware elements is non-trivial. Even so, there's simply no excuse for these reoccurring customer complaints not being aggressively addressed and resolved by the vendor.
  20. I have just started hitting this in the past week (Ubuntu 18.10) with my Cmod A7 35T. It was hit and miss before then, now I can only connect perhaps 2% of the time. I have two other boards (Basys3 and Nexus Video) and I am using the same usb cables that work 100% of the time with them. But have tried multiple cables. Here are my observations (for what they are worth) and even a guess at what the problem is. Using a combination of 'sudo lsusb' and looking at the logging from 'hw_server' I can see that the A7 appears as a JTAG Digilent devices, then drop out before being seen as a FTDI driver on the same physical device. It seems to me that the A7 is booting, my machine briefly recognises it as a JTAG device, then (*sadly) the A7 starts it's demo app, which appears to tear down the JTAG port so it can communicate with the host via the UART. At this point the hw_server thinks it has lost the JTAG/USB and so no longer sees the device, so drops it. I see the UART drop then reappear in cycles from this point out. If I have the Vivado UI up (usuallly I avoid). I will see multiple dialogs stacked, as it see's, then loses connection with the device. I think that when I am lucky (the 2% of the time!) I am hitting the hw_server just as the device is being seen for the first time, or in one of these 'cycles'. I really think that it it was not for the demo app trying to use the UART my connection would be stable. So I would love to know how to disable/delete the demo app. I think after that, I would be in good shape. Maybe these observations might help someone with more experience to determine a plan of action.
  21. Hi Zygot, I really wanted to thank you for taking the time to provide such a detailed answer for me, its hugely appreciated ๐Ÿ˜€ I have everything working now and your tool is absolutely incredible. For years I've been relying on a bunch of LED's to try and figure out what was going on in my designs. This tool is like replacing a stick with a machine gun. Its amazing! I was basically over thinking things and had made some changes to the TB which broke it. After your note, I removed my changes, fired up the TB which worked first time of course and then was able to build another TB which better tested my IO. The other thing that had me stumped for a while is that your TB code has another UART in it and I just couldn't figure what that was doing there until I had the preverbal 'light bulb moment' and thought how stupid I was being I'm actually on ISE 14.5 but haven't touched it for a long while because I only have an old Spartan 3A Starter Kit which is several years old and the USB drivers stopped working under Windows 10. Thanks Xilinx for abandoning us all btw ! Anyway, I finally managed to create a Windows 10 driver workaround and was therefore able to go back to one of my old projects which is the conversion of an ancient arcade machine to FPGA - The arcade game Gorf from 1981. One major part of the puzzle was getting a circa 1970's Votrax SC01 speech synthesizer chip interfaced to the FPGA. Previously I'd managed to do this with an Arduino by just simply building a circuit and sending it the correct sequence of bytes. What I really wanted to do however was to use my FPGA to do the same thing. I've been building or should I say tinkering with (for years) a full board reproduction of the machine which consists of several custom chips and a Z80 CPU. The problem was that although I could see what I thought was the right data coming from the machine by feeding it to the LED's on my board, I didn't know if this was just garbage or the Z80 sending the speech synthesizer the correct data. I ran the Debugger at both 115,200 and 9,600 baud with a 50Khz clock and although I've not yet built the circuitry to interface the FPGA to the Votrax, I was able send those bytes I captured with your UART Debugger and simply edit the data in to the correct format and paste it in to my Arduino sketch to test. Low and behold, there was a talking Gorf arcade machine straight out of 1984, truly awesome! Zygot - This is a really great tool. Most of the UARTS I've tried tie the input to the output of your keyboard and echo what's typed straight back to the user. That's all well and good, but when there is no input that sync's up with the output, its quite difficult (at least for me) to just get the output part working. I will be able to use this tool in loads of projects, I just wanted to say thank you once again ๐Ÿ‘
  22. Hi, Currently I'm working on a project in which I want to transfer 1MB data from PS to PL using BRAM using custom IP. I receive correct data at PL whenever I send data less then 32 bits from PS to PL but when I send more bits from PS, I'm unable to receive even a single bit. is there any clock issue as I'm using clock of PS for my custom IP or their is any other problem? Regards, Sami
  23. Last week
  24. @Boris_S I've written about this so much that I've been avoiding responding to posts such as yours any more. I decided to add my 2 cents to your thread because your experience is very similar to mine. For my older 2 CMOD-A35T boards I've never had an issue configuring the CMOD-A35T but do have USB disconnect issues with Vivado Hardware Manager if I try to use the ILA for some time. I have a drawer full of cables and none of them make a difference. I find the board useful if I use an external TTL USB UART attached to 2 IO pins. You obviously can't do that if you can't even configure the FPGA device. Digilent is set on blaming the problem on cables... yet they don't sell the board with any or guarantee operation with any known vendors cable even after a few years of complaints. You are correct that this is the only FPGA board that Digilent ( or anyone else that I know of ) makes with this problem; and Digilent has made a lot of boards with roughly the same programming interface over the past 5 years or so. My personal suspicion is that the particular FTDI device used on this board ( the newer cheaper ones have fewer power and ground pins), pcb layout decisions, and possibly the way that whatever makes their interface proprietary is different for this board is causing the issue but I can't prove that and frankly it's not worth my time to try. Neither you nor I can make Digilent take any particular action with regard to these boards but it is clearly not doing anything positive for their reputation ( I sometimes wonder if they even care about reputation ). Since they are cheap, if I were the vendor, I'd re-spin the board, test the JTAG interface exhaustively, and sell the modules with a mated cable. I suspect that the board needs a different stackup and less component density and a JTAG re-design. Making customers eat the cost of a poor design just isn't good business if you want to engender good will. There have been customers that support Digilent's claim that a different USB cable makes the problems disappear but, as you and I know, not all of us customers can verify this. I happen to think that if a customer can't use a new board with known design problems a more liberal replacement policy should be in order... the vendor can figure out what's going on working with the returns. It's problematic that the same board and cut & paste copies of newer versions are being sold without a fix. Perhaps Digilent doesn't think that the cost merits testing product but for their customers the cost is signifiant, especially when the board is unusable. I know what I do when a vendor has a habit of not treating me well... I use a different vendor. The Terasic DE0 Nano is about the same cost but comes with a USB cable and has more IO pins in a slightly larger form factor but is still quite usable for attaching to a custom board that I design. It doesn't use an Artix device but for what these embeddable modules are good at has served me quite well. I've designed a few dozen boards that have integrated either the 2 CMOD-A735T or the DE0-Nano as a component over the past couple of years. If Digilent were willing to replace your board, given the known issues, then I'd try that for the modest cost of shipping but if not I certainly wouldn't throw more money at a different one hoping for a different outcome. There are a few vendors offering similar modules but I only have experience with the two that I've mentioned. Trenz makes a few similar FPGA boards but I've never used any so I can't offer any opinions about them.
  25. @Boris_S Hi, I didn't even mean you should rig up a test cable. It would, most likely, show when the FTDI chip goes into shutdown, but that's it (it would be more useful if you could compare with a known-good board, but I think that's not the case) Of course, there is always the possibility of broken hardware. If I had to make the board work, I'd try to supply 5 V externally, with e.g. 47ยต tantalum cap in parallel. There is one corner pin for external supply. I suspect it will not reach the FTDI chip directly (D1 in the schematic), but may help to suppress current spikes from the FPGA.
  26. I am tring ti install waveforms on Ubuntu 18.04 on a Lenovo 64bit laptop. I downloaded and installed adept2.19.2 from the digilent website. Then I tried to install waveforms , it stalled with a message "Error dependencies not satisfiable digilent.adept.runtime (=> 2.17.1). It seems like it should install - what gives ?
  27. I am tring ti install waveforms on Ubuntu 18.04 on a Lenovo 64bit laptop. I downloaded and installed adept2.19.2 from the digilent website. Then I tried to install waveforms , it stalled with a message "Error dependencies not satisfiable digilent.adept.runtime (=> 2.17.1). It seems like it should install - what gives ?
  28. eray

    SOUNDS WITH VHDL

    Hello everyone, I am pretty new to VHDL and need some help! My project is air-drumming with gyroscopes. I found a code to connect MPU6050 with BASYS3. However, I need to implement drum sounds (Bass, Hi-Hat and Snare). my question is: How can I obtain "drum" sounds by using VHDL?
  29. Let me offer a suggestion to all newbies, regardless of how smart you are, before trying to do FPGA development. Read all of the user guides for the FPGA device resources that you are likely to be using. These will include the SelectIO, Clocking, CLB , and memory guides at a minimum. [edit] also read the AC switching part of the device data sheet. Like it or not what you are doing in FPGA development is digital design and you need to have a sense of how design decisions affect timing. Read the Vivado user guides for design entry, constraints, simulation, timing closure, and debugging. Understand that even though various Zynq devices are based on certain FPGA families the documentation tends to be unique for these devices. You will be overwhelmed with all of the 'basic' information. Spend a week or so running though all of the basic documentation, spending more time on specific topics each read-through. The object isn't to memorize or understand everything but to get a general feel for how Xilinx presents its information. You can also learn stuff that you will miss in specific IP documentation by using the simulation, but only if you are careful to read all of the simulator messages. This is complicated stuff and the tools, even when they behave as described in the reference material is even more complicated. The purpose of doing this is to get a general feel for how the devices work and specific use limitations and how the tools work. It will take a year or so before you start becoming competent at it if you are a normal human.
  1. Load more activity