zygot

Members
  • Content Count

    1474
  • Joined

  • Last visited

  • Days Won

    67

Everything posted by zygot

  1. @JonK, Perhaps I can clear up some confusion about the tools. Before Vitas there was Vivado and a myriad of software development tools. Vitas has corralled all ( well most all ) of those tools and made Vivado subordinate to it.. so you can start off in Vitas, create a hardware bitstream, and then, if you have a soft processor like MicroBlaze or a hard ARM core coomplex like ZYNQ, you can proceed with the software development. Digilent is committed to using a MicroBlaze in almost all of its demo designs. But you don't have to, indeed I'd suggest you shouldn't have a soft processor in most of your designs. You can do a lot just with VHDL or Verilog. I never use soft processors and rarely need a ZYNQ. All of this is to say that you don't need Vitas to develop FPGA projects on a Basys 3. Learn to use an HDL competently and then decide if you need a processor in you designs. I almost never do. The software development is a complication and distraction for learning how to do logic design in an FPGA. It should not be a crutch. Beginners should expect a fair bit of frustration learning how to do FPGA development... but not get expect to get stuck just trying to install the tools.
  2. Here's an idea for a different approach to your problem. In the Xilinx Vivado download site look for an earlier version of Vivado supported by Win10. A couple of years ago the download size was under 8 GB. The smallest Artix devices didn't exist when Vivado first came out but the Basys 3 has been around for a while now. There's a slim possibility that an earlier version of Vivado could have issues on an up to date WIN10 box. I've spent the last 2 days trying to install Vivado onto a Ubuntu 20.04 machine without success... never got to starting a download. I did just install the latest Quartus 20.1 Lite which supports Cyclone V and Cyclone IV. There are some nice cheap development boards from Terasic that you can work with using free tools. Personally, I've found that the De0 Nano is very nice for prototyping and would make for a great 'starter' board..
  3. @JColvin, OK, after looking for a while I did see the selection carefully hidden from view. As I remember it this was at the top, where a new viewer would see it immediately.
  4. That wasn't 2 weeks of downloading... it was 2 weeks of starting a download, going away for 10 hours, coming back to find that the download session was terminated after 5-10 GB of data was transferred, starting over... repeat, repeat, repeat... (2 weeks later...) success! I don't know if it's my ISP breaking the connection or Xilinx servers.
  5. That's how I remember it being in the past. Perhaps this is browser related. I use Firefox. I certainly don't see any options for sorting post replies as I look at my post above.
  6. I don't have broadband and trying to download 60 GB at 3 Mbsp DSL rates is a ridiculous in frustration. It took me 2 weeks to install Vivado 2019.2. I was given a "special" download connection by Xilinx and that never worked at all. Using the Xilinx Unified installer has never worked as my connection to xilinx always gets broken before completion. I suggest that you carefully read all of the latest notices on the Xilinx download page. I believe that the latest gargantuan monster has to be installed into an empty folder. For the Vivado 2019.2 I had to use the options page to turn off file optimization. Others have commented that they couldn't use their browser, etc, etc. Keep trying and do a lot of googling... [edit] The free version of Quartus is a comparably reasonable 6.6 GB. So there are alternatives for learning how to do FPGA development if Xilinx is tone deaf. Perhaps more people should submit posts to the Xilinx user's forum asking Xilinx could help Intel provide support for Xilins devices in Quartus. Xilinx knows that their tool install requirements are excessive and in many cases unbearable but haven't tied this to the bottom line for some reason.
  7. So write one. If you don't know how to write a testbench you can look through the code in this project: https://forum.digilentinc.com/topic/20479-inter-board-data-transfer-project/ It helps if you have some idea of how the code you want to test works. [edit] Warning! Writing good testbench code is harder than writing the code that you want to test. But everyone has to start somewhere.
  8. What you propose is to emulate an open collector or open drain driver on your Arduino. A true open drain driver might work out ok. I doubt that trying to emulate one in software would be an acceptable alternative. What you should do is create a breadboard or use a PMOD that either uses a logic level translator or has 5V logic open collector gates between your Arduino and the FPGA pins. Can you get away with doing things the wrong way? I don't have an answer to that question because doing things the right way isn't much bother. It does remind me of a quote from one of the old Dirty Harry movies. So, if you're feeling lucky, what do you think happens before and after your Arduino application is executing with your boards connected together?
  9. Hi, can anyone tell me what's happened to this board?
  10. I don't know what your expectations for the Eclypse-Z7 are but you will do well to browse through all of the content posted about the board. Just a helpful suggestion. The sales pitch: "This system allows users to plug in their Zmods of choice and get started prototyping new measurement, instrumentation and control systems without directly interfacing with the FPGA until desired. With this system, embedded Linux developers can leverage the power of FPGA without possessing hardware expertise. Currently, C and C++ are supported, with plans to add support for other programming languages in the future." is still a far off envisioning of the current support. The board is not an Analog Discovery with better capabilities. Still, it's usable for some applications if you can do your own HDL design work. Expect to do some heavy reading.
  11. Not a lot of people realize that the Spartan 3 family had IO features not universally available to Series 7 devices. If I were doing a Spartan 3 design then this would have a quite different implementation.
  12. As submitted it does almost 17 MB/s and it should work with any boards having differential PMODs. This is with 8.5" flying leads. I modified one line of code that increased this to 20 MB/s but am hoping that someone else finds it before the next, corrected, version is published. The design is specifically for differential pcb traces and a board that only has 3.3V IO banks rendering LVDS inappropriate.For ideas on using TMDS_33 see the Differential PMOD Challenge project in the Project Vault area. TMDS_33 didn't meet the criteria set for this project. You can certainly change the serializer/deserializer components to shift one bit at a time and output a 1-bit signal. There are a number of possible alternate design approaches. No doubt that there's a better one that I didn't pursue yet. I changed the clocking of the published code to increase the maximum bit rate from 25 Mb/s per channel to 40 Mb/s and that also ran without errors on my setup at about 31 MB/s. I suspect that the design can work at even higher rates. For a real interface I'd probably add series termination on the driver end to reduce overshoot. But, that is out of scope for this project. The design could work for the CMODs as their IO doesn't have 200 ohm series resistors. But I'd likely use a different design for that board. This project is more of a conceptual exercise than working implementation; though it does work on hardware and requires one to consider the same things as a real implementation would. The design would work with standard PMODs though at lower data rates, but then most people already are using those. The basic purpose of the design is to allow boards with the almost useless differential PMODs but without a high speed PC interface, like the Arty-A7 to stream data at a moderate rate to a PC. That end of the project will be forthcoming, though possibly as a different project. One advantage over other serial interfaces like USB is the low latency and ow overhead. It's also faster than 10/100 Ethernet by a wide margin and significantly less complex. Even if you packetize the data you can do it more efficiently with this design than Ethernet. Obviously, it isn't as flexible or a replacement for Ethernet. Standard serial interfaces also don't support an arbitrary word size like this design does. Like all of my Project Vault submissions this one is more about encouraging learning than solving specific problems. Like the Differential PMOD Challenge, I'm hoping for others to show of their design chops with a better concept. A bit of competition is always fun and encourages better thinking. [edit] At 31 MB/s the interface is in the same ballpark as realistic 1GbE, which has a peak data rate of 125 M bytes/s. Once you add overhead and typical issues 1GbE falls to a more attainable 30-40 MB/s.
  13. It sounds to me that you already understand the basic concepts of the NCO and DDS. Perhaps it's the HDL standing in your way. And additional thought or two. At least on some level you understand the limitation of using look up tables to produce waveforms. You can change the tone out frequency by using fewer samples of the waveform buffer, or use a pre-scaler to change the lookup rate at which you read samples or change the clock rate at which you run your logic. All of these approaches limit the selection of Fout that you can choose unless your waveform table is huge, perhaps in DDR memory. But you can always get exactly n samples per cycle for those limited tone frequencies. Sometimes this isn't reasonable so you have to figure out another approach. The DDS or NCO approach allows for an almost arbitrary selection of Fout but might introduce phase errors and jitter because of how the numbers work out. It's is possible to compensate for such issues at a cost of added complexity.Again, it all depends on the applicatio requirements. Everything in engineering involves trade-offs, but starts with good specifications. An NCO approach might be fine or not. It'd hard to go wrong with methods that calculate sin(x) on the fly if you're dealing with low frequencies. Very often a hybrid approach is the best option.
  14. Sorry, but the demo only runs on the Eclypse-Z7 with a DAC ZMOD. I haven't published my code for the NCO because I'd rather encourage people to figure it out on their own instead of relying on IP that they didn't take the time to understand... also I don't want to deprive anyone of the satisfaction of developing something on their own with perhaps a few hints. Never underestimate the power of pride in accomplishment. You can find alternate but similar code for a DDS from other contributors to this site. Still, you can download the project and read the README.txt file for some hints.
  15. A few more thoughts. The sine table that my NCO uses is 1/4 cycle 2048 samples for 8192 19-bit samples per cycle. This might not be sufficient for really fast or really slow tones... one more time, it depends on the application requirements. You can always put a filter between the NCO and the application if needed. For really low frequency high fidelity tones I'd probably calculate points on the fly using polynomial expansion.
  16. I don't tend to use the Xilinx IP as it uses more resources than I want to use and I prefer being able to do what I want as opposed to what the IP is set for. I'm also happier with the results and ease of modification and portability Your idea of using a phase accumulator as a pointer into a sine table is how the NCO in the project that I referenced earlier works. With a 32-bit phase accumulator clocked at 100 MHz I can span .25Hz - 2.5 MHz Fout just by changing how fast I increment the phase accumulator. I use 1 BRAM to get 18 bits of sine data precision plus sign for sine and cosine simultaneously. It takes a whole lot less resources than anything that Xilinx or Intel will give you with their DDS IP. But since I don't use someone else's IP I 've got no answer for your particular question. You certainly don't want to play with slow clocking rates. My advise is ditch the IP and figure out how to row your own boat.
  17. Can I interest you in a polynomial expansion using Taylor series? If depends on your application. Back to your original thought. One idea, if you want to use waveform tables is to borrow from old PC video strategies and use ping-pong buffers. You read from one while alculating and writing to the other. It can be like, or at least good enough like, calculating all of the values concurrently. Depends on the timing. I think that this could go on for a while...
  18. There are a number of ways to create a sine wave. It's important to know how you are going to use it, and if it's fixed or has to change, and other things like frequency, precision, how much phase noise can be tolerated etc. Then you are in a better position to select a method. Implementing algorithms in a DSP like the DSP56002 can be informative or lead you in the wrong direction for logic implementation. You will need to take responsibility for a lot of features that the DSP does behind the assembly code as well as understand fixed point binary numbers. The phase accumulator approach is pretty easy and flexible where appropriate. Have you looked at this ? https://forum.digilentinc.com/topic/20299-fun-with-phasors/
  19. It used to be that you could choose to read posts to a question in chronological order and understand how the discussion evolved. Context, after all, is vital to understanding content. Frankly, I've always found it to be disturbing that a third party could alter the context and misrepresent the content by shuffling the order of how posts are displayed to skew the messaging. I understand that it's your website but in a real sense it's not your forum; it's the user's forum. If you can't do the right thing and simply display comments in chronological order, then at least go back to allowing the user the courtesy of having the option to do so and follow the thread of discussion. You can always impose some sort of added bias in the form of stars or check-marks to sway viewers opinions of what they are reading toward what you prefer... if you must. The current presentation is untenable in my opinion, and reflects poorly on your company. It certainly doesn't encourage participation to those posting answers only to find that the context, and hence substance, of the posts have been altered.
  20. If you can wait a few months to make a purchase and can get an academic discount that's obviously the cheaper way to go. Even at $1K per pop the Genesys2 is a fantastic value and heavily subsidized by Xilinx. If you doubt this then, while you're at the distributor's site do a search for the XC7K325TFFG900C-2 part and compare the price. Note the lead times. If you think that you're at the wrong distributor then try Avnet or one of the bigger distributors. It's unfortunate but Xilinx seems to have moved on to other newer families for scheduling fab orders. I don't know of anything close to the Genesys2 on the market at the normal retail level. Kintex and UltraScale Kintex are great niches in the FPGA marketplace... if only small developers could buy them and make a profit selling Kintex based products... I wonder if Xilinx regrets going fabless, yet...
  21. Didn't consider this but even more reason to send an email to @JColvinor someone else... gee I think that I just did it for you.
  22. I should also point out that the Genesys2 has a very nice HPC FMC connector so you can add a USB 3.0 interface if you need to transfer large amounts of data between your FPGA platform and a PC. More information to process. You won't find an FPGA board with more FPGA resources than the Genesys2 for anything even close to the 'poor slob highest price' point.
  23. About PCIe FPGA boards. I should point out that PCIe boards are detected during BIOS boot so you can't re-configure the entire FPGA from a PC application and keep running... you have to reconfigure and reboot. For a price you can do partial reconfiguration on the fly though and have a true application accelerator. It's just something to know about before jumping on board.